Technisches SEO & Core Web Vitals 2026: Der vollständige Leitfaden

Technisches SEO bildet das Fundament, auf dem alle anderen SEO-Maßnahmen aufbauen. Die brillantesten Inhalte und die stärksten Backlinks helfen wenig, wenn Google eine Website nicht korrekt crawlen und indexieren kann.

Dieser Leitfaden deckt alle wesentlichen Bereiche des technischen SEO ab – von der Crawling-Steuerung über Page Speed bis zu den Core Web Vitals, die Google seit 2021 als offizielle Ranking-Signale bewertet.

---

Inhaltsverzeichnis

1. Was ist technisches SEO und warum ist es die Grundlage?
2. Crawling: Wie Google Ihre Website entdeckt
3. Indexierung: Was tatsächlich in den Index kommt
4. Seitenarchitektur und interne Verlinkung
5. HTTPS und Sicherheit
6. Structured Data und Schema Markup
7. Core Web Vitals: LCP, INP, CLS
8. Largest Contentful Paint (LCP) optimieren
9. Interaction to Next Paint (INP) optimieren
10. Cumulative Layout Shift (CLS) optimieren
11. Mobile-First Indexierung
12. Internationale SEO und Hreflang
13. Duplicate Content technisch lösen
14. Technisches SEO Audit: Schritt für Schritt
15. Checkliste und FAQ

---

1. Was ist technisches SEO und warum ist es die Grundlage?

Technisches SEO bezeichnet alle technischen Maßnahmen, die die Crawlbarkeit, Indexierbarkeit, Geschwindigkeit und Sicherheit einer Website verbessern. Im Gegensatz zu On-Page SEO (Inhalte) und Off-Page SEO (Links) befasst sich technisches SEO mit der Infrastruktur der Website.

Die drei Säulen guten technischen SEO

Crawlbarkeit: Google kann alle relevanten Seiten finden und besuchen.

Indexierbarkeit: Google kann die Seiten korrekt verarbeiten und in den Index aufnehmen.

Nutzererfahrung: Die Seiten laden schnell und sind auf allen Geräten nutzbar.

Warum technisches SEO oft vernachlässigt wird

Technisches SEO ist weniger sichtbar als Content-Marketing oder Backlinks. Die Auswirkungen guter technischer Grundlagen manifestieren sich oft unsichtbar im Hintergrund – die Abwesenheit technischer Probleme ist schwerer zu messen als deren Lösung.

Dennoch: Technische Fehler können dramatische Auswirkungen haben. Eine falsch gesetzte robots.txt kann dazu führen, dass Google die gesamte Website nicht mehr crawlt. Ein fehlender Canonical Tag kann Duplicate Content schwächen.

---

2. Crawling: Wie Google Ihre Website entdeckt

Was ist ein Web-Crawler?

Googlebot ist Googles Web-Crawler. Er besucht Websites, liest deren Inhalte und folgt Links zu weiteren Seiten. Dieser Prozess läuft kontinuierlich und wird durch ein Crawl-Budget reguliert.

Crawl-Budget

Das Crawl-Budget beschreibt, wie viele Seiten Google in einem bestimmten Zeitraum auf Ihrer Website crawlt. Für kleine Websites mit unter 1.000 Seiten ist das Crawl-Budget meist kein kritisches Thema – Google crawlt alle relevanten Seiten problemlos.

Für große E-Commerce-Websites mit Millionen von Seiten kann das Crawl-Budget entscheidend sein: Wenn Google sein Budget für unwichtige Seiten (z.B. Filterkombinationen, leere Suchergebnisseiten) aufbraucht, werden wichtige Produktseiten seltener gecrawlt.

robots.txt: Crawling steuern

Die robots.txt-Datei liegt im Root-Verzeichnis einer Website (domain.de/robots.txt) und gibt Crawlern Anweisungen:

User-agent: *
Disallow: /admin/
Disallow: /warenkorb/
Disallow: /intern/
Allow: /

Sitemap: https://domain.de/sitemap.xml

Wichtig: robots.txt disallowed Crawling, verhindert aber nicht die Indexierung. Eine Seite kann indexiert sein, auch wenn sie für Crawler gesperrt ist (wenn externe Links auf sie verweisen). Für vollständige Deindexierung brauchen Sie einen Noindex-Meta-Tag.

Kritischer Fehler vermeiden: Disallow: / sperrt alle Crawler vom gesamten Website-Crawling. Dieser Fehler passiert häufig auf Staging-Systemen – und manchmal landen solche Sperren versehentlich auf Produktionswebsites.

XML-Sitemap

Eine XML-Sitemap ist eine strukturierte Liste aller URLs, die Google indexieren soll. Sie beschleunigt die Entdeckung neuer Seiten, besonders bei großen oder schlecht verlinkten Websites.

Best Practices:

• Sitemap nur mit URLs befüllen, die auch indexiert werden sollen (kein Noindex-URLs)
• Sitemap über Google Search Console einreichen
• Sitemap in robots.txt referenzieren
• Bei großen Websites: Sitemap-Index mit mehreren Einzel-Sitemaps (max. 50.000 URLs pro Sitemap)
• Lastmod-Datum aktuell halten (zeigt Google, wann Seiten zuletzt aktualisiert wurden)

Crawl-Fehler analysieren

In der Google Search Console unter „Indexierung“ sehen Sie:

• Seiten, die gecrawlt, aber nicht indexiert wurden (mit Grund)
• 404-Fehler
• Server-Fehler (5xx)
• Weiterleitung-Probleme

Regelmäßige Checks der Search Console Crawl-Reports gehören zum Standard-Repertoire des technischen SEO.

---

3. Indexierung: Was tatsächlich in den Index kommt

Meta Robots Tag

Der Meta-Robots-Tag im einer Seite steuert, ob Google die Seite indexieren und verlinkte Seiten verfolgen darf:

<meta name="robots" content="index, follow">   <!-- Standard -->
<meta name="robots" content="noindex, follow">  <!-- Nicht indexieren, Links folgen -->
<meta name="robots" content="noindex, nofollow"> <!-- Nicht indexieren, Links nicht folgen -->

Wann Noindex verwenden:

• Danke-Seiten nach Formulareinsendung
• Login-Seiten und Mitgliederbereiche
• Filterseiten ohne Mehrwert (z.B. /produkte/?farbe=blau&groesse=M)
• Seiten in Entwicklung oder mit dünnem Content
• Pagination-Seiten (in manchen Fällen)

Google Search Console: Indexierungsstatus prüfen

Im URL-Inspektionstool der Google Search Console können Sie jede URL direkt prüfen:

• Ist die Seite indexiert?
• Wann wurde sie zuletzt gecrawlt?
• Gibt es Canonical-Konflikte?
• Welche Version hat Google gerendert (Rendering-Screenshot)?

Workflow: Wenn eine wichtige Seite nicht im Index erscheint, ist das URL-Inspektionstool die erste Anlaufstelle.

Canonical Tags: Die kanonische URL definieren

Der Canonical Tag (rel="canonical") teilt Google mit, welche URL die bevorzugte, kanonische Version einer Seite ist, wenn dieselbe Seite unter mehreren URLs erreichbar ist.

<link rel="canonical" href="https://www.domain.de/technisches-seo/">

Häufige Canonical-Fehler:

• Self-referencing Canonical fehlt (Seite hat kein Canonical auf sich selbst)
• Canonical zeigt auf eine Seite, die selbst einen Canonical auf eine dritte Seite hat (Canonical-Ketten)
• Canonical auf noindex-Seite
• Canonical-Widerspruch: robots.txt blockiert die Seite, aber Canonical verweist auf sie

---

4. Seitenarchitektur und interne Verlinkung

Warum Architektur für SEO zählt

Die Informationsarchitektur einer Website beeinflusst, wie Autorität durch interne Links verteilt wird und wie gut Google die Website versteht. Eine flache Architektur (wenige Klicks von der Homepage zu jeder Seite) ist besser als eine tiefe.

Klicktiefe-Empfehlung:

• Homepage: 0 Klicks
• Hauptkategorien: 1 Klick
• Unterkategorien / Blogkategorien: 2 Klicks
• Produkt- oder Artikelseiten: 3 Klicks (max.)

Seiten, die mehr als 4–5 Klicks von der Homepage entfernt sind, werden von Google oft weniger priorisiert.

Breadcrumbs

Breadcrumbs (Brotkrumenpfade) sind Navigations-Elemente, die den Standort einer Seite in der Website-Hierarchie zeigen:

Startseite > Blog > Technisches SEO > Core Web Vitals

Breadcrumbs unterstützen:

• Die interne Verlinkungsstruktur
• Die Nutzernavigation
• Google’s Verständnis der Seiten-Hierarchie (mit BreadcrumbList Schema)
• SERP-Darstellung (Google zeigt oft den Breadcrumb-Pfad statt der vollen URL)

Log File Analyse

Fortgeschrittenes technisches SEO: Analyse der Server-Logs zeigt, welche Seiten Googlebot tatsächlich besucht hat, wie oft und wann. Das gibt präzisere Insights als die Search Console allein.

Tools: Screaming Frog Log File Analyser, OnCrawl, Botify.

---

5. HTTPS und Sicherheit

HTTPS als Ranking-Signal

Google bestätigte 2014 HTTPS als Ranking-Signal. Heute haben praktisch alle seriösen Websites HTTPS – es ist keine Differenzierung mehr, sondern Grundvoraussetzung. Websites ohne HTTPS werden von modernen Browsern als „nicht sicher“ markiert und verlieren Nutzervertrauen.

SSL-Zertifikat richtig einrichten

• HTTPS erzwingen: Alle HTTP-Anfragen müssen per 301 auf HTTPS weitergeleitet werden
• Mixed Content vermeiden: Wenn eine HTTPS-Seite Ressourcen (Bilder, Skripte, CSS) per HTTP lädt, warnt der Browser
• HSTS aktivieren: HTTP Strict Transport Security weist Browser an, immer HTTPS zu verwenden

Sicherheits-Header

Neben HTTPS gibt es weitere sicherheitsrelevante HTTP-Header, die Google bei der Bewertung der Seitenqualität berücksichtigt:

• Content Security Policy (CSP): Schützt vor Cross-Site-Scripting
• X-Frame-Options: Verhindert Clickjacking
• X-Content-Type-Options: Verhindert MIME-Type-Sniffing
• Referrer-Policy: Kontrolliert, welche Referrer-Informationen weitergegeben werden

---

6. Structured Data und Schema Markup

Structured Data ist maschinenlesbare Auszeichnung, die Suchmaschinen hilft, den Kontext von Webseiten-Inhalten zu verstehen. Sie ermöglicht Rich Results (erweiterte Suchergebnis-Darstellungen).

JSON-LD: Das bevorzugte Format

Google empfiehlt JSON-LD (JavaScript Object Notation for Linked Data) als Format für Structured Data. Es wird als Script-Tag in den HTML-Head oder Body eingebettet:

{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "Technisches SEO & Core Web Vitals 2026",
  "author": {
    "@type": "Person",
    "name": "Harald Mader"
  },
  "publisher": {
    "@type": "Organization",
    "name": "F&W Perfect Image GmbH",
    "logo": {
      "@type": "ImageObject",
      "url": "https://fw-perfectimage.de/logo.png"
    }
  },
  "datePublished": "2026-06-01",
  "dateModified": "2026-06-29"
}

Wichtige Schema-Typen und ihre Rich Results

Schema-Typ	Rich Result	Geeignet für
FAQPage	Akkordeon-Fragen im SERP	Seiten mit FAQ-Abschnitt
HowTo	Schrittweise Anleitung im SERP	Anleitungsartikel
Product	Preis, Bewertung, Verfügbarkeit	E-Commerce
Recipe	Kochzeit, Bewertung, Foto	Rezeptseiten
LocalBusiness	Öffnungszeiten, Adresse, Tel.	Lokale Unternehmen
Review/Rating	Sterne-Bewertungen	Produkt-/Dienstleistungsreviews
BreadcrumbList	Breadcrumb-Pfad im SERP	Alle strukturierten Websites
VideoObject	Video-Thumbnails im SERP	Video-Content
Event	Datum, Ort, Tickets	Veranstaltungen

Rich Results testen

Nach der Implementierung: Testen Sie mit dem Google Rich Results Test (search.google.com/test/rich-results). Das Tool zeigt, ob die Structured Data korrekt erkannt wird und welche Rich Results möglich sind.

---

7. Core Web Vitals: LCP, INP, CLS

Core Web Vitals (CWV) sind drei nutzerzentrierte Performance-Metriken, die Google seit Mai 2021 als offiziellen Ranking-Faktor im Page Experience Update wertet.

Wo CWV-Daten zu finden sind

Google Search Console: „Nutzererfahrung“ → „Core Web Vitals“ – zeigt Status nach URL-Gruppe (Gut, Verbesserungsbedarf, Schlecht)

PageSpeed Insights: Analysiert einzelne URLs mit Labor- und Felddaten (echte Nutzerdaten aus dem Chrome User Experience Report)

Lighthouse in Chrome DevTools: Lokale Labordaten (kein echtes Nutzerverhalten, aber gut für Entwicklungstests)

CrUX (Chrome User Experience Report): Öffentliche Nutzerdaten auf BigQuery, gut für tiefe Analysen

Feld- vs. Labordaten

Felddaten (Field Data / Real User Monitoring): Gemessen von echten Nutzern im Chrome-Browser über den Chrome User Experience Report. Diese Daten sind ausschlaggebend für Google’s Ranking-Bewertung.

Labordaten (Lab Data / Synthetic Monitoring): Simuliert in kontrollierten Bedingungen (Lighthouse, PageSpeed Insights). Nützlich für Entwicklung und Debugging, aber nicht direkt für Rankings.

---

8. Largest Contentful Paint (LCP) optimieren

Was LCP misst

LCP misst, wann das größte sichtbare Inhaltselement (Bild, Überschrift, Textblock) im Viewport geladen und dargestellt wird. Es repräsentiert die wahrgenommene Ladezeit aus Nutzersicht.

Schwellenwerte:

• Gut: ≤ 2,5 Sekunden
• Verbesserungsbedarf: 2,5–4 Sekunden
• Schlecht: > 4 Sekunden

Häufige LCP-Ursachen

Langsame Server-Response (TTFB): Wenn der Server lange braucht, um das erste Byte zu senden, startet alles andere spät. Lösung: CDN einsetzen, Server-Hardware/Plan verbessern, Server-Side Caching aktivieren.

Render-Blocking Ressourcen: CSS und JavaScript, die im geladen werden, blockieren das Rendering. Lösung: Kritisches CSS inline einbetten, unkritisches CSS asyncron laden, JavaScript defer oder async verwenden.

Unoptimierte Bilder: Das LCP-Element ist häufig ein Hero-Bild oder Header-Bild. Lösung: WebP-Format, passende Größe (nicht 4000px-Bild für 800px-Slot), Preload für LCP-Bild.

Fehlender Preload: Wenn das LCP-Element spät entdeckt wird (z.B. in CSS definiert), wird es spät geladen. Lösung:

<link rel="preload" as="image" href="/hero-image.webp">

LCP Optimierungs-Checkliste

• TTFB unter 200ms (CDN nutzen, Server-Caching)
• LCP-Element identifiziert (PageSpeed Insights zeigt welches Element)
• LCP-Bild im WebP-Format und korrekt skaliert
• Preload für LCP-Bild gesetzt
• Render-Blocking CSS und JavaScript entfernt
• Kritisches CSS inline gesetzt
• JavaScript defer/async gesetzt

---

9. Interaction to Next Paint (INP) optimieren

Was INP misst

INP (Interaction to Next Paint) wurde im März 2024 als Core Web Vital eingeführt und ersetzt First Input Delay (FID). INP misst die gesamte Interaktivität einer Seite – nicht nur den ersten Klick, sondern alle Interaktionen während des Besuchs.

Schwellenwerte:

• Gut: ≤ 200 Millisekunden
• Verbesserungsbedarf: 200–500 ms
• Schlecht: > 500 ms

Ursachen für schlechtes INP

Langer JavaScript Main Thread: Wenn JavaScript-Code den Browser-Hauptthread blockiert, können Nutzerinteraktionen nicht sofort verarbeitet werden.

Zu viele JavaScript-Pakete: Große JavaScript-Bundles, die beim Laden komplett geparst werden, blockieren die Interaktivität.

Third-Party-Skripte: Chat-Widgets, Cookie-Banner, Analyse-Tools, Social-Media-Embeds – jedes dieser Skripte belastet den Main Thread.

INP verbessern

Lange Tasks aufteilen: JavaScript-Tasks über 50ms gelten als „lange Tasks“. Teilen Sie große Funktionen in kleinere Stücke auf, die zwischen anderen Tasks ausgeführt werden.

Code Splitting: Laden Sie JavaScript erst, wenn es gebraucht wird (Dynamic Imports), nicht alles auf einmal beim Seitenaufruf.

Third-Party-Skripte minimieren: Prüfen Sie jedes externe Skript auf echten Nutzen. Cookie-Consent-Tools, Live-Chat-Widgets und Tag Manager laden häufig Dutzende weitere Skripte.

Web Worker nutzen: Verlegen Sie intensive Berechnungen in Web Worker, die auf separaten Threads laufen.

---

10. Cumulative Layout Shift (CLS) optimieren

Was CLS misst

CLS (Cumulative Layout Shift) misst visuelle Instabilität – wie stark sich Seitenelemente während des Ladens unerwartet verschieben. Ein hoher CLS-Wert bedeutet, dass Nutzer auf Elemente klicken, die sich plötzlich verschieben (frustrierend und fehlerträchtig).

Schwellenwerte:

• Gut: ≤ 0,1
• Verbesserungsbedarf: 0,1–0,25
• Schlecht: > 0,25

Häufige CLS-Ursachen

Bilder ohne definierte Abmessungen: Wenn width und height fehlen, reserviert der Browser keinen Platz, bis das Bild geladen ist – dann verschiebt sich der umliegende Content.

<!-- Schlecht: -->
<img src="hero.webp" alt="Hero">

<!-- Gut: -->
<img src="hero.webp" alt="Hero" width="800" height="450">

Web Fonts mit FOUT (Flash of Unstyled Text): Wenn Web Fonts nachladen, wechselt die Schrift plötzlich, was Layout-Verschiebungen verursacht.

Dynamisch eingefügte Inhalte: Anzeigen, Cookie-Banner, Newsletter-Popups, die nach dem Laden eingefügt werden und anderen Content verschieben.

CLS verbessern

• Alle Bilder mit width und height Attributen versehen
• aspect-ratio in CSS nutzen für responsives Layout ohne CLS
• Web Fonts mit font-display: swap und Fallback-Schriften einbinden
• font-display: optional erwägen (lädt Font nur wenn verfügbar, kein Shift)
• Werbe-Slots und Cookie-Banner-Bereiche vorab im Layout reservieren
• transform statt top/left für Animationen nutzen (kein Layout-Neuberechnung)

---

11. Mobile-First Indexierung

Seit 2019 crawlt und indexiert Google alle neuen Websites mit dem Mobile-First-Index. Das bedeutet: Die mobile Version Ihrer Website bestimmt, wie Google Ihre Seiten bewertet – egal ob der Nutzer die Seite mobil oder am Desktop aufruft.

Was Mobile-First konkret bedeutet

Content-Parität: Jeder Inhalt, der für SEO relevant ist (Text, Bilder, Structured Data), muss auch auf der mobilen Version vorhanden sein. Wenn die Desktop-Version mehr Content hat als die Mobile-Version, ignoriert Google diesen „Desktop-only“-Content.

Geschwindigkeits-Anforderungen: Mobile Verbindungen sind oft langsamer als Desktop. Die Core Web Vitals werden auf Basis mobiler Felddaten bewertet – Mobile Performance ist kritischer.

Responsive Design bevorzugt: Google empfiehlt Responsive Design (eine URL, eine HTML-Datei, CSS passt Layout an Bildschirmgröße an) statt separater Mobile-Subdomains (m.domain.de).

Mobile Optimierung prüfen

Google Mobile-Friendly Test: Einzelne URL testen auf mobile Darstellung und Fehler.

Search Console Bericht: „Nutzererfahrung“ → „Mobile Usability“ zeigt Fehler wie zu kleiner Text, zu nah beieinander liegende Touch-Targets, horizontales Scrollen.

Eigener Test: Testen Sie Ihre Website auf verschiedenen echten Geräten und Browsern (iOS Safari, Android Chrome, Firefox Mobile).

---

12. Internationale SEO und Hreflang

Für Websites, die mehrere Sprachen oder Länder bedienen, ist Hreflang das wichtigste technische SEO-Element.

Was Hreflang macht

Hreflang teilt Google mit, welche Seitenversionen für welche Sprach-/Länderkombinationen gedacht sind, und verhindert, dass verschiedene Sprachversionen als Duplicate Content gewertet werden.

<link rel="alternate" hreflang="de" href="https://domain.de/technisches-seo/">
<link rel="alternate" hreflang="de-AT" href="https://domain.at/technisches-seo/">
<link rel="alternate" hreflang="en" href="https://domain.com/technical-seo/">
<link rel="alternate" hreflang="x-default" href="https://domain.com/technical-seo/">

Hreflang-Fehler

Fehlendes x-default: x-default zeigt die Standardseite für Nutzer, die nicht auf eine der deklarierten Sprachen passen.

Nicht-reziproke Hreflang-Tags: Wenn Seite A auf Seite B verweist, muss Seite B auch auf Seite A zurückverweisen. Fehler in diesem Muster verhindern korrekte Verarbeitung.

Hreflang auf Noindex-Seiten: Sinnlos und kann zu Problemen führen.

---

13. Duplicate Content technisch lösen

Duplicate Content entsteht, wenn dieselben oder sehr ähnliche Inhalte unter verschiedenen URLs erreichbar sind. Das verwirrt Google bei der Wahl der kanonischen URL.

Häufige Duplicate-Content-Quellen

Problem	Ursache	Lösung
www/nicht-www	Beide Version zugänglich	301-Redirect auf bevorzugte Version
HTTP/HTTPS	Beide Versionen zugänglich	301-Redirect auf HTTPS
Trailing Slash	/seite/ und /seite gleichzeitig	301-Redirect auf eine Version
URL-Parameter	/produkte/?sort=preis dupliziert /produkte/	Canonical Tag oder Noindex
Pagination	/blog/page/2/ mit ähnlichem Content	Canonical zur ersten Seite oder Noindex
Printer-Friendly-Versionen	/seite/?print=1	Noindex
Session-IDs in URLs	/seite?sessionid=abc123	URL-Parameter in Search Console konfigurieren

Canonical Tag vs. 301-Redirect

301-Redirect: Leitet den Nutzer und den Crawler dauerhaft auf die neue URL weiter. Überträgt ~99 % der Linkautorität. Ideal, wenn die duplizierte URL nie direkt angesteuert werden soll.

Canonical Tag: Teilt Google die bevorzugte URL mit, ohne den Nutzer weiterzuleiten. Ideal, wenn die URL aus technischen Gründen zugänglich bleiben muss (z.B. URL-Parameter für Funktionalität).

---

14. Technisches SEO Audit: Schritt für Schritt

Ein regelmäßiges technisches SEO Audit identifiziert Probleme, bevor sie Rankings schädigen. Hier ist der strukturierte Prozess:

Phase 1: Crawl-Daten erheben

Tool: Screaming Frog SEO Spider (kostenlose Version bis 500 URLs, danach Lizenz nötig) oder Sitebulb.

Crawlen Sie Ihre gesamte Website und exportieren Sie alle URLs mit deren Status-Codes, Title Tags, Meta-Descriptions, H1s, Canonical Tags und weiteren Meta-Daten.

Phase 2: Kritische Fehler prüfen

Kategorie	Was prüfen	Tool
Crawlbarkeit	robots.txt korrekt?	Search Console, Screaming Frog
Indexierung	Wichtige Seiten indexiert?	URL-Inspektion, Search Console
404-Fehler	Welche URLs liefern 404?	Search Console, Screaming Frog
Weiterleitungen	Redirect-Ketten, -Schleifen	Screaming Frog
Canonical Tags	Korrekt gesetzt, keine Konflikte	Screaming Frog
HTTPS	Mixed Content?	Why No Padlock, Screaming Frog

Phase 3: Performance messen

• PageSpeed Insights für 5–10 wichtige URLs
• Core Web Vitals Bericht in Search Console
• TTFB mit WebPageTest messen

Phase 4: Structured Data prüfen

• Google Rich Results Test für alle Seiten mit Schema Markup
• Such Console → „Rich-Suchergebnisse“ auf Fehler prüfen

Phase 5: Mobile Usability

• Mobile-Friendly Test für wichtige URLs
• Search Console → „Nutzererfahrung“ → „Mobile Usability“

Phase 6: Prioritäten setzen und beheben

Kategorisieren Sie gefundene Probleme nach Auswirkung und Aufwand:

• Kritisch, geringer Aufwand: Sofort beheben (falsche robots.txt, fehlende Canonical Tags)
• Kritisch, hoher Aufwand: Priorisieren und einplanen (Performance-Grundlegendes)
• Moderat, geringer Aufwand: In nächstem Sprint einplanen
• Moderat, hoher Aufwand: Langfristig planen

---

15. Checkliste und FAQ

Technisches SEO Checkliste

Crawling & Indexierung

• robots.txt korrekt konfiguriert, keine wichtigen Bereiche versehentlich gesperrt
• XML-Sitemap vorhanden und in Search Console eingereicht
• Alle wichtigen Seiten sind indexiert (Search Console prüfen)
• Canonical Tags auf allen Seiten korrekt gesetzt
• Duplicate Content durch 301-Redirects oder Canonicals gelöst
• www/nicht-www konsolidiert und weitergeleitet
• HTTPS aktiv, HTTP leitet auf HTTPS weiter
• Keine Mixed Content Warnungen

Core Web Vitals

• LCP unter 2,5 Sekunden (PageSpeed Insights)
• INP unter 200 Millisekunden
• CLS unter 0,1
• Alle Bilder mit width/height Attributen
• LCP-Element mit Preload optimiert
• Render-Blocking Ressourcen minimiert

Mobile

• Responsives Design aktiv
• Mobile-Friendly Test bestanden
• Kein Content, der nur auf Desktop sichtbar ist
• Touch-Targets groß genug (≥ 44×44px)

Structured Data

• Schema Markup für relevante Inhaltstypen implementiert
• Rich Results Test ohne Fehler
• BreadcrumbList für Website-Hierarchie

Performance

• Bilder im WebP-Format
• Lazy Loading für Bilder
• Browser-Caching aktiviert
• CDN eingesetzt

---

FAQ

Wann sollte ich ein technisches SEO Audit durchführen?

Mindestens einmal jährlich für eine vollständige Prüfung. Außerdem nach größeren Website-Änderungen (Relaunch, Plattformwechsel, neue URL-Strukturen). Bei anhaltenden Traffic-Rückgängen sofort.

Wie finde ich heraus, ob Googlebot meine Seite korrekt rendert?

Nutzen Sie das URL-Inspektionstool in der Google Search Console. Dort sehen Sie einen Screenshot, wie Google Ihre Seite gerendert hat, und können prüfen, ob JavaScript-abhängiger Content sichtbar ist.

Was ist der Unterschied zwischen Core Web Vitals und PageSpeed?

PageSpeed ist ein allgemeiner Begriff für die Ladegeschwindigkeit. Core Web Vitals sind drei spezifische, nutzerzentrierte Metriken (LCP, INP, CLS), die Google als offizielle Ranking-Signale nutzt.

Sind Core Web Vitals wirklich ein entscheidender Ranking-Faktor?

CWV sind einer von vielen Faktoren. Google hat kommuniziert, dass bei ansonsten gleichem Content der bessere CWV-Wert gewinnt. In der Praxis sind Content und Backlinks meist dominanter – aber CWV-Probleme können Rankings begrenzen und schlechte Nutzererfahrung direkt zu höheren Absprungraten führen.

Muss ich eine XML-Sitemap haben?

Für kleine Websites (unter 100 Seiten) mit guter interner Verlinkung ist eine Sitemap keine zwingende Voraussetzung. Für größere Websites, Websites mit Orphan Pages oder nach einem Relaunch ist die Sitemap sehr hilfreich und beschleunigt die Indexierung neuer Inhalte.

Was passiert, wenn ich robots.txt falsch konfiguriere?

Im schlimmsten Fall sperren Sie Google vom Crawling Ihrer Website – Seiten werden nicht mehr aktualisiert, neue Seiten werden nicht indexiert, und Rankings sinken. Testen Sie robots.txt-Änderungen immer mit dem robots.txt-Tester in der Search Console, bevor Sie live gehen.