Ein leuchtendes Fundament aus HTML5-Blöcken vor einem Server-Rack mit einem grünen 200 OK Statuslicht.
64 Views
SEO für Entwickler: Was im Code wirklich wichtig ist
SEO für Entwickler beginnt dort, wo die Arbeit des Marketing-Teams aufhört: im Quellcode und auf dem Server. Wenn Software Engineers gebeten werden, eine Website für Suchmaschinen zu optimieren, denken sie oft an nerviges Keyword-Spamming. Doch vergessen Sie Texte und Backlinks. Ihre Aufgabe als Entwickler ist es, eine saubere API für den Googlebot bereitzustellen.
Googlebot ist im Grunde ein gigantischer, automatisierter Headless-Chrome-Browser. Er konsumiert keinen Content, er konsumiert DOM-Knoten und Server-Responses. Wenn Ihre Applikation auf technischer Ebene unverständlich antwortet, wird sie nicht gerankt. In diesem ersten Teil unserer Serie schauen wir uns die absoluten Fundamente an: Statuscodes und HTML-Semantik.
TL;DR für Entwickler (Das Wichtigste in Kürze):
Status Codes: Nutzen Sie 301 für Redirects (nicht 302). Nutzen Sie 410 für gelöschte Produkte (nicht 404).
Soft 404: Eine JS-Fehlermeldung auf dem Bildschirm nützt nichts, wenn der Server im Hintergrund einen 200 OK Status sendet.
HTML: Weg mit der <div>-Soup. Nutzen Sie <main>, <article> und <nav>, um dem Crawler die Struktur zu erklären.
Accessibility = SEO: Wenn ein Screenreader Ihre Seite nicht versteht, versteht Google sie auch nicht.
1. Die Sprache des Servers: HTTP-Statuscodes
Crawler verschwenden ungern Rechenleistung. Dieses Kontingent an Zeit nennt man "Crawl Budget". Bevor Googlebot überhaupt eine Zeile HTML liest, schaut er in den HTTP-Header Ihrer Antwort. Liefern Sie hier falsche Signale, sperren Sie den Bot aus.
Der Relaunch-Killer: 301 vs. 302
Sie ziehen eine URL um (z.B. von /über-uns auf /about).
301 (Moved Permanently): Sagt Google: "Alte URL löschen, Link-Power 1:1 auf die neue URL übertragen." (Richtig)
302 (Found / Temporary): Sagt Google: "Ich bin nur kurz weg, behalte die alte URL im Index." (Falsch für Relaunches) – Sie verlieren massiv an Ranking.
Das Aufräumen: 404 vs. 410
Ein Produkt ist im Shop ausverkauft und kommt nie wieder.
404 (Not Found): "Das Produkt ist nicht da. Versuchs nächste Woche nochmal." (Google kommt wieder und verschwendet Crawl-Budget).
410 (Gone): "Dieses Produkt ist für immer gelöscht." (Google löscht die URL sofort aus dem Index und spart Ressourcen).
Die "Soft 404" Falle in SPAs
Ein moderner Klassiker bei React/Vue-Apps: Der Nutzer ruft /produkte/gibt-es-nicht auf. Die Single Page App (SPA) merkt das im Frontend und rendert eine schöne "Fehler 404"-Komponente auf den Bildschirm. Das Problem: Der Node.js/PHP-Server im Hintergrund sendet trotzdem einen 200 OK Status an Googlebot. Google denkt, Ihre Fehlerseite sei wertvoller Content und indexiert tausende tote URLs. Die Lösung: Sorgen Sie für serverseitiges Routing, das bei toten URLs einen echten 404-Header ausspielt.
2. Semantisches HTML: Das Ende der "Div-Soup"
Früher haben Entwickler Layouts über endlose <div>-Verschachtelungen gebaut. Für den Menschen (und das CSS) sieht das gut aus. Für den Crawler ist es wertloser Text-Brei ohne Kontext.
Wenn wir SEO für Entwickler betrachten, gilt: Semantik ist die API für Suchmaschinen. HTML5-Tags sagen dem Crawler exakt, welche Gewichtung ein Textteil hat.
Der <main> Tag: Darf nur einmal pro URL vorkommen. Er zeigt Google sofort: "Hier ist der unique Content dieser Seite, ignoriere den Rest".
Der <header> und <footer>: Google weiß so, dass diese Links nur Navigation sind und wertet sie als "Boilerplate" (weniger wichtig für das Ranking der spezifischen Seite).
Überschriften (H1-H6): Nutzen Sie Headline-Tags nie für Design-Zwecke (z.B. weil Sie eine fette Schrift wollen). Sie müssen einer logischen Baumstruktur folgen. Eine Seite hat exakt eine H1.
3. Googlebot ist ein blinder User
Es gibt eine goldene Regel im technischen SEO: Was gut für Barrierefreiheit (Screenreader) ist, ist gut für Google.
Viele moderne Web-Apps ersetzen klassische Links durch JavaScript-Events. Für den User funktioniert das, für Googlebot nicht.
Falsch (Google folgt diesem Link NICHT):
bash
<span onclick="window.location='/produkte'">Zu den Produkten</span>
Richtig (Googlebot folgt dem href-Attribut):
bash
<a href="/produkte">Zu den Produkten</a>
Das Gleiche gilt für Bilder. Der Crawler hat keine Augen. Ohne ein alt="Text" Attribut im <img>-Tag existiert das Bild für Google nicht. Sie verschenken damit enormen Traffic aus der Google-Bildersuche.
Fazit: Die Basics müssen sitzen
Erfolgreiches SEO für Entwickler bedeutet, eine stabile Brücke zwischen Ihrem Code und dem Crawler zu bauen. Wenn Statuscodes stimmen, das HTML semantisch logisch ist und Links echte href-Attribute haben, ist das Fundament gelegt. Wer diese Hausaufgaben macht, eliminiert 80% aller technischen SEO-Fehler.
Doch was passiert, wenn das HTML gar nicht auf dem Server existiert, sondern erst live im Browser via JavaScript generiert wird? Dann beginnt das eigentliche Problem moderner Webentwicklung.
Nein. Google ist extrem tolerant gegenüber kaputtem HTML (z.B. fehlenden schließenden Tags). Wichtig ist nicht, dass das HTML 100% W3C-konform ist, sondern dass die Struktur (DOM-Tree) für den Parser logisch ist.
Ja, wenn ein 302-Redirect sehr lange bestehen bleibt, interpretiert Google ihn irgendwann als dauerhaft (301). Das dauert aber oft Wochen. Als Entwickler sollten Sie sich nicht auf die "Gnade" des Crawlers verlassen, sondern sofort sauberen Code (301) liefern.
Verlassen Sie sich nie auf das, was der Browser auf dem Bildschirm anzeigt. Nutzen Sie das Terminal mit dem Befehl curl -I https://meine-domain.de, um nur die HTTP-Header anzusehen, oder nutzen Sie den "Network"-Tab in den Chrome DevTools.
Jein. Wenn Sie Text via CSS ausblenden (z.B. in einem Tab oder Akkordeon), indexiert Google den Text trotzdem. Allerdings wird er weniger gewichtet als sofort sichtbarer Text. Aus Entwickler-Sicht: Nutzen Sie statt JS-Akkordeons lieber die nativen HTML-Tags und .
Das JavaScript-Dilemma
Sie entwickeln mit React, Vue.js oder Angular? Dann liefert Ihr Server anfangs nur ein leeres <body>-Tag aus. Für Google ist das eine Blackbox.
Im nächsten Teil unserer SEO für Entwickler Masterclass schauen wir uns an, wie Googlebot JavaScript verarbeitet. Wir erklären das "Zwei-Phasen-Crawling", zeigen die Gefahren von Client-Side Rendering (CSR) und erklären, warum serverseitiges Rendering (SSR/Hydration) heute Pflicht ist.
Webinteger arbeitet seit vielen Jahren produktiv mit Linux-basierten Entwicklungsumgebungen unter Windows. Der Fokus liegt auf performanten Setups mit WSL 2, Docker, PHP, Node.js und modernen Build-Tools in realen Projekten – nicht auf theoretischen Beispielkonfigurationen.
Die Artikel dieser Serie entstehen direkt aus dem täglichen Einsatz in Kunden- und Eigenprojekten und dokumentieren bewusst auch typische Fehler, Engpässe und bewährte Workarounds.
Webseite besuchen
