Beginne mit den beabsichtigten Seiten und wiederverwendbaren Nachweisen
Liste die öffentlichen Seiten auf, die du für Suchende auffindbar machen möchtest: wichtige Produkte, Artikel, Kategorien und verschobene URLs. Notiere für jede die bevorzugte URL, erwartete Antwort, Indexierbarkeit, Template, Verantwortlichen und Priorität. Halte legitime Ausschlüsse separat.
Erfasse eine nicht-authentifizierte Antwort, Header, Weiterleitungspfad, Seitenquelle, gerenderte Ansicht, internen Link-Status und Sitemap-Status für repräsentative URLs. Sample jedes Template und jedes URL-Muster. Nachweise sind datiert: Eine CDN-Einstellung, ein Deployment, eine Consent-Schicht oder Personalisierung kann sie später ändern.
Eine erfolgreiche Homepage beweist nicht, dass Listings, Produktvarianten oder lokalisierte Routen funktionieren.
Bewahre datierte Header und gerenderte Nachweise, damit Fixes und spätere Regressionen verglichen werden können.
Treffe Indexierbarkeitsentscheidungen bewusst
Indexierbarkeit bedeutet, dass eine Seite in einen Suchindex aufgenommen werden kann; es ist nicht dasselbe wie Crawling oder Ranking. Prüfe Meta-Robots-Direktiven im HTML und den X-Robots-Tag in den HTTP-Response-Headern. Die Direktive noindex sagt Suchmaschinen, eine Seite nicht anzuzeigen; X-Robots-Tag gilt auch für Nicht-HTML-Dateien wie PDFs.
Prüfe robots.txt separat. Ein Crawler muss auf eine Seite zugreifen, um ihre noindex-Direktive zu finden, daher kann das Blockieren dieser URL verhindern, dass die Direktive gesehen wird. Prüfe die bereitgestellte, öffentliche Antwort, denn CMS-Einstellungen und Umgebungsflags können Regeln hinzufügen. Noindex ist keine Zugriffskontrolle: Schütze sensible Inhalte mit Authentifizierung und einer entsprechenden Sicherheitsprüfung.
Markiere noindex, Login-Antworten, Staging-Referenzen und blockierte essentielle Assets auf Seiten, die indexierbar sein sollen.
Ein HTTP-Response-Header kann eine Direktive tragen, selbst wenn kein HTML-Head vorhanden ist.
Mache eine bevorzugte URL konsistent
Canonicalization identifiziert die bevorzugte URL unter doppelten oder sehr ähnlichen Versionen, z. B. HTTP und HTTPS, Hosts, Tracking-Parameter, Filter oder Druckseiten. Vergleiche das rel=canonical-Element, interne Links, die Sitemap-URL und das Weiterleitungsziel. Für eine indexierbare Seite sollten sie normalerweise dieselbe absolute bevorzugte URL nennen.
Verwende eine permanente serverseitige Weiterleitung beim Zurückziehen eines Duplikats. Google beschreibt permanente Redirects und rel=canonical als starke Signale, während die Aufnahme in die Sitemap ein schwächeres Signal ist; übereinstimmende Signale verstärken die Präferenz. Verwende robots.txt nicht zur Kanonisierung und vermeide konkurrierende Canonicals. Ein selbstreferenzierendes rel=canonical hilft, die bevorzugte Version zu benennen, aber die Auswahl durch Suchmaschinen liegt außerhalb deiner Kontrolle.
Dokumentiere Varianten, das bevorzugte Ziel, die erforderliche Steuerung und einen Verantwortlichen.
Teste Alt-zu-Neu-Zuordnungen vor einer Migration und halte eine umkehrbare Redirect-Änderung bereit.
Prüfe Statuscodes und Weiterleitungsverhalten
Statuscodes sagen Browsern und Crawlern, was passiert ist. Wichtige Live-Seiten sollten eine aussagekräftige 2xx-Antwort mit beabsichtigtem Inhalt zurückgeben. Eine Seite ohne relevanten Ersatz sollte eine echte 404- oder 410-Antwort liefern; verschobene Inhalte sollten ihren nächstgelegenen relevanten Ersatz erreichen. Eine 200-Seite, die nur einen Fehler anzeigt, kann als Soft-404 behandelt werden.
Erfasse jeden Weiterleitungshop. Google folgt im Allgemeinen bis zu 10 Hops beim generellen Web-Crawling, aber Ketten erhöhen Latenz und Fragilität. Google sagt, dass 5xx- und 429-Antworten das Crawling vorübergehend verlangsamen können und anhaltende Serverfehler schließlich indexierte URLs entfernen können. Untersuche wiederkehrende Fehler mit dem technischen Eigentümer über Anwendungs-, CDN-, Origin-, Cache-, Dependency- und Deployment-Schichten hinweg.
Speichere Original-URL, Hops, Codes, finale URL und erwarteten Zustand.
Entferne überlappende CMS-, CDN-, Host-, Locale- oder Slash-Regeln, statt einen weiteren Hop hinzuzufügen.
Validiere JavaScript-Rendering und Routen
Untersuche sowohl das initiale HTML als auch eine gerenderte Ansicht für wichtige Templates. Bestätige, dass Hauptinhalt, Überschriften, Links, Canonical, Robots-Direktiven und Zustand nach dem Rendering vorhanden sind. Google beschreibt separate Crawl-, Render- und Index-Phasen und sagt, dass Inhalt, der im gerenderten HTML nicht sichtbar ist, nicht indexiert werden kann.
Verwende Anker-Elemente mit href-Werten für die Navigation. Nur-Fragment-Routen, die distincten Inhalt laden, sind für die Auffindbarkeit nicht zuverlässig. Requeste direkt nicht existierende Produkte, Artikel und gefilterte URLs. Client-seitige Anwendungen brauchen einen echten Fehlerzustand; Google dokumentiert Routing zu einem Server-404 oder das Hinzufügen von noindex, um Soft-404s zu vermeiden. Server-Side-Rendering oder Prerendering kann helfen, aber verifiziere die bereitgestellte Antwort.
Prüfe Response-HTML, gerendertes HTML und die menschliche Browser-Ansicht auf wesentliche Unterschiede.
Bevorzuge das Quell-HTML; wenn JavaScript es setzt, stelle sicher, dass es ein nicht-konfligierendes Canonical gibt.
Halte Sitemaps und interne Links sauber
Eine Sitemap ist eine Entdeckungslandkarte, kein Indexierkommando. Nimm erfolgreiche, beabsichtigte, bevorzugte Canonical-URLs auf; schließe Weiterleitungen, Fehler, noindex-Seiten, Parameterduplikate und geschützte URLs aus. Google empfiehlt vollständig qualifizierte absolute URLs und betrachtet die Aufnahme in eine Sitemap als Canonical-Hinweis, nicht als Garantie.
Validiere die Sitemap und vergleiche sie mit der Liste der beabsichtigten Index-URLs und der Navigation. Google dokumentiert UTF-8-Kodierung und ein Limit von 50 MB unkomprimiert oder 50.000 URLs pro Sitemap. Für größere Sites in sinnvolle Gruppen aufteilen und einen Index verwenden. Aktualisiere lastmod nur bei signifikanten, verifizierbaren Seitenänderungen.
Untersuche bedeutende Unterschiede zwischen beabsichtigten URLs, Sitemap-Einträgen und internen Links.
Prüfe die generierte Sitemap und eine Stichprobe der gelisteten URLs nach Routing- oder CMS-Änderungen.
Messe Leistung und institutionalisiere das Audit
Nutze Felddaten, wo verfügbar, und kontrollierte Labortests, um Core Web Vitals zu untersuchen: Largest Contentful Paint (LCP) für das Laden, Interaction to Next Paint (INP) für Reaktionsfähigkeit und Cumulative Layout Shift (CLS) für visuelle Stabilität. Segmentiere nach Seitentyp und Gerät, da Mittelwerte ein kaputtes hochprioritäres Template verschleiern können.
Verfolge langsame oder instabile Auslieferung über Bilder, CSS und JavaScript, Drittanbieter-Tags, Fonts, Einbettungen und Caching. Mache eine gemessene Änderung und prüfe dann Rendering und Nutzerflüsse erneut. Felddaten spiegeln echte Nutzer wider; Labordaten helfen bei der Reproduzierbarkeit. Keines von beiden sagt etwas über jeden zukünftigen Crawler oder Besucher aus. Wiederhole einen fokussierten Regressionscheck nach riskanten Releases und ein vollständigeres Audit nach Migrationen oder Plattformwechseln.
Behebe Fehler in umsatzkritischen oder stark genutzten Templates, bevor du an kleinen Score-Gewinnen anderswo arbeitest.
Prüfe vor dem Schließen Antwort, Canonical, gerenderten Inhalt, Sitemap-Zustand und relevante Performance-Nachweise erneut.