Zum Inhalt springen
Strategie-Call buchen
info@ibramdawwa-gmbh.deRegensburg, Deutschland ·  

Kostenloses Werkzeug

Die Relaunch-Checkliste, die ihre Quellen nennt

Die 56 Punkte, ohne die eine Website laut dem Developer Kit unserer Wissensbasis nicht live gehen sollte. Zu jedem Punkt: warum er zählt, wie Sie ihn umsetzen und testen und auf welcher Google-Quelle er beruht. Gefiltert nach Ihrer Situation, kostenlos und ohne Anmeldung.

Von Ibram & Dawwa GmbHAktualisiert am 13. Oktober 2026Quellen geprüft am 13. Oktober 2026Wissensbasis v2.13.0

So nutzen Sie die Liste

  1. Wählen Sie Ihre Situation: Relaunch, Domainwechsel, Plattform- oder Framework-Wechsel oder eine mehrsprachige Website bzw. eine neue Sprache. Die Liste zeigt dann die Punkte, die dafür zählen – gegliedert in „Vor dem Go-live“, „Am Go-live-Tag“ und „In den Wochen danach“. Trifft mehreres zu, wählen Sie „Alle Situationen“.
  2. Öffnen Sie einen Punkt: Sie sehen, warum er zählt, wie Sie ihn umsetzen und testen und auf welchen Quellen er beruht – Googles Dokumentation und Aussagen auf der Search Central Live.
  3. Haken Sie ab, was erledigt ist: einen Pflicht-Punkt, sobald er umgesetzt ist; einen Tabu-Punkt, sobald Sie geprüft haben, dass die Website das nicht tut.
  4. Exportieren Sie die Liste als CSV für Jira, Linear oder GitHub – die Testspalte dient als Abnahmekriterium – oder drucken Sie sie für die Freigabe aus.

Nichts wird gescannt: Die Seite fragt nach keiner URL und ruft Ihre Website nie auf. Ihre Häkchen bleiben in Ihrem Browser.

Jeder der 56 Punkte ist in Googles Dokumentation belegt; viele wurden auf der Search Central Live 2026 zusätzlich erläutert. Die Liste gibt den Stand der Wissensbasis v2.13.0 wieder, mit Daten bis zum 2. Oktober 2026.

Ihre Situation

0 von 56 erledigt

56 von 56 Punkten angezeigt

Nichts wird gescannt: Diese Seite ruft Ihre Website nie auf.

Ihre Häkchen speichert nur Ihr Browser (lokaler Speicher). Sie werden nicht an uns übertragen.

Vor dem Go-live

  1. Verifizierte Google-Crawler durch Firewall, CDN und Bot-Schutz lassen

    PflichtDEV-SRV-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google merkt nicht, dass eine Firewall- oder Bot-Regel es aussperrt – es sieht nur fehlschlagende Anfragen. Timeouts, Verbindungsabbrüche und DNS-Fehler wertet Google wie 5xx-Fehler: Das Crawling wird sofort gedrosselt, und indexierte URLs, die unerreichbar bleiben, fallen binnen Tagen aus dem Index.
    So geht’s
    Geben Sie Googles Crawler in den Regeln von WAF, CDN und Bot-Management frei – anhand der von Google veröffentlichten IP-Bereiche (common-crawlers.json, special-crawlers.json) oder per Reverse-DNS-Abgleich auf crawl-*.googlebot.com bzw. geo-crawl-*.geo.googlebot.com, nie allein anhand des User-Agents. Drosseln Sie den verifizierten Googlebot nicht und zeigen Sie ihm keine CAPTCHAs oder JavaScript-Rätsel; sorgen Sie für eine zuverlässige DNS-Auflösung aller Hosts und prüfen Sie die Regeln nach jeder Änderung bei CDN oder Sicherheitsanbieter.
    So testen Sie
    Im Bericht „Crawling-Statistiken“ der Search Console zeigt der Hoststatus keine Fehler beim Abruf der robots.txt, bei der DNS-Auflösung oder der Serververbindung. Der Live-Test der URL-Prüfung gelingt für eine URL pro Vorlage, und die WAF- und CDN-Logs zeigen keine 403-, 429- oder Challenge-Antworten an IPs, die sich als Googlebot verifizieren lassen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Kein CDN und kein Bot-Schutz im Weg: Sieben User-Agents, darunter Googlebot, erhielten identische 200-Antworten, 16 parallele Anfragen ebenfalls (Crawling-Statistiken der Search Console für diesen Check nicht ausgewertet).

  2. Bot-Challenges und Fehlerseiten nie mit Status 200 an Crawler ausliefern

    TabuDEV-SRV-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Eine Bot-Challenge-Seite erkennt Google nur sehr schwer als Fehler. Wird sie auf vielen URLs mit 200 ausgeliefert, kann Google diese URLs als Duplikate zusammenfassen und fallen lassen – und davon erholt sich eine Website nur langsam. Eine Fehlerseite mit 200 ist außerdem ein Soft-404.
    So geht’s
    Muss ein Crawler eine Challenge- oder Sperrseite bekommen, senden Sie sie mit 503 (so empfiehlt es Googles CDN-Leitfaden für Bot-Prüfseiten) oder bei Ratenbegrenzung mit 429, nie mit 200. In den meisten CDN- und Bot-Management-Produkten lässt sich dieser Statuscode einstellen; besser noch: Schicken Sie verifizierten Google-Crawlern gar keine Challenge.
    So testen Sie
    Rufen Sie einige URLs mit Googlebot-User-Agent von einer nicht verifizierten IP ab: Jede Challenge kommt mit 503 oder 429, nie mit 200. Der Bericht „Seitenindexierung“ zeigt keinen plötzlichen Anstieg von „Duplikat“ oder „Soft 404“ bei URLs, die nichts miteinander zu tun haben.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Es gibt keine Challenge- oder Zwischenseite: Crawler und Browser erhalten dieselbe Seite, unbekannte URLs antworten mit 404 statt 200.

  3. robots.txt auf jedem Host erreichbar halten: 200 mit Regeln oder 404 ohne

    PflichtDEV-SRV-04ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Antwortet die robots.txt mit einem 5xx-Fehler, stellt Google das Crawling für die ersten 12 Stunden ein und stützt sich danach bis zu 30 Tage auf eine zwischengespeicherte Kopie. Die Regeln gelten je Host und nur im Stammverzeichnis: Die Datei auf www wirkt nicht für einen API- oder CDN-Host.
    So geht’s
    Stellen Sie /robots.txt im Stammverzeichnis jedes Hostnamens bereit, der Seiten oder Ressourcen fürs Rendering ausliefert (www, die Domain ohne www, API-, Static-, CDN- und Länder-Hosts): 200 mit den Regeln oder 404, wenn der Host keine hat. Nehmen Sie die robots.txt von Wartungsmodus, WAF-Challenges und Authentifizierung aus.
    So testen Sie
    curl -I https://<jeder-host>/robots.txt liefert 200 oder 404 – nie 5xx, 401/403 oder eine Weiterleitung auf eine Login-Seite. Der robots.txt-Bericht der Search Console (unter Einstellungen) zeigt die Datei jedes Hosts als abgerufen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die robots.txt antwortet auf https://ibramdawwa.de mit 200; die www- und http-Varianten leiten in einem Schritt dorthin weiter.

  4. In der robots.txt nur die von Google unterstützten Felder nutzen (user-agent, allow, disallow, sitemap) und unter 500 KiB bleiben

    PflichtDEV-SRV-05ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google unterstützt nur user-agent, allow, disallow und sitemap und ignoriert alle anderen Zeilen wie crawl-delay – sie sparen bei Google also kein Crawl-Budget. Google liest nur die ersten 500 KiB der Datei und speichert sie in der Regel bis zu 24 Stunden zwischen; eine Änderung kann also einen Tag brauchen.
    So geht’s
    Decken Sie URL-Muster mit den Platzhaltern * und $ ab, statt URLs einzeln aufzuzählen; es gilt die längste passende Regel, bei widersprüchlichen Regeln die am wenigsten einschränkende. Schreiben Sie Feldnamen exakt, ergänzen Sie die Sitemap-Zeile mit absoluter URL und planen Sie Änderungen einen Tag im Voraus – oder fordern Sie im robots.txt-Bericht ein erneutes Crawling an.
    So testen Sie
    Prüfen Sie Abrufstatus, Warnungen und Fehler im robots.txt-Bericht der Search Console und testen Sie die Datei mit einem Parser nach RFC 9309, etwa Googles Open-Source-Bibliothek (github.com/google/robotstxt). Die Datei liegt deutlich unter 500 KiB, und wichtige URLs (Startseite mit Tracking-Parametern, JS-Bundles, API-Endpunkte, Filter-URLs) sind stichprobenartig gegen die Regeln geprüft.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die robots.txt hat vier Zeilen (User-Agent, Allow, Disallow: /api/, Sitemap), nur unterstützte Felder, weit unter 500 KiB.

  5. Keine Content-Signal- oder anderen Nicht-Standard-Zeilen zwischen user-agent-Zeilen setzen

    TabuDEV-SRV-06ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googlebot ignoriert eine unbekannte Zeile zwischen zwei user-agent-Zeilen und fasst beide User-Agents zu einer Gruppe zusammen; die folgenden Regeln gelten dann für beide. Bing beendet die Gruppe an dieser Zeile dagegen (gezeigt auf einer Google-Folie auf der Search Central Live) – dieselbe Datei sperrt also den einen Crawler und den anderen nicht. Verwaltete robots.txt-Dateien mancher CDNs fügen solche Zeilen ein.
    So geht’s
    Beginnen Sie jede Gruppe mit einer ununterbrochenen Folge von user-agent-Zeilen, gefolgt von ihren allow- und disallow-Regeln. Fügt ein CDN oder Plug-in Content-Signal oder Ähnliches ein, muss diese Zeile hinter den Regeln einer Gruppe stehen; prüfen Sie die erzeugte Datei nach jeder Änderung der CDN-Einstellungen.
    So testen Sie
    Rufen Sie die Live-Datei ab (curl https://www.example.com/robots.txt) und prüfen Sie, ob jede Folge von user-agent-Zeilen ununterbrochen ist; testen Sie sie im robots.txt-Tester der Bing Webmaster Tools und mit Googles Open-Source-Parser. Die zuletzt abgerufene Version im robots.txt-Bericht entspricht der Datei, die Ihr Team ausgeliefert hat.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die robots.txt hat eine einzige User-Agent-Gruppe und keine Content-Signal- oder sonstigen Nicht-Standard-Zeilen.

  6. Crawlern per HTTP/1.1 antworten (HTTP/2 optional), nie einen crawlbaren Host nur über HTTP/3 betreiben

    PflichtDEV-SRV-07ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googles Crawler unterstützen HTTP/1.1 (ihr Standard) und HTTP/2; HTTP/3 unterstützt Googlebot derzeit nicht. HTTP/2 kann Serverressourcen sparen, bringt aber keinen Ranking-Vorteil.
    So geht’s
    Jeder crawlbare Host muss über HTTP/1.1 antworten; HTTP/3 ist ein Zusatz für Browser. Stellen Sie sicher, dass CDN-, Firewall- und Load-Balancer-Regeln für HTTP/3-Verkehr (QUIC) keine HTTP/1.1- oder HTTP/2-Antworten stören. Wer kein Crawling über HTTP/2 möchte, beantwortet Googles HTTP/2-Anfragen mit 421.
    So testen Sie
    curl -I --http1.1 https://www.example.com/ liefert 200, und curl -I --http2 https://www.example.com/ liefert denselben Status und dieselben Canonical-, Robots- und Caching-Header (es sei denn, die Website antwortet bewusst mit 421). Die Crawling-Statistiken zeigen normale Antwortzeiten.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    HTTP/1.1 und HTTP/2 liefern für /seo denselben Status, dasselbe Canonical, dasselbe Robots-Meta-Tag und dieselben Caching-Header.

  7. Seiten, die in die Suche sollen, nie mit 401, 402 oder 403 an Crawler ausliefern

    TabuDEV-SRV-09ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    URLs mit einem 4xx-Status (außer 429) indexiert Google nicht, bereits indexierte entfernt es. Auf der Search Central Live hieß es, Google sehe in letzter Zeit mehr 403- und 402-Antworten an seine Crawler und nehme diese Seiten aus der Suche und den KI-Funktionen.
    So geht’s
    Stellen Sie sicher, dass Login-Schranken, Paywalls, Geo-Sperren und Bot-Management-Regeln verifizierten Google-Crawlern auf öffentlichen Seiten nie 401, 402 oder 403 liefern; für Artikel hinter einer Paywall gibt es das Markup für kostenpflichtige Inhalte statt einer Fehlermeldung. 401 und 403 bleiben Seiten vorbehalten, die nicht in die Suche gehören, etwa Kundenkonten.
    So testen Sie
    Crawling-Statistiken und Server-Logs zeigen auf indexierbaren Vorlagen keine 401-, 402- oder 403-Antworten an den verifizierten Googlebot, und der Live-Test der URL-Prüfung liefert für eine URL pro Vorlage 200.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Keine 401, 402 oder 403 für die sieben getesteten User-Agents, und alle 42 Sitemap-URLs antworten mit 200.

  8. Einem Crawler nur bei Bedarf eine eigene robots.txt-Gruppe geben – und diese vollständig machen

    PflichtDEV-SRV-10ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    robots.txt-Gruppen addieren sich nicht: Ein Crawler folgt nur der spezifischsten Gruppe, die ihn nennt, und ignoriert die *-Gruppe. Eine Googlebot-Gruppe, die nur /dogs/ sperrt, lässt Googlebot also alles crawlen, was die *-Gruppe sperrt (Beispiel von Dave Smart auf der Search Central Live).
    So geht’s
    Regeln, die für alle Crawler gelten, gehören in die *-Gruppe. Eine eigene Gruppe (Googlebot, Storebot-Google, ein KI-Crawler-Token) legen Sie nur an, wenn dieser Crawler andere Regeln braucht, und übernehmen jede gemeinsame Regel, die weiter gelten soll. Erzeugen Sie die Datei aus einer Vorlage, damit Änderungen an den gemeinsamen Regeln jede benannte Gruppe erreichen.
    So testen Sie
    Prüfen Sie jede benannte Gruppe mit Googles Open-Source-Parser für robots.txt und dem Token des Crawlers gegen Beispiel-URLs, die jeden in der *-Gruppe gesperrten Pfad abdecken: Jedes Ergebnis entspricht dem, was für diesen Crawler gedacht ist.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Es gibt keine eigene Gruppe für einzelne Crawler – eine Gruppe für alle User-Agents genügt dieser Website.

  9. Private Pfade nie per robots.txt verstecken, sondern per Authentifizierung schützen

    TabuDEV-SRV-11ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Die robots.txt ist keine Sicherheitsmaßnahme: Jeder kann die gesperrten Pfade lesen, und die Datei bittet nur seriöse Crawler, diese Pfade nicht abzurufen. Eine gesperrte URL kann trotzdem indexiert werden, wenn andere Websites darauf verlinken; für private Dateien verweist Google auf Passwortschutz.
    So geht’s
    Legen Sie Admin-Bereiche, interne Tools, Exporte und Staging hinter eine Authentifizierung oder eine IP-Allowlist oder nehmen Sie sie ganz vom Netz – und nennen Sie ihre Pfade nicht in der robots.txt. Soll eine öffentliche Seite nicht in die Suche, setzen Sie noindex und lassen Sie die Seite crawlbar.
    So testen Sie
    Die Live-robots.txt nennt keine Admin-, Backup-, Export- oder internen Pfade, und curl -I auf jeden privaten Pfad liefert ohne Zugangsdaten 401 oder 403.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die robots.txt nennt nur /api/, den Endpunkt des Kontaktformulars, der GET-Anfragen ablehnt (405); Admin- oder Backup-Pfade stehen nicht darin.

  10. Jeden Navigationslink als <a>-Element mit echter URL im href umsetzen

    PflichtDEV-URL-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google liest Links aus <a>-Elementen mit einer URL im href – einmal aus dem Server-HTML und noch einmal aus der gerenderten Seite – und nutzt sie, um Seiten zu finden und die Struktur der Website zu verstehen. Googlebot klickt nicht; ein Link, der nur per JavaScript funktioniert, führt Google womöglich nie zum Ziel.
    So geht’s
    Prüfen Sie jede Komponente, die Links ausgibt (Navigation, Breadcrumbs, Paginierung, Filter, Produktkacheln, Footer, Sprachwahl): Jede braucht <a href="/echter/pfad">, und die Link-Komponenten des Frameworks müssen dieses href auch rendern. Clientseitiges Routing darf den Klick abfangen, solange das href bleibt; reine Text-URLs oder die Sitemap allein reichen nicht, damit Google Seiten findet.
    So testen Sie
    In der URL-Prüfung (gerendertes HTML) und in einem Crawler mit und ohne JavaScript erscheint jeder Navigationspunkt als <a href="...">, und ein Crawl ab der Startseite erreicht alle wichtigen Vorlagen. Das gerenderte HTML enthält keine Navigation über onclick=, javascript:, routerLink oder href="#".
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jeder Navigationspunkt ist ein <a href> mit echter URL, und ein Crawl ab der Startseite, der nur Links folgt, erreichte alle 42 Sitemap-URLs.

  11. Nicht über onclick-Handler, javascript:-URLs, routerLink ohne href oder #-Pseudolinks navigieren

    TabuDEV-URL-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googles Dokumentation zu Links rät von diesen Mustern ab, und eine Google-Folie auf der Search Central Live ordnete sie unter „nicht auslesbar“ ein. So oder so kann sich Google nicht darauf verlassen, über sie Seiten zu finden – und sie sind in Single-Page-Apps und Filternavigationen verbreitet.
    So geht’s
    Ersetzen Sie jedes dieser Muster durch <a href="/pfad"> und behalten Sie Buttons für Aktionen, die die URL nicht ändern, etwa „In den Warenkorb“ oder das Öffnen eines Dialogs. URL-Fragmente (#) nutzen Sie nur dort, wo Google bewusst nicht folgen soll, etwa bei Filterkombinationen.
    So testen Sie
    Durchsuchen Sie Vorlagen und gerendertes HTML (Elements-Panel der DevTools, URL-Prüfung) nach onclick-Navigation, javascript:, routerLink ohne href, href auf span oder div und href="#/"; ein Crawler mit JavaScript-Rendering findet keine verwaisten Vorlagen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Das Server-HTML aller 42 Seiten enthält keine onclick-Links, keine javascript:-URLs, kein <a> ohne href und keine Pseudo-Links auf #.

  12. Single-Page-Apps über die History API mit echten Pfaden routen, nicht über #-Fragmente

    PflichtDEV-URL-03ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Ein Fragment (der Teil einer URL nach #) existiert nur im Browser und wird von Crawlern oft ignoriert; per Hash geroutete Ansichten sind für Google also keine eigenen Seiten. Google empfiehlt die History API für saubere URLs.
    So geht’s
    Betreiben Sie den Router im History-Modus: Links als <a href="/pfad"> rendern, den Klick abfangen, history.pushState aufrufen und popstate behandeln. Richten Sie Server oder Hosting-Rewrites so ein, dass ein direkter Aufruf jedes gültigen Pfads 200 mit der Seite liefert (idealerweise serverseitig gerendert) und unbekannte Pfade 404.
    So testen Sie
    Öffnen Sie eine tiefe URL direkt in einer frischen Browsersitzung und mit curl: Sie liefert 200 und den richtigen Inhalt. Das gerenderte HTML in der URL-Prüfung enthält keine Routen der Form href="#/...".
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jede Seite hat einen echten Pfad, der beim direkten Aufruf mit 200 und eigenem Inhalt antwortet; #/-Routen gibt es nicht.

  13. Jede indexierbare Seite aus der normalen Navigation oder einer Übersichtsseite verlinken

    PflichtDEV-URL-04ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google findet Seiten über Links und schließt aus den internen Links, wie wichtig eine Seite ist: wie viele auf sie zeigen und wie viele Klicks sie von der Startseite entfernt ist. Eine Seite, die nur über die Sitemap erreichbar ist, wird langsam gefunden und selten gecrawlt.
    So geht’s
    Verlinken Sie aus dem Menü auf Kategorieseiten, von dort auf Unterkategorien und von diesen auf jedes Produkt und jeden Artikel – immer mit <a href> – und halten Sie wichtige Seiten wenige Klicks von der Startseite entfernt. XML-Sitemap oder Merchant-Center-Feed ergänzen die Verlinkung, ersetzen sie aber nie.
    So testen Sie
    Crawlen Sie ab der Startseite nur über <a href>-Links und gleichen Sie das Ergebnis mit der Sitemap ab: Sitemap-URLs, die der Crawl nicht findet, sind verwaist. Prüfen Sie die Klicktiefe der wichtigen Vorlagen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Der Link-Crawl ab der Startseite fand alle 42 Sitemap-URLs ohne verwaiste Seite, die tiefste vier Klicks entfernt.

  14. Jeder Seite einer paginierten Liste eine eigene URL, ein eigenes Canonical und einen <a href>-Link zur nächsten Seite geben

    PflichtDEV-URL-06ibramdawwa.de: Trifft nicht zu

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googles Crawler klicken nicht auf „Weiter“-Buttons, und rel=next/rel=prev werden nicht mehr genutzt. Das Canonical von Seite 2 und folgenden auf Seite 1 zu setzen ist falsch, denn die Seiten sind keine Duplikate – Einträge, die nur auf späteren Seiten stehen, werden sonst womöglich nie indexiert.
    So geht’s
    Nutzen Sie URLs wie ?page=n (oder /page/n/), Seite 1 unter der schlichten Listen-URL; jede Seite trägt ein selbstreferenzierendes Canonical und <a href>-Links zur nächsten Seite und zurück zu Seite 1. Seitenzahlen gehören nie in ein #-Fragment, Sortier- und Filtervarianten bleiben außerhalb des Crawlings.
    So testen Sie
    Rufen Sie für die Seiten 1 bis 3 einer Liste das HTML per curl ab: Das Canonical verweist auf die Seite selbst, und der <a href>-Link zur nächsten Seite ist ohne JavaScript vorhanden. Die URL-Prüfung zeigt spätere Seiten als indexierbar.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Trifft nicht zu
    Die Website hat keine paginierten Listen: /work zeigt alle Projekte auf einer Seite, und /work?page=2 verweist per Canonical auf /work.

  15. Endlos-Scrollen und „Mehr laden“-Buttons auf paginierten URLs aufbauen

    PflichtDEV-URL-07ibramdawwa.de: Trifft nicht zu

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google rendert eine Seite in einem sehr hohen Viewport, statt zu scrollen, und Googlebot klickt keine Buttons. Inhalte, die erst nach weiterem Scrollen oder einem Klick auf „Mehr laden“ erscheinen, bleiben unsichtbar, wenn nicht jeder Abschnitt auch eine eigene URL hat.
    So geht’s
    Bauen Sie „Mehr laden“ und Endlos-Scrollen auf der paginierten Liste auf: Jeder Abschnitt hat eine dauerhafte URL, die auch beim direkten Aufruf funktioniert, die Abschnitte verlinken per <a href> aufeinander, und die History API aktualisiert die Adresse, sobald ein neuer Abschnitt den Großteil des sichtbaren Bereichs einnimmt. Lösen Sie das Nachladen per IntersectionObserver aus, nie per Scroll-Listener.
    So testen Sie
    Folgen Sie bei abgeschaltetem JavaScript dem „Mehr“-Link durch alle Seiten einer Liste. In der URL-Prüfung enthält das gerenderte HTML von Seite 1 einen crawlbaren Link auf Seite 2, und die Server-Logs zeigen, dass Googlebot die paginierten URLs abruft.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Trifft nicht zu
    Es gibt weder Endlos-Scrollen noch einen „Mehr laden“-Button; jede Liste steht vollständig im Server-HTML.

  16. Facettierte Navigation per robots.txt-Regeln oder URL-Fragmenten aus dem Crawling halten

    PflichtDEV-URL-08ibramdawwa.de: Trifft nicht zu

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Filter erzeugen nahezu unendliche URL-Räume (dieselben Filter in anderer Reihenfolge, widersprüchliche oder übermäßige Kombinationen), die Crawl-Budget verbrauchen. Googles Leitfaden zur facettierten Navigation setzt auf Vorbeugen: Filter-URLs per robots.txt sperren oder URL-Fragmente nutzen, die Google in der Regel nicht crawlt; rel=canonical und nofollow sind schwächere, langsamere Mittel.
    So geht’s
    Nur Filter mit echter Suchnachfrage bekommen eine indexierbare Landingpage mit sauberer URL, eigenem Inhalt und <a href>-Links. Alle übrigen Filter-, Sortier- und Ansichtsparameter sperren Sie per Disallow-Muster in der robots.txt oder verlegen sie ins #-Fragment; sperren Sie auch interne Suchergebnisse und Aktions-URLs (Warenkorb, Merkliste, Vergleich) und prüfen Sie CMS-Plug-ins auf erzeugte URL-Räume.
    So testen Sie
    Ein Crawl, der die robots.txt beachtet, findet eine begrenzte Zahl von Listen-URLs, und Server-Logs sowie Crawling-Statistiken zeigen keine Googlebot-Abrufe von Parameter-URLs. Googles Open-Source-Parser für robots.txt meldet mit dem Googlebot-Token für Beispiel-Filter-URLs „disallowed“ und für Artikelseiten „allowed“.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Trifft nicht zu
    Es gibt keine Facettennavigation und keine Filter- oder Sortierparameter; der Crawl fand keinen internen Link mit Query-String.

  17. Alle indexierbaren Inhalte schon beim Laden ins DOM bringen – ohne Klick, Eingabe oder Scrollen

    PflichtDEV-REN-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googlebot klickt nicht, gibt nichts ein und scrollt nicht. Inhalte, die erst nach einer Nutzeraktion geladen werden, fehlen beim Rendern im DOM und können nicht indexiert werden; Inhalte, die im DOM stehen, aber verborgen sind (Tabs, Akkordeons, „Weiterlesen“), dagegen schon.
    So geht’s
    Liefern Sie die Inhalte von Tabs, Akkordeons und „Weiterlesen“-Bereichen im ersten HTML oder DOM aus und verbergen Sie sie per CSS oder hidden-Attribut – nie erst per Klick nachladen. Technische Daten, Bewertungen, FAQs und Beschreibungen gehören beim Laden in die Seite.
    So testen Sie
    Das gerenderte HTML in der URL-Prüfung oder im Test für Rich-Suchergebnisse enthält Text aus jedem Tab und jedem Akkordeon-Panel. Im Network-Panel der DevTools wartet keine Inhaltsanfrage auf einen Klick.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Alle acht Situationstexte auf /seo und beide Vorher-nachher-Paare auf / und /studio stehen jetzt ohne Klick im Server-HTML und im gerenderten DOM.

  18. Lazy Loading nativ oder per IntersectionObserver umsetzen, nie über Scroll-Events

    PflichtDEV-REN-03ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googlebot scrollt nicht; ein Scroll-Event-Listener wird also nie ausgelöst, und die Inhalte, die er laden würde, erscheinen nicht. Stattdessen rendert Google mit einem sehr hohen Viewport – Inhalte, die beim Eintritt in den Viewport geladen werden, rendert Google also mit.
    So geht’s
    Setzen Sie loading="lazy" auf img- und iframe-Elemente, mit echtem src sowie width und height, und nutzen Sie für andere Komponenten einen IntersectionObserver. Indexierbare Inhalte dürfen nie von Scrollposition, Scrolltiefe oder einem Timer abhängen; lange Listen bekommen paginierte URLs.
    So testen Sie
    Das gerenderte HTML in der URL-Prüfung enthält Bilder und Listeneinträge unterhalb des sichtbaren Bereichs. Eine Codesuche findet keinen addEventListener('scroll')- oder onscroll-Handler, der Inhalte lädt.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Bilder nutzen natives Lazy Loading mit echter src, kein Scroll-Handler lädt Inhalte nach, und in einem Rendering ohne Scrollen zeigt jeder Zähler seinen Endwert und kein Textblock bleibt unsichtbar.

  19. JavaScript, CSS und API-Endpunkte, die Seiten zum Rendern brauchen, nicht per robots.txt sperren

    TabuDEV-REN-04ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googles Renderer ruft Skripte, Stylesheets und API-Anfragen über Googlebot ab und hält sich an die robots.txt: Was er nicht abrufen darf, kann er nicht ausführen. Ein gesperrter Skript- oder /api/-Ordner hinterlässt leere Module oder eine leere Seite, die als Soft-404 gelten kann, obwohl Nutzer eine vollständige Seite sehen.
    So geht’s
    Geben Sie alle JS-, CSS- und Font-Pfade frei. Muss ein API-Ordner gesperrt bleiben, nehmen Sie die fürs Rendern nötigen Endpunkte aus (Disallow: /api/ plus Allow: /api/products/), prüfen Sie die robots.txt jedes Hosts, von dem die Seite Daten lädt, und testen Sie nach jeder robots.txt-Änderung an Skript- oder API-Pfaden eine gerenderte Seite neu.
    So testen Sie
    Im Live-Test der URL-Prüfung ist keine Seitenressource, die für den Inhalt nötig ist, durch die robots.txt blockiert. Das Network-Panel der DevTools (Fetch/XHR) zeigt jeden API-Host, und dessen robots.txt erlaubt diese Pfade.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die robots.txt sperrt nur /api/, das keine Seite zum Rendern braucht; Skripte, Styles und Bilder sind crawlbar.

  20. Robots-Meta-Tags nicht per JavaScript hinzufügen, ändern oder entfernen

    TabuDEV-REN-05ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Per JavaScript gesetzte Robots-Regeln erkennt Google später, und ein noindex per JavaScript zu entfernen funktioniert nicht: Google rendert eine Seite, die mit noindex ankommt, unter Umständen gar nicht, sie bleibt also aus dem Index. Googles Dokumentation rät davon ab, Meta-Tags per JavaScript einzufügen oder zu ändern.
    So geht’s
    Entscheiden Sie über die Indexierbarkeit auf dem Server und senden Sie das endgültige Robots-Meta-Tag oder den X-Robots-Tag-Header schon in der ersten Antwort; liefern Sie nie ein noindex im HTML-Gerüst aus, um es nach der Hydration zu entfernen. Die einzige dokumentierte Ausnahme: noindex per JavaScript auf der Fehleransicht einer clientseitig gerenderten App.
    So testen Sie
    Das Robots-Meta-Tag in der curl-Ausgabe und im gerenderten HTML der URL-Prüfung ist auf jeder indexierbaren Vorlage identisch. Eine Suche im Client-Bundle findet keinen Code, der meta[name="robots"] schreibt – außer auf Fehleransichten.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Das Robots-Meta-Tag ist auf allen geprüften Vorlagen im Server-HTML und im gerenderten DOM identisch, und kein Client-Code schreibt es.

  21. Seiten per noindex aus der Suche halten – und die URL crawlbar lassen

    PflichtDEV-IDX-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Die robots.txt steuert nicht die Indexierung: Eine gesperrte URL kann ohne Inhalt in den Ergebnissen erscheinen, wenn andere Seiten auf sie verlinken. Und ein noindex auf einer Seite, die Google nicht abrufen darf, sieht Google nie.
    So geht’s
    Für Seiten, die gecrawlt, aber nicht indexiert werden sollen, senden Sie <meta name="robots" content="noindex"> oder X-Robots-Tag: noindex in der Serverantwort und sperren die URL nicht; die robots.txt ist nur für URLs da, die nie abgerufen werden sollen. Um bereits gesperrte URLs aus dem Index zu holen, setzen Sie zuerst das noindex und heben dann die Sperre auf, damit Google es sieht.
    So testen Sie
    Für jede URL mit noindex zeigt die URL-Prüfung, dass Crawling zulässig ist, curl zeigt das noindex, und der Bericht „Seitenindexierung“ führt die URL als durch das noindex-Tag ausgeschlossen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Nur die 404-Seite trägt noindex, und die robots.txt sperrt sie nicht.

  22. Crawl-Budget nicht mit noindex, nofollow oder crawl-delay sparen wollen

    TabuDEV-IDX-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    noindex verbraucht Crawl-Budget, weil Google die Seite abrufen muss, um es zu sehen; nofollow ist nur ein Hinweis: Die verlinkten URLs können über andere Links oder Sitemaps trotzdem gecrawlt werden; crawl-delay verarbeitet Google gar nicht.
    So geht’s
    Soll Google URLs Ihrer Website nicht abrufen, sperren Sie sie in der robots.txt; entfernte Seiten liefern 404 oder 410, Duplikate fassen Sie per Weiterleitung oder Canonical zusammen. Halten Sie die Crawling-Regeln stabil, statt Googlebot mit wechselnden Regeln umzulenken.
    So testen Sie
    Server-Logs zeigen kaum oder keine Googlebot-Abrufe von Parameter- und Aktions-URLs, die robots.txt enthält kein crawl-delay für Google, und die Crawling-Statistiken zeigen nach den Korrekturen weniger Abrufe wenig wertvoller URLs.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Nirgends steht nofollow oder crawl-delay; indexierbare Seiten tragen nur die großzügigen Vorschauregeln.

  23. Kein nosnippet und kein kurzes max-snippet setzen, es sei denn, Sie nehmen den Verlust von Snippets und von Sichtbarkeit in KI-Funktionen in Kauf

    TabuDEV-IDX-05ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    nosnippet entfernt das Text-Snippet und die Videovorschau und verhindert zudem, dass der Inhalt der Seite direkt in AI Overviews und den AI Mode einfließt; max-snippet schränkt diese Nutzung ebenfalls ein. Nur eine Seite, die für ein Snippet infrage kommt, kann in KI-Funktionen als unterstützender Link erscheinen.
    So geht’s
    Lassen Sie nosnippet und max-snippet-Grenzen standardmäßig weg; um ein einzelnes Detail wie eine Telefonnummer oder einen Mitgliederpreis auszublenden, setzen Sie data-nosnippet auf genau dieses Element. Verlangen Lizenzgründe Grenzen, setzen Sie sie bewusst je Vorlage und halten Sie den Zielkonflikt fest.
    So testen Sie
    Durchsuchen Sie Code, CMS-Einstellungen und CDN-Transformationen nach nosnippet und max-snippet und prüfen Sie wichtige Vorlagen per curl: Keines davon ist vorhanden, es sei denn, es ist gewollt.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Keine Seite nutzt nosnippet, und jede indexierbare Seite setzt max-snippet:-1, max-image-preview:large und max-video-preview:-1.

  24. Genau ein absolutes rel=canonical im serverseitig ausgelieferten head jeder indexierbaren Seite setzen

    PflichtDEV-CAN-03ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google nutzt rel=canonical beim Deduplizieren und bei der Wahl der kanonischen URL, wertet es aber als starken Hinweis, nicht als Anweisung – weil das Tag so oft falsch ist. Stehen mehrere Canonicals auf einer Seite, ignoriert Google wahrscheinlich alle.
    So geht’s
    Geben Sie jeder indexierbaren Seite ein selbstreferenzierendes Canonical mit absoluter URL auf dem gewählten Ursprung und lassen Sie Duplikate (Tracking-Parameter, Druckansichten, Sortierungen) auf die bevorzugte URL zeigen. Geben Sie es nur aus einer Schicht aus (nicht CMS, SEO-Plug-in und Framework zugleich), im vom Server gesendeten head und ohne ungültiges Element wie img oder iframe davor, denn an einem solchen Element hört Google auf, den head zu lesen; für PDFs nutzen Sie einen HTTP-Link-Header.
    So testen Sie
    Ein Crawl findet keine indexierbare Seite ohne Canonical oder mit mehreren Canonicals oder mit relativem oder Platzhalter-Wert, und Roh-HTML und gerendertes HTML tragen dasselbe Canonical. Die URL-Prüfung zeigt auf den wichtigen Vorlagen dieselbe vom Nutzer angegebene und von Google ausgewählte kanonische URL.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Alle 42 Sitemap-URLs haben genau ein absolutes Selbst-Canonical im Server-HTML, und das gerenderte Canonical stimmt damit überein.

  25. Jedes Canonical direkt auf eine endgültige URL setzen, die 200 liefert, indexierbar ist und verlinkt wird

    PflichtDEV-CAN-04ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google kann Canonical-Ketten folgen, empfiehlt aber nachdrücklich, jede Seite direkt auf eine einzige kanonische URL zeigen zu lassen. Das Ziel darf kein noindex tragen, keinen Fehler liefern, nicht per robots.txt gesperrt sein und nicht weiterleiten.
    So geht’s
    Lösen Sie jedes Canonical-Ziel beim Erzeugen der Seiten zur endgültigen URL auf und aktualisieren Sie die Canonicals nach Umzügen oder Hostwechseln. Verweisen Sie per Canonical nie auf eine URL, die weiterleitet, keinen 200-Status liefert, noindex trägt oder gesperrt ist; das Canonical-Ziel ist die URL, die auch die internen Links verwenden.
    So testen Sie
    Canonical-Audit im Crawler: URLs nach der endgültigen URL gruppieren, zu der Canonicals und Weiterleitungen führen, und markieren, was mehr als einen Schritt braucht, im Kreis läuft, mehrere Canonicals auf einer Seite hat oder auf ein Ziel zeigt, das noindex trägt, gesperrt ist, keinen 200-Status liefert, weiterleitet oder intern nicht verlinkt ist.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jedes Canonical zeigt auf die eigene URL, die mit 200 antwortet, kein noindex trägt und intern verlinkt ist.

  26. Alle Canonical-Signale in Einklang bringen: Weiterleitungen, rel=canonical, interne Links, Sitemaps und hreflang

    PflichtDEV-CAN-05ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Zeigen alle Signale auf dieselbe URL, folgt Google dem Websitebetreiber; widersprechen sie sich, kann Google nicht erkennen, was gewollt ist. Weiterleitungen und rel=canonical sind starke Signale, die Aufnahme in die Sitemap ein schwaches – zusammen wirken sie stärker.
    So geht’s
    Erzeugen Sie Canonical-Tags, Sitemap-Einträge, hreflang-URLs und interne Links aus einer gemeinsamen Funktion, damit sie nicht auseinanderlaufen, und gleichen Sie vor jeder Migration oder Vorlagenänderung jedes Signal mit der bevorzugten URL ab.
    So testen Sie
    Ein Crawl findet keine internen Links auf nicht kanonische URLs, keine Sitemap-URLs ohne Selbst-Canonical und keine hreflang-Ziele, die weiterleiten oder anderswohin kanonisieren. Stichproben in der URL-Prüfung zeigen übereinstimmende vom Nutzer angegebene und von Google ausgewählte kanonische URLs.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Interne Links, Sitemap und hreflang nutzen durchgehend die endgültigen URLs: Kein interner Link trifft auf eine Weiterleitung oder eine nicht kanonische URL.

  27. Sprachversionen nicht aufeinander kanonisieren, sondern per hreflang verbinden

    TabuDEV-CAN-06ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Ein Canonical von einer Sprachversion auf eine andere bittet Google, nur eine Sprache im Index zu behalten – nur diese Version würde dann erscheinen. Auf Seiten mit hreflang soll das Canonical auf eine Seite derselben Sprache zeigen oder, wenn es keine gibt, auf die bestmögliche Ersatzsprache.
    So geht’s
    Jede Sprach- oder Länderversion behält ihr selbstreferenzierendes Canonical und nennt ihre Alternativen per hreflang. Stellen Sie sicher, dass keine Vorlage auf übersetzten Seiten auf das Canonical der Standardsprache zurückfällt.
    So testen Sie
    Im Canonical-Audit enthält keine Canonical-Gruppe Dokumente in mehr als einer Sprache, und das Canonical jeder lokalisierten Seite ist ihre eigene URL.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jede englische und deutsche Seite verweist per Canonical auf sich selbst und ist per hreflang mit ihrem Gegenstück verbunden.

  28. Alte URLs nur auf eine Seite mit derselben Suchabsicht weiterleiten, sonst 404 oder 410 liefern

    PflichtDEV-CAN-10ibramdawwa.de: Teilweise erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googles Leitfaden zum Website-Umzug warnt davor, viele alte URLs auf ein unpassendes Ziel wie die Startseite weiterzuleiten: Das verwirrt Nutzer und kann als Soft-404 gewertet werden; für Inhalte, die nicht umziehen, soll der Server 404 oder 410 liefern. Ein 200 auf jeder neuen URL beweist nur, dass die URLs funktionieren – nicht, dass der Inhalt noch da ist, für den die Nutzer kamen.
    So geht’s
    Frieren Sie vor dem Go-live den URL-Bestand ein (CMS-Export, Crawl, Sitemaps, Suchdaten und Logs) und lassen Sie eine Weiterleitungstabelle freigeben, mit einer Zeile pro alter URL: ein Ziel mit derselben Suchabsicht oder 404 bzw. 410. Nach dem Go-live prüfen Sie die Live-Website gegen diese Tabelle.
    So testen Sie
    Ein Skript ruft jede alte URL aus der Tabelle ab und prüft: genau eine 301 auf das vorgesehene Ziel oder der vorgesehene Status 404 bzw. 410. Außer der alten Startseite leitet keine alte URL auf die neue Startseite weiter, und der Bericht „Seitenindexierung“ zeigt keinen Anstieg von Soft-404-Fehlern bei Weiterleitungszielen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Teilweise erfüllt
    /privacy und /en-home führen jetzt auf Seiten mit derselben Suchabsicht, aber das alte /services leitet weiter auf die Startseite und der entfernte Case /portfolio/etech-mobility auf die Übersicht /work statt auf 404 oder 410.

  29. Weiterleitungen crawlbarer URLs nie über eine per robots.txt gesperrte URL führen

    TabuDEV-CAN-11ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Auf der Search Central Live hieß es: Die robots.txt wird für jede URL einer Weiterleitungskette geprüft, und das Crawling endet an der ersten gesperrten – etwa bei einem Shop, der jede Seite zum Setzen der Währung über eine gesperrte /cart/-URL weiterleitete. Die Search Console meldet dann die erste URL der Kette als durch die robots.txt blockiert, obwohl diese selbst gar nicht gesperrt ist.
    So geht’s
    Setzen Sie Währung, Sprache, Einwilligung oder Sitzungsstatus auf der Seite selbst oder per Cookie, nicht über einen Weiterleitungsschritt durch Warenkorb-, Checkout-, Login- oder Tracking-URLs. Lassen Sie jede Weiterleitung direkt auf die endgültige URL zeigen, prüfen Sie die Weiterleitungstabelle erneut, sobald die robots.txt eine neue Disallow-Regel bekommt, und leiten Sie Googlebot nie anders weiter als Nutzer.
    So testen Sie
    Meldet die Search Console eine URL als durch die robots.txt blockiert, die die Datei gar nicht sperrt, verfolgen Sie die Weiterleitungskette Schritt für Schritt – mit Browser- und mit Googlebot-User-Agent – und testen jeden Schritt mit Googles Open-Source-Parser gegen die robots.txt seines Hosts. JavaScript-Weiterleitungen zeigt nur eine gerenderte Prüfung wie der Live-Test der URL-Prüfung.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die robots.txt sperrt nur /api/, und keine Weiterleitung der Website läuft darüber.

  30. Für entfernte und nicht existierende URLs 404 oder 410 liefern

    PflichtDEV-ERR-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    URLs mit 4xx-Status (außer 429) werden nicht indexiert und bremsen das Crawling nicht; ein 404 ist ein starkes Signal, die URL nicht erneut zu crawlen. Eine Soft-404-Seite wird zwar nicht indexiert, aber weiter gecrawlt und verschwendet Crawl-Budget.
    So geht’s
    Beantworten Sie unbekannte Pfade, gelöschte Inhalte ohne gleichwertigen Ersatz und ungültige Parameter mit 404 oder 410 und einer hilfreichen Fehlerseite (Suchfeld, Hauptkategorien). Leiten Sie nur weiter, wenn es wirklich gleichwertigen Ersatz gibt – und nie pauschal jede fehlende URL auf die Startseite.
    So testen Sie
    curl -I https://www.example.com/this-does-not-exist-123 liefert 404, und die Zahl der Soft-404-Fehler im Bericht „Seitenindexierung“ bleibt nahe null.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Erfundene URLs in jeder Tiefe antworten mit 404 und einer Fehlerseite mit noindex, ebenso Reste der alten Website wie /blog und die alten /porfolio/-Beiträge.

  31. In Single-Page-Apps für unbekannte Routen einen echten 404 liefern oder einen dokumentierten clientseitigen Ausweg nutzen

    PflichtDEV-ERR-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Bei Single-Page-Apps liefert der Server oft für jede URL die App mit 200 aus, während der Router eine „Nicht gefunden“-Ansicht zeigt – ein Fehler wird so nie gemeldet. Ist ein serverseitiger 404 nicht machbar, dokumentiert Google zwei Auswege: eine JavaScript-Weiterleitung auf eine URL, die 404 liefert, oder ein per JavaScript eingefügtes noindex-Robots-Meta-Tag.
    So geht’s
    Am besten löst es der Server: bekannte Pfade routen, dynamische wie Produkt-Slugs nachschlagen und für alles andere das App-Gerüst mit 404 senden. Andernfalls leiten Sie Fehleransichten im Client auf eine URL weiter, die der Server mit 404 beantwortet, oder fügen auf Fehleransichten <meta name="robots" content="noindex"> ein.
    So testen Sie
    curl -I auf eine erfundene tiefe URL liefert 404, oder das gerenderte HTML in der URL-Prüfung zeigt die Weiterleitung bzw. das noindex. Der Bericht „Seitenindexierung“ zeigt keine Soft-404-Fehler bei App-Routen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Unbekannte tiefe Routen wie /de/work/nope oder /work/concepts/trace/nope erhalten vom Server ein echtes 404.

  32. Fehlerzustände, leere Ergebnisse und fehlgeschlagene Datenabrufe nie mit Status 200 ausliefern

    TabuDEV-ERR-03ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Typische Ursachen für Soft-404-Fehler sind Seiten, die wie Fehler aussehen, dünne oder leere Inhalte, falsch konfigurierte Server oder CMS und JavaScript-Inhalte, die nicht laden. Auf der Search Central Live hieß es, die Erkennung verstehe das Seitenlayout: Eine Fehlermeldung allein im Hauptinhalt macht die Seite zum Soft-404, auch wenn Kopfbereich und Navigation normal aussehen.
    So geht’s
    Datenbank- und Backend-Ausfälle liefern 503, fehlende Inhalte 404 oder 410, leere Such- und Filterergebnisse 404 oder ein noindex. Clientseitig gerenderte Seiten zeigen bei einem fehlgeschlagenen Datenabruf eine Möglichkeit zum erneuten Laden und lassen den Hauptbereich einer 200-URL nie leer.
    So testen Sie
    Simulieren Sie auf der Staging-Umgebung einen Backend-Ausfall: Die Seiten antworten mit 503, nicht mit 200. Suchen Sie per Crawl nach 200-Seiten mit sehr kurzem Hauptinhalt oder Fehlertexten und prüfen Sie nach jedem Release die Soft-404-Liste im Bericht „Seitenindexierung“.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die Seiten sind vorgerendert und laden pro Anfrage keine Daten, keine 200-Seite zeigt einen Fehlerzustand; die 503-Antwort bei einem Ausfall ist eingerichtet, aber noch nicht geprobt.

  33. Jeder Sprach- und Länderversion eine eigene URL geben

    PflichtDEV-INT-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Wechselt die Sprache per Cookie oder durch Austausch des Inhalts auf derselben URL, kann Google die Versionen kaum auseinanderhalten. Googlebot crawlt meist von US-IP-Adressen ohne Accept-Language-Header; Inhalte, die sich an den Besucher anpassen, werden in ihren anderen Versionen womöglich nie gecrawlt.
    So geht’s
    Jede Version bekommt eine eigene URL (example.de, de.example.com oder example.com/de/), nie einen ?lang=-Parameter oder ein Cookie. Allein die URL bestimmt Sprache und Region; eine gespeicherte Auswahl darf höchstens die Sprachwahl vorbelegen.
    So testen Sie
    Rufen Sie die URL jeder Version per curl von einem Standort aus ab, ohne Accept-Language-Header und ohne Cookies: Jede liefert ihre eigene Sprache und ihren eigenen Inhalt.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Englisch liegt unter den Basis-URLs, Deutsch unter /de, und ohne Cookies und Accept-Language liefert jede URL ihre eigene Sprache.

  34. Besucher nicht automatisch nach IP-Adresse oder Browsersprache weiterleiten

    TabuDEV-INT-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Googlebot crawlt meist aus den USA ohne Accept-Language-Header; automatische Weiterleitungen können ihm daher alle anderen Versionen verbergen. Auf der Search Central Live riet Google von cleveren Geo-Weiterleitungen ab, weil sie sehr oft schiefgehen.
    So geht’s
    Liefern Sie die angefragte URL so aus, wie sie ist, und schlagen Sie eine andere Version per wegklickbarem Banner oder über die Sprachwahl vor. Lassen Sie x-default auf eine Sprachauswahl oder eine allgemeine Seite zeigen, statt von der Startseite aus weiterzuleiten.
    So testen Sie
    curl -I auf jede Länder-URL mit IP-Adressen oder Accept-Language-Headern anderer Länder liefert keine 3xx-Weiterleitung auf eine andere Version.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Anfragen an eine Sprachversion mit der jeweils anderen Sprache (oder Französisch) in Accept-Language erhalten 200, nie eine Weiterleitung.

  35. hreflang lückenlos umsetzen: Selbstreferenz, Rückverweise und vollständige URLs

    PflichtDEV-INT-03ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    hreflang-Angaben, die nur in eine Richtung zeigen, ignoriert Google; fehlende Rückverweise und Selbstreferenzen gehören zu den häufigsten Fehlern. Alternative URLs müssen vollständig sein, einschließlich https://, und dürfen auf anderen Domains liegen.
    So geht’s
    Jede Seite einer Gruppe nennt sich selbst und jede Alternative in einem identischen Block, dazu x-default für die Rückfall- oder Auswahlseite. Verweisen Sie nur auf kanonische, indexierbare URLs mit Status 200 und erzeugen Sie den Block für alle Versionen aus einer Datenquelle.
    So testen Sie
    Ein hreflang-Audit im Crawler meldet je Gruppe keine fehlenden Rückverweise, keine fehlenden Selbstreferenzen, keine Ziele ohne Status 200 oder ohne Selbst-Canonical und keine relativen URLs.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jede Seite nennt en, de und x-default als absolute URLs einschließlich sich selbst, und jedes Ziel verweist zurück.

  36. Gültige hreflang-Codes verwenden: Sprache nach ISO 639-1, optional Schrift nach ISO 15924 und Region nach ISO 3166-1 Alpha-2

    PflichtDEV-INT-04ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Typische Fehler sind Ländercodes als Sprache (se, dk und cz statt sv, da und cs), falsche Regionen (UK statt GB, GE statt DE) und Regionen, die keine Länder sind, etwa EU. Manche Fehler sind gültige Codes für etwas anderes (se steht für Nordsamisch, GE für Georgien) und sprechen unbemerkt das falsche Publikum an.
    So geht’s
    Speichern Sie jede Version als Sprache plus optionaler Schrift und Region (sv-SE, de-CH, en-GB, zh-Hant, zh-Hans-CN), prüfen Sie jeden Wert in einem Build-Check oder einer Crawler-Regel gegen die Listen nach ISO 639-1, ISO 15924 und ISO 3166-1 Alpha-2 und nutzen Sie x-default für alle anderen.
    So testen Sie
    Eine automatische Prüfung zeigt: Jeder Wert ist x-default oder folgt dem Muster sprache[-Schrift][-REGION] (Groß- und Kleinschreibung unerheblich), und jeder Teil steht in ISO 639-1, ISO 15924 bzw. ISO 3166-1 Alpha-2.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die einzigen hreflang-Werte sind en, de und x-default – alle gültig.

  37. Sprach- und Länderwahl als <a href>-Links auf jede alternative URL bauen

    PflichtDEV-INT-06ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Eine Sprachwahl als Button funktioniert für Nutzer, lässt die anderen Sprachversionen aber ohne crawlbare Links zurück: Für Google sind sie verwaist und nur über Sitemaps auffindbar – und das dauert.
    So geht’s
    Rendern Sie die Auswahl als Liste von <a href>-Links auf die entsprechende Seite jeder Version, nicht nur auf deren Startseite; ein optisches Dropdown liegt allenfalls über diesen echten Links.
    So testen Sie
    Das gerenderte HTML jeder Seite enthält <a href>-Links auf jede Version dieser Seite, und ein Crawl ab einer Version erreicht alle anderen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Der Sprachumschalter ist auf jeder Seite ein <a href> auf dieselbe Seite in der anderen Sprache.

  38. Jeder indexierbaren Seite ein eindeutiges, aussagekräftiges title-Element im Server-HTML geben

    PflichtDEV-HTM-03ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Bei der Indexierung wertet Google den Text einer Seite und wichtige Tags wie das title-Element aus und erzeugt Titellinks aus seinem Verständnis der Seite. Einen geänderten Titel bemerkt Google erst nach erneutem Crawlen und Verarbeiten – laut Googles Leitfaden zu Titellinks dauert das einige Tage bis einige Wochen.
    So geht’s
    Erzeugen Sie den Titel serverseitig aus den Daten der Seite – ohne Platzhalter, ohne HTML und ohne Dubletten innerhalb einer Vorlage – und halten Sie ihn aussagekräftig und seitenspezifisch. Erzeugen Sie ebenso je Seite eine Meta-Beschreibung als reinen Text: Google nutzt sie nur manchmal, aber eine fehlerhafte kann trotzdem in den Suchergebnissen erscheinen.
    So testen Sie
    Ein Crawl findet keine fehlenden, doppelten, leeren oder Platzhalter-Titel und keine Meta-Beschreibung mit < oder > oder einem Platzhalter.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Alle 42 Titel stehen im Server-HTML und sind eindeutig; das englische Impressum hat jetzt einen eigenen Titel.

  39. Nie Text vor Nutzern verstecken, etwa Weiß auf Weiß oder Keyword-Blöcke außerhalb des sichtbaren Bereichs

    TabuDEV-HTM-06ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Versteckter Text verstößt gegen Googles Spamrichtlinien; Websites, die dagegen verstoßen, können schlechter ranken oder gar nicht erscheinen. Auf der Search Central Live hieß es, Google speichere Spam-Merkmale wie Weiß-auf-Weiß-Text zusammen mit den Tokens einer Seite – liegen gebliebene versteckte Keyword-Blöcke sind also eine Altlast.
    So geht’s
    Entfernen Sie versteckte Keyword-Blöcke, Text in Hintergrundfarbe und Text, der für Suchmaschinen aus dem sichtbaren Bereich geschoben ist. Legitim verborgene Bedienelemente wie Tabs, Akkordeons und Beschriftungen nur für Screenreader sind in Ordnung.
    So testen Sie
    Ein Crawl mit Stilprüfung findet keinen Text in der Farbe seines Hintergrunds und keine Blöcke außerhalb des sichtbaren Bereichs oder mit display:none – abgesehen von Hilfen für Barrierefreiheit und Bedienelementen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Nicht sichtbarer Text beschränkt sich auf Screenreader-Beschriftungen, das geschlossene Menü, inaktive Tabs und Panels sowie die letzte Karte einer horizontalen Galerie, und ein Render-Scan von 14 Vorlagen fand keinen Text in Hintergrundfarbe.

  40. Nur Inhalte auszeichnen, die auf der Seite sichtbar und für sie relevant sind

    PflichtDEV-SDA-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Laut Googles Richtlinien soll Markup keine Inhalte auszeichnen, die Leser nicht sehen – auch wenn sie stimmen. Irrelevantes oder irreführendes Markup kann zu einer manuellen Maßnahme führen, die die Berechtigung für Rich-Suchergebnisse entzieht, ohne das Ranking in der Websuche zu berühren.
    So geht’s
    Erzeugen Sie Markup aus denselben Feldern, die den sichtbaren Inhalt rendern, nutzen Sie es für die maschinenlesbare Form sichtbarer Fakten (ein ISO-Datum für ein angezeigtes Datum, die URL der Startseite für eine genannte Organisation) und entfernen Sie Markup für Inhalte, die eine Seite nicht mehr zeigt.
    So testen Sie
    Für jede Vorlage entspricht die Ausgabe des Tests für Rich-Suchergebnisse dem, was die Seite sichtbar zeigt, und der Bericht „Manuelle Maßnahmen“ in der Search Console ist leer.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jedes Element der strukturierten Daten entspricht sichtbarem Inhalt: FAQ-Antworten, die Filme auf ihren Watch-Pages und der Kunde auf der CDM-Fallstudie stehen alle auf der Seite.

  41. Markup im Test für Rich-Suchergebnisse prüfen, bevor es in Vorlagen geht, und nach dem Release überwachen

    PflichtDEV-SDA-11ibramdawwa.de: Nicht erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google empfiehlt, strukturierte Daten im Test für Rich-Suchergebnisse und von Hand zu prüfen, bevor Markup in Vorlagen geht. Von KI erzeugtes Markup kann erfundene Eigenschaften oder fehlerhafte Verschachtelungen enthalten und muss vor der Veröffentlichung geprüft und validiert werden.
    So geht’s
    Bauen Sie jeden Typ zuerst auf einer Seite, validieren Sie ihn und übernehmen Sie ihn dann in die Vorlage; für Staging und andere nicht öffentliche Seiten fügen Sie das gerenderte HTML in den Test ein, denn Ressourcen hinter Firewall oder Passwort kann er nicht laden. Beheben Sie jeden Fehler, ergänzen Sie einen CI-Schritt, der das JSON-LD gerenderter Vorlagen auf Syntax und Pflichtfelder prüft, und sehen Sie nach jedem Release die Berichte zu Rich-Suchergebnissen in der Search Console durch.
    So testen Sie
    Eine URL pro Vorlage besteht den Test für Rich-Suchergebnisse ohne Fehler, und die CI schlägt bei JSON-LD-Syntaxfehlern oder fehlenden Pflichtfeldern fehl.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Nicht erfüllt
    Das JSON-LD aller 42 Seiten lässt sich fehlerfrei parsen, aber ein Lauf des Tests für Rich-Suchergebnisse ist nicht dokumentiert, und die Deploy-Pipeline prüft nur Statuscodes, keine strukturierten Daten.

  42. Bewertungen des eigenen Unternehmens nicht per Markup auszeichnen

    TabuDEV-SDA-14ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Laut Googles Leitfaden zu Rezensions-Snippets kommen Bewertungen lokaler Unternehmen und Organisationen nur auf Websites infrage, die Bewertungen über andere Unternehmen sammeln. Bewertungen, die ein Unternehmen über sich selbst zeigt, gelten als eigennützig und sind nicht berechtigt.
    So geht’s
    Erzeugen Sie Review- und AggregateRating-Markup nur aus Bewertungen, die auf der Seite sichtbar sind, etwa auf Produktseiten, und entfernen Sie LocalBusiness- oder Organization-Bewertungen Ihres eigenen Unternehmens aus dem Markup – auch solche, die Bewertungs-Widgets einfügen.
    So testen Sie
    Der Test für Rich-Suchergebnisse zeigt Rezensions-Snippets nur auf Vorlagen mit sichtbaren Bewertungen, und ein Crawl findet keine Bewertung an der eigenen Organization- oder LocalBusiness-Entität.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Keine Seite zeichnet Bewertungen oder Rezensionen aus – weder beim Unternehmen noch anderswo.

  43. Jedes Bild, das gefunden werden soll, als <img>-Element mit src-Attribut einbinden

    PflichtDEV-IMG-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google findet Bilder über img-Elemente, und src ist das wichtigste Attribut: Ohne src weiß Google nicht, wo das Bild liegt. Das picture-Element wird nur über das enthaltene img unterstützt, CSS-Hintergrundbilder werden nicht erfasst.
    So geht’s
    Inhaltsbilder stehen in img mit src, bei Bedarf (Art Direction, moderne Formate) innerhalb von picture; CSS-Hintergründe bleiben der Dekoration vorbehalten. Per Lazy Loading geladene Bilder behalten ein echtes src mit loading="lazy" statt nur eines data-src, das ein Skript befüllt.
    So testen Sie
    Im gerenderten HTML (URL-Prüfung) sind wichtige Bilder img-Elemente mit src, und eine Suche in den Vorlagen findet kein background-image bei Inhaltsbildern.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jedes inhaltliche Bild ist ein <img> mit echter src und Abmessungen; CSS-Hintergründe dienen nur als Unschärfe-Platzhalter und für ein dekoratives Poster.

  44. Jedes aussagekräftige Bild im alt-Attribut beschreiben

    PflichtDEV-IMG-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google nennt den Alternativtext das wichtigste Attribut für Bild-Metadaten und nutzt ihn zusammen mit Bilderkennung und dem Seiteninhalt, um ein Bild zu verstehen. Der Alt-Text soll das Bild für jemanden beschreiben, der es nicht sehen kann.
    So geht’s
    Machen Sie den Alt-Text im CMS zum Pflichtfeld für Inhaltsbilder, schreiben Sie konkrete Beschreibungen statt Dateinamen oder Keyword-Listen und geben Sie dekorativen Bildern ein leeres alt="". Wenn Sie Alt-Texte von einem Sprachmodell erzeugen lassen, prüfen Sie zuerst eine Stichprobe und geben Sie dem Modell neben dem Bild auch den Seitentitel mit.
    So testen Sie
    Ein Crawl findet kein Inhaltsbild mit fehlendem oder leerem alt oder einem alt gleich dem Dateinamen, und die Seiten bestehen die image-alt-Prüfung von axe oder Lighthouse.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jedes Bild aus Fallstudien, Kundenprojekten und Konzepten hat jetzt in beiden Sprachen einen konkreten Alt-Text; leer bleibt er nur bei Hover-Ebenen, Link-Vorschaubildern neben dem Projektnamen, einem Geräte-Mock-up und einer beschrifteten Collage – alles Bilder, die auf ihren Projektseiten beschrieben sind.

  45. Jedes Video in ein video-, iframe-, embed- oder object-Element einbetten, das ohne Nutzeraktion lädt

    PflichtDEV-VID-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Google findet Videos, die in diesen Elementen eingebunden sind, und erfasst sie zusammen mit den Daten in ihrem Umfeld. Ein Video, das erst nach einem Klick, einer Wischgeste oder einer Eingabe lädt, wird nicht gefunden.
    So geht’s
    Geben Sie das Player-Element beim Laden im HTML aus (ein Vorschaubild ist in Ordnung), in echter Größe und Position und nicht von anderen Elementen verdeckt; bei nachladenden Playern bleiben Element und src bzw. Embed-URL im DOM. Fehlt der Player beim Laden, meldet der Bericht zur Videoindexierung, dass Position und Größe des Videos nicht bestimmt werden können.
    So testen Sie
    Das gerenderte HTML in der URL-Prüfung enthält das video-Element oder iframe mit seiner URL, und der Bericht zur Videoindexierung führt die Seite auf.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Beide Filme stehen jetzt beim Laden als <video>-Element mit Datei-URL in der Seite (preload none), auf eigenen Watch-Pages und auf den übergeordneten Seiten; den Bericht zur Videoindexierung haben wir für diesen Check nicht ausgewertet.

  46. Nie den Browserverlauf so manipulieren, dass „Zurück“ Nutzer nicht dorthin bringt, woher sie kamen

    TabuDEV-SPM-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Back-Button-Hijacking – Eingriffe in die Browsernavigation, sodass Nutzer mit „Zurück“ nicht zur vorherigen Seite gelangen – verstößt gegen Googles Spamrichtlinie zu schädlichen Praktiken; seit dem 15. Juni 2026 ahndet Google das mit manuellen Maßnahmen oder automatischer Abwertung. Laut Google können auch eingebundene Bibliotheken oder Werbeplattformen die Ursache sein.
    So geht’s
    Rufen Sie history.pushState nur bei echter, vom Nutzer ausgelöster Navigation in der App auf – nie beim Laden, beim Scrollen oder um Zwischen- oder Ausstiegsseiten einzuschieben – und fangen Sie popstate nicht ab, um Nutzer auf der Website zu halten. Prüfen Sie Skripte von Werbe-, Engagement- und Empfehlungsanbietern und entfernen Sie jeden Code, der Verlaufseinträge hinzufügt.
    So testen Sie
    Ein automatisierter Browsertest öffnet jede Vorlage von einer anderen Seite aus, interagiert, drückt einmal „Zurück“ und landet auf der vorherigen Seite. Eine Codesuche in den gebauten Bundles findet kein pushState oder replaceState außerhalb des Routers.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Bei 13 Vorlagen führte der Aufruf von einer anderen Seite, etwas Interaktion und einmal „Zurück“ stets auf die vorige Seite.

  47. Nicht massenhaft wenig hilfreiche Seiten aus Vorlagen, Feeds oder Sprachmodell-Ausgaben erzeugen

    TabuDEV-SPM-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Missbrauch skalierter Inhalte – viele Seiten, die vor allem Rankings manipulieren statt Nutzern helfen sollen – verstößt gegen Googles Spamrichtlinien, egal ob die Seiten von generativer KI, aus fremden Feeds oder aus zusammengestückelten Quellen stammen. Auf der Search Central Live hieß es, Google zähle KI-Massenware („AI slop“) zum Missbrauch skalierter Inhalte.
    So geht’s
    Lassen Sie programmatische Seitentypen (Ort × Leistung, Produkt × Keyword, eine Seite pro Frage) vorab redaktionell prüfen: Jede Seite braucht eigenen, nützlichen Hauptinhalt, sonst wird sie nicht angelegt oder bleibt auf noindex. Veröffentlichen Sie Entwürfe aus Sprachmodellen oder Feeds nicht automatisch in großer Zahl; jede Seite braucht eine redaktionelle Freigabe.
    So testen Sie
    Ein Crawl jeder programmatischen Vorlage findet keine Gruppen nahezu identischer Seiten, die Veröffentlichungsprotokolle zeigen eine redaktionelle Freigabe für erzeugte Seiten, und der Bericht „Manuelle Maßnahmen“ in der Search Console ist leer.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Die Website hat 42 einzeln geschriebene Seiten in zwei Sprachen und keine aus Vorlagen oder Feeds erzeugten Seitenmengen.

  48. Googlebot nie andere Inhalte zeigen als Nutzern und keine Brückenseiten bauen

    TabuDEV-SPM-03ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Cloaking (Nutzern und Suchmaschinen unterschiedliche Inhalte zeigen, um Rankings zu manipulieren) und Brückenseiten (Seiten, die für ähnliche Suchanfragen ranken sollen und Nutzer auf weniger nützliche Zwischenseiten führen) sind Spamformen nach Googles Spamrichtlinien.
    So geht’s
    Unterscheiden Sie nie anhand des Googlebot-User-Agents oder der IP-Bereiche von Google, um Texte, Links oder Weiterleitungen anzupassen. Erzeugen Sie keine nahezu identischen Städte- oder Keyword-Landingpages, die Besucher auf ein Ziel lenken; fassen Sie sie zu einer nützlichen Seite pro echtem Angebot zusammen.
    So testen Sie
    Das HTML für einen Googlebot-User-Agent und für einen Browser hat denselben Hauptinhalt, dieselben Links und dieselben Weiterleitungen, und das gerenderte HTML in der URL-Prüfung entspricht dem, was Nutzer sehen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Googlebot, Bingbot, GPTBot und ein Browser erhalten byte-identisches HTML, und es gibt keine Brückenseiten.

  49. Jeden Live-Host vor dem Go-live in der Search Console verifizieren

    PflichtDEV-MON-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Wer prüfen will, was Google auf einer Website sieht – mit der URL-Prüfung, dem Bericht „Seitenindexierung“ oder den Crawling-Statistiken –, braucht zuerst verifizierten Zugriff in der Search Console.
    So geht’s
    Legen Sie eine Domain-Property an (Verifizierung per DNS-Eintrag), die alle Subdomains und Protokolle abdeckt, dazu URL-Präfix-Properties für Bereiche oder Hosts mit eigenem Zugriff, und halten Sie den Verifizierungseintrag im Infrastruktur-Code, damit er DNS- oder CMS-Wechsel übersteht.
    So testen Sie
    Die Search Console führt die Domain-Property als verifiziert, und jedes Team, das Code ausliefert, hat Zugriff.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Eine Domain-Property in der Search Console ist seit dem 10. Oktober verifiziert, der TXT-Eintrag dazu ist öffentlich im DNS sichtbar; wer im Team Zugriff hat, ist von außen nicht erkennbar.

Am Go-live-Tag

  1. Wartung und kurze Ausfälle mit 503 beantworten – höchstens ein bis zwei Tage

    PflichtDEV-SRV-03ibramdawwa.de: Teilweise erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Auf 5xx- und 429-Antworten drosselt Google vorübergehend das Crawling und behält indexierte URLs eine Weile; URLs, die dauerhaft fehlschlagen, fallen aber irgendwann heraus. Eine „Wir sind gleich zurück“-Seite mit 200 wird zum Soft-404 oder ersetzt Ihre Inhalte im Index, ein 404 entfernt die URLs. Auf der Search Central Live hieß es, Google senke die Crawling-Kapazität nach einer Häufung von 500-Fehlern binnen etwa vier Stunden, eine Erhöhung dauere dagegen ein bis drei Wochen.
    So geht’s
    Liefern Sie während der Wartung oder der Umstellung für jede Seite 503 aus (Retry-After ist optional), lassen Sie die robots.txt normal antworten und begrenzen Sie die 503-Phase auf ein bis zwei Tage. Bei längeren Pausen bleibt die Website mit eingeschränkten Funktionen online; 503 und 429 taugen nie zur dauerhaften Drosselung.
    So testen Sie
    Bei einer Wartungsprobe liefert curl -I auf eine beliebige Seite 503, curl -I auf /robots.txt dagegen 200. Danach sinkt der 5xx-Anteil in den Crawling-Statistiken wieder auf null.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Teilweise erfüllt
    Laut Server-Runbook vom 10. Oktober antwortet nginx bei gestopptem App-Container mit 503 und Retry-After und liefert die robots.txt selbst aus – in einer Wartungsübung geprobt haben wir das noch nicht.

  2. Umgezogene URLs per dauerhafter serverseitiger Weiterleitung (301 oder 308) direkt auf die Ziel-URL weiterleiten

    PflichtDEV-CAN-01ibramdawwa.de: Teilweise erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Weiterleitungen sind für Google ein starkes Signal bei der Wahl der kanonischen URL, und die Art zählt: Bei einer vorübergehenden Weiterleitung zeigt Google weiterhin die alte URL. Googles Crawler folgen bis zu 10 Weiterleitungen hintereinander, lange Ketten schaden dem Crawling, und JavaScript-Weiterleitungen sieht Google erst nach dem Rendern – wenn überhaupt.
    So geht’s
    Beantworten Sie jede verschobene, zusammengelegte oder umbenannte URL mit genau einer 301 oder 308 auf die endgültige URL und lösen Sie alte Ketten in der Weiterleitungstabelle in einen einzigen Schritt auf. Stellen Sie interne Links, Canonicals, hreflang und Sitemaps auf die neue URL um; 302 oder 307 verwenden Sie nur für wirklich vorübergehende Umzüge, Meta-Refresh- oder JavaScript-Weiterleitungen nie für dauerhafte.
    So testen Sie
    curl -sIL auf eine alte URL zeigt genau eine 301- oder 308-Weiterleitung mit 200 am Ende, und der Weiterleitungsketten-Bericht eines Crawlers ist leer. Nach dem erneuten Crawlen zeigt die URL-Prüfung die neue URL als von Google ausgewählte kanonische URL.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Teilweise erfüllt
    Jede alte https-URL, ob auf www oder der Hauptdomain, erreicht ihre neue Seite jetzt mit einer einzigen 308; http://www-Varianten alter Pfade und Varianten mit Schrägstrich am Ende brauchen aber noch zwei Schritte – der Test des Kits ohne Weiterleitungsketten ist damit noch nicht ganz erfüllt.

  3. Die Website über genau einen Host per HTTPS mit gültigem Zertifikat ausliefern und alle anderen Varianten dorthin weiterleiten

    PflichtDEV-CAN-02ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Die Versionen einer Seite mit und ohne www sind exakte Duplikate, die Google zusammenfasst und von denen es eine behält. Ob eine Seite sauber lädt, fließt in die Wahl der kanonischen URL ein; ein fehlerhaftes Zertifikat spricht also gegen eine URL.
    So geht’s
    Legen Sie einen Ursprung fest (etwa https://www.example.com), leiten Sie jede andere Kombination aus Protokoll und Hostname mit genau einer 301 dorthin weiter und liefern Sie auf jedem antwortenden Hostnamen ein gültiges TLS-Zertifikat aus – auch auf den weiterleitenden. Nutzen Sie in internen Links, Canonicals, hreflang und Sitemaps nur den gewählten Ursprung und aktivieren Sie HSTS, sobald HTTPS überall funktioniert.
    So testen Sie
    curl -I auf http://example.com, http://www.example.com und https://example.com liefert jeweils genau eine 301 auf die https://www.-URL, und eine TLS-Prüfung (openssl s_client oder ein Online-Scanner) zeigt auf jedem Hostnamen ein gültiges Zertifikat.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    http auf beiden Hostnamen und https://www erreichen https://ibramdawwa.de in einem Schritt, das Zertifikat deckt beide Namen ab, und die nackte IP sowie unbekannte Hostnamen werden abgewiesen.

  4. Staging-, Vorschau- und Spiegelkopien der Website nie öffentlich crawlbar lassen

    TabuDEV-CAN-07ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Eine crawlbare Kopie wie eine Staging-Umgebung konkurriert mit der Live-Website um die kanonische URL – und kann gewinnen. Google achtet darauf, wenn mehrere Domains für dieselben Inhalte kanonisch sein wollen, auch bei eigenen Kopien des Betreibers.
    So geht’s
    Schützen Sie Staging-, Vorschau- und QA-Umgebungen per HTTP-Authentifizierung oder IP-Allowlist – eine Seite mit 401 oder 403 wird nicht indexiert – und setzen Sie zur zusätzlichen Absicherung einen websiteweiten noindex-Header. Gehen Sie nie mit dem pauschalen noindex oder Disallow: / der Staging-Umgebung live, und lassen Sie Canonicals oder hreflang der Live-Website nie auf einen Staging-Host zeigen.
    So testen Sie
    curl -I auf den Staging-Host liefert ohne Zugangsdaten 401 oder 403, und die Prüfung vor dem Go-live zeigt: Die Live-Website hat kein globales noindex und kein Disallow: /.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Kein Staging- oder Vorschau-Host ist öffentlich, und die nackte Server-IP, die am 9. Oktober noch eine vollständige Kopie der Website auslieferte, weist die Verbindung jetzt ab.

  5. Jede Vorlage vor dem Release im Headless-Browser rendern und direkt danach in der URL-Prüfung testen

    PflichtDEV-MON-02ibramdawwa.de: Teilweise erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Das gerenderte HTML in Googles Testtools zeigt, was Google indexieren kann; der Live-Test zeigt zusätzlich Seitenressourcen, JavaScript-Konsolenmeldungen und einen Screenshot. Die URL-Prüfung testet nur öffentliche URLs einer verifizierten Property – eine Staging-Umgebung hinter Passwort kann sie nicht prüfen.
    So geht’s
    Führen Sie eine Liste mit einer typischen URL pro Vorlage (Startseite, Kategorie, Produkt, Artikel, Landingpages, jede Sprachversion). Vor dem Release rendern Sie jede Vorlage auf Staging mit Headless Chrome (Puppeteer oder Playwright), vergleichen Roh- und gerendertes DOM und sammeln Konsolenfehler; direkt nach dem Release führen Sie für eine Live-URL pro Vorlage den Live-Test der URL-Prüfung aus und prüfen gerendertes HTML, Ressourcen und Konsolenmeldungen.
    So testen Sie
    Die Release-Checkliste hält für jede Vorlage ein Headless-Render-Ergebnis vor dem Release und ein Ergebnis des Live-Tests der URL-Prüfung nach dem Release fest.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Teilweise erfüllt
    Skripte für Headless-Renderings gibt es, sie liefen am 9. und 13. Oktober von Hand, aber die Deploy-Pipeline prüft weiterhin nur Statuscodes, und Ergebnisse der URL-Prüfung je Vorlage sind nicht dokumentiert.

In den Wochen danach

  1. Seiten indexierbar und snippet-fähig halten – mehr technische Voraussetzungen gibt es für KI-Funktionen nicht

    PflichtDEV-AIF-01ibramdawwa.de: Erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Um in AI Overviews oder im AI Mode als unterstützender Link zu erscheinen, muss eine Seite indexiert sein und mit Snippet angezeigt werden dürfen; weitere technische Voraussetzungen gibt es nicht. KI-Funktionen bauen auf Googles zentralen Ranking-Systemen und seinem Index auf.
    So geht’s
    Setzen Sie den Rest dieser Checkliste um, blockieren Sie keine Snippets und lassen Sie die Einstellung für generative KI in der Search Console so, dass die Website einbezogen wird – es sei denn, sie soll bewusst ausgeschlossen sein. Taucht eine Seite nie als Quelle auf, prüfen Sie zuerst Indexierung, Snippet-Regeln und diese Einstellung.
    So testen Sie
    Die URL-Prüfung zeigt die Seite als indexiert, ihre Robots-Regeln enthalten kein nosnippet, und der Leistungsbericht für generative KI in der Search Console zeigt Impressionen.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Erfüllt
    Jede indexierbare Seite antwortet mit 200, verweist per Canonical auf sich selbst, erlaubt volle Snippets und hat ihren Text im Server-HTML; Indexierung und KI-Impressionen zeigt nur die Search Console, die wir für diesen Check nicht ausgewertet haben.

  2. CMS und Plug-ins aktuell halten und auf eingeschleuste Seiten und Links achten

    PflichtDEV-SPM-04ibramdawwa.de: Teilweise erfüllt

    Warum · So geht’s · So testen Sie · Quellen
    Warum
    Gehackte Inhalte, die über Sicherheitslücken ohne Erlaubnis auf eine Website gelangen, zählen zu den Spamformen in Googles Richtlinien; sie zu bereinigen ist aufwendig, Vorbeugen ist entscheidend. Kommt es zu einer manuellen Maßnahme, dauert die Bearbeitung der meisten Anträge auf erneute Überprüfung laut Googles Hilfe mehrere Tage oder Wochen.
    So geht’s
    Automatisieren Sie Updates von CMS, Theme und Plug-ins, entfernen Sie ungenutzte Plug-ins und Konten, verlangen Sie eine Zwei-Faktor-Anmeldung für die Redaktion und lassen Sie sich bei neuen URLs, ausgehenden Links oder Sitemap-Einträgen alarmieren, die niemand aus der Redaktion angelegt hat. Stellen Sie nach einer Bereinigung den Antrag auf erneute Überprüfung erst, wenn jede eingeschleuste Seite und jeder eingeschleuste Link entfernt ist.
    So testen Sie
    Ein wöchentlicher Abgleich von Sitemap und Crawl mit der Seitenliste des CMS findet keine unbekannten URLs, und die Berichte „Sicherheitsprobleme“ und „Manuelle Maßnahmen“ in der Search Console sind leer.
    Quellen

    In Googles Dokumentation

    Auf der Search Central Live gesagtEnglisch

    ibramdawwa.de: Teilweise erfüllt
    Es gibt kein CMS und keine Plug-ins, die Produktionsabhängigkeiten haben keine bekannten Schwachstellen und der heutige Crawl fand keine unbekannten URLs oder Ziel-Hosts – im Repository sind aber weder ein regelmäßiger Crawl-Abgleich noch ein Bot für Abhängigkeits-Updates eingerichtet.

ibramdawwa.de

So schneidet unsere eigene Website ab

Wir haben ibramdawwa.de selbst gegen diese Liste geprüft. Bei jedem Punkt steht unser Ergebnis vom Tag der Prüfung – auch dort, wo wir noch nachbessern.

Erfüllt
47
Teilweise erfüllt
5
Nicht erfüllt
1
Trifft nicht zu
3

Developer Kit der Wissensbasis zur Search Central Live Deep Dive Europe 2026, erstellt von Ibrahim Anjro (Ibram & Dawwa GmbH), CC BY 4.0, übersetzt und angepasst

Lieber mit Begleitung?

Wir gehen die Liste mit Ihnen durch: vor dem Go-live, am Go-live-Tag und in den Wochen danach – auch wenn eine andere Agentur die Website baut.

Relaunch begleiten lassenWissensbasis v2.13.0 (öffnet in einem neuen Tab)
Nächster Schritt

Sie bringen den Engpass. Wir bringen den Bauplan.

Sagen Sie uns, was entstehen oder besser laufen soll. Wir zeigen Ihnen genau, wie wir vorgehen würden: Systeme, Medien oder beides.

Bauen wir den Motor.

Strategie-Call buchen
(01) E-Mail
info@ibramdawwa-gmbh.de
(02) Telefon
+49 1575 1702770
(03) Regensburg
 Ortszeit
(04) Antwortzeit
Wir antworten innerhalb von 1 Werktag.

Agenturen automatisieren. Studios gestalten. Wir machen beides.