SEO-freundliches Webdesign: Was Design- und Entwicklungsteams von Anfang an richtig machen sollten – vom Konzept bis zum Relaunch

Viele SEO-Probleme, die wir in Audits finden, wurden nicht nach dem Launch verursacht, sondern lange davor: im Wireframe, im Designsystem, in der Wahl des Frameworks oder in der Weiterleitungstabelle, die beim Relaunch niemand gepflegt hat. SEO-freundliches Webdesign heißt, Suchmaschinen und Menschen von Anfang an als Nutzer der Website mitzudenken – nicht, nachträglich Keywords in fertige Seiten zu schreiben.

Dieser Leitfaden richtet sich an Projektteams aus Marketing, Design und Entwicklung, die eine Website neu bauen oder relaunchen. Er zeigt, welche Anforderungen in welcher Projektphase anstehen, worauf Google laut eigener Dokumentation bei Links, JavaScript, mobilen Seiten, Ladezeit und Bildern achtet und wie ein Relaunch gelingt, ohne die bestehende Sichtbarkeit zu riskieren.

Vertiefung: Websites & Webshops von YellowFrog · Technical SEO

Warum SEO in Design und Entwicklung gehört

Suchmaschinenoptimierung beginnt bei der Architektur einer Website, weil Google nur bewerten kann, was es erreicht, rendert und versteht.

Google formuliert den Grundgedanken im SEO-Starter-Guide so: Google sollte eine Seite idealerweise genauso sehen wie ein durchschnittlicher Nutzer und braucht dafür Zugriff auf dieselben Ressourcen wie der Browser. Prüfen lässt sich das mit dem URL-Prüftool der Search Console. Was im Design verborgen, nur per Klick nachgeladen oder auf dem Smartphone weggelassen wird, ist für Google im Zweifel nicht vorhanden.

In unserer Projekterfahrung ist es um ein Vielfaches aufwendiger, eine fertige Website nachträglich suchmaschinenfreundlich umzubauen, als die Anforderungen im Konzept festzuhalten. Die folgende Übersicht zeigt, was in welcher Phase ansteht:

Informationsarchitektur und Navigation

Eine gute Informationsarchitektur sorgt dafür, dass jede wichtige Seite über Links erreichbar ist und dass thematisch zusammengehörige Seiten auch strukturell zusammenstehen.

Google findet Seiten laut SEO-Starter-Guide vor allem über Links von anderen Seiten, die es bereits gecrawlt hat. In der Dokumentation zu crawlbaren Links heißt es entsprechend, dass jede Seite, die Ihnen wichtig ist, von mindestens einer anderen Seite Ihrer Website verlinkt sein sollte. Für das Konzept bedeutet das: Planen Sie Navigation, Hub-Seiten und Querverlinkungen bewusst, statt wichtige Seiten nur über die interne Suche oder Filter erreichbar zu machen.

Auch die Gliederung in Verzeichnisse hat einen Nutzen. Google schreibt im Starter-Guide, dass es lernen kann, wenn thematisch ähnliche Seiten in Verzeichnissen gruppiert sind, und die Verzeichnisse dann unterschiedlich häufig crawlen kann. Für Unternehmenswebsites ist eine Gliederung wie /leistungen/, /ratgeber/ und /referenzen/ deshalb nicht nur für Menschen übersichtlich. Für Linktexte empfiehlt Google Formulierungen, die beschreibend, angemessen kurz und relevant für die verlinkende und die verlinkte Seite sind – „Mehr erfahren“ als einziger Linktext auf einer Seite erfüllt das nicht.

Links, denen Google folgen kann

Google kann einen Link in der Regel nur crawlen, wenn er als HTML-Element <a> mit einem href-Attribut umgesetzt ist, das auf eine auflösbare URL zeigt.

Moderne Frontends bauen Navigation häufig mit Click-Handlern, Buttons oder Framework-Komponenten. Google listet in seiner Dokumentation mehrere Muster als „nicht empfohlen“ auf und merkt an, dass es dennoch versuchen kann, sie auszuwerten. Ein Vergleich:

<!-- empfohlen -->
<a href="https://www.example.com/leistungen/waermepumpen">Wärmepumpen im Überblick</a>

<!-- laut Google nicht empfohlen -->
<a onclick="goto('/leistungen/waermepumpen')">Wärmepumpen</a>
<a href="javascript:goTo('waermepumpen')">Wärmepumpen</a>
<span href="https://www.example.com/leistungen/waermepumpen">Wärmepumpen</span>

Unsere Erfahrung: Gängige Frameworks erzeugen mit ihren Link-Komponenten echte <a href>-Elemente – entscheidend ist, dass das Team sie auch verwendet und nicht für Navigation auf Buttons ausweicht.

JavaScript und Rendering

Google verarbeitet JavaScript-Websites in drei Phasen – Crawling, Rendering und Indexierung –, und die Rendering-Strategie entscheidet mit darüber, wie schnell und zuverlässig Inhalte im Index landen.

Laut Googles JavaScript-SEO-Grundlagen rendert Google Seiten mit einer aktuellen Chrome-Version. Trotzdem bezeichnet Google serverseitiges Rendering oder Pre-Rendering weiterhin als gute Idee, weil es die Website für Nutzer und Crawler schneller macht und nicht alle Bots JavaScript ausführen. Für Entwicklungsteams ergeben sich aus der Dokumentation vier konkrete Regeln:

• Eigene URLs per History API: Für das Routing zwischen Ansichten einer Web-App empfiehlt Google die History API statt Fragmenten nach dem Rautezeichen.
• Eindeutige Title und Descriptions: Jede Ansicht braucht ein beschreibendes Title-Element und eine eigene Meta-Description; JavaScript darf beides setzen.
• Aussagekräftige Statuscodes: Googlebot nutzt HTTP-Statuscodes, um zu erkennen, ob beim Crawlen etwas schiefgegangen ist – etwa 404 für nicht vorhandene Seiten.
• Keine Soft-404-Fehler: Bei clientseitigem Routing empfiehlt Google, Fehlerseiten entweder per JavaScript auf eine URL mit echtem 404-Status weiterzuleiten oder ihnen per JavaScript ein noindex-Meta-Tag zu geben.

Ob eine Website serverseitig, statisch oder clientseitig rendert, ist eine Architekturentscheidung, die sich später kaum noch ändern lässt. Gehört Sichtbarkeit in der Suche zu den Projektzielen, sollte diese Frage deshalb vor der Wahl des Frameworks geklärt sein – das ist unsere Praxisempfehlung.

Mobile First: Die Smartphone-Version ist die maßgebliche

Google verwendet für Indexierung und Ranking die mobile Version einer Website, gecrawlt mit dem Smartphone-Agent – was dort fehlt, fehlt für Google.

In den Best Practices zur Mobile-First-Indexierung empfiehlt Google responsives Webdesign, weil es das am einfachsten umzusetzende und zu pflegende Muster ist. Wer dennoch getrennte Varianten ausliefert oder Inhalte mobil kürzt, sollte die Gleichwertigkeit beider Versionen sicherstellen. Google nennt dafür unter anderem:

• denselben Inhalt auf der mobilen Seite wie auf der Desktop-Seite,
• dieselben klaren und aussagekräftigen Überschriften,
• dieselben strukturierten Daten sowie gleichwertige Title und Meta-Descriptions,
• dieselben Alt-Texte für Bilder und dieselben robots-Meta-Tags,
• keine Hauptinhalte, die erst nach einer Nutzerinteraktion per Lazy Loading geladen werden.

Für das Design heißt das nach unserer Einschätzung: Akkordeons und Tabs sind unkritisch, solange der Inhalt beim Laden im Code vorhanden ist. Kritisch wird es, wenn mobile Layouts ganze Textblöcke, Tabellen oder Bilder weglassen, die am Desktop vorhanden sind.

Performance: Core Web Vitals als Designvorgabe

Die Core Web Vitals messen Ladegeschwindigkeit, Reaktionsfähigkeit und visuelle Stabilität einer Seite und lassen sich am wirksamsten schon im Design berücksichtigen.

Laut web.dev gelten folgende Schwellenwerte als gut; gemessen wird sinnvollerweise das 75. Perzentil der Seitenaufrufe:

Die Hebel in der letzten Spalte sind unsere Praxiserfahrung, keine Liste von Google. Laut Googles Leitfaden zu hilfreichen Inhalten möchten die Kernsysteme Inhalte belohnen, die eine gute Nutzererfahrung bieten; Website-Betreiber sollten dabei auf eine insgesamt gute Erfahrung achten statt nur auf ein oder zwei Aspekte. Core Web Vitals sind also ein wichtiger Baustein, aber kein Selbstzweck.

Bilder richtig einbinden

Bilder werden für Google am zuverlässigsten auffindbar, wenn sie als standardmäßiges HTML-Bildelement eingebunden sind – Bilder aus CSS indexiert Google nicht.

Googles Best Practices für Bilder geben Designern und Entwicklern klare Vorgaben: Google unterstützt Bilder im src-Attribut des img-Elements in den Formaten BMP, GIF, JPEG, PNG, WebP, SVG und AVIF. Dateinamen sollten nach Möglichkeit kurz, aber beschreibend sein. Alt-Texte sollen nützlich und informativ sein; Alt-Attribute mit Keywords zu füllen, sieht Google dagegen kritisch. Mit dem srcset-Attribut lassen sich unterschiedliche Versionen desselben Bildes für verschiedene Bildschirmgrößen angeben, und laut JavaScript-SEO-Grundlagen ist Lazy Loading eine gute Strategie, um Bilder erst dann zu laden, wenn Nutzer sie gleich sehen. Wie Bilder auch für KI-Systeme verständlich werden, beschreibt unser Beitrag Bild-SEO für KI.

Semantisches HTML und Barrierefreiheit

Semantisches HTML und Barrierefreiheit verfolgen dasselbe Ziel wie SEO: Inhalte so auszuzeichnen, dass Maschinen ihre Struktur und Bedeutung erkennen können.

Der internationale Standard dafür sind die Web Content Accessibility Guidelines des W3C. Laut W3C Web Accessibility Initiative ist WCAG 2.2 im Oktober 2023 veröffentlicht worden; die Richtlinien sind nach vier Prinzipien gegliedert – wahrnehmbar, bedienbar, verständlich und robust – und ihre Erfolgskriterien drei Konformitätsstufen A, AA und AAA zugeordnet. Für Unternehmen im deutschen Markt kommt eine rechtliche Dimension hinzu: Das Barrierefreiheitsstärkungsgesetz gilt nach § 1 unter anderem für Dienstleistungen im elektronischen Geschäftsverkehr, die nach dem 28. Juni 2025 für Verbraucher erbracht werden. Ob und in welchem Umfang Ihre Website darunter fällt, sollten Sie rechtlich prüfen lassen.

In der Umsetzung überschneiden sich Barrierefreiheit und SEO stark: echte Überschriften statt fett formatierter Absätze, Listen als Listen, Tabellen als Tabellen, Navigation in einem nav-Element, aussagekräftige Linktexte und Alt-Texte. Wer diese Grundlagen im Designsystem verankert, gewinnt doppelt.

Staging, robots.txt und der Launch

Test- und Staging-Umgebungen gehören hinter einen Passwortschutz, nicht nur hinter eine robots.txt-Sperre.

Google schreibt in der Einführung zu robots.txt, dass die Datei kein Mechanismus ist, um eine Webseite aus Google herauszuhalten, und dass eine gesperrte URL trotzdem indexiert werden kann, wenn sie anderswo verlinkt ist. Um Seiten sicher herauszuhalten, nennt Google noindex oder einen Passwortschutz. Umgekehrt sollten Sie auf der Live-Website keine CSS- oder JavaScript-Dateien sperren, wenn Google die Seite ohne sie schlechter verstehen würde. Ein Klassiker aus unseren Relaunch-Projekten: Die Sperre der Staging-Umgebung wird beim Launch mit auf die Live-Website kopiert. Prüfen Sie robots.txt und robots-Meta-Tags deshalb am Launch-Tag als Erstes.

Relaunch ohne Sichtbarkeitsverlust

Ein Relaunch mit neuen URLs ist für Google ein Website-Umzug, und dessen Erfolg hängt fast vollständig an einer sauberen Zuordnung alter zu neuen URLs.

Googles Anleitung zum Website-Umzug mit URL-Änderungen beschreibt die wesentlichen Schritte. Daraus ergibt sich diese Reihenfolge:

1. URL-Zuordnung erstellen

Google bezeichnet es als wichtig, die URLs der alten Website den URLs der neuen Website zuzuordnen. Erfassen Sie dafür alle bestehenden URLs – insbesondere die mit Impressionen, Klicks oder externen Links – und legen Sie für jede das passende neue Ziel fest.

2. Serverseitige permanente Weiterleitungen

Google empfiehlt serverseitige permanente Weiterleitungen von den alten auf die neuen URLs gemäß dieser Zuordnung. Weiterleitungsketten sollten Sie vermeiden und direkt auf das endgültige Ziel weiterleiten. Die Weiterleitungen sollten so lange wie möglich bestehen bleiben, in der Regel mindestens ein Jahr.

3. Interne Signale aktualisieren

Interne Links sollen laut Google auf die neuen URLs zeigen, Canonical-Angaben auf der neuen Website die neuen URLs verwenden und alle Sitemaps die neuen URLs enthalten. Interne Links über Weiterleitungen sind ein häufiger Rest alter Strukturen.

4. Testen und Erwartungen klären

Google rät, die neue Website gründlich vorzubereiten und die Weiterleitungen zu testen. Gleichzeitig sollten alle Beteiligten wissen: Laut Google ist während eines Umzugs mit vorübergehenden Ranking-Schwankungen zu rechnen, und bei mittelgroßen Websites kann es einige Wochen oder länger dauern, bis Google nach und nach die neuen URLs zeigt.

Wenn Sie vor einem Relaunch eine Bestandsaufnahme wünschen, deckt ein SEO-Audit die Risiken der bestehenden Website auf, und unsere OnPage-Optimierung sorgt dafür, dass die neuen Seiten inhaltlich zu den Suchanfragen passen.

Häufige Fragen

Was ist SEO-freundliches Webdesign?

SEO-freundliches Webdesign bedeutet, eine Website so zu konzipieren, zu gestalten und zu programmieren, dass Suchmaschinen alle wichtigen Inhalte finden, rendern und verstehen können und dass Menschen sie auf jedem Gerät gut nutzen können. Dazu gehören unter anderem crawlbare Links, eine klare Seitenstruktur, gleichwertige Inhalte auf Smartphone und Desktop sowie gute Ladezeiten.

Ist eine JavaScript-Website schlecht für SEO?

Nicht grundsätzlich. Google rendert Seiten beim Crawlen und führt JavaScript mit einer aktuellen Chrome-Version aus. Google bezeichnet serverseitiges Rendering oder Pre-Rendering aber weiterhin als gute Idee, weil es die Website für Nutzer und Crawler schneller macht und nicht alle Bots JavaScript ausführen. Wichtig sind außerdem echte Links, eigene URLs per History API und korrekte HTTP-Statuscodes.

Was bedeutet Mobile-First-Indexierung für das Design?

Google verwendet für Indexierung und Ranking die mobile Version einer Website, gecrawlt mit dem Smartphone-Agent. Inhalte, Überschriften, strukturierte Daten, Title und Meta-Description sowie Alt-Texte sollten deshalb auf Smartphone und Desktop gleichwertig sein. Google empfiehlt responsives Webdesign, weil es am einfachsten umzusetzen und zu pflegen ist.

Welche Werte sollten die Core Web Vitals erreichen?

Als gut gelten laut web.dev ein Largest Contentful Paint innerhalb von 2,5 Sekunden, ein Interaction to Next Paint von höchstens 200 Millisekunden und ein Cumulative Layout Shift von höchstens 0,1. Gemessen wird dabei sinnvollerweise das 75. Perzentil der Seitenaufrufe.

Wie lange sollten Weiterleitungen nach einem Relaunch bestehen bleiben?

Google empfiehlt, Weiterleitungen so lange wie möglich beizubehalten, in der Regel mindestens ein Jahr. Verwenden Sie serverseitige permanente Weiterleitungen von jeder alten URL direkt auf die passende neue URL und vermeiden Sie Weiterleitungsketten.

Reicht robots.txt, um eine Staging-Umgebung aus Google herauszuhalten?

Nein. Google schreibt, dass robots.txt kein Mechanismus ist, um eine Webseite aus Google herauszuhalten, und dass gesperrte URLs trotzdem indexiert werden können, wenn sie anderswo verlinkt sind. Für Test- und Staging-Umgebungen ist ein Passwortschutz der sichere Weg.

Fazit: SEO ist eine Anforderung, kein Nachtrag

Eine Website ist dann suchmaschinenfreundlich, wenn Google sie so sieht wie ein Mensch: über echte Links erreichbar, vollständig gerendert, auf dem Smartphone gleichwertig, schnell und sauber ausgezeichnet. Diese Eigenschaften entstehen in Konzept, Design und Code – und beim Relaunch in der Weiterleitungstabelle. Wer sie als Anforderung ins Lastenheft schreibt, spart sich teure Nacharbeit und schützt die Sichtbarkeit, die eine Website über Jahre aufgebaut hat.

• Struktur planen: Jede wichtige Seite ist von mindestens einer anderen Seite verlinkt, Themen sind in Verzeichnissen gruppiert.
• Echte Links: Navigation als <a href>, nicht als Button oder Click-Handler.
• Rendering klären: Serverseitiges Rendering oder Pre-Rendering bevorzugen, History API, korrekte Statuscodes.
• Mobile ist maßgeblich: Inhalte, Überschriften, Daten und Alt-Texte mobil vollständig.
• Performance als Vorgabe: LCP bis 2,5 s, INP bis 200 ms, CLS bis 0,1.
• Relaunch absichern: URL-Zuordnung, direkte 301-Weiterleitungen für mindestens ein Jahr, interne Signale aktualisieren.