The Keep IT Simple Project

Kategorie: SEO

Sichtbarkeit in Suchmaschinen und bei KI-Assistenten: Einrichtung, Messungen und Korrekturen.

  • Der erste SEO-Audit: Woher der Befehl kommt

    Kurz gesagt: /seo audit kommt aus dem Plugin claude-seo, das ich installiert und mit /seo setup eingerichtet habe. Die Spezialisten laufen nacheinander.

    Am Abend des Starttags habe ich einen einzigen Befehl getippt: /seo audit. Wenige Minuten später begann eine Prüfung, an der zehn Spezialisten beteiligt waren. Der Befehl steht in Claude Code nicht von Haus aus zur Verfügung. Er kommt von außen.

    Herkunft des Befehls

    Claude Code lässt sich mit Plugins erweitern. Ein Plugin ist ein Paket aus Befehlen, Anleitungen und Hilfsprogrammen, das von anderen Menschen gebaut wird. Das Paket für den SEO-Audit heißt claude-seo. Es stammt von einem Entwickler namens AgriciDaniel, liegt öffentlich auf GitHub, steht unter der MIT-Lizenz und kommt nicht von Anthropic. In der Version 2.4.2 bringt es 26 Anleitungen und 19 Spezialisten mit, für Technik, Texte, Sitemap, Schema, Geschwindigkeit, Aussehen, Suche mit KI und einiges mehr.

    Was nötig war

    Drei Dinge standen zwischen mir und dem Befehl:

    1. Die Quelle bekannt machen. Plugins liegen in einem Marketplace, einer Art Katalog. Der Katalog von claude-seo ist nicht vorinstalliert, ich habe ihn selbst hinzugefügt. 2. Das Plugin installieren, und zwar nur für das KISP-Projekt. Es gilt damit in diesem Ordner und nirgends sonst. 3. Die Laufzeit einrichten. Das Plugin arbeitet mit Python-Programmen und einem eigenen Chromium-Browser, um Seiten wie ein Besucher aufzurufen und Bildschirmfotos zu machen. Beides richtet der Befehl /seo setup in einer abgeschotteten Umgebung ein. Dort liegen jetzt rund 1,4 Gigabyte, davon etwa 0,7 für den Browser.

    Dass Fremdcode auf dem eigenen Rechner läuft, ist eine Entscheidung. Hilfreich ist, dass der Quelltext öffentlich lesbar ist, die Lizenz freizügig und die Anleitung des Plugins vorschreibt, nichts außerhalb der Einrichtung nachzuinstallieren.

    Reihenfolge der Spezialisten

    Die Anleitung des Plugins sieht vor, dass beim Audit alle Spezialisten gleichzeitig loslaufen. Ich habe mir etwas anderes gewünscht: Sie arbeiten nacheinander, einer nach dem anderen, jeder mit abgeschlossenem Bericht, bevor der nächste beginnt. Diese Vorgabe steht in meiner persönlichen Konfigurationsdatei von Claude Code und überschreibt die Formulierung im Plugin. Der Grund ist Vorsicht. Zehn Spezialisten, die gleichzeitig arbeiten, teilen sich dasselbe Kontingent und rufen gleichzeitig die Seite und externe Dienste ab. Dabei können Ratenbegrenzungen greifen, also Sperren mit der Meldung „zu viele Anfragen“, und Abläufe können in eine Zeitüberschreitung laufen. Nacheinander vermeide ich das Risiko. Außerdem habe ich einen klaren Ablauf und kann jeden Bericht einzeln nachlesen. Ob es parallel tatsächlich geklemmt hätte, weiß ich nicht, denn ich habe es nicht ausprobiert. Selbst im Lauf nacheinander hat ein externer Dienst (PageSpeed) einmal mit „zu viele Anfragen“ geantwortet. Das Thema bleibt also im Blick.

    Was fehlte

    Der Audit lief ohne kostenpflichtigen Datendienst und ohne Zugang zur Search Console. Deshalb fehlen echte Zahlen von Google, und auch die Lighthouse-Messung scheiterte an einer Sperre des Dienstes. Das steht offen im Bericht und ist ein Grund, die Messung in einigen Wochen zu wiederholen.

    Am Ende standen 73 von 100 Punkten, ein Aktionsplan mit 27 Maßnahmen und ein Befehl, den ich in sechs bis acht Wochen wieder tippen kann. Alle Funde und Werte stehen auf der Seite SEO-Baseline, die Übersicht aller Messungen auf der Seite SEO. Was am Starttag davor geschah, erzählt Geschafft: 100 Punkte und eine Seite, die sich zu helfen weiß.

    Zeig mir, wie es geht: Plugin installieren
    • Quelle: GitHub-Repository AgriciDaniel/claude-seo, Marketplace-Name agricidaniel-claude-seo, Plugin claude-seo, Version 2.4.2, Lizenz MIT.
    • Installation in Claude Code, die Befehle sind aus den Einträgen in installed_plugins.json und known_marketplaces.json abgeleitet:
    /plugin marketplace add AgriciDaniel/claude-seo
/plugin install claude-seo@agricidaniel-claude-seo
    • Bereich der Installation: project, Projektpfad /data/terruhn.it/CLAUDE/kisp. Der Zeitstempel der Installation lautet 2026-10-06 14:53 UTC.
    • Danach stehen /seo mit Unterbefehlen (/seo audit, /seo technical, /seo content und weitere) und die Spezialisten seo-technical, seo-content, seo-schema und weitere bereit.
    • Prüfen kannst du vorher: README.md, SECURITY.md und PRIVACY.md im Repository. Die Fetcher des Plugins sind nach eigener Angabe gegen SSRF und DNS-Rebinding abgesichert; das habe ich nicht selbst geprüft.
    Zeig mir, wie es geht: Laufzeit mit /seo setup
    • Voraussetzung: Python 3.10 oder neuer. Auf dem Rechner läuft Python 3.12.
    • Der Befehl in Claude Code:
    /seo setup

    Er ruft das Startprogramm des Plugins auf:

    "$HOME/.claude/plugins/cache/agricidaniel-claude-seo/claude-seo/2.4.2/scripts/claude-seo" setup
    • Ergebnis: isolierte Python-Umgebung und Playwright-Chromium unter ~/.local/share/claude-seo/ (rund 1,4 GB, davon Chromium unter ms-playwright/ rund 0,66 GB). Der Zustand steht in runtime-state.json (browser_ready: true, Plugin 2.4.2, Python 3.12).
    • Fehlt die Laufzeit, meldet das Plugin „setup required“ und schlägt /seo setup vor. Die Anleitung des Plugins verbietet ein eigenes pip install.
    • Aufräumen: Verzeichnis ~/.local/share/claude-seo/ löschen und das Plugin deinstallieren.
    Zeig mir, wie es geht: Audit nacheinander statt parallel
    • Aufruf:
    /seo audit https://thekeepitsimpleproject.org
    • Die Anleitung skills/seo/SKILL.md verlangt: „delegate to subagents in parallel“. Meine globale Datei ~/.claude/CLAUDE.md ersetzt das durch: einen Spezialisten starten, den Abschluss abwarten, dann den nächsten.
    • Vorgehen laut dieser Datei: zuerst Geschäftstyp erkennen und das Set der Spezialisten festlegen, dann eine gemeinsame Kontextdatei schreiben (audit-context.md), dann der Reihe nach arbeiten.
    • Reihenfolge: erst Struktur (seo-technical, seo-sitemap, seo-schema), dann Inhalt (seo-content, seo-geo, seo-sxo), dann Messungen (seo-performance, seo-visual), zuletzt datenabhängige (seo-backlinks). Zusätzlich lief seo-agentic. Nicht gestartet: seo-google (kein Zugang), seo-cluster, seo-drift.
    • Begründung: Ratenbegrenzung (HTTP 429) und Zeitüberschreitungen vermeiden. Ein Vergleichslauf mit parallelem Start liegt nicht vor. Der Abruf von PageSpeed lieferte auch nacheinander einmal HTTP 429.
    • Stoppt ein Spezialist an seinem Turn-Limit, wird er fortgesetzt und die Kürzung im Bericht vermerkt.
    • Ablage: seo-audits/thekeepitsimpleproject.org-audit/ mit FULL-AUDIT-REPORT.md, ACTION-PLAN.md, audit-data.json, findings/ und screenshots/.
    • Laufzeit der zehn Spezialisten zusammen: rund 46 Minuten.

  • Geschafft: 100 Punkte und eine Seite, die sich zu helfen weiß

    Kurz gesagt: Erste Messung mit 100 Punkten, Sitemaps bei Google und Bing, eigene 404-Seite über eine .htaccess.

    Die Seite ist online. Noch am selben Tag, direkt nach dem ersten Push, war Zeit für den ersten Blick von außen.

    Die Messung

    Google bietet ein kostenloses Werkzeug an, PageSpeed Insights. Es ruft eine Seite auf und bewertet sie: Wie schnell lädt sie, wie gut lässt sie sich bedienen, wie sauber ist sie gebaut. Die Skala reicht bis 100. Bei mir stand dort in allen Bereichen die 100, mobil und am Desktop. Dazu kam eine 3 von 3 bei Agentic Browsing, einer Prüfung, wie gut KI-Programme mit der Seite zurechtkommen.

    Ich freue mich darüber, und ich ordne es ein: Die Seite hat noch keine Bilder. Wo nichts Schweres geladen werden muss, geht es leicht. Der Wert ist ein Ausgangspunkt. Nach den ersten Bildern und dem Design messe ich noch einmal.

    Sitemap und Indexierung

    Suchmaschinen finden eine neue Seite nicht von selbst. Sie freuen sich über eine Sitemap, ein Inhaltsverzeichnis, das alle Seiten auflistet. Yoast SEO erzeugt es, Simply Static exportiert es mit. Ich habe die Adresse bei der Google Search Console und bei den Bing Webmaster Tools eingetragen. Zusätzlich habe ich bei beiden die Startseite direkt zur Indexierung angemeldet, also darum gebeten, sie in den Suchindex aufzunehmen. Damit wissen beide, wo sie nachschauen können, und die Startseite steht ganz vorn in der Warteschlange.

    404-Seite

    Wer sich vertippt oder einem alten Link folgt, landet bei einer Adresse, die es nicht gibt. Der Fachbegriff dafür ist 404. Ohne eigene Seite zeigt der Hoster seine Standardmeldung, und die erzählt nichts von KISP.

    Also habe ich in WordPress eine schlichte Seite gebaut: ein Satz und vier Wege weiter, zur Startseite, zum Blog, zur Dokumentation und zum Glossar. Simply Static exportiert sie als 404.html.

    Beim Test gab es eine Überraschung. Die Datei lag auf dem Server, die Meldung des Hosters erschien trotzdem. Die Datei war da, der Webserver wusste nur nichts von ihr. Ihm fehlte ein Hinweis: „Wenn eine Seite fehlt, zeige diese hier.“ Der Hinweis passt in eine Zeile, in eine Datei namens .htaccess.

    Ein zweiter Stolperstein lag im Übertragungsskript. Es gleicht den Server mit dem Export ab und entfernt, was im Export fehlt. Eine Datei, die nur auf dem Server liegt, wäre beim nächsten Lauf verschwunden. Deshalb schreibt das Skript die .htaccess selbst mit. Danach hat es funktioniert: Eine erfundene Adresse zeigt jetzt die eigene Seite.

    Heute Abend folgt der nächste Schritt: der erste SEO-Audit. Er hält fest, wie die Seite am Tag des Go-live dasteht, als Nullpunkt für alles, was danach kommt.

    Zeig mir, wie es geht: 404-Seite und .htaccess
    • Seite in WordPress anlegen, Slug seite-nicht-gefunden, Inhalt kurz mit Links auf /, /blog/, /dokumentation/, /glossar/. Yoast: noindex, damit die Seite weder in Suchergebnissen noch in der Sitemap erscheint.
    • Simply Static Pro kennt dafür die Optionen generate_404 und custom_404_page. Dort wählst du die Seite als 404-Seite aus. Der Export enthält danach 404.html im Wurzelverzeichnis.
    • Der Webserver braucht den Hinweis. Bei All-Inkl genügt im Webroot eine .htaccess mit einer Zeile:
    ErrorDocument 404 /404.html
    • Das Übertragungsskript überträgt per rsync --delete-after. Eine Datei, die nur auf dem Server liegt, würde dabei gelöscht. Das Skript schreibt die .htaccess deshalb nach dem Bereinigen ins Arbeitsverzeichnis, sofern 404.html vorhanden ist:
    printf 'ErrorDocument 404 /404.html\n' > "$ARBEIT/.htaccess"
    • Prüfung mit einer erfundenen Adresse, erwartet sind Status 404 und der Text der eigenen Seite:
    curl -s -o /dev/null -w "%{http_code}\n" https://thekeepitsimpleproject.org/gibt-es-nicht-xyz
curl -s https://thekeepitsimpleproject.org/gibt-es-nicht-xyz | grep -i "Seite nicht gefunden"
    • Ohne .htaccess liefert der Hoster zwar den Status 404, aber seine Standardseite (content-type: iso-8859-1).
    Zeig mir, wie es geht: Sitemap und Startseite einreichen
    • Die Adresse steht in der robots.txt: https://thekeepitsimpleproject.org/sitemap_index.xml.
    • Google: Search Console → Sitemaps → Adresse sitemap_index.xml eintragen.
    • Bing: Webmaster Tools → Sitemaps → vollständige Adresse eintragen.
    • Startseite direkt anmelden: Google Search Console → URL-Prüfung → https://thekeepitsimpleproject.org/ eingeben → „Indexierung beantragen“. Bing Webmaster Tools → URL-Übermittlung → Adresse eintragen. Die Menünamen können je nach Sprache und Version abweichen.
    • Verarbeitungsstatus und Zahl der gefundenen URLs lassen sich nach einigen Stunden ablesen. Ich halte sie in der SEO-Baseline fest.

  • Aufräumen nach dem Export

    Kurz gesagt: Ein Skript entfernt nach jedem Export die Spuren von Yoast SEO aus llms.txt, Sitemaps und robots.txt.

    Der Export war schlank, und ich las ihn zum ersten Mal wie ein Besucher von außen: Datei für Datei, mit dem Auge eines Suchprogramms.

    Spuren von Yoast SEO

    Dabei fiel mir etwas auf. In fast jeder Datei stand der Name des Helfers, der sie erzeugt hatte. Yoast SEO ist das Plugin, das sich um Suchmaschinen kümmert. Es hat seine Visitenkarte an vielen Stellen hinterlassen: als Satz in der llms.txt, als Kommentar am Ende jeder Sitemap, als Hinweis in der Anzeige der Sitemap und als Markierung in der robots.txt.

    Diese Dateien sind für Maschinen gedacht. Auf der fertigen Seite braucht niemand den Hinweis, mit welchem Werkzeug sie entstanden sind. Außerdem zeigt eine Seite, die ohne WordPress auskommt, ihre Herkunft besser durch das, was sie tut.

    BOM in der llms.txt

    Dazu kam eine Kleinigkeit am Anfang der llms.txt: ein unsichtbares Zeichen, das BOM. Es markiert eine Textdatei als Unicode und stört dort, wo Programme die erste Zeile genau lesen.

    Bereinigung per Skript

    Ich habe die Aufräumarbeit nicht von Hand erledigt. Ein kleines Skript macht es nach jedem Export in einem Zug. Zuerst durfte es an einer Kopie üben. Es hat die Spuren entfernt, die Sitemaps blieben gültig, und ein zweiter Lauf änderte nichts mehr. Danach habe ich es auf den echten Export losgelassen.

    Stehen geblieben ist nur eine CSS-Klasse im Quelltext der Seiten, yoast-schema-graph. Sie hat keine sichtbare Wirkung und trägt keine Information nach außen. Wer mag, kann sie später entfernen.

    Ergebnis: llms.txt, Sitemaps und robots.txt sind schlank und tragen keinen Werkzeugnamen mehr. Das Skript soll vor jeder Übertragung nach All-Inkl laufen. Die Übertragung selbst beschreibt Die Seite geht online.

    Zeig mir, wie es geht: Skript export-bereinigen.sh
    • Skript export-bereinigen.sh (0.1), Aufruf mit optionalem Verzeichnis, Standard ist das Staging:
    bash skripte/export-bereinigen.sh /data/terruhn.it/kisp/staging
    • Was es bereinigt:
    • llms.txt: BOM (EF BB BF) am Anfang und die Zeile Generated by Yoast SEO … samt folgender Leerzeile.
    • sitemap.xml: Schlusskommentar <!-- XML Sitemap generated by Yoast SEO -->.
    • main-sitemap.xsl: der Satz „Generated by Yoast SEO, this is an XML Sitemap …“ wird zu „This is an XML Sitemap …“.
    • robots.txt: die Zeilen # START YOAST BLOCK, # END YOAST BLOCK und die Trennlinien dazwischen.
    • Umsetzung mit perl -0pi bzw. perl -ni. Das Skript ist idempotent und prüft am Ende per grep -rIil yoast auf Reste in diesen Dateien (Exit-Code 1, wenn noch etwas steht).
    • Kontrolle:
    head -c 3 /data/terruhn.it/kisp/staging/llms.txt | xxd
cat /data/terruhn.it/kisp/staging/robots.txt

    Die erste Zeile der Ausgabe beginnt mit 23 20 54 (# T) statt efbb bf.

    • Bewusst nicht angefasst: die Klasse yoast-schema-graph am Schema-Skript im HTML. Ein Ersetzen in jeder Seite brächte Aufwand ohne sichtbaren Nutzen.
    • Verworfen: die Texte schon in Yoast zu ändern. Die Zeilen entstehen beim Erzeugen der Dateien, und ein Eingriff dort würde vermutlich mit einem Plugin-Update überschrieben.

  • Erzähl deine Geschichte selbst

    Kurz gesagt: Yoast SEO ist schlank eingerichtet, Google und Bing kennen die Domain, die Indexierung war zu diesem Zeitpunkt noch gesperrt.

    Stell dir vor, jemand fragt einen KI-Assistenten nach deinem Projekt. Der Assistent antwortet in zwei Sätzen, freundlich und sicher im Ton. Was in diesen Sätzen steht, hat er irgendwo gelesen. Und wenn deine Seite für ihn schwer lesbar war, hat er sich die Geschichte bei jemand anderem geholt.

    Daraus wächst das Motto dieser Etappe: Erzähl deine Geschichte selbst. Wer keine eigene, klar lesbare Quelle anbietet, überlässt die Erzählung anderen. Suchmaschinen und KI-Assistenten sind dafür die wichtigsten Leser der kommenden Jahre. Sie arbeiten langsam: Was sie heute verstehen, prägt über Monate, was Menschen finden. Das Papier „Gemeinsam kann mehr“ hat mich darin bestärkt. Es beschreibt, wie eine Stadt ihre Geschichte mit eigenen Kanälen, eigenen Daten und eigener Technik selbst erzählt, und es bringt das auf drei Gedanken, die ich für KISP übernehme.

    Erstens: Zugänglichkeit ist die Grundlage. Ein klar gegliederter Text hilft Menschen mit Screenreader, mit wenig Zeit, mit Lernschwierigkeiten oder mit müden Augen. Dieselbe Klarheit hilft Suchmaschinen und KI: eindeutige Überschriften, kurze Sätze, erklärte Fachbegriffe, Datum und Version. Was für Menschen verständlich ist, ist für Maschinen lesbar. Das Thema fällt oft unter den Tisch, obwohl es mehrere Ziele auf einmal erreicht. Bei KISP steht es deshalb am Anfang und nicht am Ende. Die Prüfung der Barrierefreiheit folgt mit dem Inhalt der Seite.

    Zweitens: Eigene Technik, eigene Daten. Die Seite wird statisch ausgeliefert: schnell, sicher, ohne Cookies, ohne fremde Skripte. Dazu passt, dass ich Messwerkzeuge und Plugins meide, die Besucher an Dritte weiterreichen.

    Drittens: Offen und strukturiert. Gute Quellen erklären, wie sie entstanden sind. Genau das tut dieser Blog. KI-Systeme geben klare Aussagen korrekt wieder oder lassen sie weg. Ein sauberer Aufbau entscheidet also mit, ob deine Worte in einer Antwort auftauchen.

    Yoast als Werkzeug

    Für die Umsetzung installiere ich das Plugin Yoast SEO. Es hilft, Titel und Beschreibungen so zu schreiben, dass Suchmaschinen sie gut lesen, und es liefert die Sitemap, eine Art Inhaltsverzeichnis für die Seite.

    Yoast bringt viel mit, und vieles davon braucht KISP nicht: Werbung für die Bezahlversion, Verbindungen zu fremden Diensten, Funktionen für große Shops. Ich gehe die Liste durch und lasse nur an, was zur Idee passt: schlank, ohne Cookies, ohne Anrufe bei fremden Servern. Die Hilfen für KI-Texte bleiben aus, weil Claude die Texte ohnehin selbst schreibt.

    Eine Datei bleibt bewusst an: die llms.txt. Sie ist ein kleines Inhaltsverzeichnis, das sich an KI-Assistenten richtet. Dort steht, welche Seiten es gibt und worum es geht. Es ist ein Stück „Geschichte selbst erzählen“ in Dateiform. Auch die Schema-Angaben bleiben an. Das sind unsichtbare Etiketten im Quelltext, die Maschinen sagen: Das ist ein Artikel, das ist die Startseite, das ist der Name der Seite.

    Gesperrt, bis die Geschichte steht

    Solange die Seite noch leer ist, bleibt sie für Suchmaschinen gesperrt. Ein Haken in WordPress erledigt das. Der Haken wird vor dem öffentlichen Start wieder entfernt, und dieser Punkt steht fest auf dem Board.

    Google und Bing kennenlernen

    Dann geht es an die Anmeldung. Bei Google heißt das Werkzeug Search Console. Damit Google glaubt, dass die Domain mir gehört, schreibe ich einen kurzen Text in den Namensdienst der Domain, einen TXT-Eintrag im DNS. Das dauerte wenige Minuten, dann stand das Häkchen.

    Bei Bing lief es ähnlich, mit einem CNAME-Eintrag. Bing ist wichtig, weil auch DuckDuckGo, Ecosia und KI-Assistenten auf seine Daten zurückgreifen. Wer nur an Google denkt, lässt einen großen Teil der Leser aus.

    Was ich ablehne

    Das Google-Plugin Site Kit installiere ich nicht. Es würde Skripte und Cookies auf die Seite bringen, und beides braucht KISP nicht. Die Search Console funktioniert auch ohne. Ebenso habe ich ein Plugin verworfen, das Yoast-Werbung ausblendet: ein weiteres Plugin für eine Aufgabe, die sich später beim Export erledigen lässt.

    Denn eine Kleinigkeit bleibt: Yoast hinterlässt Spuren im Quelltext, in der Sitemap und in der llms.txt. Beim Export der statischen Seite lasse ich sie von Simply Static entfernen.

    Ergebnis: Yoast SEO ist schlank eingerichtet, die Indexierung ist gesperrt, Google und Bing kennen die Domain. Der Weg ist vorbereitet, damit die Geschichte später dort ankommt, wo gefragt wird.

    Zeig mir, wie es geht: Yoast installieren und schlank stellen
    • Installation im Stack-Ordner /data/terruhn.it/kisp:
    docker compose -p kisp run --rm wpcli wp plugin install wordpress-seo --activate
docker compose -p kisp run --rm wpcli wp plugin list --fields=name,status,version

    Der Wrapper kisp-wp erlaubt bewusst keine Plugin-Befehle. Das gehört zum Zugriffskonzept von Claude.

    • Yoast SEO v28.6, Einstellungen → Allgemein → Website-Funktionen:
    • an: SEO-Analyse, Lesbarkeitsanalyse, Cornerstone-Inhalt, Schema-Framework, XML-Sitemaps, Open Graph, X-Kartendaten, llms.txt (Automatik)
    • aus: Yoast KI, Schema-Aggregationspunkt, Einblicke, Inklusive Sprachanalyse, Text-Link-Zähler, REST-API-Endpunkt, Slack-Freigabe, Aufgabenliste, Admin-Leiste
    • Nutzungsdaten teilen: aus
    • Integrationen (Semrush, Wincher, Zapier, Algolia und weitere): aus, sie sprechen externe Dienste an.
    • Website-Grunddaten: Name „The Keep IT Simple Project“, alternativer Name „KISP“, Trennzeichen „–“.
    • Vorlagen für Beiträge und Seiten: SEO-Titel %%title%% %%sep%% %%sitename%%; Beitrags-Beschreibung %%excerpt%%.
    • Aus der Suche genommen: Kategorien, Schlagwörter, Autoren-, Datums- und Formatarchive, Medienseiten.
    • Indexierungssperre: Einstellungen → Lesen → „Suchmaschinen davon abhalten …“. Der Wert blog_public steht auf 0:
    sudo -n /usr/terruhn.it/sbin/kisp-wp option get blog_public
    Zeig mir, wie es geht: Search Console und Bing
    • Search Console, Property-Typ Domain: Eingabe thekeepitsimpleproject.org (ohne Protokoll und ohne www). Google nennt einen Wert google-site-verification=….
    • Im KAS von All-Inkl unter den DNS-Einstellungen der Domain einen Eintrag anlegen: Host leer (Hauptdomain), Typ TXT, Wert wie von Google genannt. Danach in der Search Console „Bestätigen“.
    • Bing Webmaster Tools: Bestätigung per DNS mit einem CNAME-Eintrag, den Bing vorgibt. Die Property lässt sich auch aus der Search Console importieren.
    • Das Meta-Tag im <head> wäre ein weiterer Weg und würde auch aus der statischen Seite exportiert. Es gilt für eine URL-Präfix-Property.
    • Die Sitemap (/sitemap_index.xml) wird erst nach dem öffentlichen Start eingereicht.
    Zeig mir, wie es geht: Yoast-Spuren entfernen
    • Yoast schreibt Kommentare in den <head>, einen Hinweis in die Sitemap und die Zeile „Generated by Yoast SEO“ in die llms.txt.
    • Geplanter Weg: „Suchen und Ersetzen“ in Simply Static Pro beim Export. Verworfen wurden ein Fremd-Plugin (Toasty Purge) und eine eigene Datei im Ordner mu-plugins.
    • Die automatische llms.txt listet bisher nur die Startseite und die Kategorie „Etappen“, die Links zeigen auf die Arbeitsinstanz. Beim Export wird geprüft, ob die Adressen umgeschrieben werden; bei Bedarf stellt die Auswahl auf manuell.