Als Entwickler kontrollierst du die Hälfte des SEO-Spiels komplett selbst: Rendering, Ladezeit, Struktur, Auffindbarkeit. Diese technische Hälfte entscheidet zwar nicht allein über Rankings — ohne guten Content rankt nichts — aber sie entscheidet darüber, ob dein Content überhaupt eine faire Chance bekommt. Und sie ist für uns Devs der Teil mit dem besten Aufwand-Nutzen-Verhältnis.
Ich betreibe eigene Projekte und Kundenseiten, deren Traffic zu einem großen Teil über Suche kommt, und habe dabei gelernt: Das meiste “SEO-Wissen” da draußen ist für Marketer geschrieben und technisch schwammig. Hier ist die Dev-Version — konkret, priorisiert, ohne Voodoo.
Rendering-Strategie: Die Architektur-Entscheidung mit SEO-Folgen
Die folgenreichste technische SEO-Entscheidung triffst du beim Projekt-Setup: Wie kommt dein HTML zum Crawler? Die Kurzfassung der Optionen:
- Statisch generiert (SSG): HTML liegt fertig auf dem Server. Für Blogs, Docs, Landingpages und Marketing-Seiten die beste Wahl — schnell, robust, crawlbar ohne Wenn und Aber. Astro, Next mit Static Export, Eleventy: egal, Hauptsache das HTML ist beim ersten Byte vollständig.
- Server-Side Rendering (SSR): HTML wird pro Request gebaut. Gleichwertig crawlbar, nötig bei personalisierten oder hochdynamischen Inhalten.
- Client-Side Rendering (reines SPA): Der Crawler bekommt erst mal eine leere Hülle plus JavaScript. Google kann JS rendern, aber: Das Rendering passiert verzögert in einer zweiten Welle, Fehler bleiben unbemerkt, und andere Crawler (Bing, Social-Previews, KI-Crawler) sind deutlich schlechter darin. Für alles, was ranken soll, ist ein reines SPA die schlechteste Wahl.
Die pragmatische Regel: Content-Seiten statisch oder serverseitig rendern, App-Teile hinter dem Login dürfen SPA sein. Wenn deine Marketing-Seite und deine App im selben Framework leben, achte darauf, dass die öffentlichen Routen vollständiges HTML liefern — mit curl statt Browser prüfen, dann siehst du, was der Crawler sieht.
Core Web Vitals: Wichtig, aber richtig eingeordnet
Core Web Vitals — LCP (größtes sichtbares Element geladen), INP (Reaktionszeit auf Interaktion), CLS (Layout-Springen) — sind ein Rankingfaktor, aber ein schwächerer, als die Tool-Industrie suggeriert. Ehrliche Einordnung: Eine Seite mit besserem Content und mittelmäßigen Vitals schlägt die schnellere Seite mit dünnem Content fast immer. Die Vitals sind ein Tiebreaker und vor allem eine Conversion-Frage — langsame Seiten verlieren Besucher, bevor Rankings überhaupt relevant werden.
Was in der Praxis die Werte ruiniert, in absteigender Häufigkeit: unoptimierte Bilder (fehlende Größenangaben → CLS, riesige Dateien → LCP), zu viel JavaScript (Hydration-Kosten → INP), Web-Fonts ohne font-display: swap, und Third-Party-Skripte, die du “nur mal eben” eingebunden hast. Die Gegenmittel sind Standard-Handwerk: moderne Bildformate mit expliziten Dimensionen und Lazy Loading außerhalb des Viewports, JS-Budget klein halten (ein Blog braucht keine 300 KB Hydration), Fonts selbst hosten und subsetten.
Messen: PageSpeed Insights nutzt echte Felddaten (CrUX), Lighthouse im DevTools ist Labor. Optimiere auf Felddaten, nicht auf den Laborwert — und hör auf zu optimieren, wenn alles grün ist. Der Sprung von 85 auf 100 Punkte ist Zeit, die in Content besser investiert wäre.
Struktur und Auffindbarkeit: Das unterschätzte Fundament
Ein paar unspektakuläre Dinge entscheiden, ob Suchmaschinen deine Inhalte finden und verstehen:
- Saubere URLs und interne Verlinkung: Jede wichtige Seite sollte über wenige Klicks von der Startseite erreichbar sein und von thematisch verwandten Seiten verlinkt werden. Verwaiste Seiten ranken schlecht — der Crawler bewertet auch, wie wichtig du selbst deine Inhalte nimmst.
- Title und Meta-Description pro Seite: Der Title ist der stärkste On-Page-Faktor; einzigartig pro Seite, Kernbegriff vorn. Die Description rankt nicht, bestimmt aber die Klickrate im Suchergebnis.
- Sitemap.xml und robots.txt: Zwei Dateien, zehn Minuten Arbeit, bei jedem Framework generierbar. Sitemap in der Search Console einreichen — damit siehst du auch, welche Seiten Google kennt, aber nicht indexiert.
- Canonical-Tags: Verhindern, dass Parameter-Varianten und Duplikate dein Ranking-Signal aufsplitten. Besonders relevant bei Pagination, Filtern und wenn Inhalte unter mehreren Pfaden erreichbar sind.
- Ein H1 pro Seite, logische Heading-Hierarchie: Nicht wegen magischer Keyword-Wirkung, sondern weil die Struktur bestimmt, wie Maschinen (und Screenreader) dein Dokument verstehen.
Strukturierte Daten: Konkrete Chancen, klare Grenzen
Schema.org-Markup in JSON-LD macht deine Inhalte maschinenlesbar und kann erweiterte Suchergebnisse freischalten: FAQ-Blöcke, Breadcrumbs, Artikel-Metadaten, Bewertungssterne bei Produkten. Der ehrliche Rahmen: Strukturierte Daten verbessern nicht dein Ranking, sie verbessern die Darstellung — und damit die Klickrate. Für einen Dev-Blog lohnen sich Article, BreadcrumbList und wo passend FAQPage; für Produkte Product mit Preis. Implementierung ist trivial (ein JSON-LD-Block im Head), Validierung über den Rich-Results-Test von Google.
Zunehmend relevant: Auch KI-Systeme mit Suchfunktion konsumieren strukturiertes, sauber gerendertes HTML deutlich besser als JS-Blobs. Wer heute crawlbar und maschinenlesbar baut, ist für die Suche von morgen — die immer öfter eine Antwort-Engine ist — besser aufgestellt.
Was du getrost ignorieren kannst
Zeit sparen ist auch Optimierung, deshalb die Liste der überbewerteten Maßnahmen: Keyword-Dichte-Analysen (Google versteht Synonyme und Kontext seit Jahren), Meta-Keywords (werden schlicht ignoriert), das hundertste Performance-Audit bei bereits grünen Werten, XML-Sitemap-Ping-Dienste, und der Kauf von Backlink-Paketen — letzteres ist nicht nur nutzlos, sondern riskant. Auch die Angst vor “Duplicate Content Penalties” bei eigenen Inhalten ist übertrieben: Canonicals setzen, fertig.
Genauso wichtig wie die Ignorierliste: Technisches SEO ist gedeckelt. Ab einem soliden Stand kommt zusätzliches Ranking fast nur noch aus Inhalten, die Suchintentionen wirklich beantworten, und aus Verweisen, die du dir mit nützlicher Arbeit verdienst. Die Technik sorgt dafür, dass nichts davon verpufft.
Die Prioritätenliste zum Abarbeiten
Wenn du heute eine Stunde investieren willst, in dieser Reihenfolge: Prüfe mit curl, ob deine wichtigen Seiten vollständiges HTML liefern. Reiche die Sitemap in der Search Console ein und schau, welche Seiten nicht indexiert sind — und warum. Fixe Titles und Descriptions der zehn wichtigsten Seiten. Optimiere die Bilder der Startseite. Alles Weitere folgt aus den Daten, die dir die Search Console ab jetzt liefert: Sie zeigt dir Queries, bei denen du auf Position 8 bis 25 stehst — genau da liegt dein billigster Traffic-Zuwachs.
Wenn du deine Projekte-Setups vergleichen oder ein konkretes Indexierungs-Problem zerlegen willst: Im Discord der Community haben einige von uns ihre Search-Console-Daten offen auf dem Tisch.