Technical-SEO-Basis nach Modernisierung

Technical SEO entscheidet nach einem Stack-Wechsel, ob Google und generative Engines deine neuen URLs überhaupt finden, zusammenführen und zitieren können. Ohne Canonicals und Redirects zerfällt Link-Equity; ohne Sitemap und interne Links bleiben neue Pfade unsichtbar; ohne Schema und sauberes HTML fehlt die semantische Zuordnung trotz Crawlability. Dieser Leitfaden ist die Unique-Evidence-Schicht für die Technical-SEO-Basis: Checkliste nach Modernisierung, Baseline vs. Modern-Stack-Lieferung und die Census-Gaps zu JSON-LD, Sitemap und robots — gebunden an den Projektablauf und Rankingverlust vermeiden.

Warum Technical SEO Lieferumfang der Modernisierung ist

Antwort zuerst: Nach dem Cutover zählt nicht das neue Design, sondern ob Crawler Kern-URLs mit 200, korrekter Kanonik und konsistentem Schema finden — deshalb ist Technical SEO Teil jeder Modernisierung, nicht optionaler „SEO-Aufschlag“.

Klassische Legacy-Webseiten (Census: 69,4 % Legacy-CMS in der AI-Readiness-Studie) akkumulieren www/Apex-Duplikate, Parameter-URLs, Pagebuilder-Rauschen und Plugin-Schema, das vom sichtbaren Text abweicht. Ein Stack-Wechsel ohne Technical-SEO-Programm überträgt diese Fehler — oder erzeugt neue Soft-404, wenn Pfade umziehen.

Modern Stack liefert deshalb mit WordPress-Migration, Redesign und Content-Cutover dieselbe Basis: Crawlability, Canonicals, Sitemap, robots, Redirects, Schema und CWV. Modernes Technical SEO (Edge, Speculation Rules, AI-Bot-Allowlist) baut darauf auf — ersetzt aber nicht die Grundlagen.

Was der Census zu Technical-SEO-Gaps sagt

Antwort zuerst: Sitemap und robots sind im Feld relativ verbreitet; JSON-LD und echte Maschinenoberflächen fehlen — Crawlability ohne Semantik ist der typische Engpass.

In der AI-Readiness-Studie (6.675 Audits) liegen die Technical-SEO-Benchmarks so:

Lokal spiegeln Bad Schönborn und Bruchsal dasselbe Muster: technische Tür offen, zitierfähige Struktur dünn. Technical SEO allein macht dich nicht „AI-ready“ — ohne diese Basis scheitert GEO aber zuverlässig. Princeton GEO (Aggarwal et al., arXiv:2311.09735) setzt auf Zitate, Stats und Quellen — auf extrahierbarem HTML, nicht auf Plugin-DOM.

Baseline vs. Modern-Stack-Lieferung

Antwort zuerst: Die Baseline ist, was typische Dienstleister-Webseiten im Census haben; die Modern-Stack-Lieferung ist der verbindliche Cutover-Sollzustand — nicht „irgendwann nachziehen“.

Diese Tabelle ist das Unique Evidence Asset dieses Artikels: Baseline messbar am Census, Lieferung messbar am Go-Live — nicht an Marketing-Claims.

Technical-SEO-Checkliste nach der Modernisierung

Antwort zuerst: Nach dem Cutover prüfst du acht Blöcke in fester Reihenfolge — Canonical, Sitemap, robots, Redirects, Schema, CWV, hreflang (falls vorhanden), Crawl — sonst riskierst du Ranking- und Extraktionsverlust in den ersten 48 Stunden.

1. Canonicals und Host-Kanonik

Jede Kern-URL trägt ein self-referencing link rel="canonical" auf die Apex-URL. Kein www/Apex-Mix in Sitemap, OG-Tags und Canonicals. Parameter-URLs und Staging-Hosts zeigen nie auf sich selbst als Kanonik. Vertiefung: Canonical.

2. XML-Sitemap

/sitemap.xml (oder Index) erreichbar, enthält nur kanonische Live-URLs mit Status 200, keine Redirect-Ziele und keine Soft-404. In Search Console eingereicht. Sitemap ohne interne Links bleibt wirkungslos — siehe Sitemap.

3. robots.txt

Datei unter /robots.txt erreichbar, verweist auf die Sitemap, blockiert keine CSS/JS-Ressourcen und keine Kernpfade. AI-Crawler nur bewusst steuern — unreflektiertes Blocken aller GPT-/Perplexity-Bots sabotiert GEO, wenn du Sichtbarkeit in generativen Antworten willst. Siehe robots.txt.

4. Redirects

Jede Zeile der URL-Matrix ist ein 301. Keine Ketten (A→B→C), keine Soft-404 (200 mit „Seite nicht gefunden“). Smoke-Test der Top-Traffic-URLs aus Search Console. Rollback und Risiken: Redirect, Soft-404, Rankingverlust vermeiden.

5. Schema / JSON-LD

Organization/LocalBusiness, Article/FAQ wo sichtbar — Inhalt und Markup deckungsgleich. Kein Yoast-/Plugin-Schema, das Preise oder Adressen erfindet. Census-Gap 41,9 % → Ziel ist saubere Entity, nicht „irgendein JSON-LD“. Vertiefung: Strukturierte Daten für GEO.

Minimaler Organization-Kern (Prinzip — Felder müssen mit Impressum und sichtbarer NAP übereinstimmen):

{
  "@context": "https://schema.org",
  "@type": "Organization",
  "name": "Beispiel GmbH",
  "url": "https://example.de",
  "email": "info@example.de",
  "telephone": "+491234567890",
  "address": {
    "@type": "PostalAddress",
    "streetAddress": "Musterstraße 1",
    "postalCode": "76669",
    "addressLocality": "Bad Schönborn",
    "addressCountry": "DE"
  }
}

Wenn Markup und sichtbarer Text auseinanderlaufen, ist Schema schädlicher als kein Schema: Crawler und generative Engines sehen Widersprüche. Nach Modernisierung gehört Validierung (Rich-Results-Test / Schema-Stichprobe) in dieselbe Abnahme wie Canonicals.

6. Core Web Vitals

LCP/INP/CLS auf denselben Top-Landings wie vor der Migration messen (Field wo möglich, Lab als Frühwarnung). Langsame TTFB, blockierende Third Parties und riesige Hero-Bilder sind Technical-SEO-Probleme, kein separates „Speed-Projekt“. Siehe Core Web Vitals und CWV-Modernisierung.

Pragmatische Stichprobe: Startseite, umsatzstärkste Leistungsseite, Kontakt/Anfrage. Mobile zuerst. Wenn Lab grün und Field rot ist, prüfe Consent-Banner, Chat-Widgets und schwere Analytics — nicht nur Bildkompression.

7. hreflang — nur wenn vorhanden

hreflang setzt du nur bei echten Sprach- oder Länder-Varianten mit wechselseitigen Annotations und korrektem x-default. Einsprachige DE-Sites brauchen kein hreflang-Theater — falsche Annotations erzeugen Duplikat-Chaos. Wenn du später EN-Maschinenfelder (Markdown, Schema) auslieferst, ist das kein Ersatz für HTML-hreflang-Paare; Kanon bleibt de-DE, solange keine parallelen Sprach-URLs existieren.

8. Crawl-Smoke

Automatisierte Stichprobe der Kernliste (Start, Top-Leistungen, Kontakt, Studie/Hubs): HTTP 200, Titel gesetzt, Canonical self-referencing, kein unbeabsichtigter noindex. Zusätzlich: Klickpfad Start → Leistung → Anfrage. Parallel: Soft-404- und Redirect-Fehler in Search Console in den ersten Wochen.

Kurz als Deploy-Gate (Prinzip):

# Kern-URLs: Status, Canonical-Hinweis, Title (vereinfachtes Smoke-Muster)
for path in / /leistungen /kontakt /studie; do
  curl -sI "https://example.de$path" | head -n1
  curl -s "https://example.de$path" \
    | rg -o 'rel="canonical" href="[^"]+"|<title>[^<]+' | head -n5
done
curl -sI "https://example.de/sitemap.xml" | head -n1
curl -sI "https://example.de/robots.txt" | head -n1

Zusätzlich prüfst du nach dem Cutover stichprobenartig, ob externe Backlinks und alte Marketing-URLs in der Redirect-Matrix landen — nicht nur die internen Menüpfade. Eine fehlende Zeile für /wp-content/...-Legacy-Assets ist oft irrelevant; eine fehlende Zeile für die Top-10-GSC-URLs ist ein Ranking-Risiko.

Wie Canonicals und Redirects Rankings schützen

Antwort zuerst: 301-Matrix plus widerspruchsfreie Apex-Kanonik halten Link-Equity und Bookmarks zusammen — Soft-404 und Canonical-Konflikte sind die häufigsten Cutover-Fails.

Beim Domain-Cutover ändern sich Pfade, Trailing Slashes und oft der Host. Ohne Mapping landen externe Links und interne Bookmarks auf 404 oder auf „ähnlichen“ Seiten mit 200 und leerem Inhalt (Soft-404). Gleichzeitig müssen Canonical und Redirect dieselbe Wahrheit erzählen: Redirect-Ziel = kanonische URL, Canonical zeigt auf sich selbst, Sitemap listet nur Kanonik. Google fasst Duplikate über Canonicals zusammen (Consolidate duplicate URLs); widersprüchliche Signale verzögern die Neu-Zuordnung um Wochen.

Praxisregel: Mapping-Matrix vor Rebuild fertigstellen (Alter Pfad → neuer Pfad → 301), auf Staging kettenfrei testen, nach DNS-Cutover 48 Stunden Search Console und Logs beobachten. Details und Pre-Cutover-Tabelle: Rankingverlust vermeiden. Content-Umzug: Content-Migration. Hosting und Origin-Stabilität: Hosting nach Migration.

Häufiger Fehler: Canonical zeigt auf Apex, Redirects landen aber auf www, und die Sitemap listet beide. Dann fragmentierst du Signale bewusst. Ein zweiter Fehler: 302 statt 301 „vorübergehend“ für den Cutover — Suchmaschinen behandeln das als unsicher und übertragen Equity zögerlich. Dritter Fehler: Catch-all auf die Startseite — das erzeugt Soft-404-Muster und verwässert Relevanz der Homepage.

Warum Hub-Verlinkung wichtiger ist als Sitemap allein

Antwort zuerst: Eine Sitemap ist eine Adressliste; Crawler und Nutzer finden Tiefe über interne Links — Footer, Breadcrumbs und Themen-Hubs.

Google beschreibt Sitemaps als Unterstützung, nicht als Ersatz für Crawl-Pfade (Sitemaps Overview). Nach der Modernisierung verknüpft Modern Stack Leistungen, Regionen, Glossar und Studien bidirektional, damit wichtige URLs nicht verwaist sind. Stichprobe: Startseite → Leistung → Anfrage — alle 200, canonical self-referencing, keine Parameter-URLs als Kanonik.

Ohne Hubs bleibt selbst eine perfekte Sitemap wirkungslos: der Crawler sieht URLs, aber der Graph der Seite signalisiert keine Priorität. Das ist der Unterschied zwischen „indexierbar“ und „auffindbar“. Für GEO gilt dasselbe: generative Engines bevorzugen Passagen, die in einem klaren Themenkontext stehen — isolierte Landingpages ohne Entity-Nachbarn wirken dünner, auch wenn die Sitemap sie enthält.

Praktisch: Breadcrumbs spiegeln die Informationsarchitektur, Footer trägt Evergreen-Hubs, Fließtext verlinkt Glossar- und Regions-Entities. Nach jedem größeren Content-Deploy prüfst du nicht nur „steht die URL in der Sitemap?“, sondern „erreiche ich sie in drei Klicks von der Startseite?“.

robots.txt, AI-Bots und IndexNow

Antwort zuerst: robots steuert den Zugang; IndexNow beschleunigt die Benachrichtigung — keines von beiden ersetzt Substanz oder Crawlability.

robots.txt dokumentiert Allow/Disallow und den Sitemap-Hinweis (Google robots intro). Unnötige Blocks auf AI-User-Agents sind ein verbreiteter GEO-Fehler, wenn du gleichzeitig in ChatGPT & Co. genannt werden willst. Edge-/CDN-WAF-Regeln können dasselbe bewirken wie eine Disallow-Zeile — prüfe Allowlists nach Deploy. Staging-Umgebungen gehören hinter Auth oder noindex, nicht hinter eine robots-Datei, die versehentlich auf Production kopiert wird.

IndexNow meldet unterstützten Suchmaschinen URL-Änderungen schneller — sinnvoll nach Content-Updates oder neuen Regionsseiten. Es ersetzt keine Qualität: ohne crawlbares HTML und ohne Antwortsubstanz indexiert niemand dauerhaft. Monitoring in den ersten Wochen: Soft-404, Redirect-Fehler, CWV-Regression. IndexNow ist ein Signal „URL geändert“ — keine Garantie für Indexierung oder Ranking.

Performance als Technical-SEO-Signal

Antwort zuerst: Core Web Vitals sind Teil der Technical-SEO-Basis — langsame Origins kosten Crawl-Budget, Nutzer und Extraktion.

LCP, INP und CLS (web.dev/vitals) beeinflussen Ranking und Conversion. KI-Crawler mit Timeout priorisieren langsame Origins herunter. Nach Migration vergleichst du dieselben URLs vorher/nachher; wenn nur Lab grün ist, liegt das Problem oft an Netz, Gerät oder Third Parties — dann nachjustieren statt nur Lighthouse zu „gewinnen“. Edge-Auslieferung und Caching vertieft Edge Rendering und Hosting nach Migration.

Technical SEO und Performance teilen dieselben Hebel: weniger Render-Blocking, deterministisches HTML aus SSR/SSG, Bilder mit Größenattributen, Fonts ohne Layout-Shift. Ein Stack-Wechsel ohne CWV-Stichprobe ist unvollständig — genauso wie eine Sitemap ohne Redirect-Matrix.

Barrierefreiheit und technische Qualität überlappen

Antwort zuerst: Semantisches HTML, klare Überschriften und Alt-Texte helfen Menschen und Maschinen — Technical SEO und Barrierefreiheit teilen dieselbe Extraktionsbasis.

Layout-Tabellen, leere Buttons und fehlende Focus-States sind nicht nur Accessibility-Fails; sie erschweren Strukturverständnis für Crawler und Assistive Tech. Eine saubere H1–H3-Hierarchie macht Abschnitte zitierfähig — genau das, was Atomic-Answer-Seiten für SEO und GEO brauchen. Barrierefreiheit in der Modernisierung gehört deshalb in dieselbe Abnahme wie Canonicals und Schema — nicht in ein separates „späteres Projekt“.

Typische Schwachstellen vor der Modernisierung

Antwort zuerst: Fehlende Canonicals, www/Apex-Duplikate, blockierte Ressourcen, Schema ohne Content und Pagebuilder-Rauschen sind Standardbefunde — genau das schließt die Liefer-Tabelle.

Weitere Klassiker: Sitemap mit 404-URLs, robots die CSS/JS blockieren, Redirect-Ketten aus Jahren Plugin-SEO, noindex auf Staging das versehentlich live geht, und Host-Mix in OG/SITE_URL. Technical SEO bleibt die Basis; GEO braucht darüber hinaus llms.txt, Markdown-Negotiation und answer-first Inhalte — in dieser Reihenfolge: Stack und Crawl zuerst, Content-Taktiken danach.

Wenn du nur eins priorisieren kannst nach dem Cutover: Redirects + Canonicals + Crawl-Smoke der Top-URLs. Sitemap und robots folgen sofort; Schema und CWV in derselben Woche; hreflang nur bei Bedarf. llms.txt und Knowledge-Graph-Module sind die nächste Schicht — nicht der Ersatz für kaputte 301er.

Wie Technical SEO und GEO zusammenhängen — und wo nicht

Antwort zuerst: Technical SEO öffnet die Tür; GEO füllt sie mit zitierfähigen Antworten — vermische weder die Metriken noch die Reihenfolge.

AI-Readiness (technische Audit-Scores: Crawl, Schema, llms, Markdown) ist nicht dasselbe wie AI-Visibility (tatsächliche Nennungen in ChatGPT & Co.). Der Census zeigt genau diese Trennung: Sitemap 73,5 % und robots 72,5 % sind relativ häufig, Agent-Ready liegt trotzdem bei Ø 25/100, weil Extraktion und Antwortsubstanz fehlen. Wer nach der Modernisierung nur „Sitemap eingereicht“ abhakt, hat Technical SEO halb gemacht und GEO noch nicht begonnen.

Reihenfolge bei Modern Stack: Modernisierung inkl. Technical-SEO-Basis → optional Redesign/Conversion → Knowledge Graph / llms.txt / answer-first Inhalte. Princeton-Taktiken (Zitate, Stats, Quellen) wirken auf sauberem HTML; auf Pagebuilder-Rauschen optimierst du Rauschen. Siehe auch GEO-Empirie 2026/2027 und die Nischenstudien unter Dienstleistung.

Was du vor Kick-off und nach Go-Live brauchst

Antwort zuerst: Vor dem Projekt brauchst du Zugang und Baseline; nach dem Cutover brauchst du die Acht-Punkte-Checkliste und ein Monitoring-Fenster — nicht „DNS umstellen und hoffen“.

Vor Kick-off: Domain-/Hosting-Zugang, Search-Console-Top-URLs der letzten 12 Monate, bekannte Alt-URLs und Marketing-Kampagnen-Links, Klarheit Apex vs. www, Liste kritischer Formulare und Tracking-Events, vorhandene hreflang-Varianten ja/nein, Screenshot oder Export der aktuellen robots/Sitemap/Canonicals als Baseline.

Nach Go-Live (48 h–2 Wochen): Checkliste oben abarbeiten und dokumentieren, Search Console Coverage/Redirects/Soft-404, CWV Field auf Top-Landings, IndexNow bei größeren Content-Batches, Stichprobe externer Backlink-Ziele, Wartung für laufende Deploys damit Canonical/SITE_URL nicht wieder driftet.

Referenz mit sauberem Cutover: Mallorca Expats. Kurz: Technical-SEO-Basis ist Infrastrukturentscheidung nach der Modernisierung — Crawl, Kanonik, Redirects, Schema und CWV zuerst, dann GEO. Anfrage stellen · info@modern-stack.de