mendoi-apps

Eine KI-Artikelwebsite so erklärt, dass sie sogar ein Grundschulkind versteht: von null bis 12 Sprachen, interne Links, Hubs und eine selbstreparierende Content-Fabrik in 10 Schritten

Bei „Artikelwebsite mit KI bauen“ denken viele zuerst:

Autor: Mendoi-chan

TL;DR

Bei „Artikelwebsite mit KI bauen“ denken viele zuerst:

KI schreibt 100 Artikel, ich lade sie hoch, fertig.

Nein.

Das ist ungefähr so, als würde man einen Kopierer kaufen und danach verkünden, man habe eine Bibliothek gebaut.

Eine echte KI-Content-Website muss auch dann verständlich bleiben, wenn sie wächst. Leser dürfen sich nicht verirren. Alte Übersetzungen dürfen sich nicht als aktuelle Version ausgeben. Die 12 Sprachen dürfen nicht falsch miteinander verbunden werden. Links dürfen nicht kaputtgehen. Zwei Automationen dürfen sich nicht gegenseitig überschreiben. Und wenn etwas schiefgeht, muss das System den Fehler erkennen und sicher zurück in einen korrekten Zustand kommen.

KI ist deshalb nicht nur eine „Schreibmaschine“. Sie ist ein Team aus Autoren, Redakteuren, Prüfern, Bibliothekaren, Straßenbauern und Wartungstechnikern.

Das Gesamtsystem lässt sich in zehn Schritten erklären:

  1. Festlegen, wozu die Website da ist.
  2. Grundstück und Lager für die Inhalte vorbereiten.
  3. Jedem Artikel eine stabile Identität und einen Versions-Fingerabdruck geben.
  4. Zuerst einen guten Artikel in einer Quellsprache erstellen.
  5. Vor der Übersetzung QA durchführen.
  6. Auf 12 Sprachen erweitern, ohne Fehler zu vervielfältigen.
  7. Interne Links und Hubs als Straßen und Informationsschalter bauen.
  8. Die Fabrik nach Zustand steuern, nicht nur nach Uhrzeit.
  9. Erst „veröffentlicht“ sagen, wenn die echte Produktionsseite geprüft wurde.
  10. Die Website ständig mit einem 100-Punkte-Ideal vergleichen und Abweichungen reparieren.

Wenn man nur sagt „KI, mach mir eine schöne Website“, kann der KI-Kleingartenverein drei identische Häuser und sechs Straßen ins Nirgendwo bauen.

Entscheidend ist nicht die intelligentere KI.

Entscheidend ist das sicherere System.

Einfaches Modell: Website = Bibliothek + Straßennetz + Fabrik

  • Artikel = Buch
  • Website = Bibliothek
  • Kategorie = Bücherregal
  • Hub-Artikel = Informationsschalter
  • Interner Link = Straße
  • URL = Adresse
  • Artikel-ID = stabile Registrierungsnummer
  • SHA / Hash = Fingerabdruck einer Version
  • GitHub = Lager für Dateien und Historie
  • QA = Lehrer mit rotem Korrekturstift
  • Deploy = die Bibliothek tatsächlich öffnen
  • Monitoring-Routine = Nachtwache
  • CAS / bedingtes Update = „nur ersetzen, wenn es noch Ausgabe 3 ist“
  • Stage-Token = Stempel „genau diese Version hat diese Stufe bestanden“

Mit diesem Bild werden viele technische Begriffe zu normalen Verkehrsregeln.

1. Festlegen, welches Problem die Website löst

1-1. Artikelzahl nicht zum Ziel machen

Schlechtes Ziel:

100 Artikel pro Tag veröffentlichen.

Wenn 30 dasselbe beantworten, Links kaputt sind und Übersetzungen alt, ist kein Wissen entstanden.

Es wurden 100 Müllsäcke mit hoher Geschwindigkeit produziert.

Ein besseres Ziel beschreibt, was Leser können:

  • schnell eine Antwort finden
  • wissen, wo Anfänger anfangen sollen
  • natürlich zu tieferen Erklärungen weitergehen
  • Beziehungen zwischen Artikeln verstehen
  • dieselbe Bedeutung in ihrer eigenen Sprache erreichen

1-2. Regeln definieren, die KI niemals brechen darf

Zum Beispiel:

  • keine persönlichen Daten veröffentlichen
  • Zahlen oder Daten nicht heimlich ändern
  • keine Quellen erfinden
  • alte Übersetzungen nicht als current behandeln
  • keine kaputten URLs veröffentlichen
  • japanische Leser nicht als Content-Fallback auf irrelevante englische Artikel schicken
  • zwei Worker nicht still dasselbe Ergebnis überschreiben lassen
  • „KI sagt fertig“ nicht als Beweis akzeptieren

Das sind die Schutzgeländer der Fabrik.

1-3. Den 100-Punkte-Idealzustand aufschreiben

Wenn das Ideal explizit ist, kann das System fragen:

Wie viele Punkte haben wir jetzt?
Wo gehen Punkte verloren?
Was lässt sich sicher reparieren?
Wie hoch ist die Punktzahl danach?

Das ist die Grundschleife von QC.

2. Grundstück und Lager vorbereiten

2-1. Minimale Ausstattung

Für den Start reichen:

  • Domain
  • GitHub
  • Web-Framework
  • Hosting
  • Analytics

Astro, Next.js, Eleventy oder andere Frameworks funktionieren. Wichtiger als der Markenname ist:

Content-Daten und Darstellungsprogramm trennen.

2-2. Quelle und generierte Ergebnisse trennen

Nicht jeder automatische Prozess sollte direkt die Quelldatei umschreiben.

Besser getrennt halten:

  • Quellartikel
  • redigierte Version
  • Übersetzungen
  • interne Link-Overlays
  • QA-Nachweise
  • Veröffentlichungsstatus

In einer Küche kippen auch nicht alle Köche ihre Soße direkt auf das rohe Fleisch im Kühlschrank.

Vorbereitung, Kochen, Anrichten und Kontrolle sind getrennte Schritte.

2-3. Git-Historie als Zeitmaschine verwenden

Automationen sollten:

  • kleine, erklärbare Änderungen machen
  • den Grund dokumentieren
  • force push vermeiden
  • bei langen Batches Checkpoints speichern

3. Jedem Artikel stabile Identität und Fingerabdruck geben

3-1. Nicht nur die URL als Identität verwenden

URL und Titel können sich ändern.

Ein logischer Artikel bekommt eine stabile ID:

articleFamilyId = article_000123

Japanische, englische und koreanische Version desselben Inhalts teilen diese family ID.

3-2. Locale als eigene Dimension behandeln

article_000123 + ja
article_000123 + en
article_000123 + ko

Damit kann das System ausdrücken:

  • Englisch stale
  • Koreanisch fehlt
  • Japanisch wurde heute geändert
  • Französisch ist noch current

3-3. Hash ist der Fingerabdruck

Ändert sich der Inhalt, ändert sich der Hash.

Damit lässt sich fragen:

Aus welcher japanischen Version wurde diese englische Übersetzung erstellt?

Wenn Japanisch geändert wurde, Englisch aber noch auf den alten Fingerabdruck zeigt, ist Englisch stale.

Keine Diskussion mit der KI nötig.

Der Nachweis entscheidet.

3-4. Explizite Zustände speichern

Beispiele:

  • Draft
  • Source-QA bestanden
  • Übersetzung läuft
  • Übersetzungs-QA bestanden
  • Navigation validiert
  • Veröffentlichung möglich
  • veröffentlicht
  • stale

Die State Machine ist das Rückgrat der Automatisierung.

4. Zuerst einen starken Quellartikel erstellen

4-1. Schlechte Quelle nicht übersetzen

Eine schlechte Quelle in 11 weitere Sprachen zu übersetzen heißt, den Bug zu internationalisieren.

Glückwunsch: Der Fehler hat jetzt weltweiten Vertrieb.

Zuerst eine Quellsprache fertigstellen.

4-2. Mindeststandard eines guten Artikels

  • Titel zeigt klar das Problem
  • Einstieg beantwortet die Leserfrage
  • Struktur ist nur anhand der Überschriften verständlich
  • schwierige Begriffe werden erklärt
  • konkrete Beispiele
  • Zahlen, Daten, Namen und Unsicherheit bleiben erhalten
  • Fakten und Meinungen getrennt
  • Quellen, wenn nötig
  • keine personenbezogenen Daten
  • wenig unnötige Wiederholung
  • weniger generische KI-Template-Sprache

4-3. Humor soll das Verständnis stärken

Beispiel:

Eine kaputte Quelle in 11 Sprachen zu übersetzen ist wie ein schiefes Haus elfmal zu klonen.

Die Regel bleibt hängen.

Unpassende Witze sind Straßenkunst mitten in der Baustelle.

5. QA vor der Übersetzung

5-1. „Generiert“ bedeutet nicht „fertig“

KI-Ausgabe ist abgegebene Hausaufgabe, noch keine bestandene Note.

Mindestens prüfen:

  • Titel und Body passen
  • Fakten unverändert
  • Daten, Preise und Einheiten korrekt
  • URLs existieren
  • Zitate und Quellen intakt
  • Markdown/HTML gültig
  • Überschriftenhierarchie sinnvoll
  • persönliche Daten entfernt
  • keine gefährliche Sicherheit hinzugefügt
  • keine massive Überschneidung mit bestehender Suchintention

5-2. Beweise speichern, nicht nur eine grüne Lampe

Speichern:

  • Artikel-ID
  • Source-Hash
  • Output-Hash
  • QA-Ergebnis
  • was geändert wurde
  • welche Regel den Status begründet

„Hausaufgaben gemacht?“
„Ja.“

Schwacher Beweis.

„Zeig das Heft.“

Viel besser.

5-3. Ein Fehler darf nicht die ganze Fabrik stoppen

Wenn 1 von 100 Artikeln nicht sicher verarbeitet werden kann:

  • diesen Artikel defer
  • Grund speichern
  • mit anderem eligible Item weitermachen

Eine lockere Schraube erfordert keinen Stromausfall in der ganzen Stadt.

6. Auf 12 Sprachen erweitern

6-1. Locale-Liste fest definieren

Zum Beispiel:

ja / en / ko / zh-Hans / zh-Hant / es / pt-BR / id / th / vi / fr / de

Eine feste Liste vereinfacht URLs, QA, hreflang, Sitemap und Links.

6-2. Pro Sprache eigene URL

/ja/articles/...
/en/articles/...
/ko/articles/...

Mit hreflang wird markiert, dass es Sprachvarianten desselben Artikels sind.

6-3. Aktuelle Übersetzungen wiederverwenden

  • current → wiederverwenden
  • stale → nur dieses Locale aktualisieren
  • missing → neu erstellen

Alles bei jedem Lauf neu zu übersetzen kostet mehr und schafft mehr Bug-Flächen.

6-4. Japanische Satzform nicht kopieren

Übersetzung ist kein Worttausch.

Je Sprache anpassen:

  • Satzlänge
  • Überschriften
  • Übergänge
  • Witze
  • Linktext
  • Erklärungsreihenfolge

Bedeutung behalten, Form natürlich machen.

6-5. QA pro Artikel × Locale

Englisch bestanden sagt nichts über Thai aus.

Ein lokaler Fehler sollte nur dieses Locale verzögern können.

7. Straßen mit internen Links und Hubs bauen

7-1. Keine Links für eine Quote einfügen

Guter Anchor erklärt das Ziel.

Gut:

Anfänger können zuerst den Leitfaden zur Wahl der Retinol-Konzentration lesen.

Schlecht:

Hier klicken.

Ein Straßenschild mit „da lang“ ist wenig hilfreich.

7-2. Linktypen trennen

Mindestens:

  1. Hub structural — Informationsschalter → Detailartikel
  2. Body contextual — natürliche Referenz im Text
  3. Related recommendation — nächster Leseschritt
  4. Language alternate — gleicher Artikel, andere Sprache
  5. Breadcrumb — zurück durch die Hierarchie

Wenn alles nur „Link“ heißt, kollidieren die Regeln irgendwann.

7-3. Content-Navigation in derselben Sprache halten

Fehlt das japanische Ziel, nicht automatisch auf Englisch fallbacken.

Sprache wechseln und Thema wechseln sind zwei unterschiedliche Aktionen.

7-4. Hub ist kein URL-Lager

Ein guter Hub erklärt:

  • was das Thema abdeckt
  • für wen er ist
  • wo Anfänger anfangen
  • wichtige Unterthemen
  • welcher Detailartikel zu welcher Frage passt

Zwanzig nackte URLs sind ein Informationsschalter, dessen Mitarbeiter nach Hause gegangen ist und nur eine Karte auf dem Stuhl gelassen hat.

7-5. Vor neuem Hub einen bestehenden breiten Artikel prüfen

Sonst entstehen:

  • Kompletter Guide
  • Ultimativer Guide
  • Gesamtguide
  • Alles-was-du-wissen-musst-Guide

Die um dieselbe Intention kämpfen.

Das ist keine Informationsarchitektur.

Das ist SEO Battle Royale.

7-6. Maschinenkandidaten + semantische Prüfung

Kandidaten können entstehen aus:

  • Textbedeutung
  • Linkgraph
  • User Journeys
  • Suchintention
  • Duplicate-Risiko

Vor der Anwendung muss aber erklärbar sein, warum die Beziehung nützlich ist.

8. Fabrik nach Zustand steuern, nicht nur nach Uhrzeit

8-1. Schedule ist nur der Wecker

Man kann planen:

  • Minute 02: Hub
  • 07: Source
  • 27: Übersetzung
  • 37: interne Links
  • 58: Veröffentlichung

Aber Minute 27 beweist nicht, dass die Source fertig ist.

Die Uhr weckt den Worker.

Der State gibt die Erlaubnis.

8-2. Upstream-Stempel prüfen

Vor Übersetzung:

  • source current
  • QA current
  • ID korrekt
  • Hash korrekt

Vor Linking:

  • locale current
  • route current
  • quality current

Vor Veröffentlichung kommen SEO und Validation dazu.

8-3. Content-basierte Stage Tokens verwenden

done=true ist zu schwach.

Ein starker Token kann enthalten:

article ID
+ locale
+ content hash
+ route
+ rule version
+ upstream token

Ändert sich Upstream, wird der alte Downstream-Token stale.

8-4. CAS / bedingte Updates verwenden

Zwei KIs lesen Version 3.

A schreibt Version 4.

B versucht später, ein Ergebnis auf Basis von Version 3 zu schreiben.

Ohne Schutz löscht B die Arbeit von A.

Sichere Regel:

nur schreiben, wenn die Ressource noch die Version ist, die ich gelesen habe.

Sonst neu lesen oder defer.

8-5. Checkpoints speichern

Wenn ein Batch 50 Ziele hat, nach einigen Erfolgen speichern.

Stoppt er bei 20, beim nächsten Mal mit 21 weitermachen.

Videospiele haben das vor Jahrzehnten gelöst: speichern.

9. GitHub-Commit ist nicht gleich Veröffentlichung

9-1. Veröffentlichung ist eine Kette

content complete
↓
translations current
↓
navigation validated
↓
validation passed
↓
publication allowed
↓
deploy
↓
production HTML checked
↓
production verified

9-2. Unfertige Locales nicht erzwingen

Ein stale Locale kann warten.

Andere dürfen nur weiter, wenn die formale Publication Policy es erlaubt.

9-3. SEO-Leitungen prüfen

  • title
  • description
  • canonical
  • hreflang
  • sitemap
  • robots/indexability
  • structured data
  • 404/redirect
  • internal links

Mehrsprachiges Routing lässt sich leicht falsch verkabeln.

9-4. Echte Produktions-URL abrufen

Commit vorhanden, Build erfolgreich, Deploy erfolgreich: noch nicht genug.

Auf der echten URL prüfen:

  • HTTP 200
  • aktueller Inhalt
  • richtige Sprache
  • title/meta
  • canonical/hreflang
  • funktionierende Links

Nicht „Lieferung abgeschlossen“ sagen, wenn das Essen noch vor der eigenen Haustür steht.

10. Die Website immer wieder auf 100 Punkte bringen

10-1. QC-Schleife

beobachten
↓
bewerten
↓
Lücken finden
↓
Ursache klassifizieren
↓
sicher reparieren
↓
erneut testen
↓
erneut bewerten

10-2. Hard Gates gegen Punktekosmetik

Selbst bei rechnerisch 100 Punkten kein 100-Punkte-Status, wenn es gibt:

  • broken link
  • cross-locale content link
  • stale translation als current
  • nicht existierendes Hub-Mitglied
  • doppelt gezählten formal success
  • lost update
  • gefälschte Validation Evidence

10-3. Wiederkehrende Fehler müssen die Fabrik verbessern

Wenn dasselbe Problem zurückkommt:

  • Vertrag zu schwach?
  • Validator fehlt?
  • State Model schwach?
  • Concurrency Guard fehlt?
  • Schedule-Kollision?
  • externe Infrastruktur?

Das Ziel steigt von „kaputtes Produkt reparieren“ zu „weniger Defekte produzieren“.

10-4. Monitoring bei 100 nicht abschalten

Heute 100, morgen nach neuem Content 98.

Normal.

Die Routine bringt 98 wieder auf 100.

Dass gestern kein Einbrecher kam, ist kein Grund, heute das Schloss wegzuwerfen.

Das ganze System in 30 Sekunden

Mensch definiert Ziel + Grenzen
        ↓
100-Punkte-Ideal
        ↓
KI erstellt Source
        ↓
QA + Beweise
        ↓
11-Sprachen-Erweiterung
        ↓
QA pro Locale
        ↓
Links + Hubs
        ↓
State/Hash/Token
        ↓
Validation
        ↓
Publication Policy
        ↓
Deploy
        ↓
echte URL/HTML
        ↓
Nutzerverhalten messen
        ↓
mit Ideal vergleichen
        ↓
sicher reparieren
        └────→ wiederholen

Zehn klassische Unfälle

  1. 100 Artikel, 30 beantworten dasselbe
  2. Source-Fehler wird in 12 Sprachen international verteilt
  3. Übersetzung existiert, ist aber stale
  4. Japanische Seite springt plötzlich zum englischen Artikel
  5. So viele Hubs, dass der Informationsschalter selbst zum Ziel wird
  6. Alle Anchors heißen „hier klicken“
  7. Zwei KIs überschreiben denselben Artikel
  8. Ziel 50, ein Erfolg, dann „complete“
  9. Commit mit Production verwechselt
  10. Monitoring findet einen Fehler, also schaltet jemand Monitoring ab

Nummer 10 ist: Rauchmelder erkennt Rauch, also Stecker vom Rauchmelder ziehen.

Minimale Checkliste

Design

  • ☐ Leserziel
  • ☐ 100-Punkte-Ideal
  • ☐ Verbote
  • ☐ stabile Artikel-ID
  • ☐ Locale getrennt
  • ☐ Content Hash

Content

  • ☐ Source QA
  • ☐ Datenschutz
  • ☐ Fakten/Zahlen/URLs geschützt
  • ☐ konkrete Beispiele
  • ☐ weniger KI-Template-Stil

Mehrsprachig

  • ☐ URL pro Sprache
  • ☐ hreflang
  • ☐ Source Fingerprint
  • ☐ nur stale aktualisieren
  • ☐ QA pro Locale
  • ☐ kein Cross-Locale-Content-Fallback

Links/Hubs

  • ☐ Hub structural getrennt von Body Links
  • ☐ beschreibende Anchors
  • ☐ Orphan Audit
  • ☐ broken/self/duplicate/cross-locale
  • ☐ Promotion vor neuem Hub prüfen
  • ☐ Duplicate-Hub-Audit

Automation

  • ☐ Gates über State/Hash/Token
  • ☐ claim/CAS
  • ☐ Checkpoints
  • ☐ exactly-once formal success
  • ☐ ein Fehler stoppt nicht alles

Veröffentlichung

  • ☐ Validation
  • ☐ canonical/hreflang/sitemap
  • ☐ Publication Policy
  • ☐ echte URL
  • ☐ echtes HTML

Wartung

  • ☐ regelmäßiges 100-Punkte-Audit
  • ☐ Hard Gates
  • ☐ Root Cause wiederkehrender Fehler beheben
  • ☐ Monitoring nach 100 aktiv lassen

Letzte Lektion

Die stärkste KI-Artikelwebsite ist nicht die mit dem teuersten Modell.

Sie ist die Website, die Fehler erkennen und in einen korrekten Zustand zurückkehren kann, wenn KI sich irrt, Content stale wird, mehrere Prozesse parallel laufen oder ein externer Dienst ausfällt.

Der Mensch definiert Ziel, Ideal, Grenzen und letzte Verantwortung.

Die KI erzeugt, vergleicht, prüft, repariert und protokolliert.

Der Abschluss wird belegt durch:

  • Hashes
  • Tests
  • Git-Historie
  • echte URLs
  • echtes HTML
  • Leser-Verhalten

Dann ist es nicht mehr nur ein Blog.

Es ist ein kleiner Verlag + Bibliothek + Straßenbauamt + QC-Fabrik innerhalb eines Repositories.

Mit einem Artikel anfangen.

ID geben.

QA hinzufügen.

Eine Sprache hinzufügen.

Sichere Links hinzufügen.

States hinzufügen.

Schicht für Schicht bauen.

Am ersten Tag braucht niemand eine Raumstation.

Aber bitte nicht 100 Kopierer kaufen und „Raumstation fertig“ verkünden.

References / 参考文献

This article intentionally separates research-backed principles from site-specific engineering guardrails. Research can tell us that descriptive links, explicit multilingual URLs, semantic relationships, user journeys, and conditional updates are useful. Exact thresholds such as batch size, hub-member limits, or score cutoffs should be treated as configurable engineering rules and validated with real site data.

Editorial note

The article is deliberately written in plain language. Terms such as SHA, CAS, hreflang, canonical, state, and token are kept because they are useful in real implementations, but each is explained through a simple analogy. The goal is not to hide complexity. The goal is to make the complexity understandable enough that a beginner can build the system one layer at a time.

Als Nächstes lesen

Mendoi-chan

Verfasst von

Mendoi-chan

Sie macht Reibungen im Beruf und Alltag als klare Struktur und konkrete nächste Schritte verständlich.

Über diese Website