Viele Website-Projekte folgen demselben Muster: Ein Team baut sechs Monate lang ein Produkt oder eine Website, geht live – und fragt dann erst, wie man das eigentlich bei Google sichtbar macht. Zu diesem Zeitpunkt ist die Antwort meistens: "Ihr müsst einiges umbauen." SEO ist kein Layer, den man obendrauf legt. Es ist eine Eigenschaft des Systems – und die entscheidet sich in der Architekturphase.
Das Problem fängt bei der URL-Struktur an
URL-Strukturen sind keine technische Kleinigkeit. Sie sind das Skelett eurer Informationsarchitektur – und Google liest sie genau so wie ein Mensch: von links nach rechts, mit klarer Erwartung an Hierarchie und Kontext. Wer anfangs auf /page?id=4711 setzt oder alles flach unter der Root ablegt, bekommt das später schmerzlich zu spüren: URL-Migrationen sind teuer, riskant und werden von Suchmaschinen misstrauisch beäugt, selbst wenn Redirects sauber gesetzt sind. Die Signale, die eine Domain über Jahre aufgebaut hat, verteilen sich bei einer Migration nie verlustfrei.
Konkret heißt das: Bevor die erste Zeile Code geschrieben wird, sollte feststehen, wie die Seitenstruktur aussieht. Welche Kategorien gibt es? Wie tief geht die Hierarchie? Welche Inhalte bekommen eigene URLs – und welche nicht? Das sind keine SEO-Fragen, das sind Produktentscheidungen. Wer sie erst im Nachhinein trifft, trifft sie zweimal.
Rendering-Strategie ist keine Dev-Entscheidung allein
Hier kommt Next.js ins Spiel – und warum wir bei happycoding Berlin fast ausnahmslos darauf setzen. Next.js gibt Entwicklerteams granulare Kontrolle darüber, welche Seiten server-side gerendert werden (SSR) und welche zur Build-Zeit als statisches HTML ausgeliefert werden (SSG). Diese Unterscheidung ist für SEO fundamental. Statisch generierte Seiten sind blitzschnell, sofort crawlbar und benötigen keine Client-Side-Execution, bevor Google den Inhalt indexieren kann. SSR sorgt dafür, dass auch dynamische Inhalte – Produktseiten, personalisierte Bereiche, API-abhängige Daten – mit vollständigem HTML beim Crawler ankommen.
Ein klassisches React-SPA, das alles clientseitig rendert, ist dagegen für Suchmaschinen ein Rätsel. Googlebot kann zwar JavaScript ausführen – aber mit Verzögerung, unzuverlässig, und mit einem Budget, das bei großen Crawls schnell aufgebraucht ist. Die Entscheidung für ein Framework ist damit keine reine Dev-Entscheidung: Sie bestimmt, wie gut eure Inhalte überhaupt gefunden werden können.
Strukturierte Inhalte schlagen nachträgliche Optimierung
Was für das Rendering gilt, gilt genauso für das Content-Management. Wer Inhalte in Sanity strukturiert – mit definierten Feldern für Titel, Beschreibung, Slug, kanonische URL, Open-Graph-Daten und Portable Text für den Body – hat alles, was er für SEO braucht, von Anfang an sauber getrennt und maschinell lesbar. Das ist kein Luxus, das ist Hygiene.
Der Vergleich zu WordPress macht das deutlich. WordPress-Seiten verlassen sich typischerweise auf Plugins wie Yoast oder RankMath, um SEO-Felder nachträglich ins CMS zu bringen. Das funktioniert – aber es schafft eine gefährliche Abhängigkeit: von Plugin-Updates, von Kompatibilitäten, von Datenstrukturen, die sich ändern können, ohne dass man es merkt. Ein headless CMS wie Sanity erzwingt diese Struktur von Anfang an. SEO-relevante Felder sind Teil des Schemas, nicht eines Plugins. Das ist der Unterschied zwischen Architektur und Workaround.
Technisches SEO ist Teamaufgabe
Core Web Vitals – LCP, INP, CLS – sind seit 2021 offiziell Rankingfaktor. Wer Ladezeiten, Interaktivität und Layout-Stabilität erst nach dem Launch optimiert, kämpft gegen die Architektur. Bildformate, Schriftladestrategien, Ressourcen-Priorisierung: Das sind Entscheidungen, die im Design und in der Komponentenstruktur getroffen werden – nicht in einem SEO-Audit sechs Monate später.
Für Product Manager und CTOs im Mittelstand bedeutet das: SEO muss in der Anforderungsphase auf den Tisch. Nicht als Checkbox am Ende, sondern als Qualitätsmerkmal, das über Architektur, Framework-Wahl und CMS-Struktur verhandelt wird. Wer das tut, zahlt einmal. Wer es nicht tut, zahlt zweimal – und bekommt beim zweiten Mal trotzdem nur das Mögliche, nicht das Optimale.
Was das konkret heißt, bevor Code geschrieben wird
Klärt in der Planungsphase: Welche URLs braucht ihr – und warum? Welche Inhalte müssen für Suchmaschinen sofort sichtbar sein, welche dürfen dynamisch laden? Welche Felder braucht ihr im CMS, damit Redakteure SEO-relevante Metadaten selbst pflegen können, ohne Entwickler einzuschalten? Und: Welches Framework unterstützt eure Rendering-Anforderungen von Haus aus – nicht durch nachträgliche Patches?
Diese Fragen klingen banal. In der Praxis werden sie erschreckend selten in der Planungsphase gestellt. Die Projekte, die bei uns gut laufen, sind die, bei denen der Kunde diese Fragen mitbringt – oder bereit ist, sie gemeinsam zu klären, bevor das erste Ticket erstellt wird.
