Echte Anker-Tags vs. JavaScript-only-Links: Warum Google braucht

Ein Shopify-Ladenbesitzer installierte letztes Jahr eine Premium-Mega-Menu-App. Die App hatte großartige Bewertungen, schöne Animationen und eine saubere Benutzeroberfläche. Der Umsatz blieb stabil. Drei Monate später zeigte die Google Search Console einen Rückgang der gecrawlten Seiten um 40%. Das Problem war nicht das Menü-Design – die Menü-Links existierten nur in JavaScript. Der Crawler von Google sah eine Homepage ohne Links zu Kategorieseiten. Die Kategorien waren verwaist.

Das ist der häufigste Navigation-SEO-Fehler, den ich sehe: ein Menü, das für Nutzer perfekt aussieht, aber für Suchmaschinen unsichtbar ist. Die Lösung ist nicht komplex, erfordert aber das Verständnis des Unterschieds zwischen echten HTML-Links und JavaScript-only-Navigation-Mustern – und zu wissen, wie du deine eigene Website überprüfst, um das Problem zu erkennen, bevor es dir Traffic kostet.

Was der Crawler von Google wirklich sieht

Wenn Google eine Seite crawlt, stellt es eine HTTP-Anfrage an deinen Server und erhält HTML als Antwort. Der Crawler analysiert das HTML nach Links – speziell nach <a>-Tags mit href-Attributen. Jede gefundene URL wird zur Crawl-Queue hinzugefügt.

Das ist der erste Pass. Der Crawler von Google kann JavaScript ausführen (er nutzt eine Version von Chrome im Hintergrund), aber JavaScript-Rendering findet später statt, in einem zweiten Pass, und ist nicht für jede Seite garantiert. Google priorisiert das erste-Pass-HTML-Crawl, weil es schnell und zuverlässig ist. Seiten, die vollständig auf JavaScript für Navigation angewiesen sind, sind im Nachteil.

Das ist, wonach Google sucht:

<a href="/collections/summer-shoes">Summer Shoes</a>

Das ist ein echter Link. Das href-Attribut enthält eine URL. Der Crawler von Google extrahiert /collections/summer-shoes und fügt es zur Crawl-Queue hinzu. Diese Seite wird gecrawlt und indexiert.

Das ignoriert oder verpasst Google beim ersten Pass:

<div onclick="window.location='/collections/summer-shoes'">Summer Shoes</div>
<a href="javascript:void(0)" onclick="navigate('/collections/summer-shoes')">Summer Shoes</a>
<button data-url="/collections/summer-shoes">Summer Shoes</button>

Das sind keine Anker-Tags mit echten href-Attributen. Die URLs existieren im Code (in onclick-Handlern oder data-Attributen), aber der erste-Pass-Crawler von Google führt JavaScript nicht aus und analysiert beim Linkdiscovery keine data-Attribute. Diese Links sind beim initialen Crawl unsichtbar.

Google könnte diese Seiten eventually durch andere Mittel entdecken (Sitemaps, externe Backlinks, JavaScript-Rendering), aber sie erhalten nicht die Crawl-Priorität oder Link-Equity, die mit dem Sein-Linked-in-Navigation-HTML kommt.

View Source: der definitive Test

Du brauchst keine speziellen Tools, um zu überprüfen, ob deine Navigation crawlbar ist. Jeder Browser hat eine “View Source”-Funktion, die das rohe HTML zeigt, das der Server sendet, bevor JavaScript ausgeführt wird. Das ist genau das, was der erste-Pass-Crawler von Google sieht.

So überprüfst du es

1. Öffne die Homepage deines Ladens in Chrome, Firefox oder Safari.
2. Mache einen Rechtsklick an einer beliebigen Stelle der Seite und wähle “Seitequellcode anzeigen” (oder drücke Strg+U unter Windows, Cmd+Option+U auf Mac).
3. Ein neuer Tab zeigt das rohe HTML.
4. Drücke Strg+F (Cmd+F auf Mac) und suche nach der URL einer deiner Hauptkategorieseiten – zum Beispiel /collections/women.

Wenn du die URL in einem Anker-Tag wie diesem findest:

<a href="/collections/women">Women's Clothing</a>

Ist deine Navigation crawlbar. Google kann diesem Link folgen.

Wenn die URL nicht in View Source erscheint oder nur in einem <script>-Tag oder in einem data-Attribut wie diesem erscheint:

<div class="menu-item" data-url="/collections/women">Women's Clothing</div>

Ist deine Navigation im ersten Pass nicht crawlbar. Der initiale HTML-Crawl von Google wird sie verpassen.

Mobil vs. Desktop

Viele Ladengeschäfte nutzen unterschiedliche Navigation-Implementierungen für Mobilgeräte und Desktop. Die Desktop-Version könnte semantische HTML-Anker-Tags verwenden, während die Mobile-Version JavaScript-only-Hamburger-Menüs nutzt. Da Google Mobile-First-Indexing nutzt (die Mobile-Version ist die Primärversion, die Google crawlt), musst du das Mobile-HTML separat überprüfen.

In Chrome:

1. Öffne DevTools (F12 oder Rechtsklick → Untersuchen).
2. Klicke auf das Device-Toolbar-Symbol (oder drücke Strg+Shift+M / Cmd+Shift+M).
3. Wähle ein Mobilgerät aus der Dropdown-Liste (zum Beispiel iPhone SE).
4. Lade die Seite neu.
5. Mache einen Rechtsklick und zeige die Quelle erneut.

Suche nach deinen Kategorie-URLs im Mobile-HTML. Wenn sie nicht vorhanden sind, sieht der Mobile-Crawler von Google deine Navigation-Links nicht.

Häufige Muster, die den View-Source-Test nicht bestehen

Muster 1: JavaScript-generierte Mega-Menüs

Viele moderne Menu-Apps funktionieren so:

1. Der Server sendet minimales HTML – nur einen Menu-Trigger-Button.
2. Wenn der Nutzer schwebt oder klickt, fetcht JavaScript Menu-Daten von einer API oder analysiert ein JSON-Objekt.
3. JavaScript erstellt das volle DOM (einschließlich aller <a>-Tags) und injiziert es in die Seite.

Beispiel-HTML, das der Server sendet:

<button id="mega-menu-trigger">Shop</button>
<div id="mega-menu-container"></div>
<script>
  const menuData = {
    "women": {"label": "Women", "url": "/collections/women"},
    "men": {"label": "Men", "url": "/collections/men"}
  };
  // JavaScript erstellt und injiziert Links bei Nutzer-Interaktion
</script>

View Source zeigt den Button und den leeren Container. Die Links existieren noch nicht. Der erste-Pass-Crawl von Google sieht keine Links zu Kategorieseiten.

Muster 2: Single-Page-App-Routing

Ladengeschäfte, die mit React, Vue oder anderen SPA-Frameworks erstellt wurden, nutzen oft Client-Side-Routing. Das Menü könnte im Framework-Code so aussehen:

<Link to="/collections/summer-shoes">Summer Shoes</Link>

Ob das crawlbar ist, hängt davon ab, wie das Framework es rendet und ob die App Server-Side-Rendering nutzt. Wenn die App eine reine Client-Side-SPA ist (der Server sendet eine einzelne index.html-Shell und JavaScript rendet alles), zeigt View Source eine leere Shell ohne Navigation-Links:

<!DOCTYPE html>
<html>
<head><title>Store</title></head>
<body>
  <div id="root"></div>
  <script src="/bundle.js"></script>
</body>
</html>

Der ganze Inhalt, einschließlich Navigation, wird von JavaScript gerendert. Der erste-Pass-Crawl von Google sieht nichts.

Muster 3: Onclick-Handler ohne href

Manche Menüs nutzen Anker-Tags, platzieren aber die Navigation-Logik in onclick-Handlern und nutzen javascript:void(0) als href:

<a href="javascript:void(0)" onclick="goToCategory('women')">Women</a>

Das sieht für Nutzer wie ein Link aus und verhält sich sogar wie ein Link, wenn es geklickt wird, aber javascript:void(0) ist keine echte URL. Der Crawler von Google extrahiert javascript:void(0) aus dem href-Attribut und verwirft es, weil es keine crawlbare URL ist. Das echte Ziel (/collections/women) ist in der JavaScript-Funktion goToCategory() begraben, die der Crawler beim ersten-Pass-HTML-Parsing nicht ausführt.

Muster 4: Divs und Buttons mit data-Attributen

Entwickler erstellen manchmal Navigation mit nicht-semantischen Elementen:

<div class="nav-item" data-url="/collections/women" onclick="navigate(this.dataset.url)">
  Women
</div>

Das funktioniert für Nutzer (JavaScript liest das data-Attribut und navigiert beim Klick), aber es gibt kein <a>-Tag und kein href-Attribut. Der Crawler von Google sucht nicht in data-Attributen nach URLs. Der Link ist unsichtbar.

Wie man JavaScript-only-Links behebt

Behebung 1: Links im HTML rendern, mit JavaScript erweitern

Der beste Ansatz: Dein Server (oder Static-Site-Generator) gibt vollständiges HTML mit echten Anker-Tags aus. JavaScript fügt Interaktivität oben drauf hinzu.

Server-gerendertes HTML:

<nav>
  <a href="/collections/women">Women</a>
  <a href="/collections/men">Men</a>
  <a href="/collections/kids">Kids</a>
</nav>

Dieses HTML ist crawlbar. Google sieht die Links sofort.

Dann erweitert JavaScript es:

document.querySelectorAll('nav a').forEach(link => {
  link.addEventListener('click', (e) => {
    // Glätte Übergänge hinzu, Analytics, etc.
    // Lass den Browser normal navigieren (preventDefault nicht aufrufen)
  });
});

Die Navigation funktioniert ohne JavaScript (Graceful Degradation), funktioniert perfekt mit JavaScript (Progressive Enhancement) und ist in beiden Fällen crawlbar.

Behebung 2: Server-Side-Rendering für SPAs nutzen

Wenn dein Laden eine Single-Page-App ist, die mit React, Vue oder ähnlich erstellt wurde, implementiere Server-Side-Rendering (SSR) oder Static-Site-Generation (SSG).

Frameworks, die das einfach machen:

• Next.js für React
• Nuxt für Vue
• SvelteKit für Svelte
• Gatsby für statische Seiten

Diese Frameworks rendern das volle HTML (einschließlich Navigation) auf dem Server. Der initiale Seitenladevorgang liefert vollständiges, crawlbares HTML. Dann hydratisiert JavaScript die Seite und übernimmt für nachfolgende Navigation, was dir die SPA-Erfahrung für Nutzer und crawlbares HTML für Suchmaschinen gibt.

Behebung 3: Überprüfe die Einstellungen deiner Menu-App

Wenn du eine Shopify-Menu-App verwendest, überprüfe die Einstellungen der App nach einer “SEO-Mode”- oder “Server-Side-Rendering”-Option. Viele Apps bieten das als Toggle an. Wenn aktiviert, rendet die App Navigation-Links in Liquid (Shopifys Server-Side-Template-Sprache) statt JavaScript.

Wenn deine App diese Option nicht anbietet und du (via View Source) bestätigt hast, dass deine Navigation nicht crawlbar ist, erwäge, zu einer App zu wechseln, die das tut. Navi+ AI Menu Builder rendet alle Links standardmäßig im HTML – die Links sind in der initialen HTML-Payload, und JavaScript kümmert sich nur um Interaktion und Animation.

Behebung 4: Progressive Enhancement für Hamburger-Menüs

Mobile Hamburger-Menüs verstecken Navigation oft, bis der Nutzer das Symbol tippt. Das Menü kann trotzdem crawlbar sein, solange die Links im HTML existieren:

<nav class="mobile-menu" aria-hidden="true">
  <a href="/collections/women">Women</a>
  <a href="/collections/men">Men</a>
</nav>

CSS versteckt das Menü standardmäßig:

.mobile-menu {
  display: none;
}
.mobile-menu.is-open {
  display: block;
}

JavaScript togglet die Klasse, wenn das Hamburger-Menü getippt wird:

hamburgerButton.addEventListener('click', () => {
  mobileMenu.classList.toggle('is-open');
});

Die Links existieren im HTML (View Source zeigt sie), also kann Google sie crawlen, obwohl sie durch CSS versteckt sind. Das ist in Ordnung – Google bestraft versteckte Inhalte nicht, solange sie nicht deceptiv sind (du versteckst nicht Keyword-gefüllten Spam).

Was nicht funktioniert: das Mobile-Menu-DOM mit JavaScript nur dann erstellen, wenn das Hamburger-Menü getippt wird:

hamburgerButton.addEventListener('click', () => {
  const menu = document.createElement('nav');
  menu.innerHTML = '<a href="/de/collections/women">Women</a>...';
  document.body.appendChild(menu);
});

Dieses Menü existiert im HTML nicht, bis der Nutzer interagiert. Der Crawler von Google tippt nicht auf Hamburger-Symbole. Die Links sind unsichtbar.

Deine Behebung testen

Nachdem du deine Navigation aktualisiert hast, überprüfe, dass sie jetzt crawlbar ist:

1. View-Source-Test: Lade deine Homepage erneut und zeige die Quelle. Suche nach Kategorie-URLs. Bestätige, dass sie in Anker-Tags vorhanden sind.
2. JavaScript-deaktivierter Test: In Chrome DevTools, deaktiviere JavaScript (Einstellungen → Debugger → JavaScript deaktivieren). Lade deine Homepage neu. Bestätige, dass Navigation-Links sichtbar und klickbar sind. Das Klicken auf einen Link sollte zur Kategorieseite navigieren (die Seite sieht ohne JavaScript kaputt aus, aber die Navigation sollte funktionieren).
3. Google Search Console: Warte ein paar Tage, dann überprüfe den Coverage-Bericht (Seiten → Indexiert). Wenn vorher verwaiste Kategorieseiten anfangen, als indexiert zu erscheinen, hat deine Behebung funktioniert.

Überprüfe sowohl Desktop als auch MobilFühre den View-Source-Test sowohl auf Desktop- als auch auf Mobile-Versionen deiner Website aus. Wenn deine Mobile-Navigation eine andere Implementierung nutzt (Hamburger-Menü, andere App, vereinfachte Struktur), teste sie separat. Googles Mobile-First-Indexing bedeutet, dass die Mobile-Version für Rankings zählt.

Warum das wichtiger ist, als du denkst

Navigation ist nicht nur einer von vielen internen Links auf deiner Website – es ist der prominenteste, konsistenteste Satz von Links, den Google sieht. Das Hauptmenü erscheint auf jeder Seite. Es ist im Header, in der Nähe der Oberseite des HTML-Dokuments, wo Google erwartet, wichtige Links zu finden. Wenn Google deine Homepage crawlt, ist die Navigation der erste Satz von Links, auf den es trifft.

Wenn diese Links nicht crawlbar sind, verpasst Google nicht nur ein paar Seiten. Es verliert das primäre Signal zum Verstehen deiner Website-Architektur. Kategorieseiten werden Waisen. Produkte, die nur von diesen Kategorieseiten verlinkt sind, werden Waisen eine Ebene tiefer. Die ganze Site-Struktur fällt aus Googles Perspektive zusammen.

Und weil Navigation so konsistent ist (gleiches Menü auf jeder Seite), verstärkt sich die Auswirkung. Wenn deine Homepage-Navigation nur-JavaScript ist, hat jede Seite auf deiner Website das gleiche Problem. Google crawlt 100 Seiten und findet null Navigation-Links auf allen 100 Seiten. Das ist kein kleines SEO-Problem – es ist ein fundamentales Crawlbarkeits-Versagen.

Der View-Source-Test dauert 30 Sekunden. Wenn deine Kategorie-URLs nicht im rohen HTML erscheinen, hast du die wichtigste SEO-Behebung gefunden, die du machen kannst. Alles andere – Keyword-Optimierung, Backlinks, technische Verbesserungen – baut auf der Annahme auf, dass Google deine Seiten crawlen kann. Ohne crawlbare Navigation ist diese Annahme falsch.