URL-Fragment-Indexierung

Indexierung von URL-Fragmenten ist größtenteils ein Altlastenproblem, taucht aber in SPA-Audits immer noch jeden Monat auf. Wenn sich wichtige Inhalte nur unter /page#state oder /page#!/view anzeigen lassen, behandelt Google das in der Regel als dieselbe URL wie /page – nicht als eigenes Dokument.

Die geschäftliche Auswirkung ist simpel: Versteckte URLs ranken nicht. Produktzustände, Hilfeartikel, gefilterte Kategoriesichten und App-Routen können aus der Suche verschwinden, obwohl Nutzer sie im Browser problemlos aufrufen können.

Was Google mit Fragmenten tatsächlich macht

Bei normaler Indexierung entfernen Suchmaschinen das Fragment. Google hat das alte AJAX-Crawling-Schema bereits vor Jahren eingestellt – und damit verschwand auch die alte #!-Umgehungslösung. In der Praxis ruft Googlebot die Basis-URL ab, nicht jede Hash-Variante, die darauf aufsetzt.

Das bedeutet: example.com/docs#setup ist keine zweite Seite. Es ist normalerweise einfach example.com/docs mit einem Sprung innerhalb der Seite. Wenn dein React- oder Vue-Router für eindeutige Inhalte weiterhin auf hashbasierte Zustände angewiesen ist, liegt ein Indexierungsproblem vor – kein kleines technisches Detail.

Ein ehrlicher Hinweis: Fragmente sind in Ordnung für Anker, Tabs und Sprunglinks auf einer Seite, die bereits indexierbar ist. Das Problem beginnt, wenn Teams erwarten, dass Fragmente eigenständige Suchtreffer erzeugen.

Wo das die SEO-Performance kaputtmacht

• SPAs mit Hash-Routing: Routen wie /#/pricing oder /#!/features laufen oft in eine einzige crawlbare URL zusammen.
• Facettierte Navigation: Filter, die nur über Fragmente geladen werden, können keine Rankings für Long-Tail-Kombinationen erzielen.
• Dokumentations-Hubs: Artikelzustände, die hinter Fragmenten gerendert werden, werden häufig nicht einzeln indexiert.
• Verwechslungsgefahr bei Link Equity: Backlinks auf Fragment-Varianten erzeugen selten separate Ranking-Signale für diese Zustände.

In Screaming Frog zeigt sich das üblicherweise als eine einzige HTML-URL mit vielen JavaScript-Änderungen des Zustands, aber ohne klar unterscheidbare crawlbare Pfade. In der Google Search Console siehst du Impressionen, die sich auf die Basis-URL konzentrieren, während die vermeintlichen Unteransichten keine Ausbeute bekommen. Ahrefs und Semrush melden dann weniger Ranking-URLs, als das Product-Team glaubt, dass es sie gibt.

Was stattdessen tun

1. Verlege wichtige Zustände auf echte URLs – mithilfe von pathbasiertem Routing oder Query-Parametern.
2. Render indexierbaren Content serverseitig oder pre-render ihn mit Frameworks wie Next.js, Nuxt oder Astro.
3. Setze Canonicals auf die neuen URLs – nicht auf Fragment-Versionen.
4. Aktualisiere interne Links, XML-Sitemaps und Navigation, damit Google die neuen Pfade findet.
5. Prüfe das mit GSC URL-Inspektion, gerenderten Crawls in Screaming Frog und – falls vorhanden – mit Logfiles.

Wenn es sich um eine Migration handelt, mappe alte fragmentbasierte Zielseiten (die Nutzer sehen) nach Möglichkeit auf gleichwertige crawlbare URLs. Streng genommen kannst du kein 301 für ein Fragment setzen, weil das Fragment clientseitig verarbeitet wird und nicht in der HTTP-Anfrage mitgeschickt wird. Das ist die Einschränkung, die viele Glossare auslassen. Du brauchst JavaScript-Handling, Updates der internen Links und die Rückgewinnung externer Links in Ahrefs oder Moz – nicht nur eine saubere serverseitige Redirect-Regel.

Fazit: Fragmente sind für Positionen auf einer Seite gedacht – nicht für indexierbare Dokumente. Wenn die Seite für organischen Traffic relevant ist, gib ihr eine echte URL.