Technische Suchgrundlage
Technisches SEO verbindet Ursache und Umsetzung
Ein technischer Befund ist erst hilfreich, wenn klar ist, welche URL-Muster betroffen sind, warum das Problem entsteht und wie eine Änderung ohne neue Schäden ausgerollt wird.
Problemrahmen
Technische Symptome brauchen eine Systemdiagnose
«Nicht indexiert», ein schlechter Core Web Vital oder ein Validierungsfehler benennt einen Zustand. Die Ursache kann in Templates, internen Links, Deployment, Datenmodellen, JavaScript oder redaktionellen Regeln liegen. Ohne diesen Zusammenhang führt die Korrektur oft nur zu einer neuen Variante desselben Problems.
Ist die Ursache noch unklar oder betrifft die Frage mehrere SEO-Bereiche, kann ein SEO-Audit zuerst den Umfang und die Priorität bestimmen. Bei einer bereits geplanten Migration sollte die Arbeit direkt als SEO-Relaunch organisiert werden, weil URLs, Templates und Messung gleichzeitig wechseln können.
Fehlerklassen
Die Ebene bestimmt die richtige Prüfung
| Bereich | Typisches Symptom | Prüffläche |
|---|---|---|
| Crawling | Bots erreichen wichtige URLs nicht oder verlieren Ressourcen in Filtern und Duplikaten | Crawl-Pfade, interne Links, Robots-Regeln und URL-Räume |
| Indexierung | Wichtige Seiten fehlen oder ungeeignete Seiten erscheinen im Index | Canonicals, Statuscodes, Sitemaps, Noindex und Inhaltsüberschneidung |
| Rendering | Inhalte oder Links entstehen zu spät, uneinheitlich oder nur im Browser | Server-Ausgabe, JavaScript-Abhängigkeiten und gerenderter DOM |
| Performance | Langsame oder instabile Seiten beeinträchtigen Nutzung und Verarbeitung | Templates, Ressourcen, Bilder, Skripte und Core Web Vitals |
| Strukturierte Daten | Auszeichnung widerspricht dem sichtbaren Inhalt oder ist technisch ungültig | Schema-Typ, Pflichtfelder, Wahrheit der Entität und Rendering |
Arbeitsweise
Von der Beobachtung zur kontrollierten Änderung
1. Muster statt Einzelfall bestimmen
Eine Beispiel-URL macht das Problem sichtbar. Für die Lösung muss bekannt sein, welche Templates, Parameter, Sprachversionen oder Seitentypen dasselbe Verhalten teilen.
2. Ursache reproduzieren
Crawls, Logdaten, Search Console, gerenderte Seiten und Quellcode beantworten unterschiedliche Fragen. Die benötigten Daten richten sich nach der Hypothese, nicht nach einem festen Werkzeugkasten.
3. Änderung spezifizieren
Eine technische Anforderung sollte Sollverhalten, betroffene Muster, Ausnahmen und Abnahmekriterien enthalten. Damit kann ein Entwicklungsteam die Änderung einschätzen, ohne die SEO-Absicht erraten zu müssen.
4. Vor und nach dem Rollout prüfen
Tests in einer Vorschau reduzieren Risiken, ersetzen aber die Kontrolle der veröffentlichten Website nicht. Nach dem Rollout müssen Ausgabe, interne Links, Statuscodes und die Verarbeitung durch Suchmaschinen beobachtet werden.
Auftrag
Fragen, die den Umsetzungsumfang sichtbar machen
- Welche Systeme, Domains, Länder- und Sprachversionen gehören dazu?
- Wer betreibt Plattform, Hosting, CDN und Deployment?
- Stehen Vorschauumgebung, Logs und notwendige Analysezugänge zur Verfügung?
- Wer übersetzt SEO-Anforderungen in Tickets und wer nimmt sie ab?
- Welche Release-Fenster, Abhängigkeiten und Rückfallwege bestehen?
- Wie wird nach Veröffentlichung geprüft, ob die Ursache wirklich behoben ist?