Werden URL Fragmente (Hash) von Google indexiert? SPA und # erklärt

Werden URL Fragmente (Hash) von Google indexiert?

Nein. Ein URL Fragment, also der Teil nach dem Rautezeichen, wird von Google nicht als eigene Seite indexiert. Die Google Dokumentation sagt, dass Google Search URL Fragmente im Allgemeinen nicht unterstützt. Allerdings ist ein Hash, der nur zu einer Stelle auf derselben Seite springt, harmlos. Ein Hash, der den Seiteninhalt austauscht, ist ein Problem.

Hinter dieser kurzen Antwort stecken also einige Unterschiede. Außerdem ist nicht jede Website gleich aufgebaut. In diesem Beitrag beantworten wir eine einzige Frage vollständig: Was passiert mit Inhalten hinter einem URL Fragment, was tun Sie bei einer Single Page Application, und wo stehen Sprungmarken und UTM Parameter?

Wir, Talha Aslan und Team, sehen das Thema oft nach dem Start einer neuen Website. Dann heißt es: "Die Hälfte unserer Seiten fehlt bei Google." Die Ursache liegt häufig in der Art, wie die Navigation gebaut ist.

Was ist ein URL Fragment und was macht der Browser damit?

Ein Fragment ist der Teil einer Adresse, der mit einem Rautezeichen beginnt. Bei example.com/ratgeber#preise ist zum Beispiel "preise" das Fragment. Der Browser lädt die Seite und scrollt danach zu dem Element mit der passenden ID.

Wichtig ist ein Detail: Der Browser sendet das Fragment normalerweise nicht an den Server. Der Server sieht also keinen Unterschied zwischen "ratgeber" und "ratgeber#preise". Das Fragment lebt also komplett im Browser.

Daraus folgen zwei Konsequenzen:

• Der Server kann für einen Hash keinen anderen Inhalt liefern, denn er erfährt den Hash nie.
• Jede Änderung des Inhalts muss deshalb aus JavaScript kommen, dem Code, der im Browser läuft.

Wenn sich der Inhalt mit dem Hash ändert, tauscht also ein Skript den Inhalt aus. Eine Suchmaschine erwartet dagegen eine Antwort pro Adresse, denn sie arbeitet adressweise. Daher ist dieser Widerspruch die Wurzel des Problems.

Warum behandelt Google das URL Fragment nicht als eigene Seite?

Die Google Dokumentation zur URL Struktur sagt es direkt. Verwenden Sie keine Fragmente, um den Inhalt einer Seite zu ändern, weil Google Search URL Fragmente im Allgemeinen nicht unterstützt. Das schlechte Beispiel in diesem Dokument zeigt einen Pfad, der in der Adresse mit #/ beginnt.

Die Logik ist einfach. Google ruft eine Adresse ab, erhält eine Antwort und ordnet diese Antwort der Adresse zu. Weil das Fragment den Server nie erreicht, liefern example.com/#/produkte und example.com/#/kontakt dieselbe Antwort. Für Google sind das eine einzige Seite.

Sie können also sicher sagen: Google behandelt durch Fragmente getrennte Adressen im Allgemeinen nicht als eigene Seiten. Das Wort "im Allgemeinen" stammt aus der Dokumentation selbst. Zudem versprechen wir nicht mehr als das. Trotzdem ist es sicherer, auf dieser Annahme zu planen, als auf das Gegenteil zu hoffen.

Das praktische Ergebnis: Hat eine Ansicht Suchwert, geben Sie ihr eine echte URL. Ansichten, die nur ein Fragment trennt, können nicht mit eigenem Titel und eigener Beschreibung in den Ergebnissen erscheinen.

Was passiert bei einer Website, die Inhalte per URL Fragment wechselt?

Nehmen wir zum Beispiel ein Szenario. Eine Produktseite steuert ihr ganzes Menü per Hash: Startseite example.com/#/, Produkte example.com/#/produkte, Preise example.com/#/preise. Im Browser funktioniert zunächst alles.

Wenn Google diese Website abruft, sieht es nur example.com. Die Menülinks zeigen auf Fragment Adressen, deshalb entdeckt Google keine einzelnen Seiten. Folglich erscheint nur die Startseite in der Suche. Somit taucht Ihre Preisansicht bei keiner Suchanfrage auf.

Bei einer Website, die mit einem URL Fragment arbeitet, verlieren Sie drei Dinge:

• Entdeckung: Innere Ansichten werden nicht als eigene Seiten gefunden.
• Signale: Externe Links zeigen oft auf die Hash Adresse und zählen für die Startseite.
• Messung: Die Webanalyse zeigt alle Besuche als eine einzige Seite.

Dabei ist das ein Architekturszenario, kein Kundenergebnis. Trotzdem sehen wir dieses Muster häufig, besonders bei Unternehmensseiten, die mit älteren JavaScript Frameworks gebaut wurden.

Wie richten Sie Routing in einer Single Page Application richtig ein?

Wenn Sie eine Single Page Application (SPA, eine Web App, die Ansichten ohne Neuladen der Seite wechselt) betreiben, lautet die Antwort History API. Die Google Dokumentation zu den JavaScript SEO Grundlagen empfiehlt die History API für das Routing zwischen den Ansichten Ihrer App.

Die History API lässt Sie also die Adressleiste ohne Neuladen aktualisieren. Öffnet ein Nutzer die Preisansicht, lautet die Adresse dann example.com/preise. Diese Adresse ist ein echter Pfad, und der Server kann sie ebenfalls beantworten.

Ein korrektes Setup hat diese Bestandteile:

1. Jede Ansicht hat einen eigenen, sauberen und dauerhaften Pfad.
2. Wenn Sie den Pfad direkt in den Browser eingeben, liefert der Server denselben Inhalt.
3. Menülinks sind echte Link Elemente, und der href Wert trägt den Pfad.
4. Jede Ansicht hat einen eigenen Titel und eine eigene Beschreibung.

Zudem erleichtert serverseitiges Rendering oder Prerendering, also das Vorbereiten des Inhalts als HTML, Google das Erkennen des Inhalts. Daher hängt diese Wahl von Ihren Zielen für Leistung und Wartung ab. Ob sie nötig ist, entscheiden Sie anhand der Struktur Ihrer Website.

Unterstützt Google Hashbang Adressen (#!) noch?

Ein Hashbang ist ein altes Format, bei dem eine Adresse mit den Zeichen #! beginnt. Zunächst ein Rückblick: Früher beschrieb Google ein spezielles "AJAX Crawling Schema" für solche Adressen. Allerdings ist dieses Schema inzwischen abgekündigt.

Das offizielle Konto von Google Search Central hat erklärt, dass Hashbang und AJAX Crawling Schema schon vor langer Zeit abgekündigt wurden. Es empfiehlt eine sauberere URL Struktur, die weder # noch #! braucht. Daher gibt es für ein neues Projekt keinen Grund, Hashbangs einzusetzen. Auch ein #! erzeugt also keine eigene Seite.

Finden Sie #! auf einer älteren Website, gehen Sie so vor:

• Akzeptieren Sie, dass das Schema nicht mehr unterstützt wird, und verlassen Sie sich nicht darauf.
• Legen Sie für jede #! Adresse einen echten Pfad fest.
• Planen Sie die Umstellung von den alten Adressen auf die neuen Pfade.

Hinweis: Der Server sieht den Hash nie. Deshalb können Sie eine Hash Adresse nicht direkt per 301 weiterleiten. Diese Grenze braucht eine eigene Lösung, die wir im Abschnitt zur Umstellung beschreiben.

Sind Sprungmarken mit # ein Problem?

Nein. Das Rautezeichen für Sprungmarken innerhalb einer Seite ist in Ordnung. In dieser Verwendung ändert der Hash den Inhalt also nicht. Er scrollt nur zu einer Überschrift oder einem Abschnitt derselben Seite.

Ein Inhaltsverzeichnis am Anfang eines langen Ratgebers ist ein gutes Beispiel. Zum Beispiel führt der Link "Preise" zur Preis Überschrift auf der Seite. Der Inhalt steht bereits dort, deshalb muss Google keine eigene URL sehen.

Zudem hilft das der Bedienung. Leser erreichen den gewünschten Teil mit einem Klick. Außerdem navigieren Nutzer mit Tastatur oder Screenreader schneller.

Sie müssen nur eines prüfen: Die Ziel ID muss auf der Seite existieren, und der Inhalt muss beim ersten Laden im HTML stehen. Entsteht die ID dagegen erst später durch JavaScript, kann der Sprung scheitern.

Ob solche Sprungmarken in den Suchergebnissen als "Springe zu" Links erscheinen, ist eine andere Frage. Wir haben sie in unserem Beitrag zum Inhaltsverzeichnis und den Sprunglinks bei Google behandelt und wiederholen sie hier nicht.

Sollten Tabs, Akkordeons und Filter das URL Fragment nutzen?

Nicht, wenn die Ansicht Suchwert hat, denn sie muss auffindbar sein. Steht der Text in einem Tab oder Akkordeon schon im HTML der Seite, zeigt der Hash nur, welcher Bereich offen ist. Dann bleibt der Inhalt sichtbar. Allerdings beginnen Probleme, wenn Inhalt erst nach der Hash Änderung lädt.

Sie können diese Aufteilung nutzen:

• Sichtbarer Zustand: Welcher Tab offen ist, darf im Hash stehen.
• Eigener Inhalt: Soll jeder Tab eine auffindbare Seite sein, geben Sie ihm eine echte URL.
• Filter: Gefilterte Listen können Sie mit einem Query String (zum Beispiel ?farbe=blau) statt mit einem Hash bauen. Bei vielen Filterkombinationen brauchen Sie jedoch einen Indexierungsplan.

Die Probleme von Filterkombinationen haben wir im Beitrag zur Facettennavigation behandelt. Deshalb löst die Flucht in den Hash das Problem nicht. Er versteckt es nur.

Kurz gesagt: Zeigen Sie dem Nutzer nur eine Einstellung, reicht ein Hash. Für alles, was Google finden soll, brauchen Sie eine echte Adresse.

Was passiert, wenn Sie UTM Parameter hinter das # setzen?

Setzen Sie UTM Tags hinter das #, können Ihre Analysedaten kaputtgehen. Die Google Analytics Hilfe zu URL Buildern sagt, dass Sie die Parameter mit einem Fragezeichen von der URL trennen. Sie schreibt die Parameter als Paare aus Name und Wert, verbunden durch ein kaufmännisches Und.

Der Grund ist leicht zu sehen, denn der Hash bleibt im Browser. Der Hash geht nicht an den Server, und viele Setups lesen nur den Query String. Bleibt Ihr Tag hinter dem #, kann die Kampagnenquelle in einer falschen Gruppe landen, etwa "direkt" oder "Verweis".

Allerdings kann dieses Verhalten je nach Tool abweichen. Testen Sie es daher in Ihrem eigenen Setup. Prüfen Sie außerdem in der offiziellen Hilfe Ihrer Werbeplattform, wie sie ein Fragment in der Ziel URL behandelt.

Die sichere Regel lautet: erst der Query String, zuletzt der Hash. Zum Beispiel ist example.com/seite?utm_source=newsletter#preise richtig. Statt Tags von Hand zu tippen, nutzen Sie unseren UTM Generator. Die ganze Logik lesen Sie in unserem Beitrag zu UTM Parametern im Kampagnen Tracking.

Wie unterscheiden sich URL Fragment, Query String und History API?

Die drei Methoden verfolgen nicht dasselbe Ziel. Das URL Fragment bleibt im Browser, der Query String geht an den Server, und die History API aktualisiert einen echten Pfad im Browser. Die Tabelle zeigt alle drei nebeneinander.

Die Formulierung "Im Allgemeinen nein" entspricht dem Wortlaut der Google Dokumentation. Lesen Sie sie nicht als absolute Regel.

Kurz gesagt ist der Entscheidungsbaum einfach. Liegt der Inhalt auf derselben Seite, nutzen Sie ein Fragment. Ist der Inhalt ein anderer, geben Sie ihm einen echten Pfad. Für optionale Variablen wie Sortierung oder Kampagnen nutzen Sie einen Query String, planen aber das Canonical Verhalten dieser Adressen. Unser Beitrag zum Canonical Tag erklärt diesen Teil.

Woran erkennen Sie, dass Ihre Website hashbasiertes Routing nutzt?

Die Anzeichen zeigen sich also meist in den ersten Monaten. Es gibt einige klare Hinweise, und jeder ist leicht zu prüfen.

Achten Sie auf diese Zeichen:

• Beim Klicken durch das Menü zeigt die Adressleiste ein # mit einem Pfad dahinter.
• Die Google Suche zeigt nur Ihre Startseite oder sehr wenige Seiten.
• Die Search Console meldet weit weniger entdeckte Seiten, als Ihre Website Ansichten hat.
• Fast alle Sitzungen verbucht die Webanalyse auf eine einzige Seitenadresse.
• Im Seitenquelltext fehlt der Text der anderen Ansichten, weil Inhalte später nachgeladen werden.

Sehen Sie zwei oder drei Zeichen zugleich, prüfen Sie das Setup. Allerdings ist keines allein ein Beweis. Eine ganz neue Website wurde zum Beispiel vielleicht schlicht noch nicht gecrawlt.

Falls Sie neu bei der Search Console sind, behandelt unsere Anleitung zur Google Search Console die wichtigsten Berichte. Für Seiten, die nicht im Index landen, hilft der Beitrag zum Finden nicht indexierter Seiten.

Wie prüfen Sie eine hashbasierte Website Schritt für Schritt?

Dafür brauchen Sie keine Spezialwerkzeuge. Mit dieser Reihenfolge klären Sie die Lage in etwa einer Stunde.

1. Öffnen Sie Ihre Website im Browser und klicken Sie jeden Menülink an. Notieren Sie, wie sich die Adressleiste ändert.
2. Kopieren Sie die Adresse jeder Ansicht und öffnen Sie sie direkt in einem neuen Tab. Sehen Sie denselben Inhalt?
3. Nutzen Sie in der Search Console das Tool zur URL Prüfung (URL Inspection), um zu sehen, wie Google diese Adressen sieht.
4. Prüfen Sie dann im Seitenquelltext, ob der Haupttext jeder Ansicht vorhanden ist.
5. Bestätigen Sie, dass die Menülinks echte Link Elemente mit einem href Wert sind.
6. Öffnen Sie in der Webanalyse den Bericht auf Seitenebene und sehen Sie nach, ob die Ansichten in getrennten Zeilen erscheinen.

Am Ende haben Sie zwei Listen: Ansichten mit echter URL und Ansichten, die sich nur per Hash öffnen. Somit ist die zweite Liste das Rückgrat Ihres Korrekturplans.

Hinweis: Menü und Schaltflächennamen in Tools ändern sich mit Oberflächen Updates. Deshalb schreiben wir "der passende Bericht" statt eines genauen Schaltflächentextes. Das Gegenstück finden Sie in Ihrem eigenen Panel.

Wie wechseln Sie von Hash Adressen zu echten URLs?

Der schwierigste Teil der Umstellung ist also, dass der Hash den Server nie erreicht. Sie können dem Server nicht sagen, er solle "#/preise" auf "/preise" leiten. Deshalb brauchen Sie einen Plan mit zwei Ebenen.

Zunächst ist die erste Ebene der Aufbau der neuen Struktur. Geben Sie jeder Ansicht einen echten Pfad, stellen Sie sicher, dass der Server diese Pfade direkt beantwortet, und stellen Sie die alten Menülinks auf die neuen Pfade um.

Danach betrifft die zweite Ebene Besucher, die über alte Adressen kommen. Eine kleine clientseitige Zuordnung, die nach dem Laden der Seite läuft, kann sie auf den neuen Pfad schicken. Das ist allerdings keine echte 301. Sie schützt den Besucher, garantiert aber keine Übertragung von Signalen.

Beachten Sie bei der Umstellung diese Punkte:

• Nehmen Sie alle neuen Pfade in die Sitemap auf.
• Stellen Sie interne Links vom alten Hash Format auf die neuen Pfade um.
• Prüfen Sie zuerst Seiten, die externe Links auf alte Adressen erhalten.
• Beobachten Sie nach der Umstellung einige Wochen den Abdeckungsbericht in der Search Console.

Sind Sie bei den Weiterleitungsarten unsicher, lesen Sie unseren Beitrag zur 302 Weiterleitung und den Unterschieden zu 301, 307 und 308.

Warum sind Statuscodes und Soft 404 bei SPAs wichtig?

Bei Single Page Apps findet das Routing im Client statt. Deshalb liefert der Server oft für jeden Pfad den Status 200. Die Google Dokumentation räumt das ein: Beim clientseitigen Routing können aussagekräftige HTTP Statuscodes unmöglich oder unpraktisch sein.

Hier liegt der Haken. Zum Beispiel öffnet ein Besucher einen Pfad, den es nicht gibt. Die App zeigt "nicht gefunden", doch der Server liefert trotzdem 200. Google kann das als Soft 404 werten, also als Seite, die wie ein Fehler aussieht, aber einen Erfolgscode liefert.

Dann nennt die Dokumentation zwei Lösungen. Sie leiten auf eine echte 404 Seite um, oder Sie fügen der Fehlerseite per JavaScript ein noindex Robots Meta Tag hinzu. Deshalb schreiben wir das Tag hier bewusst nicht als Code. Ihr Entwickler kann die Dokumentation direkt öffnen.

Außerdem wirkt dieses Thema getrennt von der Hash Frage, entsteht aber aus derselben Architekturentscheidung. Sobald Sie den Hash verlassen und die History API nutzen, gehört es auch zu Ihren Aufgaben, ungültige Pfade richtig zu beantworten. Das noindex Verhalten erklärt unser Beitrag zum Unterschied von noindex und nofollow.

Wie schreiben Sie Links, denen Google folgen kann?

Laut der Google Dokumentation zu crawlbaren Links braucht die Link Entdeckung echte Link Elemente mit einem href Attribut. Auch per JavaScript hinzugefügte Links können funktionieren, müssen aber dieselben Regeln einhalten.

Ist ein Menüpunkt zum Beispiel als Schaltfläche oder klickbare Box gebaut, sieht Google ihn eventuell nicht als Link. Konstruktionen, die auf einen Hash wechseln, aber keinen href tragen, gehören in diese Gruppe. Die Dokumentation warnt außerdem, dass Adressen, die das Schema „javascript“ verwenden, problematisch sind, weil sie nicht zu einer echten Webadresse führen.

Nutzen Sie diese Checkliste:

• Jeder Menüpunkt hat einen href, der auf eine echte Adresse zeigt.
• Ein Klick Handler ergänzt das Verhalten des Links und ersetzt ihn nicht.
• Auch Links zur Seitennummerierung und zu Filtern nutzen echte Adressen.
• Interne Links haben einen aussagekräftigen Linktext.

Daher hängt diese Regel direkt mit dem Hash Thema zusammen. Die meisten hashbasierten Menüs laufen über Klick Ereignisse und bieten keine Adresse, über die einzelne Seiten auffindbar wären. Zur Wirkung schwerer Skripte auf die Geschwindigkeit lesen Sie JavaScript und Ladezeit.

Welche Mythen gibt es rund um das URL Fragment?

Das Thema klingt technisch, deshalb kreisen einige falsche Annahmen darum. Wir haben alle schon gehört, daher nehmen wir sie ernst.

• "Google führt JavaScript aus, also funktioniert der Hash." Das Ausführen von JavaScript ist ein anderes Thema. Das Problem ist, dass ein Fragment nicht als eigene Seitenadresse gilt.
• "Nehme ich die Hash Adresse in die Sitemap auf, wird sie indexiert." Ein Sitemap Eintrag bringt Google nicht dazu, die Adresse als eigene Seite zu behandeln.
• "Ein Canonical Tag trennt Hash Ansichten." Ein Canonical steuert Duplikate. Eine eigene Seite erzeugt es also nicht.
• "Hash ist schlecht für jede SEO." Für Sprungmarken ist ein Hash völlig sicher.
• "Nach der Umstellung ist das Problem vorbei." Danach prüfen Sie weiter Statuscodes, Links und Sitemap.

Allen Mythen ist gemeinsam: Sie suchen die Lösung in Tags oder Dateien. Stattdessen liegt die echte Lösung in der Adresse selbst. Eine Ansicht braucht eine eindeutige, dauerhafte Adresse, die der Server beantworten kann, bevor sie ranken kann.

Um Ihre Website auf weitere technische Lücken zu prüfen, nutzen Sie unseren SEO Check. Eine Hash Architektur behebt er nicht allein, zeigt aber die grundlegenden Lücken schnell.

Sollten Sie Sprache oder Region per URL Fragment wählen?

Manche Websites steuern die Sprache mit Hash Werten wie example.com/#de und example.com/#en. In diesem Aufbau liegen beide Sprachen unter einer Adresse, und Google sieht womöglich nur eine davon. Folglich entsteht für die andere Sprache keine eigene Seite.

Ein eigener Pfad pro Sprache ist gesünder, zum Beispiel /de/ und /en/. Dann hat jede Sprache eine eigene Seite, einen eigenen Titel und eine eigene Beschreibung. Das Verknüpfen von Sprachversionen ist ein eigenes Fachgebiet.

Eine automatische Weiterleitung nach IP Adresse bringt ein weiteres Risiko. Das haben wir im Beitrag zur automatischen Sprachweiterleitung nach IP untersucht. Hier betonen wir nur: Sprache oder Land brauchen eine echte Adresse, keinen Hash.

Ist der Sprachwechsel nur eine Oberflächenpräferenz, etwa weil der Text jeder Sprache bereits im HTML steht, schadet ein Hash nicht. Der Unterschied liegt also darin, an welcher Adresse der Inhalt steht.

Welche Fehler passieren bei der Umstellung von Hash auf echte URLs?

Allerdings scheitert eine Umstellung meist an Eile. Zudem ist jeder Fehler unten vermeidbar.

• Halbe Umstellung: Die neuen Pfade funktionieren, aber das Menü nutzt noch alte Hash Links. Google entdeckt die neuen Pfade nicht.
• Überall 200 liefern: Auch fehlende Pfade liefern Erfolg, und es entstehen Soft 404.
• Doppelte Titel: Jede Ansicht trägt denselben Titel. Eine Ansicht mit eigenem Pfad braucht einen eigenen Titel.
• Sitemap vergessen: Die neuen Pfade fehlen in der Sitemap, und die Entdeckung verlangsamt sich.
• Webanalyse auslassen: Seitenaufruf Ereignisse feuern beim Routenwechsel nicht, und Sitzungen wirken weiter wie eine Seite.
• Ungetestet live gehen: Veröffentlichen, ohne jeden Pfad vorher von Hand zu öffnen.

Bei der Planung der Adressen helfen die Grundsätze aus unserem Beitrag zu den Regeln für URL Slugs. Wir wiederholen den Slug hier nicht. Wir erinnern nur daran, dass ein Pfad lesbar und dauerhaft bleiben soll.

Nach der Umstellung beobachten Sie Canonical Fehler mit der Checkliste aus dem Beitrag zum Erkennen von Canonical Fehlern in der Search Console.

Wann ist ein Hash völlig unproblematisch?

Manchmal ist ein Hash genau das richtige Werkzeug. Fällt Ihre Nutzung in diese Gruppe, müssen Sie sich keine Sorgen machen.

• Der Sprung vom Inhaltsverzeichnis zu einem Abschnitt.
• Ein Link "Nach oben" auf einer langen Seite.
• Die Anzeige, welcher Tab auf der Seite offen ist.
• Ein Link zu einem Kommentar oder einer Fußnote auf der Seite.
• Der Fokus auf die Fehlermeldung eines Formulars.

Gemeinsam ist: Der Inhalt steht bereits im HTML der Seite, und der Hash zeigt nur eine Position oder einen Zustand. Dass Google dieselbe Adresse als eine Seite sieht, ist hier genau das, was Sie wollen.

Wir sind also nicht gegen den Hash. Wir sind dagegen, Inhalt, der eine eigene Seite sein sollte, hinter einem Hash zu verstecken. Entscheiden Sie, ob ein Inhalt eine eigene auffindbare Seite bekommt. Wenn ja, geben Sie ihm einen echten Pfad. Wenn nein, genügt ein Hash.

Wie gehen wir als Team an dieses Thema heran?

Als Talha Aslan und Team beginnen wir technische Probleme wie dieses im Rahmen der SEO Beratung mit der Bestandsaufnahme. Bei einer hashbasierten Website prüfen wir zuerst, welche Ansichten Suchwert tragen.

Der Ablauf sieht meist so aus:

1. Wir listen die aktuelle Struktur und die Ansichten auf.
2. Danach legen wir mit Suchdaten fest, welche Ansichten eigene Seiten sein müssen.
3. Anschließend geben wir Ihrem Entwicklerteam schriftliche Vorgaben für echte Pfade, Statuscodes und Links.
4. Zuletzt beobachten wir nach der Umstellung die Daten der Search Console und der Webanalyse.

Ergebnisse versprechen wir nicht, denn über die Indexierung entscheidet Google. Wir beseitigen die Hürden in der Architektur, die Google daran hindern, Ihre Inhalte zu finden.

Planen Sie eine neue Website, ist diese Entscheidung am Anfang deutlich günstiger. In unserem Webdesign Angebot klären wir die Routing Struktur schon im Entwurf. Für die technische Prüfung einer bestehenden Seite sehen Sie sich unsere SEO Beratung an.

Wann sollten Sie Expertenhilfe holen?

In manchen Fällen spart technische Hilfe Zeit gegenüber dem Alleingang.

Erwägen Sie Hilfe in diesen Situationen:

• Ihre ganze Website läuft auf Hash Routing und braucht eine Neufassung.
• Nach einer Umstellung ist der Traffic gefallen, und Sie finden den Grund nicht.
• Ihrem Team fehlt Erfahrung mit Architekturentscheidungen wie serverseitigem Rendering.
• Viele externe Links zeigen auf alte Adressen, und Sie riskieren Signalverlust.

Sie können sich vorbereiten, bevor Sie fragen. Listen Sie Ihre Ansichten auf, markieren Sie, welche Google finden soll, und notieren Sie den aktuellen Traffic in der Webanalyse. Diese drei Angaben beschleunigen jedes technische Gespräch.

Zum Schluss: Für den Hash gibt es nicht die eine richtige Antwort. Die richtige Lösung hängt davon ab, ob der Inhalt eine auffindbare Seite ist. Soll er gesucht werden, geben Sie ihm eine echte URL. Wenn nicht, nutzen Sie den Hash ruhig weiter. Den Traffic nach einer Änderung prüfen Sie mit den Schritten aus dem Beitrag zum Traffic Einbruch in der Search Console.