Vorlage: Checkliste für das technische SEO-Audit
Prüfen Sie Crawlbarkeit, Indexierung, Geschwindigkeit und strukturierte Daten mit priorisierten, wiederholbaren Checklisten.
Arbeiten Sie diese Module durch, damit das technische Fundament solide bleibt. Notieren Sie zu jedem Problem Schweregrad und Verantwortlichen, damit die Behebungen wirklich ausgeliefert werden.
6 einsatzbereite Varianten
Audit von Crawlbarkeit & Indexierung
Stellen Sie sicher, dass Suchmaschinen genau die richtigen Seiten finden, crawlen und indexieren können – und nichts anderes.
Robots & Crawl-Anweisungen
- ☐ Bestätigen Sie, dass die robots.txt unter der Root-Domain auflöst und den Status 200 zurückgibt, nicht 4xx/5xx.
- ☐ Prüfen Sie, dass keine Disallow-Regel CSS, JavaScript oder wichtige Inhaltsverzeichnisse blockiert, die zum Rendern nötig sind.
- ☐ Prüfen Sie, dass Staging- oder Entwicklungs-Hosts vom Produktivsystem ausgesperrt sind und die Produktion nicht versehentlich seitenweit gesperrt ist (['Disallow: /']).
- ☐ Bestätigen Sie, dass in der robots.txt ein gültiger Verweis auf die Sitemap deklariert ist.
- ☐ Prüfen Sie Meta-Robots und X-Robots-Tag-Header auf ungewolltes noindex oder nofollow bei indexierbaren Seiten.
- ☐ Stellen Sie sicher, dass Seiten, die Sie indexiert haben möchten, nicht durch die robots.txt blockiert sind (eine gesperrte URL kann ihr eigenes noindex-Tag nicht auslesen).
XML-Sitemaps
- ☐ Bestätigen Sie, dass die Sitemap nur kanonische, indexierbare URLs mit Status 200 listet: keine Weiterleitungen, kein noindex, keine gesperrten URLs.
- ☐ Prüfen Sie, dass die Sitemap unter den Limits pro Datei bleibt (['50,000 URLs / 50 MB unkomprimiert']) und bei Bedarf einen Sitemap-Index verwendet.
- ☐ Prüfen Sie, dass URLs absolute, konsistente https-Pfade nutzen, die zur bevorzugten Domain passen.
- ☐ Reichen Sie die Sitemap in der Search Console ein und bestätigen Sie, dass sie fehlerfrei gelesen wird.
- ☐ Gleichen Sie die Anzahl der Sitemap-URLs mit der Anzahl indexierter Seiten ab und untersuchen Sie große Lücken.
Kanonisierung
- ☐ Bestätigen Sie, dass jede indexierbare Seite ein selbstreferenzierendes Canonical (absolute URL) deklariert.
- ☐ Prüfen Sie, dass Canonical-Tags auf aktive URLs mit Status 200 zeigen, nicht auf Weiterleitungen oder 404.
- ☐ Prüfen Sie auf widersprüchliche Signale (Canonical vs. noindex, Canonical vs. hreflang, Canonical vs. Sitemap).
- ☐ Stellen Sie sicher, dass Parameter-, Facetten-, Paginierungs- und Session-ID-Varianten korrekt kanonisieren.
- ☐ Bestätigen Sie, dass über http/https, www/non-www und Trailing-Slash-Varianten hinweg nur eine URL-Version kanonisch ist.
Index-Abdeckung
- ☐ Prüfen Sie den Bericht Seitenindexierung in der Search Console und triagieren Sie jeden Grund für Nicht indexiert.
- ☐ Untersuchen Sie Gecrawlt – zurzeit nicht indexiert und Erkannt – zurzeit nicht indexiert auf Qualitäts- oder Crawl-Budget-Probleme.
- ☐ Beheben Sie die Muster Duplikat – vom Nutzer nicht als kanonisch festgelegt und Alternative Seite mit richtigem kanonischen Tag.
- ☐ Nutzen Sie die URL-Prüfung, um gerendertes HTML, Canonical und Indexierbarkeit wichtiger Templates zu bestätigen.
- ☐ Prüfen Sie Server-Logs oder den Crawling-Statistik-Bericht auf Spitzen bei 4xx/5xx-Antworten und Crawl-Verschwendung.
- ☐ Bestätigen Sie, dass wichtige Seiten über interne Links erreichbar sind, nicht nur über die Sitemap.
Audit von Website-Architektur & interner Verlinkung
Sorgen Sie dafür, dass Ihre wichtigsten Seiten flach liegen, gut verlinkt sind und interne Linkkraft erhalten.
Crawl-Tiefe & Struktur
- ☐ Führen Sie einen vollständigen Crawl ab der Startseite durch und erfassen Sie die Klicktiefe für jede URL.
- ☐ Bestätigen Sie, dass Prioritätsseiten in geringer Tiefe zur Startseite liegen (['3 Klicks oder weniger']).
- ☐ Identifizieren Sie tiefe Seiten, die hinter Paginierung, Filtern oder dünnen Hub-Seiten vergraben sind, und flachen Sie die Struktur wo sinnvoll ab.
- ☐ Prüfen Sie eine logische, konsistente URL-Hierarchie, die die Website-Bereiche widerspiegelt.
- ☐ Bestätigen Sie, dass Hauptnavigation und Footer die Top-Kategorien und wichtigen Money-Seiten freigeben.
Verwaiste & Sackgassen-Seiten
- ☐ Gleichen Sie Crawl-Daten mit Sitemap sowie Analytics-/Log-Daten ab, um verwaiste Seiten zu finden (URLs ohne interne eingehende Links).
- ☐ Fügen Sie kontextuelle interne Links hinzu, um wertvolle verwaiste Inhalte zurückzugewinnen, oder entfernen/leiten Sie geringwertige Waisen um.
- ☐ Identifizieren Sie Sackgassen-Seiten mit wenigen oder keinen ausgehenden internen Links und ergänzen Sie relevante Links.
- ☐ Bestätigen Sie, dass paginierte und gefilterte Seiten weiterhin Crawl-Pfade zu den zugrunde liegenden Elementen freigeben.
Linkkraft & Ankertext
- ☐ Kartieren Sie die Anzahl interner eingehender Links und markieren Sie hochwertige Seiten, die zu wenig verlinkt sind.
- ☐ Reduzieren Sie Links auf geringwertige URLs (Login, Warenkorb, Hilfsseiten), die Linkkraft verwässern.
- ☐ Verwenden Sie beschreibenden, abwechslungsreichen, keyword-relevanten Ankertext statt des generischen hier klicken.
- ☐ Bestätigen Sie, dass wichtige interne Links crawlbare <a href>-Elemente sind, keine reinen JavaScript-Klick-Handler.
- ☐ Beheben Sie interne Links, die über Weiterleitungen laufen oder auf 404 landen, damit Linkkraft direkt fließt.
Breadcrumbs & Hub-Seiten
- ☐ Implementieren Sie Breadcrumb-Navigation auf tiefen Templates und zeichnen Sie sie mit BreadcrumbList-Structured-Data aus.
- ☐ Stellen Sie sicher, dass Breadcrumb-Links echte Anker sind und die wahre Website-Hierarchie widerspiegeln.
- ☐ Bauen oder stärken Sie Hub-/Kategorieseiten, die auf verwandte Cluster-Inhalte verlinken.
- ☐ Bestätigen Sie, dass Related-Content- und Kontextmodule thematisch relevante Seiten lateral untereinander verlinken.
Audit von Core Web Vitals & Performance
Diagnostizieren und priorisieren Sie die Ladegeschwindigkeits- und Stabilitätsprobleme, die Nutzererlebnis und Rankings schaden.
Felddaten & Diagnostik
- ☐ Prüfen Sie den Bericht Core Web Vitals in der Search Console und notieren Sie URL-Gruppen, die auf Mobil und Desktop durchfallen.
- ☐ Priorisieren Sie Feld- (Real-User-)Daten gegenüber Laborwerten; nutzen Sie Labortools nur zum Reproduzieren und Debuggen.
- ☐ Bestätigen Sie die Zielwerte: LCP bei oder unter ['2.5s'], INP bei oder unter ['200ms'], CLS bei oder unter ['0.1'] im 75. Perzentil.
- ☐ Auditieren Sie repräsentative Templates (Startseite, Kategorie, Produkt/Artikel) statt nur der Startseite.
Largest Contentful Paint (LCP)
- ☐ Identifizieren Sie das LCP-Element auf jedem wichtigen Template und bestätigen Sie, dass es früh lädt.
- ☐ Preloaden Sie das LCP-Bild oder die Schrift und vermeiden Sie Lazy-Loading von Above-the-Fold-Medien.
- ☐ Liefern Sie Hero-Bilder in modernen Formaten mit korrekten Abmessungen und responsivem srcset aus.
- ☐ Reduzieren Sie die Serverantwortzeit (TTFB) über Caching und ein CDN.
Interaction to Next Paint (INP)
- ☐ Brechen Sie lange JavaScript-Tasks auf und verzögern Sie unkritische Skripte.
- ☐ Minimieren Sie Main-Thread-Arbeit durch Drittanbieter-Tags, A/B-Tools und Chat-Widgets.
- ☐ Entfernen Sie ungenutztes JavaScript und CSS und splitten Sie große Bundles per Code-Splitting.
- ☐ Testen Sie echte Interaktionen (Taps, Menü-Öffnen, Formulareingaben) auf einem Mittelklasse-Mobilgerät.
Cumulative Layout Shift (CLS)
- ☐ Setzen Sie explizite Breite und Höhe (oder aspect-ratio) für Bilder, Videos und Embeds.
- ☐ Reservieren Sie Platz für Anzeigen, Banner und dynamisch eingefügte Inhalte.
- ☐ Preloaden Sie Webfonts und nutzen Sie font-display, um Layout-Verschiebungen durch Textwechsel zu begrenzen.
- ☐ Vermeiden Sie es, nach dem Laden Inhalte über bestehenden Inhalten einzufügen.
Auslieferung, Caching & Mobil
- ☐ Beseitigen Sie renderblockierendes CSS/JS und inlinen Sie nur kritisches CSS.
- ☐ Aktivieren Sie Textkomprimierung (gzip/Brotli) und langlebige Cache-Header für statische Assets.
- ☐ Prüfen Sie, dass HTTP/2 oder HTTP/3 und ein CDN die Assets nah an den Nutzern ausliefern.
- ☐ Bestätigen Sie, dass das mobile Layout responsiv ist, mit für Touch dimensionierten Tap-Zielen und Schriftgrößen.
- ☐ Testen Sie nach jeder Behebung erneut und beobachten Sie die Felddaten über ein vollständiges Erfassungsfenster, bevor Sie Erfolg verkünden.
Audit von strukturierten Daten & Rich Results
Validieren Sie, dass Ihr Schema-Markup korrekt und berechtigt ist und die Rich Results erhält, für die es qualifiziert ist.
Schema-Abdeckung & Typauswahl
- ☐ Inventarisieren Sie, welche Templates strukturierte Daten haben und welchen berechtigten Templates sie fehlen.
- ☐ Ordnen Sie jede Seite den passenden Typen zu (['Article, Product, FAQPage, BreadcrumbList, Organization, LocalBusiness']).
- ☐ Bevorzugen Sie JSON-LD im Seitenquelltext und halten Sie pro Seite ein konsistentes Markup-Format.
- ☐ Implementieren Sie eine Organization- oder Site-Level-Entität mit Logo und sameAs-Profilen, wo relevant.
Regeln zu Korrektheit & Berechtigung
- ☐ Bestätigen Sie, dass ausgezeichnete Inhalte für Nutzer auf der Seite sichtbar sind: keine versteckten oder rein im Markup vorhandenen Daten.
- ☐ Nehmen Sie alle erforderlichen Eigenschaften je Typ auf und ergänzen Sie empfohlene, um die Berechtigung zu stärken.
- ☐ Stellen Sie sicher, dass Werte wahrheitsgemäß und aktuell sind (Preis, Verfügbarkeit, Bewertungen, Daten) und den Seiteninhalt widerspiegeln.
- ☐ Verwenden Sie Review-/Rating-Markup nur für echte Bewertungen auf der Seite und befolgen Sie die aktuellen Richtlinien zu eigennützigen Bewertungen.
- ☐ Bestätigen Sie, dass Entitätsreferenzen und IDs über zusammenhängende Markup-Blöcke hinweg konsistent sind.
Validierung & Testen
- ☐ Prüfen Sie jedes wichtige Template mit dem Rich Results Test und einem Schema-Validator.
- ☐ Beheben Sie alle gemeldeten Fehler und lösen Sie Warnungen auf, die Verbesserungen blockieren.
- ☐ Testen Sie das gerenderte HTML, da manches Markup nach dem Laden per JavaScript eingefügt wird.
- ☐ Prüfen Sie stichprobenartig mehrere echte URLs pro Template, nicht nur ein Beispiel.
Monitoring & Wartung
- ☐ Verfolgen Sie jeden Rich-Result-Typ in den Verbesserungen-Berichten der Search Console auf neue Fehler.
- ☐ Richten Sie Alerts oder eine wiederkehrende Prüfung nach Template-, CMS- oder Plugin-Änderungen ein.
- ☐ Re-validieren Sie, wenn sich Richtlinien ändern oder ein Feature eingestellt wird.
- ☐ Führen Sie ein Log, welche Templates welche Schema-Typen ausgeben und wer sie verantwortet.
Audit von internationalem SEO
Stellen Sie sicher, dass die richtige Sprach- und Regionalversion jeder Seite für die richtige Zielgruppe ausgeliefert und indexiert wird.
hreflang-Umsetzung
- ☐ Bestätigen Sie, dass jede Seite in einem Sprach-/Regionsset auf alle Alternativen verlinkt, inklusive eines selbstreferenzierenden hreflang.
- ☐ Prüfen Sie, dass Rücktags bidirektional sind: jede Alternative verlinkt auf die anderen zurück (keine einseitigen Verweise).
- ☐ Verwenden Sie gültige Sprach- und optionale Regionscodes (['en, en-GB, es-MX']) im ISO-Format.
- ☐ Nehmen Sie ein x-default-Tag als globales Fallback bzw. für den Sprachwähler auf.
- ☐ Wählen Sie eine Auslieferungsmethode (HTML-Head, HTTP-Header oder Sitemap) und wenden Sie sie konsistent an.
- ☐ Verweisen Sie hreflang-URLs auf aktive, indexierbare, kanonische Seiten mit Status 200 – niemals auf Weiterleitungen oder noindex-Seiten.
Zusammenspiel von Canonical & Indexierung
- ☐ Stellen Sie sicher, dass jede lokalisierte URL selbstkanonisch ist und nicht auf eine andere Sprachversion kanonisiert wird.
- ☐ Bestätigen Sie, dass hreflang und Canonical sich auf derselben Seite nicht widersprechen.
- ☐ Prüfen Sie, dass nahezu doppelte lokalisierte Seiten nicht auf ein einziges Canonical zusammengeführt werden.
- ☐ Prüfen Sie, dass lokalisierte Seiten in ihren eigenen Sitemaps mit korrekten Alternate-Verweisen erscheinen.
Geo-Targeting & URL-Struktur
- ☐ Bestätigen Sie eine klare, skalierbare Struktur für Sprachen/Regionen (ccTLD, Subdomain oder Unterverzeichnis) und wenden Sie sie konsistent an.
- ☐ Setzen Sie Länder-Targeting, wo sinnvoll, und richten Sie es an Ihrer URL-Strategie aus.
- ☐ Vermeiden Sie IP-basierte Auto-Weiterleitungen, die Crawler blockieren oder Nutzer in der falschen Version einsperren; bevorzugen Sie ein Sprachbanner oder einen Wähler.
- ☐ Lokalisieren Sie Inhalte sinnvoll (Währung, Einheiten, Kontaktdaten, Schreibweise), statt eine Sprache zu duplizieren.
Validierung
- ☐ Crawlen Sie die Website mit aktiviertem hreflang-Reporting und beheben Sie fehlende oder defekte Rücktags.
- ☐ Nutzen Sie die URL-Prüfung, um zu bestätigen, wie Alternativen erkannt werden.
- ☐ Prüfen Sie stichprobenartig mehrere Sprachräume auf korrektes Rendern, Indexierbarkeit und Auslieferung.
- ☐ Auditieren Sie erneut, nachdem Sie neue Sprachräume oder Templates hinzugefügt haben.
Audit von Website-Migration / Relaunch
Schützen Sie Rankings und Traffic vor, während und nach einer Migration oder einem Relaunch, indem Sie Weiterleitungen und Parität prüfen.
Vorbereitung vor dem Launch
- ☐ Crawlen Sie die Live-Website und exportieren Sie als Baseline ein vollständiges Inventar indexierbarer URLs, Titel, Metadaten und Statuscodes.
- ☐ Erfassen Sie die Baseline-Leistung: Top-organische Landingpages, Rankings, Traffic, Conversions und Index-Abdeckung.
- ☐ Bestätigen Sie, dass die Staging-Site von der Indexierung ausgeschlossen und geschützt ist (Auth oder IP-Allowlist), aber prüfen Sie, dass die Direktiven beim Launch entfernt werden.
- ☐ Erstellen Sie eine vollständige Weiterleitungskarte von jeder alten URL zu ihrem nächsten neuen Äquivalent.
- ☐ Bereiten Sie neue XML-Sitemaps, robots.txt und Analytics-/Search-Console-Properties für die neue Struktur vor.
Weiterleitungs-Mapping
- ☐ Verwenden Sie permanente 301-Weiterleitungen für geänderte URLs und vermeiden Sie 302 für dauerhafte Umzüge.
- ☐ Mappen Sie alte URLs eins-zu-eins auf relevante neue Seiten; vermeiden Sie Massenweiterleitungen zur Startseite.
- ☐ Beseitigen Sie Weiterleitungsketten und -schleifen, damit jede alte URL in einem einzigen Hop auflöst.
- ☐ Erhalten oder migrieren Sie hreflang, Canonical und strukturierte Daten auf die neuen URLs.
- ☐ Planen Sie für Legacy-Parameter, Mediendateien und alle URLs mit externen Backlinks.
Inhaltliche & technische Parität
- ☐ Prüfen Sie, dass Titel, Meta-Descriptions, Überschriften, Body-Inhalt und Bilder übernommen oder verbessert wurden.
- ☐ Bestätigen Sie, dass interne Links direkt auf neue URLs zeigen, nicht über Weiterleitungen.
- ☐ Prüfen Sie, dass Canonical-Tags, strukturierte Daten und hreflang auf den neuen Templates korrekt sind.
- ☐ Vergleichen Sie Core Web Vitals und wichtige Seitengeschwindigkeit vorher und nachher, um Regressionen zu erkennen.
Validierung beim & nach dem Launch
- ☐ Entfernen Sie beim Go-Live die Staging-noindex/robots-Sperren und bestätigen Sie, dass die Produktivseite crawlbar ist.
- ☐ Reichen Sie neue Sitemaps ein und nutzen Sie die URL-Prüfung, um für Prioritätsseiten die Indexierung anzufordern.
- ☐ Re-crawlen Sie die neue Website, um zu bestätigen, dass Weiterleitungen auflösen, keine kritischen 404 existieren und kein Template ungewolltes noindex ausgibt.
- ☐ Überwachen Sie Index-Abdeckung, Crawling-Statistik, Rankings und Traffic in den ersten Wochen täglich und achten Sie auf anhaltende Einbrüche.
- ☐ Halten Sie Weiterleitungen langfristig aktiv und beheben Sie neu entdeckte defekte Pfade.
So verwendest du diese Vorlage
- Definieren Sie den Umfang und ziehen Sie eine Baseline: Listen Sie die zu auditierenden Templates und URL-Sets auf und exportieren Sie dann Search-Console-Berichte (Seitenindexierung, Core Web Vitals, Verbesserungen sowie wichtige Leistungs-/Traffic-Daten) als Referenzpunkt.
- Führen Sie einen vollständigen Crawl ab der Startseite mit aktiviertem Rendering durch und erfassen Sie für jede URL Statuscodes, Canonicals, Meta-Robots, hreflang, interne Links, Klicktiefe und Indexierbarkeit.
- Gleichen Sie die Crawl-Daten mit der XML-Sitemap, Analytics und Server-Logs ab, um verwaiste Seiten, Crawl-Verschwendung und Lücken zwischen eingereichten und indexierten URLs aufzudecken.
- Protokollieren Sie jeden Befund in einem Tracker mit Schweregrad-Bewertung (kritisch/hoch/mittel/niedrig), den betroffenen URLs oder Templates und einem namentlich benannten Verantwortlichen (Engineering, Content oder SEO).
- Beheben Sie zuerst Crawl- und Index-Blocker mit hohem Schweregrad (versehentliche noindex-/robots-Sperren, defekte Canonicals, Weiterleitungsketten und 5xx-Fehler), bevor Sie kosmetische Probleme angehen.
- Arbeiten Sie die Liste nach Schweregrad durch – Architektur, Performance, strukturierte Daten und internationale Korrekturen – und validieren Sie jede mit dem passenden Testtool (URL-Prüfung, Rich Results Test, Performance-Diagnostik).
- Re-crawlen und re-testen Sie nach dem Ausrollen der Behebungen, um die Lösung zu bestätigen und Regressionen zu erkennen; bei Feldmetriken wie Core Web Vitals warten Sie ein vollständiges Datenerfassungsfenster ab, bevor Sie die Wirkung beurteilen.
- Legen Sie einen wiederkehrenden Audit-Rhythmus fest (zum Beispiel ein Tiefen-Audit pro Quartal plus laufendes Monitoring) und führen Sie das relevante Modul nach jeder größeren Website-, Template- oder CMS-Änderung erneut aus.
Profi-Tipps
- Vertrauen Sie bei Core Web Vitals stets Feld- (Real-User-)Daten mehr als einmaligen Laborwerten: ein einzelner schneller Laborlauf kann Probleme verbergen, auf die echte Besucher mit langsameren Geräten und Netzen stoßen.
- Auditieren Sie nach Template, nicht nach einzelner Seite: eine Produkt- oder Artikelseite zu beheben behebt meist tausende, also nehmen Sie mehrere URLs pro Template als Stichprobe und schieben Sie Fixes stromaufwärts ins Template oder CMS.
- Crawlen Sie den gerenderten DOM, nicht nur das rohe HTML, wenn die Website auf JavaScript setzt: clientseitig eingefügte Canonicals, Links und strukturierte Daten können von der ersten Antwort abweichen.
- Verknüpfen Sie jeden Befund im Moment der Protokollierung mit einem Schweregrad und einem Verantwortlichen; ein Audit bewegt nur dann etwas, wenn wirkungsstarke Punkte priorisiert sind und jemand für die Auslieferung der Behebung verantwortlich ist.
Haeufige Fragen
Wie oft sollte ich ein technisches SEO-Audit durchführen?
Für die meisten Websites funktioniert ein umfassendes technisches Audit pro Quartal gut, gepaart mit laufendem Monitoring dazwischen. Große, sich häufig ändernde Websites (große E-Commerce- oder Nachrichten-Publisher) profitieren von monatlichen Tiefenanalysen, während kleine, stabile Websites oft ein halbes Jahr auskommen. Über den Zeitplan hinaus sollten Sie das relevante Audit-Modul stets nach jedem größeren Ereignis ausführen: einer Migration, einem Relaunch, einer CMS-Änderung oder einem Template-Update, denn genau dann werden technische Probleme eingeführt.
Was ist der Unterschied zwischen einem Audit und laufendem Monitoring?
Ein Audit ist eine punktuelle, umfassende Überprüfung, bei der Sie systematisch Crawlbarkeit, Architektur, Performance, strukturierte Daten und mehr inspizieren, um Probleme zu finden und zu priorisieren. Monitoring ist die kontinuierliche, automatisierte Schicht, die zwischen den Audits auf neue Probleme achtet und Index-Abdeckung, defekte Links, Statuscode-Spitzen, Core Web Vitals und Structured-Data-Fehler verfolgt, damit Regressionen schnell auffallen. Audits setzen die Richtung und decken tiefe Probleme auf; Monitoring fängt neue schnell ab. Sie brauchen beides.
Sind Core Web Vitals ein Ranking-Faktor?
Ja. Core Web Vitals sind Teil der Page-Experience-Signale von Google und können Rankings beeinflussen, besonders als Tiebreaker zwischen Seiten ähnlicher Relevanz und Qualität. Sie sind kein Allheilmittel (relevante, hilfreiche Inhalte bleiben der dominierende Faktor), behandeln Sie Core Web Vitals also als bedeutsame Nutzererlebnis- und Ranking-Größe, die es richtig zu machen gilt, nicht als Ersatz für Inhaltsqualität und die allgemeine Gesundheit der Website.
Rendert Google JavaScript, und warum ist das für ein Audit wichtig?
Google kann JavaScript rendern, aber das Rendering geschieht in einem zweiten Durchlauf nach dem ersten Crawl und hängt davon ab, dass die Ressourcen crawlbar sind. Wenn kritischer Inhalt, interne Links, Canonicals oder strukturierte Daten erst nach dem Ausführen von clientseitigem JavaScript erscheinen, werden sie womöglich spät entdeckt oder verpasst, falls Skripte blockiert sind oder fehlschlagen. Prüfen Sie während eines Audits immer den gerenderten DOM zusätzlich zum rohen HTML und bestätigen Sie, dass Ihre robots.txt das für das Rendering nötige JavaScript und CSS erlaubt.
Welche technischen Probleme sollte ich zuerst beheben?
Priorisieren Sie alles, was das Crawlen oder Indexieren wichtiger Seiten blockiert: versehentliche noindex-Tags, zu breite robots.txt-Disallow-Regeln, defekte oder widersprüchliche Canonicals, Serverfehler (5xx) sowie Weiterleitungsketten oder -schleifen. Diese können Seiten vollständig aus der Suche entfernen und wiegen daher schwerer als kosmetische Korrekturen. Nachdem Sie Crawl- und Index-Blocker beseitigt haben, arbeiten Sie sich nach Schweregrad durch Website-Architektur, Core Web Vitals, strukturierte Daten und internationale Themen.
Wie lange nach dem Beheben von Problemen sehe ich Ergebnisse?
Das variiert je nach Problem und wie schnell Suchmaschinen die betroffenen Seiten neu crawlen. Das Entfernen eines Index-Blockers kann sich für Prioritäts-URLs, die Sie über die URL-Prüfung anfordern, innerhalb von Tagen widerspiegeln, während breite Änderungen auf einer großen Website Wochen dauern können, bis das Re-Crawling abgeschlossen ist. Feldbasierte Metriken wie Core Web Vitals aktualisieren sich erst, nachdem ein vollständiges Datenerfassungsfenster vergangen ist, rechnen Sie also mit einer Verzögerung, bevor Verbesserungen in diesen Berichten erscheinen. Re-crawlen, validieren und überwachen Sie, statt eine sofortige Änderung anzunehmen.