Eine bestehende Website diagnostizieren und Korrekturen priorisieren

Öffentlichen Umfang und URL-Liste festlegen

Dieselbe Korrektur für alle in der Suche fehlenden Seiten kann Ursachen bestehen lassen. Unverlinkte Artikel brauchen Entdeckungswege, noindex-Seiten korrigierte Indexierungsanweisungen und Texte ohne Antwort bessere Inhalte. Zuerst tatsächliche Antwort und Suchverarbeitungsprotokoll derselben URL vergleichen, um die Verluststelle zu finden.

Mit dem Betreiber zunächst Öffentlichkeit und Suchaufnahme festlegen. Erlaubt die Richtlinie alle öffentlichen Inhalte in der Suche, nicht allein wegen des Typs Artikel, Mitteilung, Vorstellung oder Fotobeschreibung noindex setzen. Anmeldepflichtiges Material, Entwürfe, noch nicht fällige Veröffentlichungen und Rücknahmen getrennt behandeln. Suchausschluss und Zugriffsbeschränkung sind verschiedene Einstellungen; private Inhalte durch Authentifizierung und Berechtigungen schützen.

Öffentliche URLs aus Inhaltsspeicher oder CMS exportieren und mit Sitemap, tatsächlichen Menüs und Inhaltslinks abgleichen. Allein die Sitemap zeigt nicht, welche Artikel darin fehlen. Routentypen wie Liste, Detail, Seitennavigation, Bild und Anhang erfassen. Öffentliche Artikel ohne Inhaltslink und Sitemap-Eintrag sind Kandidaten für zusätzliche Verbindungen.

Je URL Inhalts-ID, Typ, Veröffentlichungsstatus, erwarteten Statuscode, kanonische Adresse, Veröffentlichungs- und wesentliches Änderungsdatum sowie Fragen festhalten. Mit repräsentativen URLs je Vorlage beginnen, den abschließenden Abgleich aber auf alle Ziele anwenden. Entwürfe, Rücknahmen und fehlende URLs als separate Stichproben aufnehmen, damit sie nicht mit öffentlichen Artikeln vermischt werden.

Ausgangswerte und Beobachtungstabelle vor Bereitstellung erstellen

Ziel-URLs und Fragen vor Beobachtungsbeginn festlegen. Vorhandene Vorher-Daten anhand derselben Menge vergleichen; sonst die erste Beobachtung als Ausgangswert verwenden. Neue URLs und geänderte Fragen versionieren und Ergänzungen kennzeichnen. Ein Gesamtwert trennt Wachstum durch neue Inhalte nur schwer von Verbesserungen bestehender Seiten.

Technische Aufzeichnungen sichern tatsächliche Websiteantworten. Suchaufzeichnungen sichern den zuletzt verarbeiteten Suchmaschinenzustand. KI-Aufzeichnungen sichern Antwort und Zitate einer Frage. Auch für dieselbe URL können die Zeitpunkte abweichen; jedes Original samt Beobachtungszeit bewahren. Unten folgt ein fiktives Protokoll des anfänglichen Bibliotheksfehlers.

Direkt nach Bereitstellung prüfen, ob neue Inhalte und kanonische URL in der Antwort stehen. Später bei Suche und KI letztes Crawling und Datum zitierter Dokumente lesen. Verbliebenes Altmaterial hilft entscheiden, ob erneutes Crawling abzuwarten oder die Erklärung des Geltungszeitraums zu verbessern ist.

Erstaufbau, Umbau und neue Funktionen abgrenzen

Beim Erstaufbau öffentliche URLs und Grundinhalt, seitenspezifische Titel, Beschreibungen und canonicals, robots, Sitemap und Such-Property-Registrierung erstellen. Beim Umbau zusätzlich Umzug oder Erhalt alter URLs, Trennung aktueller und historischer Informationen sowie Veröffentlichungsbedingungen neuer Abfragen untersuchen.

Bei neuen Menüs oder Seitenbereichen zuerst dokumentieren, welche Inhalte woher gelesen und wie Details verlinkt werden. Die erste Antwort auf Text, Titel, Detaillinks, Bilder und Originalquellen prüfen. Bei erst nach Tabs, Karussells oder Scrollen sichtbarem Material Browserverhalten und crawlbare Wege gemeinsam betrachten.

Serverantwort und Browseransicht gemeinsam erfassen

Das folgende Beispiel ist eine rein lesende Untersuchung in einer macOS- oder Linux-Shell. example.com dient der Illustration. Durch die Zieladresse ersetzen und einen öffentlichen Detailartikel auswählen. Ohne Cookies und Administratorauthentifizierung beginnen.

AUDIT_ORIGIN='https://example.com' AUDIT_PAGE="$AUDIT_ORIGIN/guides/opening-hours" mkdir -p seo-audit curl -sS -D seo-audit/page.headers -o seo-audit/page.html "$AUDIT_PAGE" curl -sS "$AUDIT_ORIGIN/robots.txt" -o seo-audit/robots.txt curl -sS "$AUDIT_ORIGIN/sitemap.xml" -o seo-audit/sitemap.xml

Die erste Anfrage folgt Weiterleitungen nicht automatisch. Statuscode, Location, X-Robots-Tag und Content-Type aus der Headerdatei lesen. Bei 3xx mit dem nächsten Befehl auch Endadresse und Anzahl der Weiterleitungen erfassen. Eine funktionierende kanonische URL muss den vorgesehenen öffentlichen Inhalt statt einer Anmeldung liefern.

curl -sS -L -o /dev/null -w 'status=%{http_code} redirects=%{num_redirects} final=%{url_effective}\n' "$AUDIT_PAGE" rg -n -i 'noindex|canonical|<title|application/ld\+json' seo-audit/page.html

rg sucht Zeichenfolgen in Dateien. Die in Ergebnissen gefundenen Einstellungen lokalisieren. Auch einzeiliges HTML oder JavaScript-Zeichenfolgen können Treffer sein; echte Tags und Inhalt getrennt lesen. Dieselbe URL in einem neuen unangemeldeten Browserfenster öffnen und Text, Fotos und Links prüfen. Enthält HTML nur einen Ladehinweis statt der Antwort, anhand des Datenflusses der Rendering-Konfiguration verfolgen, wann die Daten eintreffen. Siehe auch Googles Anleitung zur JavaScript-Verarbeitung.

Fehlen Schließtage im gespeicherten HTML, erscheinen aber im Browser, JavaScript-Ausführung und Datenanfragen zwischen beiden untersuchen. Fehlen sie in beiden, Text oder Serverabfrage korrigieren. Diese Unterscheidung verhindert vorschnelle Framework-Wechsel allein wegen geringer Suchsichtbarkeit.

Je ein statisches und ein CMS-Foto bei gleicher Ansichtsbreite öffnen. Fordert das statische Foto eine Transformation mit Breite an, das CMS-Foto aber das Original, den Weg vom CMS-Feld bis img.src verfolgen. CSS-Breiten allein zeigen nicht die übertragenen Bytes. In der CMS-Bildübung verwenden Original- und Derivatansicht dieselben Daten und Anordnung; dadurch lassen sich Übertragungswege vergleichen.

Symptome mit Korrekturstellen verbinden

Im Repository mit den folgenden Suchen die Erzeugungsstelle der Einstellungen finden. Pfade an die Projektstruktur anpassen. Neben Standardwerten auch Seitenüberschreibungen, Antwortheader und Bereitstellungsumgebung verfolgen. Dasselbe noindex kann gleichzeitig in HTML und HTTP-Header stehen.

rg -n 'noindex|X-Robots-Tag|generateMetadata|canonical' src app public rg -n 'sitemap|robots|dateModified|datePublished|application/ld\+json' src app public rg -n 'published|visibility|deletedAt|publishedAt' src app

Bei externem Peer-Review zunächst Ziel-URL, Zeitpunkt, Bedingungen und Messwerte des Originals übertragen. Befunde in Antworten und Code reproduzieren und Korrekturstellen zuordnen. Bereits behobene, verbleibende und wegen Betriebsrichtlinien nicht übernommene Vorschläge unterscheiden. Leistungsbefunde auf derselben Seite, demselben Gerät und unter denselben Netzwerkbedingungen vorher/nachher messen.

Die Ursache langsamer Fotos hängt auch vom Anfragezeitpunkt ab. Erscheint die URL spät im HTML, Rendering und Datenabfrage prüfen. Erscheint sie früh, dauert aber der Download, Dateigröße und Verbindung prüfen. Dauert die Anzeige nach Download, Hauptthread und Dekodierung untersuchen. So lässt sich die Korrekturstelle vor einem kompletten Framework-Wechsel eingrenzen.

Korrekturreihenfolge und Entscheidungsgrundlage festlegen

Zuerst übergreifende Probleme wie private Offenlegung, unzugängliche öffentliche Artikel und großflächig falsche noindex- oder canonical-Werte behandeln. Danach fehlenden Inhalt, defekte Links sowie falsche Daten und Fakten korrigieren. Titel, Zusammenfassungen, Tabellen und Bildbeschreibungen dort verbessern, wo Antworten schwer zu finden sind. Externe Antworten einmal vorab als Ausgangswert erfassen und nach Bereitstellung unter denselben Bedingungen weiter beobachten.

Jede Aufgabe als „URL / Symptom / Originalantwort oder Ansicht / Ursache / Korrektur / Bestehenskriterium / Wiederholungsfrage“ erfassen. Erbt eine öffentliche Detailseite noindex aus dem gemeinsamen Layout, Standardwert und öffentliche Überschreibung korrigieren und reguläre Artikel, Entwürfe und fehlende URLs gemeinsam prüfen. Unbelegte Vermutungen als Untersuchungsaufgaben getrennt von bestätigten Korrekturen führen.

Googles generative Suche nutzt grundlegende Suchqualität und technische Anforderungen. Öffentliche Inhalte, Zugriff und Quellen zuerst verbessern. Für ein separates Werkzeug, das llms.txt liest, zu liefernde Inhalte und Aktualisierungszeit bestimmen. Leitfaden zur Optimierung für generative Suche

Unterlagen für den nächsten Schritt

Nach der Diagnose Fragen-URL-Liste, Veröffentlichungstabelle, Antwort- und Bildschirmbelege sowie priorisierte Korrekturliste hinterlassen. Verantwortliche müssen daraus Codepositionen und Bestehenskriterien direkt finden. Bei unzugänglichen externen Berichten zugängliche und unbeobachtete Punkte dokumentieren. Auch Gründe für leere Werte für die nächste beobachtende Person verständlich festhalten.

Jeden Diagnosepunkt mit Dateien, Einstellungen oder Inhalten und erwarteter Antwort verbinden. Vor Rendering-Änderungen Datenfrequenz und Veröffentlichungsbedingungen bestimmen; bei URL-Problemen zuerst kanonische URLs und Altadressenzuordnung. Danach mit denselben URLs und Fragen erneut prüfen.

Drei Symptome der fiktiven Bibliothek in Korrekturaufgaben umwandeln

Die Detailadresse der Öffnungszeiten ohne Anmeldung anfordern und den Inhalt speichern. Bei reiner Ladeanzeige den Abfragezeitpunkt untersuchen. Zeigt canonical zur Startseite, die Detailmetadaten-Erzeugung suchen. Datum und Geltungszeitraum vergleichen, um die Eignung alter Zeitpläne für aktuelle Fragen zu beurteilen.

Die Tabelle verbindet drei Bibliotheksfehler mit Korrekturstellen. Antwort-HTML, canonical-Wert und alten Hinweis nebeneinander lesen, um nötige Änderungen zu unterscheiden.

Belege für technische und inhaltliche Fehler trennen

Das gleiche Symptom „wenig Suchzugriffe“ kann verschiedene Ursachen haben. Bei fehlendem Antwortinhalt den Auslieferungsweg, bei fehlenden Anmeldebedingungen den Text und bei Fehlern nach dem Anmeldebutton den Konversionsweg untersuchen. Fragen aus Keyword-Recherche und echten Anfragen in die Diagnose aufnehmen und prüfen, ob jede Seite sie beantwortet.

Frage, URL, veröffentlichte Fassung, Geltungszeitraum und Beobachtungszeit im Ausgangsprotokoll festhalten. Die aktuelle Ansicht nicht unmittelbar mit einem einen Monat alten Suchbericht vergleichen, sondern die möglicherweise tatsächlich gezeigte Fassung feststellen. Fehlstellen anhand der Dokumentrollen in der Suchabsichtskarte suchen.

Indexierte, aber in generativen Antworten fehlende Seiten eingrenzen

Auch bei laut URL-Prüfung indexierten Öffnungszeiten können Schließungsbedingungen in Antworten fehlen. Zuerst die tatsächlich zitierte URL sichern. Bei aktueller Information prüfen, ob Ausnahmen im Text stehen und durch nosnippet oder data-nosnippet verborgen werden. Bei Archivzitaten Zeitraum und aktuellen Link vergleichen. Ohne Zitat Teilnahme an Search generative AI und zur Frage passende Inhalte prüfen.

Frage und zitierte Adresse gemeinsam dokumentieren, ergänzt um letztes Crawling und Snippet-Anweisungen aus der URL-Prüfung. Zitiert die KI einen Hinweis von 2025, zuerst dessen Zeitraum und aktuellen Link lesen. Zitiert sie aktuelle Informationen ohne Schließtage, Satz und Ausnahmeerklärung vergleichen.

War das letzte Crawling am 20. Oktober und wurden Schließbedingungen am 24. ergänzt, kann eine Antwort aus dem Material vom 20. sie nicht enthalten. Zitiert sie Material ab dem 24. und lässt die Ausnahme dennoch aus, Platzierung von Antwort und Bedingungen, Zitat und Frageverständnis erneut prüfen. Crawl-Daten trennen noch nicht übermittelte Korrekturen von falsch verwendeten bereits übermittelten Inhalten.