Technische-SEO-Checkliste

TL;DR — Eine technische SEO-Checkliste ist die Liste der technischen Kästchen, die Ihre Website abhaken muss, damit Suchmaschinen Ihre Seiten finden, lesen und anzeigen können. Kurzfassung von Google: Eine Seite muss crawlbar, indexierbar, verständlich und renderbar sein. Arbeiten Sie die Liste in Prioritätsreihenfolge ab und überspringen Sie die Abschnitte, die nicht auf Ihre Website-Größe zutreffen — eine 20-seitige Broschüren-Website muss sich nicht um dieselben Dinge kümmern wie ein Geschäft mit 500 000 Produkten.

Evidence for this claim Google's minimum technical requirements include accessible Googlebot crawling, a successful HTTP response, and indexable content. Scope: Eligibility prerequisites, not a guarantee of indexing or ranking. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements Evidence for this claim Meeting technical requirements does not guarantee that Google will crawl, index, or serve a page. Scope: Google Search eligibility and selection behavior. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements

Was diese Checkliste ist (und was nicht)

Technisches SEO ist die Infrastruktur. Bevor Ihre Inhalte ranken können, müssen Suchmaschinen in der Lage sein, Ihre Seiten zu erreichen, herunterzuladen, zu verstehen und abzulegen. Eine technische SEO-Checkliste ist einfach die geordnete Liste der Dinge, die das ermöglichen.

Sie ist nicht das gesamte SEO. Sie deckt nicht das Schreiben guter Inhalte, die Auswahl der richtigen Keywords oder den Aufbau von Links ab. Diese Dinge sind enorm wichtig — sie sind nur eine andere Aufgabe. Wenn Sie die Alles-auf-einmal-Version möchten, ist das eine vollständige SEO-Audit-Checkliste, und das ist ein separates, umfassenderes Thema. Diese Seite bleibt technisch.

Die Prioritätsreihenfolge

Gehen Sie diese ungefähr von oben nach unten durch. Je weiter oben in der Liste, desto mehr kann es leise alles darunter kaputt machen.

1. Können Suchmaschinen Ihre Website crawlen? Überprüfen Sie, ob Ihre robots.txt nicht Seiten blockiert, die auffindbar sein sollen. Beheben Sie defekte Seiten (404s) und Serverfehler (5xx).
2. Können Ihre Seiten indexiert werden? Stellen Sie sicher, dass Sie Google nicht versehentlich anweisen, wichtige Seiten zu noindex, und dass doppelte Versionen einer Seite auf eine bevorzugte Version verweisen.
3. Ist Ihre Website auf HTTPS? Das kleine Vorhängeschloss. Es ist jetzt eine Basiserwartung.
4. Funktioniert sie gut auf Handys? Google indexiert die mobile Version Ihrer Website, daher muss Ihre Telefonversion denselben Inhalt haben wie Ihre Desktop-Version.
5. Haben Sie eine XML-Sitemap? Eine einfache Liste Ihrer URLs, die Sie Google und Bing geben, damit sie nicht alles durch das Verfolgen von Links finden müssen.
6. Ist Ihre strukturierte Daten gültig? Optional, aber es kann Ihnen reichhaltiger aussehende Suchergebnisse einbringen. (Es wird Ihre Rankings nicht verbessern — mehr zu diesem Mythos unten.)
7. Wie steht es um Ihre Seitengeschwindigkeit? Die Core Web Vitals von Google messen Laden, Reaktion und visuelle Stabilität.

Die zwei Mythen, die Sie kennen sollten

• Das Blockieren einer Seite in robots.txt entfernt sie nicht aus Google. Es stoppt nur das Lesen durch Google. Um eine Seite tatsächlich zu entfernen, lassen Sie Google sie crawlen und fügen Sie ein noindex-Tag hinzu. (Das Blockieren in robots.txt und das Hinzufügen von noindex ist eine klassische Falle — der Bot kann die Seite nicht crawlen, also sieht er das noindex nie.)
• Strukturierte Daten sind keine Ranking-Verbesserung. Sie können Ihr Ergebnis reichhaltiger aussehen lassen, was Klicks helfen kann — aber das Hinzufügen von Schema bringt Sie nicht in den Ergebnissen nach oben.

Nicht alles trifft auf Sie zu

Das Nützlichste an dieser Checkliste ist zu wissen, was Sie überspringen können. Wenn Sie eine kleine Website betreiben, können Sie das Crawl-Budget-Management komplett ignorieren — Google selbst sagt, dass die meisten Websites nicht darüber nachdenken müssen. Möchten Sie das vollständige Bild, einschließlich wer doch diese fortgeschrittenen Abschnitte benötigt? Wechseln Sie zur Registerkarte Erweitert.

TL;DR — Technisches SEO ist der Boden, nicht die Decke: Seiten müssen crawlbar → indexierbar → verständlich → renderbar sein, bevor Inhaltsarbeit sich auszahlt. Führen Sie die Checkliste in Prioritätsreihenfolge aus und stufen Sie Abschnitte nach Website-Typ ein — die meisten kleinen Websites können Crawl-Budget, Facetten-Navigationskontrolle, Log-Analyse und JS-Rendering-Engineering überspringen, was Googles eigenes Crawl-Budget-Dokument bestätigt. Töten Sie zwei Mythen auf Sicht: robots.txt deindexiert nicht, und strukturierte Daten sind kein Ranking-Faktor. Behandeln Sie Core Web Vitals als Ziele, nicht als Bestehen/Nichtbestehen-Gates — das ist Googles eigene “strive to”- Sprache. Und selbst wenn Sie jedes Kästchen erfüllen, garantiert das keine Indexierung.

Evidence for this claim Google's minimum technical requirements include accessible Googlebot crawling, a successful HTTP response, and indexable content. Scope: Eligibility prerequisites, not a guarantee of indexing or ranking. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements Evidence for this claim Meeting technical requirements does not guarantee that Google will crawl, index, or serve a page. Scope: Google Search eligibility and selection behavior. Confidence: high · Verified: 2026-07-14 Google Search Essentials: Technical requirements

Das mentale Modell: vier Bedingungen

Google rahmt die gesamte technische SEO um vier tragende Bedingungen – eine Seite muss crawlbar, indexierbar, verständlich und renderbar sein. Die technischen Anforderungen der Search Essentials reduzieren das auf drei Mindestanforderungen: “Googlebot isn’t blocked,” (Übersetzung) „Googlebot ist nicht blockiert“, “The page works” (Übersetzung) „die Seite funktioniert“ (sie wird mit HTTP-Status 200 ausgeliefert) und “The page has indexable content.” (Übersetzung) „die Seite enthält indexierbare Inhalte“. Alles auf dieser Checkliste dient letztlich diesen Bedingungen.

Der entscheidende Vorbehalt, direkt aus demselben Dokument: “Just because a page meets these requirements doesn’t mean that a page will be indexed; indexing isn’t guaranteed.” (Übersetzung) „Nur weil eine Seite diese Anforderungen erfüllt, bedeutet das nicht, dass sie indexiert wird; die Indexierung ist nicht garantiert.“ Technische SEO ist ein Tor, das Sie passieren müssen, kein Hebel, der Ergebnisse garantiert. Deshalb habe ich immer argumentiert, dass die technische Checkliste der Boden ist – Sie räumen sie ab, damit Inhalte und Links ihre Arbeit tun können, nicht an ihrer Stelle.

Bevor Sie beginnen: Welche Abschnitte betreffen Sie überhaupt?

Jede konkurrierende Checkliste organisiert nach Thema und wendet das Ganze auf jede Website an. Das ist der falsche Standard. Die bessere Organisationsachse ist der Website-Typ, weil Google selbst seine fortschrittlichsten Anleitungen nach Website-Größe staffelt. Aus dem Leitfaden zum Crawl-Budget für große Websites: “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (Übersetzung) „Wenn Ihre Website nicht viele Seiten hat, die sich schnell ändern, oder wenn Ihre Seiten am selben Tag gecrawlt zu werden scheinen, an dem sie veröffentlicht werden, müssen Sie diesen Leitfaden nicht lesen.“

Googles eigene (bewusst grobe) Schwellenwerte dafür, wann das Crawl-Budget relevant wird:

• Große Websites – 1 Million+ eindeutige Seiten mit sich etwa wöchentlich ändernden Inhalten.
• Mittlere oder größere Websites – 10 000+ eindeutige Seiten mit sehr schnell wechselnden (täglichen) Inhalten.
• Websites mit einem großen Anteil an URLs, die in der Search Console im Status “Discovered - currently not indexed” (Übersetzung) „Entdeckt – zurzeit nicht indexiert“ festhängen.

Hier ist also die Aufteilung, die ich tatsächlich vornehmen würde:

Starter-Track – kleine / Broschüren- / lokale Unternehmens-Websites (< ~10 000 URLs): Crawlbarkeits- Plausibilitätsprüfung, Indexierungs-/Kanonikalitäts-Plausibilitätsprüfung, HTTPS, mobile Parität, eine XML-Sitemap, eine Runde Core Web Vitals, gültige strukturierte Daten, wo sie ein Rich Result verdienen. Überspringen Sie Crawl-Budget, Facetten-Navigationskontrolle, Logdatei-Analyse und JS-Rendering-Engineering vollständig.

Fortgeschrittenen-Track – große / E-Commerce- / JS-lastige / Enterprise-Websites: alles im Starter-Track plus Crawl-Budget-Verwaltung, Facetten-Navigationskontrolle, JavaScript-Rendering-Audits, Server-Log-Analyse und (falls international) hreflang.

1. Crawlbarkeit

• robots.txt-Korrektheit. Stellen Sie sicher, dass Sie nichts ausschließen, das Sie indexiert haben möchten. Google: “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.” (Übersetzung) „Eine robots.txt-Datei teilt Suchmaschinen-Crawlern mit, auf welche URLs der Crawler auf Ihrer Website zugreifen kann. Sie dient hauptsächlich dazu, eine Überlastung Ihrer Website mit Anfragen zu vermeiden; sie ist kein Mechanismus, um eine Webseite von Google fernzuhalten.“ Nutzen Sie die Datei, um Bots von Bereichen mit geringem Wert fernzuhalten (interne Suche, endlose Parameterkombinationen), nicht als Werkzeug zur Deindexierung. Der robots.txt-Vertiefungsartikel behandelt dieses Thema ausführlich.
• Die robots.txt- + noindex-Widerspruchsfalle. Blockieren Sie eine URL nicht in robots.txt und verlassen Sie sich auf ein noindex darauf. Google: “While Google won’t crawl or index the content blocked by a robots.txt file, we might still find and index a disallowed URL if it is linked from other places on the web.” (Übersetzung) „Obwohl Google die durch eine robots.txt-Datei blockierten Inhalte nicht crawlt oder indexiert, könnten wir eine nicht erlaubte URL dennoch finden und indexieren, wenn sie von anderen Stellen im Web verlinkt ist.“ Der Bot kann die Seite nicht crawlen, sieht also nie das noindex, und die URL kann dennoch nackt in den Ergebnissen auftauchen. Um eine Seite zu entfernen: Crawling erlauben + noindex oder sie passwortschützen.
• Crawl-Fehler. Beheben Sie unerwartete 4xx- und 5xx-Fehler. Google indexiert nur Seiten, die mit einem 200 ausgeliefert werden, und “Client and server error pages aren’t indexed.” (Übersetzung) „Client- und Server-Fehlerseiten werden nicht indexiert.“
• Redirect-Ketten und -Schleifen. Reduzieren Sie A→B→C→D auf A→D. Ketten verschwenden Crawl- Budget und verlieren bei jedem Sprung ein wenig. Das Crawling- und Redirect-Material geht hier tiefer.

2. Indexierbarkeit

• Indexabdeckung. Gleichen Sie im Page-Indexing-Bericht der Search Console ab, was Sie indiziert haben möchten, mit dem, was tatsächlich indiziert ist. Untersuchen Sie große Gruppen mit “Discovered/Crawled - currently not indexed” (Übersetzung) „Entdeckt/Gecrawlt – zurzeit nicht indexiert“.
• Kanonisierung. Weisen Sie doppelte und nahezu doppelte URLs einer bevorzugten Version zu. Google nennt rel="canonical" “a strong signal that the specified URL should become canonical” (Übersetzung) „ein starkes Signal dafür, dass die angegebene URL kanonisch werden sollte“ – ein Signal, keine zwingende Anweisung. Und entscheidend: “Don’t use the robots.txt file for canonicalization purposes.” (Übersetzung) „Verwenden Sie die robots.txt-Datei nicht zur Kanonisierung.“ Prüfen Sie, ob Sie widersprüchliche Kanonisierungssignale über HTML-Tag, HTTP-Header und Sitemap senden – der Kanonisierungs-Deep Dive erläutert, wie Sie diese konsolidieren.
• Doppelte Inhalte. Parameter, Druckversionen, Staging-Leaks, http/https- und www/Nicht-www-Trennungen erzeugen alle Duplikate. Wählen Sie eine aus, kanonisieren oder leiten Sie den Rest um.

3. HTTPS

Basislinie, nicht optional. Stellen Sie die gesamte Website über HTTPS bereit, leiten Sie http auf https um und suchen Sie nach Mixed Content (eine sichere Seite, die ein unsicheres Bild, Skript oder Stylesheet lädt). Chris Greens SEO in 2026- Realitätscheck beziffert die HTTPS-Adoption auf “91%+” (Übersetzung) „91 % oder mehr“ – Sie wollen nicht in den hinteren 9 % landen.

4. Mobile SEO

Google verwendet Mobile-First-Indexierung: “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” (Übersetzung) „Google verwendet die mobile Version der Inhalte einer Website, die mit dem Smartphone-Agenten gecrawlt wird, für die Indexierung und das Ranking.“ Die Paritäts-Checkliste, direkt aus Googles Mobile-First-Dokumentation:

• “Make sure that your mobile site contains the same content as your desktop site.” (Übersetzung) „Stellen Sie sicher, dass Ihre mobile Website dieselben Inhalte enthält wie Ihre Desktop-Website.“
• “Make sure that the title element and the meta description are equivalent across both versions of your site.” (Übersetzung) „Stellen Sie sicher, dass Title-Element und Meta-Beschreibung in beiden Versionen Ihrer Website gleichwertig sind.“
• “Make sure that your mobile and desktop sites have the same structured data.” (Übersetzung) „Stellen Sie sicher, dass Ihre mobile Website und Ihre Desktop-Website dieselben strukturierten Daten enthalten.“
• “Use the same robots meta tags on the mobile and desktop site.” (Übersetzung) „Verwenden Sie auf der mobilen Website und der Desktop-Website dieselben Robots-Meta-Tags.“
• “Don’t lazy-load primary content upon user interaction.” (Übersetzung) „Laden Sie primäre Inhalte nicht erst nach einer Nutzerinteraktion nach.“
• “Make sure that the mobile site has the same alt text for images as the desktop site.” (Übersetzung) „Stellen Sie sicher, dass Bilder auf der mobilen Website denselben Alt-Text wie auf der Desktop-Website haben.“

Der häufigste Fehler ist eine abgespeckte mobile Vorlage, die stillschweigend Inhalte, Links oder strukturierte Daten entfernt, die auf dem Desktop vorhanden sind – Google indiziert die dünnere Version.

5. Sitemaps und Auffindbarkeit

• XML-Sitemap-Hygiene. Verwenden Sie absolute, kanonische URLs; bleiben Sie unter dem 50 MB / 50 000-URL-Limit pro Datei; listen Sie nur indexierbare, kanonische URLs; halten Sie lastmod korrekt. Verweisen Sie in robots.txt darauf (Sitemap: https://example.com/sitemap.xml), damit Suchmaschinen sie automatisch entdecken. Vollständige Behandlung im XML-Sitemaps-Material.
• Bing kümmert sich weiterhin darum. Aus Bings Leitfaden vom Juli 2025: “Sitemaps remain a foundational signal for ensuring comprehensive URL coverage across your site,” (Übersetzung) „Sitemaps bleiben ein grundlegendes Signal für eine umfassende URL-Abdeckung Ihrer Website“; “XML remains the preferred format for sitemaps,” (Übersetzung) „XML bleibt das bevorzugte Sitemap-Format“; und “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling.” (Übersetzung) „Das Feld lastmod in Ihrer Sitemap bleibt ein wichtiges Signal und hilft Bing, URLs für erneutes Crawlen zu priorisieren.“
• IndexNow. Die meisten Google-zentrierten Checklisten lassen es aus, aber es ist ein einfacher, kostenloser Gewinn: Bing empfiehlt, “Use IndexNow for real-time URL submission, instantly notifying Bing and participating search engines” (Übersetzung) „IndexNow für die URL-Übermittlung in Echtzeit zu verwenden und Bing sowie teilnehmende Suchmaschinen sofort zu benachrichtigen“, wenn sich Inhalte ändern. Es ergänzt Sitemaps, ersetzt sie aber nicht. (Hinweis: Google verwendet IndexNow nicht für allgemeine Seiten.)

6. Strukturierte Daten

• Was es bewirkt: schafft die Voraussetzung für Rich Results und hilft Maschinen (und LLMs), Ihre Seite zu verstehen. “Adding structured data can enable search results that are more engaging to users… which are called rich results.” (Übersetzung) „Das Hinzufügen strukturierter Daten kann ansprechendere Suchergebnisse ermöglichen; diese werden Rich Results genannt.“
• Was es nicht bewirkt: keine Ranking-Verbesserung. Die Google-Dokumentation beschreibt Schema ausschließlich als Berechtigung für Rich Results und maschinelles Verständnis – nicht als Ranking-Signal. Verkaufen Sie es nicht als Ranking-Maßnahme und planen Sie kein Budget dafür ein.
• Format: “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.” (Übersetzung) „Im Allgemeinen empfiehlt Google JSON-LD für strukturierte Daten, sofern die Einrichtung Ihrer Website dies zulässt, weil Website-Betreiber es am einfachsten in großem Umfang implementieren und pflegen können.“ Validieren Sie mit dem Rich Results Test. Das Material zu strukturierten Daten behandelt die spezifischen Typen, die sich lohnen.

7. Core Web Vitals und Seitenerfahrung

Ziele, keine Hürden – Google verwendet ausdrücklich “strive to,” (Übersetzung) „anstreben“; viele Checklisten überzeichnen diese Formulierung zu harten Bestehensgrenzen:

• LCP – “strive to have LCP occur within the first 2.5 seconds of the page starting to load.” (Übersetzung) „Streben Sie an, dass LCP innerhalb der ersten 2,5 Sekunden nach Ladebeginn eintritt.“
• INP – “strive to have an INP of less than 200 milliseconds.” (Übersetzung) „Streben Sie einen INP von weniger als 200 Millisekunden an.“
• CLS – “strive to have a CLS score of less than 0.1.” (Übersetzung) „Streben Sie einen CLS-Wert unter 0,1 an.“

Und zum häufig überbewerteten Verhältnis mit dem Ranking sagt Google: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (Übersetzung) „Die Google-Suche versucht stets, die relevantesten Inhalte anzuzeigen, selbst wenn die Seitenerfahrung unterdurchschnittlich ist.“ Gute Core Web Vitals sind ein Entscheidungskriterium zwischen relevanten Ergebnissen, kein Ersatz für Relevanz. Messen Sie mit echten Nutzerdaten (CrUX/Felddaten), nicht nur mit Laborwerten.

8. Erweiterte Ergänzungen (nur für große / E-Commerce- / stark JS-lastige Websites)

• Crawl-Budget. Nur wenn Sie die oben genannten Schwellenwerte von Google erreicht haben. Kapazität + Nachfrage; Sie gewinnen Budget eher durch die Beseitigung von Verschwendung (Parameter-Explosionen, Facetten-Navigations-Kombinationen, Spider-Fallen, doppelte URLs), als indem Sie versuchen, Google dazu zu bringen, „mehr“ zu crawlen. Siehe den Crawl-Budget-Deep-Dive.
• JavaScript-Rendering. Stellen Sie sicher, dass wichtige Inhalte und Links im gerenderten HTML vorhanden und über echte <a href>-Links erreichbar sind, nicht nur über klickbasierte Navigation. Dies ist JavaScript-SEO-Territorium.
• Kontrolle der Facettennavigation. Entscheiden Sie, welche Filter-/Sortierkombinationen crawlbar/indexierbar sind, und kontrollieren Sie den Rest.
• Logdatei-Analyse. Die Grundlage für das, was Bots tatsächlich abrufen, wie oft und mit welchen Statuscodes.
• hreflang – nur wenn Sie wirklich multiregional/mehrsprachig sind. Das ist ein großes Thema, das in einem eigenen internationalen SEO-Material behandelt werden sollte; setzen Sie es nicht halbfertig auf.

9. Zugriff für KI-/LLM-Crawler (kurz, begrenzt)

Zwei Grundvoraussetzungen im Jahr 2026, und nicht mehr – die tiefgehende GEO/AEO-Arbeit findet im KI-Suchmaterial statt, nicht hier:

• Entscheiden Sie über den Zugriff von KI-Crawlern in robots.txt. Erlauben oder verbieten Sie explizit die KI-User-Agents, die Ihnen wichtig sind (Trainings-, KI-Such- und nutzerausgelöste Fetcher sind unterschiedliche Bots). Chris Green formuliert es so: “Robots.txt is no longer just crawl housekeeping. It’s becoming a policy surface.” (Übersetzung) „robots.txt dient nicht mehr nur der Crawl-Verwaltung, sondern wird zunehmend zu einer Richtlinienoberfläche.“
• Strukturierte Daten dienen LLMs auch als Maschinenkontext – ein zusätzlicher Grund, Ihr Schema gültig zu machen, keine neue Arbeitslinie.

10. So priorisieren Sie, was Sie finden

Hier scheitern die meisten Checklisten: Sie liefern 90 Punkte ohne Gewichtung. Beheben Sie nicht alles, sondern das, was den größten Unterschied macht. Patrick rät zu Kunden-Audits: “If clients are coming to you asking for an audit, they already have a pain point. Talk to them. Solve that one thing and they’ll be happy with the audit.” (Übersetzung) „Wenn Kunden ein Audit anfragen, haben sie bereits ein konkretes Problem. Sprechen Sie mit ihnen. Lösen Sie genau dieses Problem, und sie werden mit dem Audit zufrieden sein.“ Das gleiche SEO Audit Template formuliert es als “sweating the small stuff rarely does much for your rankings” (Übersetzung) „Kleinigkeiten zu perfektionieren bringt Ihren Rankings selten viel“. Besser ist es, “80% of your time fixing the 20% of things that matter.” (Übersetzung) „80 % Ihrer Zeit auf die 20 % der Dinge zu verwenden, die wirklich zählen.“

Und betrachten Sie die gesamte Übung aus der Vogelperspektive: Eine Checkliste bringt Sie zu okay. John Mueller von Google hat wiederholt darauf hingewiesen, dass Grundlagen allein zu guten, aber nicht großartigen Ergebnissen führen – echte Dominanz entsteht durch thematische Tiefe und Autorität, nicht durch das Abhaken jedes technischen Kästchens. Die Checkliste räumt den Boden; Inhalte und Links bauen das Haus.

Möchten Sie die Vollversion der Website?

Diese Seite ist bewusst rein technisch. Wenn Sie den breiteren Audit wünschen – technisch plus On-Page, Content und Off-Page – dann ist das die SEO-Audit-Checkliste, ein separates, breiteres Ding. Versuchen Sie nicht, diese eine Seite beide Aufgaben erfüllen zu lassen.

KI-Zusammenfassung

Eine komprimierte Darstellung der erweiterten Version:

• Technisches SEO = die Basis. Googles vier Bedingungen: crawlbar, indexierbar, verständlich, renderbar. Sie zu erfüllen ist notwendig, aber nicht ausreichend – “indexing isn’t guaranteed.” (Übersetzung) „Die Indexierung ist nicht garantiert.“
• Nach Seitentyp filtern, nicht nur nach Thema. Die meisten kleinen Websites können Crawl-Budget, Facetten-Navigation, Log-Analyse und JS-Rendering-Engineering überspringen. Googles eigene Schwellenwerte: 1 Mio.+ Seiten, die wöchentlich wechseln, oder 10 000+, die täglich wechseln, oder viele “Discovered - currently not indexed.” (Übersetzung) „Entdeckt – zurzeit nicht indexiert“.
• Prioritätsreihenfolge: Crawlbarkeit (robots.txt, 4xx/5xx, Redirect-Ketten) → Indexierung (Abdeckung, Kanonisierung, Duplikate) → HTTPS + gemischte Inhalte → Mobile-First- Parität → XML-Sitemap + IndexNow → strukturierte Daten → Core Web Vitals.
• Zwei Mythen, die es zu entkräften gilt: robots.txt deindexiert nicht (blockierte, aber verlinkte URLs können weiterhin nackt erscheinen); strukturierte Daten sind kein Ranking-Faktor (nur Rich-Result-Berechtigung).
• CWV sind Ziele, keine Hürden – Google verwendet “strive to” (Übersetzung) „anstreben“: LCP < 2,5 s, INP < 200ms, CLS < 0,1. Außerdem: “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (Übersetzung) „Die Google-Suche versucht stets, die relevantesten Inhalte zu zeigen, selbst wenn die Seitenerfahrung unterdurchschnittlich ist.“
• Mobile-First-Parität: gleiche Inhalte, Titel/Meta, strukturierte Daten, Robots-Meta- Tags und Alt-Text auf Mobilgeräten und Desktop; laden Sie primäre Inhalte nicht erst bei Interaktion nach.
• Nach Wirkung priorisieren (lösen Sie den tatsächlichen Schmerzpunkt des Kunden; 80/20). Eine Checkliste bringt Sie zu „okay“; thematische Tiefe gewinnt.
• Vollversion der Website (technisch + Inhalt + Links) = die separate SEO-Audit-Checkliste.

Offizielle Dokumentation

Primärquellen-Dokumentation der Suchmaschinen.

Google

• Technische Anforderungen für die Google Suche – die Mindestanforderungen für Crawlbarkeit/Funktion/Indexierbarkeit und den Hinweis „Indexierung ist nicht garantiert“.
• Einführung in robots.txt – was robots.txt tut und nicht tut.
• Sitemap erstellen und einreichen – Formate, das 50-MB-/50 000-URL-Limit und die Referenzierung in robots.txt.
• Doppelte URLs zusammenführen – Kanonisierungssignale und „verwenden Sie robots.txt nicht zur Kanonisierung“.
• Einführung in strukturierte Daten – Rich Results und die JSON-LD-Empfehlung.
• Core Web Vitals verstehen – die „bemühen Sie sich um“-LCP/INP/CLS-Ziele.
• Seitenerfahrung in den Google-Suchergebnissen – Relevanz vs. Seitenerfahrung.
• Best Practices für Mobile-First-Indexierung – die Paritätsanforderungen für Mobilgeräte/Desktop.
• Crawl-Budget optimieren – wer tatsächlich Crawl-Budget-Verwaltung benötigt, mit Schwellenwerten (früher betitelt „Leitfaden für Betreiber großer Websites zur Verwaltung des Crawl-Budgets“; das Dokument wurde unter Googles Crawling-Infrastruktur-Dokumentation verschoben).

Bing / Microsoft

• Inhalte mit Sitemaps in der KI-gestützten Suche auffindbar halten – Bings Sitemap- und IndexNow-Leitfaden vom Juli 2025.
• Bing-Webmaster-Richtlinien – Crawling, Indexierung, Ranking und Qualität (per Referenz zitieren; die Seite ist JS-gerendert).

Zitate aus der Quelle

Dokumentierte Aussagen von Google und Bing. Ein entsprechend markierter Link führt direkt zur zitierten Passage auf der Quellseite.

Google – die Mindestanforderungen

• “Client and server error pages aren’t indexed.” (Übersetzung) „Client- und Serverfehlerseiten werden nicht indexiert.“ — Google Search Central, Google Search technical requirements. Zum Zitat springen
• “Just because a page meets these requirements doesn’t mean that a page will be indexed; indexing isn’t guaranteed.” (Übersetzung) „Nur weil eine Seite diese Anforderungen erfüllt, bedeutet das nicht, dass sie indexiert wird; die Indexierung ist nicht garantiert.“ Zum Zitat springen

Google – robots.txt und Kanonisierung

• “A robots.txt file tells search engine crawlers which URLs the crawler can access on your site. This is used mainly to avoid overloading your site with requests; it is not a mechanism for keeping a web page out of Google.” (Übersetzung) „Eine robots.txt-Datei teilt den Crawlern von Suchmaschinen mit, auf welche URLs der Crawler auf Ihrer Website zugreifen kann. Dies dient hauptsächlich dazu, eine Überlastung Ihrer Website durch Anfragen zu vermeiden; es ist kein Mechanismus, um eine Webseite von Google fernzuhalten.“ Zum Zitat springen
• “rel=“canonical” link annotations are a strong signal that the specified URL should become canonical… Don’t use the robots.txt file for canonicalization purposes.” (Übersetzung) „rel=“canonical”-Link-Anmerkungen sind ein starkes Signal dafür, dass die angegebene URL kanonisch werden sollte … Verwenden Sie die robots.txt-Datei nicht für Kanonisierungszwecke.“ — Google, Consolidate duplicate URLs. Dokumentation lesen

Google – strukturierte Daten und Core Web Vitals

• “Adding structured data can enable search results that are more engaging to users… which are called rich results.” (Übersetzung) „Das Hinzufügen strukturierter Daten kann Suchergebnisse ermöglichen, die für Nutzer ansprechender sind … diese werden als Rich Results bezeichnet.“ — Google, Intro to structured data markup. Dokumentation lesen
• “In general, Google recommends using JSON-LD for structured data if your site’s setup allows it, as it’s the easiest solution for website owners to implement and maintain at scale.” (Übersetzung) „Im Allgemeinen empfiehlt Google die Verwendung von JSON-LD für strukturierte Daten, wenn das Setup Ihrer Website dies zulässt, da es für Website-Betreiber die einfachste Lösung ist, um sie in großem Umfang zu implementieren und zu pflegen.“ Dokumentation lesen
• “strive to have LCP occur within the first 2.5 seconds” (Übersetzung) „Streben Sie an, dass LCP innerhalb der ersten 2,5 Sekunden eintritt“; “strive to have an INP of less than 200 milliseconds” (Übersetzung) „Streben Sie einen INP von weniger als 200 Millisekunden an“; “strive to have a CLS score of less than 0.1.” (Übersetzung) „Streben Sie einen CLS-Wert unter 0,1 an.“ — Google, Understanding Core Web Vitals. Dokumentation lesen
• “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (Übersetzung) „Die Google-Suche versucht stets, die relevantesten Inhalte anzuzeigen, auch wenn die Seitenerfahrung unterdurchschnittlich ist.“ — Google, Page experience. Dokumentation lesen

Google – Mobile-First-Indexierung

• “Google uses the mobile version of a site’s content, crawled with the smartphone agent, for indexing and ranking.” (Übersetzung) „Google verwendet die mobile Version des Inhalts einer Website, die mit dem Smartphone-Agenten gecrawlt wird, für die Indexierung und das Ranking.“ — Google, Mobile-first indexing best practices. Dokumentation lesen

Google – Crawl-Budget (wer es braucht)

• “If your site doesn’t have a large number of pages that change rapidly, or if your pages seem to be crawled the same day that they are published, you don’t need to read this guide.” (Übersetzung) „Wenn Ihre Website nicht viele Seiten hat, die sich schnell ändern, oder wenn Ihre Seiten scheinbar am selben Tag gecrawlt werden, an dem sie veröffentlicht werden, müssen Sie diesen Leitfaden nicht lesen.“ — Google, Crawl-Budget optimieren. Zum Zitat springen

Bing – Sitemaps und IndexNow (Juli 2025)

• “XML remains the preferred format for sitemaps.” (Übersetzung) „XML bleibt das bevorzugte Format für Sitemaps.“ / “The lastmod field in your sitemap remains a key signal, helping Bing prioritize URLs for recrawling.” (Übersetzung) „Das lastmod-Feld in Ihrer Sitemap bleibt ein wichtiges Signal und hilft Bing, URLs für das erneute Crawlen zu priorisieren.“ — Fabrice Canel & Krishna Madhavan, Bing Webmaster Blog. Beitrag lesen

Patrick Stox – wie man ein Audit priorisiert

• “If clients are coming to you asking for an audit, they already have a pain point. Talk to them. Solve that one thing and they’ll be happy with the audit.” (Übersetzung) „Wenn Kunden zu Ihnen kommen und ein Audit anfragen, haben sie bereits einen Schmerzpunkt. Sprechen Sie mit ihnen. Lösen Sie genau diese eine Sache, und sie werden mit dem Audit zufrieden sein.“ — Patrick Stox, zitiert in Ahrefs’ Free SEO Audit Template. Zum Zitat springen

Welche Checkliste sollte ich tatsächlich ausführen?

Führen Sie nicht dieselbe 90-Punkte-Liste auf jeder Website aus. Beginnen Sie hier.

F1. Wie viele URLs hat Ihre Website und wie schnell ändern sich die Inhalte?

• Unter ~10 000 URLs, die sich gelegentlich ändern → führen Sie die Starter-Strecke aus und stoppen Sie: Crawlbarkeits-Sanity-Check, Indexierungs-/Kanonik-Sanity-Check, HTTPS, Mobile-Parität, eine XML-Sitemap, eine Runde Core Web Vitals, valide strukturierte Daten, wo sie ein Rich Result verdienen. Überspringen Sie Crawl-Budget, Facetten-Navigationskontrolle, Log-Analyse und JS-Rendering- Engineering. Gehen Sie zu F3.
• 10 000+ URLs, die sich täglich ändern, oder 1 Mio.+ wöchentlich, oder viele URLs mit dem Status “Discovered - currently not indexed” (Übersetzung) „Entdeckt – zurzeit nicht indexiert“ → führen Sie die Fortgeschrittenen-Strecke aus (Starter + Crawl-Budget + Facetten-Navigation + JS-Rendering + Logs). Gehen Sie zu F2.

F2. Ist die Website JavaScript-lastig oder international?

• JS-lastig (SPA, client-gerenderte Inhalte/Links) → fügen Sie ein Rendering-Audit hinzu: Bestätigen Sie, dass kritische Inhalte und <a href>-Links im gerenderten HTML vorhanden sind. Dies ist der Punkt, der am wahrscheinlichsten stillschweigend Ihre Indexierung kostet.
• Wirklich mehrregionig / mehrsprachig → fügen Sie hreflang hinzu, ordentlich umgesetzt, in einem eigenen Arbeitsstrom. Wenn Sie nicht wirklich international sind, überspringen Sie es.
• Weder noch → fahren Sie mit F3 fort.

F3. Was hat das Audit aufgedeckt – und was sollten Sie zuerst beheben?

• Ein Crawl-/Indexierungsblocker (robots.txt-Disallow auf wichtigen Seiten, massenhaftes noindex, falsches Canonical, seitenweite 5xx) → zuerst beheben, immer. Diese blockieren alles darunter.
• Viele mittlere Probleme, begrenzte Zeit → wenden Sie das 80/20-Prinzip an: Beheben Sie die ~20 %, die den Unterschied machen, und wenn es ein Kunde ist, beheben Sie zuerst den spezifischen Schmerzpunkt, mit dem sie zu Ihnen gekommen sind. Übergeben Sie nicht 90 undifferenzierte Einzelposten.
• Nur noch kosmetische/Randprobleme übrig → Sie haben die Basis erreicht. Hören Sie auf, die Infrastruktur zu optimieren und gehen Sie zu Inhalten und Links über.

F4. Möchten Sie tatsächlich die Vollversion der Website?

• Ja – technisch + Inhalt + On-Page + Links → diese technische Checkliste ist es nicht. Führen Sie stattdessen die umfassendere SEO-Audit-Checkliste aus; diese Seite ist bewusst nur technisch.
• Nein – nur die technische Basis → Sie sind auf der richtigen Seite.

Einzeiler: klein + stabil → nur Starter-Strecke; groß/JS/international → fügen Sie die fortgeschrittenen Abschnitte hinzu; dann beheben Sie zuerst Crawl-/Indexierungsblocker und priorisieren Sie den Rest nach Auswirkung.

Die technische SEO-Checkliste

Zwei Strecken. Führen Sie die Starter-Strecke auf jeder Website aus; fügen Sie die fortgeschrittenen Punkte nur hinzu, wenn Sie das Website-Typ-Gate erfüllen (10K+ URLs, die sich täglich ändern, 1M+ wöchentlich, oder JS-lastig/international).

Starter-Strecke – jede Website

Crawlbarkeit

• robots.txt verbietet nichts, das Sie indexiert haben möchten (und blockiert doch Bereiche mit geringem Wert wie interne Suche).
• Keine wichtige URL ist in robots.txt blockiert und verlässt sich auf ein noindex (die Falle).
• Unerwartete 4xx/5xx behoben; wichtige Seiten geben 200 zurück.
• Redirect-Ketten/-Schleifen auf einen einzigen Hop reduziert.

Indexierbarkeit

• Seiten-Indexierungsbericht abgeglichen – was Sie indexiert haben möchten, ist tatsächlich indexiert.
• Kanonische URLs zeigen auf eine bevorzugte Version; keine widersprüchlichen Signale zwischen HTML-Tag, HTTP-Header und Sitemap.
• http→https und www/nicht-www auf eine Version vereinheitlicht.

HTTPS

• Gesamte Website auf HTTPS; http leitet auf https weiter.
• Kein gemischter Inhalt (sichere Seite lädt unsichere Ressourcen).

Mobilgeräte

• Mobile Version hat denselben Inhalt, dieselben Titel/Meta, strukturierte Daten, Robots-Meta-Tags und Alt-Texte wie die Desktop-Version.
• Primärer Inhalt wird nicht erst bei Benutzerinteraktion nachgeladen.

Sitemaps

• XML-Sitemap listet nur kanonische, indexierbare URLs; korrektes lastmod; unter 50 MB/50 000 URLs pro Datei.
• Sitemap in der Search Console und in Bing Webmaster Tools eingereicht und in robots.txt referenziert.

Strukturierte Daten

• Schema (JSON-LD) im Rich Results Test gültig und nur dort verwendet, wo es ein Rich Result einbringt.

Core Web Vitals

• LCP, INP, CLS anhand von Feld-/CrUX-Daten gegen Googles Zielwerte (2,5 s / 200ms / 0,1) geprüft – als Richtwerte behandelt, nicht als Bestehen/Nichtbestehen-Schwellen.

Erweiterter Pfad – nur für große / E-Commerce / JS-lastige / internationale Websites

• Crawl-Budget geprüft (nur wenn Googles Schwellen überschritten); Verschwendung entfernt (Parameter, Facetten, Fallen, Duplikate).
• JS-Rendering geprüft – kritischer Inhalt und <a href>-Links im gerenderten HTML vorhanden.
• Facettierte Navigation: entschieden, welche Kombinationen crawlbar/indexierbar sind.
• Server-Logs auf Crawl-Verschwendung und nicht gecrawlte wichtige URLs analysiert.
• IndexNow für die Echtzeit-Übermittlung von Änderungen an Bing und teilnehmende Suchmaschinen eingerichtet.
• hreflang korrekt und reziprok (nur bei tatsächlich mehrsprachigen/multiregionalen Websites).
• Zugriff von KI-Crawlern in robots.txt explizit festgelegt.

Die mentalen Modelle

1. Die vier Bedingungen – crawlbar → indexierbar → verständlich → renderbar. Jeder technische Punkt dient einer dieser Bedingungen. Wenn eine Seite nicht performt, finden Sie heraus, welche Bedingung sie verletzt, bevor Sie etwas anfassen: Ist sie überhaupt crawlbar? Indexierbar? Verständlich? Gerendert?

2. Fundament, nicht Obergrenze. Technisches SEO schafft das Fundament, damit Inhalte und Links ihre Wirkung entfalten können. “Indexing isn’t guaranteed” (Übersetzung) „Die Indexierung ist nicht garantiert“, selbst wenn Sie alle Prüfungen bestehen – behandeln Sie ein grünes technisches Audit also nicht als „SEO erledigt“.

3. Nach Websitetyp eingrenzen. Der nützlichste Schritt: Entscheiden Sie im Voraus, welche Abschnitte nicht zutreffen. Kleine/stabile Website → Starter-Pfad, erweiterte Infrastruktur überspringen. Groß/JS/international → hinzufügen. Google grenzt seine eigenen Crawl-Budget-Empfehlungen so ein; Sie sollten es auch tun.

4. Signale vs. Direktiven. Unterscheiden Sie, welche Kontrollen Google befolgen muss und welche nur starke Signale sind. noindex ist eine Direktive; rel=canonical ist “a strong signal” (Übersetzung) „ein starkes Signal“, das Google übersteuern kann. Die CWV-Werte sind mit “strive to” (Übersetzung) „anstreben“ formulierte Ziele, keine Hürden. Schlechte Empfehlungen entstehen oft dadurch, dass ein Signal fälschlich als Garantie dargestellt wird.

5. Wirkung vor Vollständigkeit (80/20). Eine Checkliste mit 90 Punkten ist ein Menü, keine To-do-Liste. Beheben Sie die ~20 %, die den Unterschied machen, lösen Sie zuerst den eigentlichen Schmerzpunkt, und hören Sie auf, die Infrastruktur zu optimieren, sobald das Fundament klar ist.

6. Dies ist der technische Teil. Crawl-/Index-/Render-/Auslieferungsmechanik gehört hierher; Inhaltsqualität, Keyword-Ausrichtung und Links gehören zur umfassenderen SEO-Audit-Checkliste. Halten Sie die Grenze sauber, damit keine der beiden Aufgaben halb erledigt bleibt.

Technisches SEO – Schnellreferenz

Was jede Kontrolle bewirkt

Core Web Vitals-Zielwerte (Googles „anstreben“-Zahlen)

Crawl-Budget-„Relevanz?“-Schwellenwerte (Googles eigene, bewusst grob)

• ~1 Mio.+ Seiten, die sich etwa wöchentlich ändern → ja.
• 10 000+ Seiten, die sich täglich ändern → ja.
• Große Gruppe mit “Discovered - currently not indexed” (Übersetzung) „Entdeckt – zurzeit nicht indexiert“ → ja.
• Sonst → “you don’t need to read this guide.” (Übersetzung) „Sie müssen diesen Leitfaden nicht lesen.“

Schnelle Fakten

• Sitemap-Limit: 50 MB / 50 000 URLs pro Datei; XML bevorzugt; in der robots.txt referenzieren.
• Strukturierte Daten: Rich Results, keine Rankings. JSON-LD empfohlen.
• IndexNow: Bing/Yandex/andere – nicht Google. Google indexiert die mobile Version.
• Mobile Parität: gleicher Inhalt, Titel/Meta, strukturierte Daten, Robots-Meta-Tags, Alt-Text.

Mythen und Fehler, die Sie vermeiden sollten

Die häufigsten Fallstricke – mehrere davon sind weit verbreitete Mythen, die eine Korrektur verdienen:

• „Das Blockieren einer URL in der robots.txt hält sie aus Google heraus.“ Nein. Google: “it is not a mechanism for keeping a web page out of Google.” (Übersetzung) „Es ist kein Mechanismus, um eine Webseite aus Google herauszuhalten.“ Eine gesperrte URL kann trotzdem indexiert werden (nackt, ohne Snippet), wenn sie extern verlinkt ist. Verwenden Sie noindex oder Passwortschutz.
• „Sperren Sie die URL in der robots.txt und setzen Sie zusätzlich noindex.“ Die häufigste selbst zugefügte Wunde. Wenn die URL blockiert ist, crawlt Googlebot sie nie, also sieht er das noindex nie – und die URL kann trotzdem nackt auftauchen. Wählen Sie eines: Crawl erlauben + noindex, oder nicht erlauben (akzeptieren, dass sie trotzdem erscheinen kann).
• „Schema hinzufügen verbessert Rankings.“ Nein. Google stellt strukturierte Daten ausschließlich als Rich-Result-Berechtigung und maschinelles Verständnis dar – nicht als Ranking-Signal. Verkaufen Sie es als reichhaltigere Ergebnisse, nicht als höhere Positionen.
• „Core Web Vitals zu bestehen schlägt einen relevanteren Wettbewerber.“ Nein. “Google Search always seeks to show the most relevant content, even if the page experience is sub-par.” (Übersetzung) „Die Google-Suche versucht stets, die relevantesten Inhalte zu zeigen, auch wenn die Seitenerfahrung unterdurchschnittlich ist.“ CWV ist ein ergänzendes Signal, kein Ersatz für Relevanz.
• „CWV-Schwellenwerte sind harte Bestehen/Nichtbestehen-Gates.“ Google verwendet “strive to” (Übersetzung) „anstreben“ – sie sind Ziele. Ein perfektes Laborergebnis auf Kosten von allem anderen zu jagen, ist verschwendete Mühe.
• „Crawl-Budget ist für jede Website wichtig.“ Nein. Google beschränkt seinen eigenen Leitfaden auf 1 Mio.+ Seiten (wöchentliche Änderungen) oder 10 000+ (täglich). Den meisten kleinen Websites wird direkt gesagt: “you don’t need to read this guide.” (Übersetzung) „Sie müssen diesen Leitfaden nicht lesen.“ Verschwenden Sie bei kleinen Websites keine Zeit mit unnötiger Crawl-Budget-Optimierung.
• „rel=canonical ist eine Direktive, die Google befolgen muss.“ Nein – es ist “a strong signal.” (Übersetzung) „ein starkes Signal“. Google kann bei widersprüchlichen Signalen ein anderes Canonical auswählen. Reduzieren Sie die Konflikte, statt davon auszugehen, dass das Tag gewinnt.
• „Ein grünes technisches Audit bedeutet, dass SEO abgeschlossen ist.“ Nein. “Indexing isn’t guaranteed” (Übersetzung) „Die Indexierung ist nicht garantiert“, selbst wenn Sie alle Prüfungen bestehen. Technisches SEO ist das Fundament; Inhalte und Links bleiben erforderlich.
• „Führen Sie dieselbe 90-Punkte-Liste auf jeder Website aus.“ Der Unterschied liegt darin zu wissen, was man überspringen sollte. Segmentieren Sie Abschnitte nach Website-Typ und priorisieren Sie nach Wirkung, sonst ertränken Sie Kunden in irrelevanten Einzelposten.

SOP: Technische SEO-Checkliste ausführen (wiederkehrend)

Ein wiederholbarer Durchlauf. Ungefähr 60–90 Minuten für eine kleine Website; einen Tag oder mehr für große/JS-lastige. Führen Sie ihn vierteljährlich oder nach jeder großen Migration, jedem Redesign oder jeder CMS-Änderung durch.

1. Bestätigen Sie den Seitentyp und wählen Sie eine Spur. Zählen Sie die URLs (Search Console → Seiten oder ein Crawl) und notieren Sie, wie schnell sich Inhalte ändern. Unter ~10K und stabil → nur Starter-Spur. Über den Schwellenwerten oder JS-lastig/international → fügen Sie die Advanced-Abschnitte hinzu. Das entscheidet, was Sie überspringen.
2. Crawlen Sie die Website mit Screaming Frog, Ahrefs Site Audit oder Ähnlichem. Erfassen Sie Statuscodes, Redirect-Ketten, blockierte URLs, Kanonische, Indexierbarkeit und Tiefe.
3. Prüfen Sie zuerst robots.txt. Rufen Sie /robots.txt ab, bestätigen Sie, dass nichts Wichtiges ausgeschlossen ist, und prüfen Sie auf die Disallow-plus-noindex-Falle. Bestätigen Sie, dass die Sitemap:-Zeile vorhanden ist.
4. Gleichen Sie die Indexierung ab. Vergleichen Sie im Page-Indexing-Bericht der Search Console, was indexiert ist, mit dem, was Sie indexiert haben möchten. Untersuchen Sie große Gruppen mit “Discovered/Crawled - currently not indexed” (Übersetzung) „Entdeckt/Gecrawlt – zurzeit nicht indexiert“ sowie „Duplicate“-Gruppen.
5. Überprüfen Sie HTTPS und mobile Parität. Bestätigen Sie siteweites HTTPS ohne gemischte Inhalte. Vergleichen Sie dann die mobil gerenderte Seite mit dem Desktop in Bezug auf Inhalte, Titel/Meta, strukturierte Daten, Robots-Meta-Tags und Alt-Text (Google indexiert die mobile Version).
6. Validieren Sie Sitemaps und strukturierte Daten. Bestätigen Sie, dass die XML-Sitemap nur kanonische, indexierbare URLs mit korrektem lastmod auflistet; führen Sie wichtige Vorlagen durch den Rich-Results-Test.
7. Ziehen Sie Core Web Vitals aus Felddaten. Verwenden Sie den CrUX/Feldbericht in der Search Console oder PageSpeed Insights – nicht nur Laborwerte – und vergleichen Sie mit den 2,5 s / 200ms / 0,1 Zielen.
8. (Advanced-Spur) Analysieren Sie Logs und Crawl-Budget. Lesen Sie Server-Logs auf Crawl-Verschwendung und nicht gecrawlte wichtige URLs; prüfen Sie JS-Rendering und Facetten-Navigations-Kombinationen.
9. Priorisieren Sie die Ergebnisse nach Auswirkung, nicht nach Anzahl. Setzen Sie Crawl-/Index-Blocker an die Spitze; wenden Sie 80/20 auf den Rest an; wenn es ein Kunde ist, führen Sie mit seinem tatsächlichen Schmerzpunkt.
10. Protokollieren Sie eine Basislinie und prüfen Sie im nächsten Zyklus erneut. Halten Sie den Zustand fest, damit der nächste Quartalsdurchlauf Fortschritt misst, nicht einen Neustart.

Fertige KI-Prompts

Copy-Paste-Ausgangspunkte für die Triage einer technischen SEO-Checkliste mit einem LLM. Überprüfen Sie LLM-Ausgaben immer gegen Primärdokumente und Ihre eigenen Crawl-Daten – behandeln Sie diese als Entwurfshilfen, nicht als Quellen der Wahrheit.

Die richtige Spur für eine Website auswählen

Ich betreibe eine Website mit etwa [N] URLs, und Inhalte ändern sich ungefähr [wie oft]. Sie ist auf [CMS/Framework] aufgebaut, ist [einsprachig / mehrsprachig] und ist [statisch / JavaScript-gerendert]. Basierend auf Googles eigenen Größen-Schwellenwerten für das Crawl-Budget, sagen Sie mir, welche Abschnitte einer technischen SEO-Checkliste wirklich auf mich zutreffen und welche ich sicher überspringen kann. Seien Sie explizit, was zu überspringen ist und warum.

Crawl-Export nach Auswirkung triagieren

Hier ist ein CSV-Export aus einem Website-Crawl [Spalten einfügen: URL, Statuscode, Indexierbarkeit, Kanonische, Redirect-Kette, robots.txt-Status]. Gruppieren Sie die Probleme in (1) Crawl-/Index-Blocker, die zuerst behoben werden sollten, (2) mittlere Auswirkungen, (3) kosmetisch/geringe Auswirkungen. Für jede Gruppe erklären Sie die SEO-Konsequenz in einem Satz. Sagen Sie mir nicht, „alles zu reparieren“ – ordnen Sie nach Auswirkung.

Einen bestimmten Indexierungsstatus erklären

Eine Gruppe meiner URLs zeigt [exakter Search-Console-Status, z. B. “Discovered - currently not indexed” (Übersetzung) „Entdeckt – zurzeit nicht indexiert“]. Erklären Sie die wahrscheinlichen Ursachen in Prioritätsreihenfolge, wie Sie jede diagnostizieren, und die konkrete Lösung. Kennzeichnen Sie alles, was ein Symptom des Crawl-Budgets vs. ein Problem pro Seite ist.

Plausibilitätsprüfung für die robots.txt + noindex-Falle

Hier ist meine robots.txt [einfügen] und eine Liste von URLs, die ich aus Google heraushalten möchte [einfügen]. Sagen Sie mir für jede URL, ob mein aktuelles Setup sie tatsächlich aus dem Index heraushält oder in die Falle „in robots.txt blockiert, aber über Links weiterhin indexierbar“ fällt, und geben Sie die korrekte Lösung (Crawl erlauben + noindex, oder Passwortschutz).

Einen priorisierten Sanierungsplan entwerfen

Wandeln Sie diese bestätigten technischen Befunde [einfügen] in einen priorisierten Sanierungsplan für einen Entwickler um: zuerst Blocker, dann nach Auswirkung sortiert, jeweils mit der konkreten Änderung und einer einzeiligen Begründung. Der vom Kunden genannte Schmerzpunkt ist [X] – setzen Sie zuerst Korrekturen um, die damit zusammenhängen.

Tools für die Bearbeitung der technischen SEO-Checkliste

Beginnen Sie mit gezielten Tests für den Fehler, den Sie prüfen. Ein einzelner All-in-One-Score verdeckt oft den Unterschied zwischen Crawl-Zugriff, Antwortverhalten, Indexsignalen, Rendering und Feldleistung.

Patricks kostenlose Tools

• Google Index Checker prüft den beobachtbaren Status, Weiterleitungen, noindex und Canonical-Blocker und verweist Sie dann an URL Inspection für den tatsächlichen Indexstatus von Google.
• robots.txt Tester testet URLs gegen Bot-Regeln und zeigt die gewinnende Allow- oder Disallow-Regel. Verwenden Sie ihn, bevor Sie Crawl-Kontrollen ändern.
• XML Sitemap Validator prüft Sitemap-Syntax, URL- Inventar und Dateiprobleme, bevor Sie die Datei einreichen.
• Canonicalization Checker vergleicht HTML- und HTTP- Canonical-Signale und testet die Ziel-URL auf Konflikte.
• Bulk HTTP Status Code Checker prüft Statuscodes, Ziele, Ketten und Schleifen über eine URL-Menge.
• Schema Markup Validator validiert strukturierte Daten- Syntax und die Anforderungen von Google für Rich Results vor der Veröffentlichung.
• Render Gap vergleicht initiales HTML mit gerendertem Output für JavaScript-abhängige Inhalte, Links, Canonicals und Robots-Direktiven.
• Core Web Vitals Checker trennt verfügbare Felddaten von einer aktuellen Leistungsprüfung, damit Sie einen Lab-Lauf nicht mit Nutzerdaten verwechseln.
• Mobile-Friendly Tester prüft Viewport, responsives Layout, Tap-Targets und verwandte mobile Implementierungssignale.
• Log File Analyzer verwandelt Server-Logs in Beweise dafür, was Such-Bots tatsächlich abgerufen haben – am nützlichsten bei großen Websites.

Suchmaschinen-Tools

• Google Search Console bietet Page Indexing, URL Inspection, Crawl Stats, Sitemaps, Core Web Vitals, Rich-Result-Berichte, manuelle Maßnahmen und Sicherheitsprobleme.
• Bing Webmaster Tools ergänzt Bings eigene Index- und Leistungsansichten, IndexNow, Site Explorer, Site Scan und Crawl Control.

Crawler und Browser-Tools

• Ahrefs Site Audit oder Screaming Frog SEO Spider ist die skalierbare Ebene zum Crawlen von Vorlagen, Statuscodes, Direktiven, internen Links und strukturierten Daten.
• Chrome DevTools legt die Netzwerkantwort, das gerenderte DOM, Konsolenfehler und Leistungs-Trace für einzelne Seiten offen.
• PageSpeed Insights und CrUX bieten Googles Labor- und Feldleistungsansichten; verwenden Sie Felddaten für die dauerhafte Nutzererfahrungs-Baseline, wenn verfügbar.

Testen Sie sich: Technische SEO-Checkliste

Fünf kurze Fragen dazu, was auf eine technische SEO-Checkliste gehört und wie man priorisiert. Wählen Sie eine Antwort für jede Frage und prüfen Sie dann.

Ressourcen, die Ihre Zeit wert sind

Meine verwandten Artikel

• Einführung in technisches SEO – das größere Bild, in das diese Checkliste eingebettet ist.
• Vorlage für ein SEO-Audit – mein wirkungsorientierter 80/20-Rahmen und der Rat, das tatsächliche Problem des Kunden zu lösen; zugleich kommt dieser Beitrag einem umfassenden Website-Audit am nächsten.
• Wie ich zwei gut rankende Seiten mit robots.txt blockierte – mein eigenes Experiment dazu, was eine robots.txt-Sperre tatsächlich bewirkt.
• Indexiert, obwohl durch robots.txt blockiert – der Mechanismus hinter der Disallow-plus-noindex-Falle.
• robots.txt und SEO: Alles, was Sie wissen müssen.

Meine Vorträge

• So funktioniert die Suche (SlideShare) – mein Durchlauf von Crawling, Rendering, Indexierung und Ranking, also der Pipeline, die diese gesamte Checkliste absichert.

Meine veröffentlichten Arbeiten, die zitierwürdig sind

• Web Almanac 2021 – SEO-Kapitel – ich war Hauptautor; die Quelle für die Häufigkeit widersprüchlicher Canonical-Signale im realen Web.
• Rankable, Folge 65 – Prioritäten im technischen SEO ordnen (iPullRank) – mein Beitrag dazu, technische Probleme auf einer Roadmap zu priorisieren; genau das ist das Organisationsprinzip dieser Checkliste.

Aus der Branche

• Technische Anforderungen der Google-Suche – die maßgebliche Aussage zu den Mindestanforderungen und der Hinweis, dass eine Indexierung nicht garantiert ist.
• Crawl-Budget optimieren (Google) – die Quelle für die Abgrenzung nach Websitegröße; die Seite hieß früher „Leitfaden für Betreiber großer Websites zur Verwaltung des Crawl-Budgets“ und wurde in die Dokumentation zur Crawling-Infrastruktur verschoben.
• Inhalte mit Sitemaps in der KI-gestützten Suche auffindbar halten (Bing) – Sitemap- und IndexNow-Empfehlungen, welche die meisten rein auf Google ausgerichteten Checklisten auslassen.
• SEO im Jahr 2026: höhere Standards, KI-Einfluss und ein Web mit Nachholbedarf (Chris Green, Search Engine Land) – ein Realitätscheck zum tatsächlichen Stand von Websites (HTTPS-Adoption von 91 % oder mehr; robots.txt als Richtlinienoberfläche).
• Web Almanac 2022 – SEO-Kapitel (HTTP Archive) – Daten zu Kanonisierungsmethoden und zur Verbreitung von Schema-Markup im Web.
• Technische SEO-Checkliste: der vollständige Leitfaden (DebugBear) – eine stark leistungsorientierte Sicht auf dasselbe Gebiet.
• Technische SEO-Checkliste mit mehr als 90 Punkten (Kristina Azarenko) – eine gründliche, prioritätsorientierte Alternative.

Statistiken, die sich zu zitieren lohnen

• HTTPS-Adoption ~91 %+. Wo Websites hinsichtlich der HTTPS-Baseline Anfang 2026 tatsächlich stehen (HTTP Archive-Daten, via Chris Green). Quelle
• Kanonische Adoption stieg von 65 % (2024) auf 67 %+ (2025). Die Abdeckung des kanonischen Tags nimmt zu, ist aber weit von universell entfernt. Quelle
• ~67 % der Bilder haben kein loading-Attribut; 91 %+ der iframes haben keins. Naheliegende Leistungsgewinne, welche die meisten Websites noch ungenutzt lassen. Quelle
• Widersprüchliche kanonische Signale traten auf ~0,3–0,4 % der Seiten auf. Klein, aber real — ein Grund, warum größere Websites auf kanonische Konflikte über mehrere Signale hinweg prüfen sollten (Web Almanac 2021 SEO-Kapitel, das ich geleitet habe). Quelle
• Sitemap-Dateilimit: 50 MB / 50 000 URLs pro Datei — die harte Obergrenze, gegen die große Sitemaps aufgeteilt werden sollten (Google). Quelle

Änderungsprotokoll