Technisches SEO beginnt beim betroffenen URL-Muster

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.

«Nicht indexiert» ist ein Zustand mit mehreren möglichen Ursachen

Beginnen Sie mit der vorgesehenen Seite, nicht mit dem Fehlertext. Soll die URL eine eigenständige Suchaufgabe besitzen? Ist sie über normale interne Links erreichbar? Liefert sie einen erfolgreichen Statuscode, eine indexierbare Robots-Anweisung und einen Canonical auf sich selbst oder auf den tatsächlich gewünschten Besitzer? Zeigt das gerenderte Dokument die entscheidenden Inhalte und Links?

Erst danach hilft der konkrete Search-Console-Status bei der Eingrenzung. Eine gecrawlte, aber nicht indexierte URL verlangt eine andere Untersuchung als eine URL, die Google nur aus einer Sitemap kennt. Wählt Google einen anderen Canonical, muss geprüft werden, ob Inhalt und interne Signale die behauptete Eigenständigkeit stützen. Eine erneute Indexierungsanfrage löst keinen dieser Widersprüche.

Die drei häufigsten falschen Abkürzungen

• Mehr Text: Länge hilft nicht, wenn mehrere Seiten dieselbe Aufgabe beanspruchen oder der zusätzliche Text nichts erklärt.
• Mehr Sitemap-Einträge: Eine Sitemap meldet URLs. Sie ersetzt weder interne Entdeckung noch klare Seitenrollen.
• Seite löschen: Fehlende Indexierung widerlegt nicht die zugrunde liegende Suchaufgabe. Wenn die Seite relevant und absichtlich gewählt ist, wird zuerst die Ursache verbessert.

Bei grossen Beständen kommt die URL-Ökonomie hinzu. Filter, Kalender, interne Suche und Parameter können nahezu unbegrenzte Räume erzeugen. Dann reicht die Korrektur einzelner Canonicals nicht. Das System muss festlegen, welche Zustände überhaupt erreichbar, crawlbar und indexierbar sein dürfen.

Von der Beobachtung zur kontrollierten Änderung

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.

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.

Ä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.

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.

Zur Abnahme gehören deshalb zwei verschiedene Belege: Der Browser oder Crawler zeigt, dass das System die vereinbarte Ausgabe liefert. Search Console und Logdaten zeigen später, ob Google die geänderten URLs erneut abruft und verarbeitet. Die zweite Beobachtung braucht Zeit; die erste darf beim Release nicht fehlen.