Technisches Baseline-Audit

Phase P2 · Stufe A — Verstehen
Zeitrahmen: 2–4 Stunden für einen leichten Durchlauf, 1–2 Arbeitstage für einen Standarddurchlauf oder 3–8 Arbeitstage für einen tiefgehenden Durchlauf.
Verantwortlicher: der technische SEO-Leiter. Die Verantwortlichen für Technik, Analytik, Content und Lokalisierung liefern Belege und akzeptieren Korrekturen in ihren Bereichen.

Ein technisches Baseline-Audit stellt fest, ob Suchmaschinen die URLs, die das Unternehmen erwartet, erreichen, interpretieren und auswählen können. Sein Umfang umfasst Crawl-Steuerungen, HTTP-Antworten, Indexierung, Canonicals, Links, Rendering, internationale Ausrichtung und sichere Auslieferung. Das Ergebnis ist ein priorisiertes Befundregister mit benannten Verantwortlichen und Abnahmetests, keine Bewertung.

Warum diese Phase hier steht

Das Veröffentlichen auf einer Seite mit Crawling- oder Indexierungsproblemen verstärkt den Schaden. Suchmaschinen entdecken einen wiederholten Fehler über neue URLs oft schneller, als sie den Inhalt bewerten und belohnen. Eine kaputte Canonical-Vorlage kann jeden Artikel woanders hinleiten; eine Robots-Regel kann ein Verzeichnis verstecken; clientseitig gerenderte Navigation kann Waisen für einen Nicht-JavaScript-Client erzeugen. Jede neue Seite vergrößert die betroffene Menge und macht die Reparatur riskanter.

Beheben Sie zuerst das Fundament. Die Reihenfolge ist Crawlability → Indexierbarkeit → Inhaltsqualität → Leistung, weil jede Ebene ein Tor ist. Crawlability bedeutet, dass ein Crawler eine URL entdecken und anfordern kann; Indexierbarkeit bedeutet, dass die erreichbare URL für die Aufnahme in Frage kommt. Erst dann sollten Inhaltsqualität und Leistung bewertet werden. Eine schnelle, durch robots.txt blockierte Seite kann nicht konkurrieren, und Title-Tags sind auf nicht erreichbaren Seiten irrelevant.

Diese Phase verbraucht den Umfang, die priorisierten Journeys, Märkte und Risiken aus Entdeckung und Ziele . Wird sie früher durchgeführt, entsteht ein Crawl ohne Geschäftskontext. Wird sie übersprungen, lassen Forschung und Produktion auf Vorlagen abzielen, die nicht zuverlässig in den Index gelangen können.

Eingaben und Ausgaben

Eingaben definieren die beabsichtigte Seite, nicht nur das, was ein Crawler findet. Ausgaben teilen dem nächsten Verantwortlichen mit, welche URLs sicher getestet werden können und welche blockiert bleiben.

Wählen Sie die Audittiefe

Wählen Sie die Tiefe vor dem Crawling. Die Schätzungen gehen davon aus, dass der Zugriff bereit ist, und schließen die Implementierung aus.

Die Checkliste

Arbeiten Sie in der Reihenfolge. Ein fehlgeschlagenes Tor kann spätere Stichproben ungültig machen. Halten Sie daher den Fehler und seinen Umfang fest, bevor Sie fortfahren.

1. Bestätigen Sie, dass das Ziel die Produktion ist

Was zu tun ist: Schema, Host, Robots-Datei, Analytics-Property, Search Console-Property und Sitemap-Host überprüfen. Warum es wichtig ist: Staging kann sauber aussehen, während die Produktion defekt bleibt. Wie es zu tun ist: Den vereinbarten canonical Host auflösen, Prioritätsseiten und Antwort-Header vergleichen und den Crawl-Ursprung dokumentieren. Tool: Browser, Crawler-Konfiguration, Search Console-Auswahl. Erledigt, wenn: Das Register den bestätigten Produktions-Ursprung und die -Property nennt, ohne Staging-Hostnamen in Seeds oder Exporten.

2. Testen Sie robots.txt vor dem Crawling

Was zu tun ist: Die /robots.txt jedes Produktionshosts und die referenzierten Sitemaps prüfen. Warum es wichtig ist: Eine Disallow-Regel verhindert das Crawling, bevor Inhalte bewertet werden können. Wie es zu tun ist: Disallow-Muster mit dem beabsichtigten Inventar vergleichen, passende und nicht passende URLs testen und einen Crawl-Block von noindex unterscheiden. Tool: Rohantwort und Robots-Tester. Erledigt, wenn: Robots 200 zurückgibt, beabsichtigte Blockaden Gründe haben, indexierbare Stichproben erlaubt sind und eine unbeabsichtigte Blockade einen kritischen Befund auslöst.

3. Gleichen Sie Sitemaps mit echten URLs ab

Was zu tun ist: Eingereichte Sitemaps mit dem canonicalen, indexierbaren Inventar vergleichen. Warum es wichtig ist: Eine Sitemap sollte URLs nennen, die die Seite ausgewählt haben möchte, keine Weiterleitungen, Fehler oder Duplikate. Wie es zu tun ist: Einträge normalisieren, Anzahlen nach Vorlage vergleichen, dann Ergänzungen und Auslassungen in Sitemaps und Indexierung stichprobenartig prüfen. Tool: https://app.amicited.com/reports/google-search/sitemaps-indexing und Crawl-Exporte. Erledigt, wenn: Die Abdeckung mindestens 95 % beträgt, 0 Einträge weiterleiten oder fehlerhaft sind und jede Lücke einen Grund oder Verantwortlichen hat.

4. Messen Sie die Statuscode-Verteilung

Was zu tun ist: Antworten als 2xx, 3xx, 4xx oder 5xx klassifizieren. Warum es wichtig ist: Fehler stoppen den Abruf und Weiterleitungen erhöhen die Hops. Wie es zu tun ist: Weiterleitungen verfolgen und melden, nach Vorlage segmentieren und mit Bing-Crawl vergleichen. Tool: https://app.amicited.com/reports/bing-webmasters/crawl, Crawler und Monitoring. Erledigt, wenn: Indexierbare URLs 200 zurückgeben; interne Fehler, Schleifen und Ketten bei null liegen und beabsichtigte Weiterleitungen dokumentiert sind.

5. Entfernen Sie Weiterleitungsketten und -schleifen

Was zu tun ist: Weiterleitungen bis zur endgültigen Antwort verfolgen. Warum es wichtig ist: Hops verlangsamen die Entdeckung; eine Schleife erreicht nie den Inhalt. Wie es zu tun ist: Pfade exportieren, interne Links auf finale Canonicals aktualisieren und Regeln konsolidieren. Tool: Weiterleitungsbericht und Header-Prüfungen. Erledigt, wenn: Interne Links direkt gehen, Legacy-Weiterleitungen einen Hop benötigen und keine Schleife oder Kette mehr vorhanden ist.

6. Ermitteln Sie das zulässige Indexierungsverhältnis

Was zu tun ist: Googles Index-Status mit absichtlich berechtigten URLs vergleichen. Warum es wichtig ist: Das Einbeziehen von Weiterleitungen, Filtern, Duplikaten oder noindex-Seiten macht das Verhältnis bedeutungslos. Wie es zu tun ist: Den berechtigten Nenner bilden, Prioritätsstichproben in URL-Inspektion prüfen und Ausschlüsse nach Vorlage gruppieren. Tool: https://app.amicited.com/reports/google-search/url-inspection, Search Console und Inventar. Erledigt, wenn: Mindestens 90 % indexiert sind oder jede Lücke einen Verantwortlichen für die Ursache hat; unter 80 % ist ein schwerwiegender Befund.

7. Überprüfen Sie die Canonical-Korrektheit

Was zu tun ist: Deklarierte, finale und von Google ausgewählte Canonicals vergleichen. Ein Canonical ist die bevorzugte Version unter ähnlichen URLs. Warum es wichtig ist: Ein falscher Canonical konsolidiert Signale weg von der beabsichtigten Seite. Wie es zu tun ist: Selbstreferenzen eindeutiger Seiten, bewusste Cross-Canonicals und Konsistenz über HTML, Sitemaps, Weiterleitungen und Links testen. Tool: Canonical-Bericht und https://app.amicited.com/reports/google-search/url-inspection. Erledigt, wenn: 100 % der eindeutigen indexierbaren Seiten einen absoluten, 200, indexierbaren Canonical nennen, mit jeder ausgewählten Abweichung erklärt.

8. Finden Sie Duplikat- und Nahezu-Duplikat-Cluster

Was zu tun ist: URLs mit identischen oder weitgehend überlappenden Hauptinhalten und demselben Suchzweck gruppieren. Warum es wichtig ist: Duplikate teilen interne Signale auf und zwingen Suchmaschinen, eine Version zu wählen, die das Unternehmen möglicherweise nicht bevorzugt. Wie es zu tun ist: Exakte Hashes, normalisierte Textähnlichkeit, Titel, Canonicals, Parameter und Vorlagenzweck vergleichen; dann Konsolidierung, Differenzierung, noindex oder Entfernung wählen. Tool: Crawler-Duplikatberichte, Seiteninventar und Google-Suchseiten . Erledigt, wenn: Kein Cluster mehr als eine unerklärte canonical indexierbare URL enthält, die demselben Zweck dient, und jede akzeptierte Variante einen dokumentierten, eigenen Zweck hat.

9. Finden Sie Waisen und messen Sie die Linktiefe

Was zu tun ist: Crawler-URLs mit Sitemaps, Analytik, Search Console, CMS-Exporten und Backlinks zusammenführen, um Seiten ohne crawlbare interne Verlinkung zu finden. Messen Sie den kürzesten Klickpfad von der Startseite. Warum es wichtig ist: Eine Waise kann in einer Sitemap erscheinen, aber wenig internen Kontext oder Autorität erhalten; übermäßige Tiefe macht die Entdeckung fragil. Wie es zu tun ist: Quellen vergleichen, Verzeichnismuster in Verzeichnisansicht prüfen und Navigation, Breadcrumbs, Hubs und kontextuelle Links verfolgen. Tool: https://app.amicited.com/reports/directory und ein Multi-Quellen-Crawl. Erledigt, wenn: Die Anzahl beabsichtigter Waisen null ist, Prioritätsseiten innerhalb von drei Klicks von der Startseite liegen, andere beabsichtigte indexierbare Seiten innerhalb von fünf Klicks und jede Ausnahme einen bewussten Entdeckungsweg hat.

10. Vergleichen Sie gerendertes und Nicht-JavaScript-HTML

Was zu tun ist: Die anfängliche Serverantwort mit der Seite nach Ausführung von JavaScript vergleichen. Warum es wichtig ist: Ein Browser kann Inhalte und Links anzeigen, die ein Nicht-JavaScript-Client nie erhält. Wie es zu tun ist: Repräsentative Seiten mit deaktivierten Skripten abrufen, rohes HTML inspizieren, dann Überschriften, Haupttext, Links, Canonical, Robots-Direktiven, strukturierte Daten und Status nach dem Rendering vergleichen. Tool: Crawler im HTML- und Rendering-Modus sowie Browser-Entwicklertools. Erledigt, wenn: Die anfängliche Antwort die primären Inhalte, Canonical, Index-Direktiven und crawlbare Navigation enthält, die zum Auffinden von Prioritätsseiten erforderlich sind; jede JavaScript-only-Abhängigkeit explizit akzeptiert und über Vorlagen getestet ist.

11. Validieren Sie hreflang, wo zutreffend

Was zu tun ist: Annotationen überprüfen, die sprachliche oder regionale Entsprechungen verbinden. Warum es wichtig ist: Unvollständige oder widersprüchliche Cluster können dazu führen, dass Suchmaschinen die Ausrichtung ignorieren und die falsche Marktversion anzeigen. Wie es zu tun ist: Gültige Sprach-Regions-Codes, absolute canonical URLs, Selbstreferenzen, gegenseitige Rückverlinkungen, x-default wo es eine tatsächliche Fallback-Rolle hat, und Indexierbarkeit jedes Ziels testen. Tool: Crawler-hreflang-Bericht und URL-Stichproben. Erledigt, wenn: Ungültige Codes, fehlende Selbstreferenzen, fehlende Rückverweise, nicht-canonicale Ziele, Weiterleitungen und Fehler alle bei null liegen. Wenn die Seite keine lokalisierten Entsprechungen hat, „nicht zutreffend" dokumentieren, anstatt Annotationen zu erfinden.

12. Testen Sie Paginierung und Crawl-Pfade

Was zu tun ist: Überprüfen, ob mehrseitige Kategorie- oder Archivsequenzen crawlbare Links und nützliche eindeutige URLs bereitstellen. Warum es wichtig ist: Unendliches Scrollen oder reines Button-Laden kann tiefere Elemente verstecken, während das Kanonikalisieren jeder Seite auf Seite eins das gesamte Inventar aus der Entdeckung entfernen kann. Wie es zu tun ist: JavaScript deaktivieren, Weiter- und Nummernlinks folgen, Status, Canonical- und Robots-Direktiven prüfen und die letzte Seite sowie außerhalb des Bereichs liegende Parameter testen. Tool: Nicht gerenderter Crawl und Browser. Erledigt, wenn: Jedes beabsichtigte Element über Ankerlinks erreichbar ist, jede nützliche Seite selbstkanonikalisiert, ungültige Seitennummern einen angemessenen Fehler anstelle eines weichen 200 zurückgeben und keine Sequenz einen unbegrenzten URL-Raum erzeugt.

13. Überprüfen Sie die mobile Parität

Was zu tun ist: Mobile und Desktop-Auslieferung für Inhalte, Links, Metadaten, Direktiven, strukturierte Daten und Antwortstatus vergleichen. Warum es wichtig ist: Google bewertet primär die mobile Darstellung; das Ausblenden bedeutender Inhalte oder Links nur auf Mobilgeräten ändert, was Google verstehen kann. Wie es zu tun ist: Mit Desktop- und Smartphone-User-Agents crawlen und repräsentative Vorlagen vergleichen, nicht nur visuelle Screenshots. Tool: Gepaarte Crawls, mobile URL-Inspektion und Browser-Responsive-Modus. Erledigt, wenn: Alle indexierbaren Inhalte und crawlbarer Links, die für Bedeutung und Entdeckung erforderlich sind, gleichwertig sind, mit null mobil-only-Blöcken, Canonical-Unterschieden oder Fehlerantworten.

14. Setzen Sie HTTPS durch und entfernen Sie Mixed Content

Was zu tun ist: Sichere Auslieferung, Host-Weiterleitungen, Zertifikate, canonical Schema, interne URLs und über HTTP geladene Ressourcen überprüfen. Mixed Content bedeutet, dass eine HTTPS-Seite eine unsichere Ressource anfordert. Warum es wichtig ist: Unsichere Anfragen können blockiert werden, setzen Benutzer Risiken aus und erzeugen inkonsistente URL-Signale. Wie es zu tun ist: Alle HTTP-Varianten crawlen, Zertifikatsabdeckung und Browser-Sicherheitsfehler prüfen und gerenderte Ressourcenanfragen durchsuchen. Tool: Crawler, Browser-Sicherheitspanel und Serverkonfiguration. Erledigt, wenn: Jede HTTP-Seite einmal auf ihre passende HTTPS-URL weiterleitet, alle Canonicals und internen Links HTTPS verwenden, Zertifikate für jeden Live-Host gültig sind und aktive oder passive Mixed-Content-Anfragen bei null liegen.

Tools in AmICited

Verwenden Sie Produktberichte als Checklisten-Belege, nicht als Crawl-Ersatz.

• Sitemaps und Indexierung unter https://app.amicited.com/reports/google-search/sitemaps-indexing zeigt den Zustand eingereichter Sitemaps, Warnungen, Fehler und Indexierungsaktionen.
• URL-Inspektion unter https://app.amicited.com/reports/google-search/url-inspection gibt Googles Live-Urteil für Stichproben-URLs und den ausgewählten Canonical.
• Bing-Crawl unter https://app.amicited.com/reports/bing-webmasters/crawl zeigt Bings Crawler-Aktivität und URL-bezogene Probleme.
• Google-Suchseiten unter https://app.amicited.com/reports/pages hilft bei der Auswahl hochwertiger Landingpages und trennt Seiten mit Sichtbarkeit von Seiten, die in Suchdaten fehlen.
• Verzeichnisansicht unter https://app.amicited.com/reports/directory zeigt bereichsbezogene Muster und unterstützt Tiefen- und Waisenuntersuchungen.
• Datengesundheit unter https://app.amicited.com/features/data-health/ dokumentiert, ob die angebundenen Belege vollständig genug sind, um fundierte Entscheidungen zu unterstützen.

Entscheidungsregeln

Schwellenwerte erzeugen Befunde; sie ersetzen kein Urteilsvermögen. Segmentieren Sie nach Vorlage und geschäftlicher Bedeutung: Zehn Fehler im Checkout-Bereich können wichtiger sein als tausend kaputte Archiv-Tags.

Priorisieren Sie mit Auswirkung × Aufwand × Vertrauen. Bewerten Sie die Auswirkung von 1–5 basierend auf betroffenen berechtigten URLs und Geschäfts-Journeys. Bewerten Sie den Aufwand von 1–5 als Erleichterungsfaktor, wobei 5 für eine kleine, umkehrbare Änderung und 1 für ein großes riskantes Programm steht; dokumentieren Sie auch die realistische Schätzung in Stunden oder Tagen. Bewerten Sie das Vertrauen mit 0,5 für eine plausible Hypothese, 0,75 für wiederholte Belege oder 1,0 für eine reproduzierte Ursache. Das Produkt ergibt eine Ordnungshilfe, keine falsche Präzision.

Wenden Sie die Abhängigkeitsübersteuerung an: Eine Korrektur, die andere Arbeiten freigibt, hat Vorrang vor einer größeren Bewertung, die dies nicht tut. Das Entfernen eines Robots-Blocks vor dem Launch hat Vorrang vor dem Polieren von indexierten Title-Tags. Auf derselben Abhängigkeitsebene gehen vorlagenweite Ursachen vor Symptomen.

Ergebnis: Das priorisierte Befundregister

Übergeben Sie ein gemeinsames Register, keinen Crawl-Export. Verwenden Sie eine Zeile pro Ursache und fügen Sie URL-Stichproben separat bei.

Das Register ist vollständig, wenn kritische und schwerwiegende Befunde Verantwortliche und Schätzungen haben, Blocker eine Reihenfolge haben, Hypothesen gekennzeichnet sind und die Veröffentlichungsentscheidung explizit ist.

Was schiefgeht

Ein 200-Punkte-Bericht, mit dem niemand arbeiten kann

Crawl-Exporte verwechseln Beobachtungen mit Entscheidungen. Gruppieren Sie wiederholte URLs unter der Vorlage oder Regel, die sie verursacht, stellen Sie eine repräsentative Stichprobe bereit und weisen Sie einen Verantwortlichen zu. Zweihundert defekte URLs, die von einer einzigen Navigationskomponente erzeugt werden, sind ein einziger ursachenbezogener Befund mit einem messbaren Umfang, nicht zweihundert Aufgaben.

Symptome statt Ursachen melden

„Seite nicht indexiert" ist ein Symptom. Die Ursache kann ein unbeabsichtigter Canonical, eine verwaiste Vorlage, dünne Parameter-Varianten, ein mobiler Fehler oder ein JavaScript-only-Link sein. Ein Befund ist erst bereit für die Priorisierung, wenn er die kontrollierbare Ursache identifiziert oder den nächsten diagnostischen Test klar benennt.

Versehentliches Auditieren von Staging

Staging kann andere Robots-Regeln, Authentifizierung, Daten, Vorlagen, Feature-Flags und Host-Verhalten aufweisen. Dokumentieren Sie den Produktions-Ursprung und die Search Console-Property oben in jedem Export. Wenn ein Crawl zu Release-Sicherungszwecken gegen Staging laufen muss, kennzeichnen Sie ihn als separaten Vergleich und führen Sie seine Metriken niemals mit der Produktions-Baseline zusammen.

Vermeiden Sie auch, bewusste Ausschlüsse als Verluste zu zählen, die Sitemap-Aufnahme als Indexierungsnachweis zu behandeln, nur die Startseite zu testen oder allein nach URL-Anzahl zu priorisieren. Definieren Sie die berechtigte Menge, segmentieren Sie nach Vorlage und bewahren Sie die Abnahmebelege auf.

Nächste Phase

Die nächste Phase, KI-Zugänglichkeit und Agentenbereitschaft , benötigt eine technisch stabile Stichprobe. Übergeben Sie das beabsichtigte indexierbare Inventar, saubere repräsentative URLs für jede Prioritätsvorlage, rohe und gerenderte HTML-Vergleiche, Robots- und Antwortbelege, Canonical-Entscheidungen, bekannte Ausschlüsse und das Register der offenen Befunde.

Behaupten Sie nicht, die Seite sei „technisch gesund". Geben Sie an, welche Vorlagen die Crawl- und Index-Tore bestanden haben, welche blockiert bleiben und ob die Veröffentlichung fortgesetzt werden kann. Der nächste Verantwortliche akzeptiert, wenn er KI-spezifische User-Agents und Extraktion testen kann, ohne ungelöste Such-Crawl-Fehler wiederzuentdecken.

FAQ

Wie oft sollten wir ein technisches Baseline-Audit wiederholen?

Führen Sie es vor einer Migration, einem Redesign, einem Domainwechsel oder einem großen Publishing-Programm durch und wiederholen Sie die betroffenen Prüfungen nach der Veröffentlichung. Überwachen Sie kontinuierlich und wiederholen Sie einen Standarddurchlauf, wenn sich Vorlagen, Navigation, Rendering oder Canonical-Regeln ändern.

Welches Indexierungsverhältnis sollte eine gesunde Seite haben?

Für absichtlich berechtigte URLs sind 90 % oder mehr die Ausgangserwartung, 80–90 % benötigen eine Erklärung, und unter 80 % ist ein Befund. Schließen Sie Weiterleitungen, Duplikate, Filter und absichtliche noindex-Seiten aus dem Nenner aus.

Können wir Inhalte veröffentlichen, während technische Korrekturen laufen?

Nur wenn neue URLs crawlbar, indexierbar, kanonikalisiert, intern verlinkt und vom Fehler nicht betroffen sind. Wenn die Entdeckung oder Auswahl blockiert ist, pausieren Sie; neue URLs vergrößern nur die Bereinigung.

Brauchen wir einen Crawler, wenn die Search Console angebunden ist?

Ja. Die Search Console berichtet, was Google beobachtet hat; ein Crawler testet die aktuelle Seite und deckt Links, Antworten, Tiefe, Canonicals und Duplikate auf. Keines ersetzt das andere.

Wer ist für die im Audit gefundenen Korrekturen verantwortlich?

Der SEO-Leiter ist für das Register und die Abnahmekriterien verantwortlich. Die Technik ist in der Regel für Server-, Rendering-, Redirect-, Canonical- und HTTPS-Korrekturen zuständig; Content-Teams können für Duplikate und Verlinkung zuständig sein. Jeder Eintrag benötigt eine benannte Person.