Warum deine Website nicht rankt — und warum ich selten beim Content anfange

Vielleicht kennst du das auch: Du hast einen Artikel geschrieben, die Keywords recherchiert, die Meta-Description formuliert, interne Links gesetzt — und trotzdem taucht die Seite nicht in den Suchergebnissen auf. Nicht auf Seite eins, nicht auf Seite fünf, nirgendwo. Dann fängst du an, am Content zu feilen, Überschriften umzuformulieren, Synonyme einzubauen. Und nichts passiert. Ich habe das bei eigenen Projekten erlebt und bei Kunden, und ehrlich gesagt war das Problem fast nie der Content. Sondern etwas viel Grundlegenderes.

Google sieht nicht, was du siehst

Wenn du deine Website im Browser öffnest, siehst du die fertige Seite. Text, Bilder, Überschriften, alles da. Aber was du siehst, ist das Ergebnis eines Prozesses: Dein Browser hat den HTML-Code empfangen, dann CSS geladen, dann JavaScript ausgeführt, und erst danach hat er die Seite gerendert. Das Problem ist, dass Google diesen Prozess nicht immer vollständig durchläuft. Der Googlebot holt sich zuerst den rohen HTML-Code — und wenn dein Content erst durch JavaScript nachgeladen wird, sieht Google im ersten Durchgang eine leere Seite. Es gibt zwar einen zweiten Rendering-Durchgang, aber der kann Tage oder Wochen dauern. Und manchmal passiert er gar nicht.

Das klingt nach einem Nischenproblem, aber es betrifft mehr Websites als du denkst. Jede Single Page Application, die ihre Inhalte per API lädt. Jedes React- oder Vue-Frontend ohne Server-Side Rendering. Jede WordPress-Seite mit einem Builder, der Inhalte per AJAX nachlädt. Sogar manche Slider und Accordion-Elemente verstecken Content vor dem initialen HTML. Bevor du also auch nur eine einzige Überschrift optimierst, musst du eine Frage klären: Kann Google meinen Content überhaupt sehen?

Der erste Check: Was liefert dein Server wirklich aus?

Der schnellste Weg, das herauszufinden, ist ein simpler curl-Befehl. Öffne dein Terminal und schau dir an, was dein Server als HTML-Antwort zurückgibt — ohne Browser, ohne JavaScript, ohne Rendering. Genau das sieht Google beim ersten Crawl.

curl -s https://deine-website.de/artikel/ | head -100

Wenn du in diesen ersten hundert Zeilen deinen Artikeltext siehst, Überschriften, Absätze, strukturiertes HTML — dann ist alles in Ordnung. Wenn du stattdessen ein leeres <div id="app"></div> siehst und ein paar Script-Tags, dann hast du dein Problem gefunden. Dein Content existiert nur im JavaScript, nicht im HTML. Für Google ist deine Seite im schlimmsten Fall leer.

Noch genauer wird es, wenn du gezielt nach deinen Überschriften suchst. Denn die Headline-Struktur ist für Google ein zentrales Signal, und wenn die im initialen HTML fehlt, fehlt das komplette semantische Gerüst.

curl -s https://deine-website.de/artikel/ | grep -iE '<h[1-6]'

Kommt hier nichts zurück, weißt du Bescheid. Dann werden deine H1- und H2-Tags erst vom Browser gebaut, nicht vom Server geliefert. Das ist der Moment, in dem du aufhörst, an Keywords zu schrauben, und anfängst, an der Architektur zu arbeiten.

view-source versus gerenderte Seite

Im Browser gibt es zwei Wege, den Code einer Seite zu betrachten, und die Unterschiede sind entscheidend. Wenn du in Chrome view-source:https://deine-website.de/artikel/ in die Adresszeile tippst, siehst du den rohen HTML-Code, so wie er vom Server kommt. Kein JavaScript wurde ausgeführt, kein DOM manipuliert. Das ist im Wesentlichen das, was auch der curl-Befehl liefert.

Wenn du dagegen die DevTools öffnest und im Elements-Tab den DOM inspizierst, siehst du das Ergebnis nach der JavaScript-Ausführung. Da steht dann der ganze Content, alle dynamisch erzeugten Elemente, alles schön aufbereitet. Der Unterschied zwischen diesen beiden Ansichten zeigt dir exakt, wie viel deiner Seite von JavaScript abhängt. Und damit, wie viel Google beim ersten Crawl möglicherweise nicht sieht.

Ein noch radikalerer Test: Deaktiviere JavaScript komplett in den DevTools. Geh in die Einstellungen, unter Debugger, und setz den Haken bei „Disable JavaScript“. Dann lade die Seite neu. Was übrig bleibt, ist das, was Google garantiert sieht. Wenn das eine weiße Seite ist oder nur ein Ladebalken — dann hast du kein Content-Problem, du hast ein Rendering-Problem.

Den gerenderten DOM systematisch prüfen

Wenn du schon in den DevTools bist, gibt es ein paar Konsolenbefehle, die ich bei jedem SEO-Audit als Erstes ausführe. Die zeigen dir in Sekunden, was auf der Seite strukturell passiert — und wo es hakt.

// Alle Überschriften der Seite auflisten
document.querySelectorAll('h1, h2, h3, h4, h5, h6').forEach(h =>
  console.log(h.tagName, h.textContent.trim())
);

Damit siehst du sofort, ob die Überschriften-Hierarchie stimmt. Gibt es mehrere H1? Springt die Struktur von H2 direkt auf H4? Fehlen Überschriften komplett? All das sind Signale, die Google verarbeitet, und wenn die Hierarchie kaputt ist, leidet das Ranking — unabhängig davon, wie gut dein Text formuliert ist.

// Prüfen, ob eine Meta-Description existiert
console.log(document.querySelector('meta[name="description"]')?.content);

Klingt banal, aber ich habe schon Seiten gesehen, bei denen das SEO-Plugin eine Meta-Description nur im gerenderten DOM erzeugt hat, nicht im initialen HTML. Der Server hat sie nicht ausgeliefert, also hat Google sie nicht gesehen. Das Plugin war so konfiguriert, dass es die Tags clientseitig injiziert hat. Ein klassischer Fall von „funktioniert im Browser, existiert nicht für den Crawler“.

Was Google wirklich indexiert hat

Der einfachste Weg zu prüfen, was Google tatsächlich von deiner Seite kennt, ist die site:-Suche. Tipp in die Google-Suche site:deine-website.de ein und schau dir die Ergebnisse an. Jede URL, die dort auftaucht, hat Google indexiert. Jede, die fehlt, hat Google entweder nicht gefunden, nicht crawlen können oder bewusst ausgeschlossen.

# Anzahl der indexierten Seiten grob einschätzen
# Vergleiche das mit der Anzahl deiner tatsächlichen Seiten
curl -s "https://www.google.com/search?q=site:deine-website.de" | grep -o 'Ungefähr [0-9.]*'

Wenn du 200 Seiten hast, aber Google nur 40 davon kennt, liegt das Problem nicht am Content der fehlenden 160 Seiten. Es liegt daran, dass Google sie nicht findet oder nicht crawlen will. Das bringt uns zu zwei Themen, die viele unterschätzen: Interne Verlinkung und Crawl-Budget.

Verwaiste Seiten und die Architektur der internen Links

Stell dir deine Website als Gebäude vor. Jede Seite ist ein Raum, und jeder interne Link ist eine Tür zwischen zwei Räumen. Wenn ein Raum keine einzige Tür hat, die zu ihm führt — dann existiert er für Google nicht. Das sind sogenannte Orphan Pages, verwaiste Seiten. Sie sind in keinem Menü, werden von keiner anderen Seite verlinkt, haben keine Sitemap-Einträge. Technisch existieren sie, praktisch sind sie unsichtbar.

Das passiert schneller als du denkst. Du erstellst einen neuen Beitrag, vergisst ihn im Menü, verlinkst ihn von keinem anderen Artikel aus, und die Sitemap wird nur einmal am Tag aktualisiert. Für ein paar Stunden oder Tage ist die Seite eine Insel. Und wenn Google in dieser Zeit vorbeischaut und sie nicht findet, kann es dauern, bis er wiederkommt.

Interne Verlinkung ist keine SEO-Kosmetik, es ist Architektur. Jeder Link verteilt Crawl-Priorität und PageRank. Wenn deine wichtigsten Seiten nur über drei Klicks erreichbar sind, signalisierst du Google, dass sie nicht besonders wichtig sind. Wenn jede Seite von der Startseite aus in maximal zwei Klicks erreichbar ist, versteht Google die Struktur — und crawlt effizienter.

Crawl-Budget: Weniger ist oft mehr

Google weist jeder Website ein begrenztes Crawl-Budget zu. Das ist die Anzahl der Seiten, die der Bot bei einem Besuch crawlen wird, bevor er weiterzieht. Bei einer kleinen Website mit 50 Seiten ist das selten ein Problem. Aber wenn deine Website durch Tag-Seiten, Paginierung, Filterseiten und Archivseiten plötzlich 5.000 URLs hat, von denen 4.500 keinen echten Mehrwert bieten, dann verschwendet der Bot sein Budget auf Seiten, die niemand braucht — und kommt nie bei deinen eigentlichen Inhalten an.

Die Lösung ist nicht mehr Content, sondern weniger URLs. Setz ein noindex auf Tag-Archive, die nur drei Beiträge haben. Verhindere das Crawling von Filterseiten per robots.txt oder Canonical Tags. Konsolidiere dünne Seiten. Jede URL, die Google crawlt, sollte es wert sein, gecrawlt zu werden. Ich habe bei einem Projekt die indexierten Seiten von 3.000 auf 400 reduziert — und der organische Traffic hat sich innerhalb von sechs Wochen verdoppelt. Nicht weil die verbleibenden Seiten besser waren, sondern weil Google endlich verstanden hat, welche Seiten wichtig sind.

SPA, SSR und warum die Architekturentscheidung SEO bestimmt

Wenn du eine Single Page Application mit React, Vue oder Angular baust und kein Server-Side Rendering einrichtest, liefert dein Server bei jedem Request im Wesentlichen eine leere HTML-Hülle mit einem JavaScript-Bundle. Der Browser führt das JavaScript aus, holt Daten von einer API, und baut die Seite zusammen. Für den Nutzer funktioniert das wunderbar. Für Google ist es ein Problem, weil der Rendering-Schritt aufwendig ist und der Bot ihn nicht bei jeder Seite durchführt.

Server-Side Rendering löst das, weil der Server den HTML-Code vollständig ausliefert. Der Content steht im initialen HTML, Google sieht ihn beim ersten Crawl, alles gut. Aber SSR hat Kosten: höhere Serverbelastung, komplexere Deployment-Pipeline, Hydration-Probleme im Frontend. Es ist eine Architekturentscheidung, die du am Anfang eines Projekts treffen musst, nicht nachträglich. Nachträglich SSR einzubauen ist möglich, aber es ist ein Umbau, kein Feature.

Für die meisten Content-Websites ist die Antwort ehrlich gesagt einfacher: Nimm ein System, das HTML aus Templates generiert. WordPress, ein statischer Site-Generator, ein klassisches Symfony- oder Laravel-Projekt. Kein Framework-Overhead, kein Rendering-Problem, kein JavaScript-Dependency für Content, der schlicht Text ist. Nicht jede Website braucht eine SPA. Die meisten brauchen verlässliches HTML.

Ein kompletter Debugging-Durchlauf

Wenn du das Gefühl hast, deine Seite rankt nicht, obwohl sie es sollte, mach Folgendes — in genau dieser Reihenfolge. Nicht beim Content anfangen, sondern bei der Technik.

# 1. Was liefert der Server als HTML?
curl -s https://deine-website.de/artikel/ | head -100

# 2. Sind Überschriften im HTML vorhanden?
curl -s https://deine-website.de/artikel/ | grep -iE '<h[1-6]'

# 3. Ist eine Meta-Description im HTML?
curl -s https://deine-website.de/artikel/ | grep -i 'meta.*description'

# 4. Gibt es Canonical-Tags?
curl -s https://deine-website.de/artikel/ | grep -i 'canonical'

# 5. Wie antwortet der Server? (Statuscode prüfen)
curl -sI https://deine-website.de/artikel/ | head -5

# 6. Ist die Seite in der Sitemap?
curl -s https://deine-website.de/sitemap.xml | grep 'artikel'

Erst wenn all diese Checks sauber sind — HTML-Content vorhanden, Überschriften im Quellcode, Meta-Tags gesetzt, Statuscode 200, Seite in der Sitemap — erst dann lohnt es sich, über Content-Optimierung nachzudenken. Alles andere ist Symptombehandlung. Du polierst den Text auf einer Seite, die Google gar nicht richtig lesen kann. Das ist, als würdest du die Schriftart auf einem Brief verbessern, den die Post nicht zustellen kann, weil die Adresse fehlt.

Technisches SEO ist nicht glamourös. Es ist Terminal, curl, Quelltext lesen, Sitemap prüfen, Status-Codes verstehen. Aber es ist das Fundament. Ohne Fundament bringt der schönste Content nichts.