Welche verheerenden Auswirkungen ein Relaunch unter SEO-Gesichtspunkten haben kann, veranschaulicht Abbildung 1. Zu sehen sind die Auswirkungen der Neugestaltung eines Onlineshops für Mode. Gleichzeitig durchgeführt wurde der Wechsel von domain.fr auf domain.com. Die Linien zeigen die organische Sichtbarkeit bei Google, ermittelt mit dem SEO-Tool SISTRIX. Der blaue Bereich repräsentiert die .fr-Domain, der rote die neue .com-Domain. Man sieht deutlich, dass durch den Relaunch und Domainwechsel circa 66 Prozent der Sichtbarkeit verloren gingen. Und das dauerhaft. Der Traffic ging proportional zurück und damit auch der Umsatz – um etwa 37 000 Euro pro Woche. Das war 2014. Anfang 2016 gab es das Unternehmen nicht mehr, denn die Korrekturen wurden viel zu spät gestartet, und das verwendete System war nicht flexibel genug für SEO.

Abb 1: Vergleich der SEO-Sichtbarkeit von alter und neuer Website

Solche Horrorszenarien sind leider keine Einzelfälle. Wenn man beim Relaunch jedoch die wichtigsten Dinge beachtet, kann man seine Rankings stabil halten und vermutlich sogar verbessern. Wir wollen uns in diesem Artikel ansehen, welche Punkte hierbei eine Rolle spielen. Doch vorab noch ein Hinweis: SEO ist keine exakte Wissenschaft. Es geht hier vielmehr um Erfahrung, darum, Muster zu erkennen und zu nutzen sowie aus Fehlern und Experimenten zu lernen.

Die Phasen eines Relaunches aus technischer SEO-Sicht

Für Serveradministratoren und Systementwickler sind folgende Phasen des Relaunches wichtig:

• Vorbereitung

• Weiterleitungen

• Performance

• Checks kurz vor und nach dem Relaunch

Die Reihenfolge dieser Punkte ist etwas willkürlich, weil sie im Prinzip alle gleichzeitig beachtet werden müssen.

Vorbereitung

70 % Planung, 30 % Umsetzung – Vorbereitung ist das Wichtigste. Je nachdem, was für ein Projekt einem Relaunch unterzogen wird, können manche Probleme nämlich nachträglich nicht mehr oder nur über einen viel zu langen Zeitraum behoben werden. Bei der Vorbereitung geht es also darum, Informationen zu sammeln und schwerwiegende strategische Entscheidungen für die neue Website zu treffen. Neben allen technischen Systemdetails sind folgende Informationen wichtig:

• Zugang zur Google Search Console: Gibt es überhaupt einen? Wenn nicht, dann anlegen!

• Tracking/Webanalyse: Was gibt es, was soll es geben? Wie wird es im neuen System umgesetzt?

• Mehrsprachigkeit: Soll die Website in verschiedenen Sprachen angelegt werden?

• Erzeugung korrekter Canonical Tags

• Welche Seiten performen gut?

• Welche Seiten ranken gut?

• Zukünftiges URL-Schema

• Erzeugung von XML-Sitemaps

• Strukturierte Daten

• TLS-Verschlüsselung für die ganze Website

• Wie kann man zukünftig SEO-Grundlagen in den redaktionellen Workflow integrieren?

Gehen wir die hier angesprochenen Punkte nun in den folgenden Abschnitten im Detail durch.

Google Search Console und SEO-Tools

Um feststellen zu können, wie sich der Relaunch auf die Sichtbarkeit auswirkt, muss diese vor und nach dem Relaunch gemessen werden. Dafür gibt es SEO-Tools, die solche Daten ermitteln. Besonders hilfreich sind Werkzeuge, die es erlauben, ein eigenes Keyword-Set anzulegen – zusätzlich zu den Millionen Keywords, die diese Tools schon allgemein überwachen. Je früher vor dem Relaunch ein Keyword-Set im Tool der Wahl angelegt wird, desto besser bekommt man ein Gefühl dafür, was normale Schwankungen und was langfristige Veränderungen sind. Aber auch die Google Search Console zeigt durchschnittliche Positionen bei Suchanfragen an (Abb. 2). Und vor allem: In der Search Console sieht man direkte Daten von Google zu den Impressionen und Klickraten, zu Problemen mit der Website, dazu, welche Seiten auf „noindex“ stehen usw. Eine Webseite zu betreiben, ohne die GSC zu nutzen, gleicht einem Blindflug.

Abb 2: Google Search Console – hilfreiche Informationen über Probleme mit der eigenen Website

 

Bei der Search Console sollte man auch seine Sitemap(s) einreichen. Google hat Anfang 2018 die Search Console erneuert, und noch sind nicht alle Funktionen der „alten“ Search Console übertragen. Deswegen gibt es unten links den Link zurück zur alten Version. Das wichtigste fehlende Feature findet man in der alten Version unter Crawling | Abruf wie durch Google. Hier kann man für jeden URL prüfen, wie er vom Google Bot gerendert wird. Dieser crawlt Webseiten wie ein Browser – mit JavaScript, Bildern usw. Die Zeiten, als Google nur Text gelesen hat, sind lange vorbei. Wer auf seiner Seite JS-Frameworks mit clientseitigem Rendering einsetzt, kann über diese Funktion erkennen, ob der Google Bot damit zurechtkommt.

Tracking und Webanalyse

Dieser Punkt hat nicht direkt etwas mit SEO zu tun, aber die Daten aus dem Webtracking fließen natürlich in die spätere Arbeit eines SEO ein. Grundsätzlich sollte das Tracking vor dem Launch der neuen Seite bereits fehlerfrei implementiert sein, sodass in den Daten keine Lücke entsteht. Zu beachten sind hier die Anforderungen der DSGVO (Cookiehinweis, Datensparsamkeit etc.).

Mehrsprachigkeit

Aus SEO-Sicht sind mehrsprachige Webseiten das Komplizierteste, womit man es zu tun haben kann. Das liegt daran, dass hier gleich mehrere Faktoren auf einmal zusammenkommen. Der wichtigste ist die Vermeidung von doppelten Inhalten (Duplicate Content, DC) – denn die mag Google gar nicht. Google will jedes Ergebnis nur einmal anzeigen, Seiten mit (nahezu) identischen Inhalten sind daher aus Sicht der Suchmaschine völlig nutzlos. Das führt zu schlechten Rankings – oder sogar zu gar keinen. Auch 1:1-Übersetzungen sind DC. Das nächste Problem ist, dass in verschiedenen Ländern dieselbe Sprache gesprochen wird. Deutschland und Österreich, USA, England und Australien sind solche Beispiele.

Google erkennt zwar die Sprache einer Website (selbst bei falscher Sprachangabe im Quellcode), aber nicht zwingend die Region – und je nach Domainkonstrukt schon gar nicht die Zusammengehörigkeit. Und genau dafür wurde das hreflang-Tag geschaffen. Damit lassen sich im Head-Bereich einer jeden Seite die alternativen Sprachversionen definieren – inklusive Regionsangabe. Eine Angabe der Sprachversionen könnte also wie in Listing 1 aussehen.

Listing 1

<link rel=“alternate“ hreflang=“en-GB“ href=“http://www.meineseite.co.uk/en-GB/kategorie/unterkategorie/“ />
<link rel=“alternate“ hreflang=“en-US“ href=“http://www.meineseite.com/en-US/kategorie/unterkategorie/“ />
<link rel=“alternate“ hreflang=“de-DE“ href=“http://www.meineseite.de/de-DE/kategorie/unterkategorie/“ />
<link rel=“alternate“ hreflang=“de-CH“ href=“http://www.meineseite.de/de-CH/kategorie/unterkategorie/“ />

Wichtig ist, dass auf allen Seiten die hreflang-Angaben wechselseitig erfolgen. Und zwar zum korrekten, spezifischen URL, nicht nur zur Startseite. Das ist bei manchen Systemen eine harte Nuss, die man knacken muss. Da dies immens wichtig ist, sollte man sich vor dem Launch unter [1] in das Thema einlesen.

Erzeugug korrekter Canonical Tags

Ein Canonical Tag ist eine Information für den Suchmaschinenbot, welcher URL zu der Seite indexiert werden soll. Der einzige Zweck ist es, Duplicate Content zu vermeiden. Dabei gibt es folgende Probleme, von denen mindestens eines immer auftritt:

Beispiel 1: Die Seite https://www.url.de/inhalt/ ist identisch mit https://www.url.de/inhalt/?session_id=123xyz. In dem Fall sollte man immer ein Canonical Tag mit https://www.url.de/inhalt/ als kanonischem URL setzen.

Beispiel 2: Jede Seite ist unter http:// und https:// erreichbar. Daher braucht jede HTTP-Seite einen Canonical URL auf die HTTPS-Variante.

Beispiel 3: Jede Seite ist unter dem richtigen URL und zudem noch mittels eines URL mit dem Verzeichnis / cms/ erreichbar. Daher erfolgt hier im Canonical Tag der Verweis auf den URL ohne /cms/.

Ein Canonical Tag befindet sich im Head jeder Seite und ist relativ simpel:

<link rel=”canonical” href=”https://www.domain.de/richiger-url”>

Es schadet nicht, bei den Seiten mit korrektem URL ein Canonical auf „sich selbst“ zu setzen. Auch ist es hilfreich, das System so zu gestalten, dass man gelegentlich die automatisch erzeugten Canonical Tags manuell überschreiben kann. Das ist zwar selten erforderlich, wenn aber doch, ist es meist wichtig. Ein Canonical soll auch keine Weiterleitung ersetzen (z. B. von domain.de auf www.domain.de). Und ganz wichtig: Canoncial Tags „vererben“ die meta-robots-Einstellung auf den URL, auf den verwiesen wird. Ist eine Seite auf noindex konfiguriert und hat einen Canonical auf einen anderen URL, kann es passieren, dass der Google Bot auch dort noindex anwendet, selbst wenn die Seite unter dem Canonical URL anders konfiguriert ist. Noch etwas komplizierter wird es dann bei paginierten Seiten. Darauf einzugehen, wäre jedoch ein Artikel für sich. Für wen dieses Thema relevant ist, der kann (und sollte) sich vor einem Relaunch unter [2] eingehender informieren.

Welche Seiten performen gut/ranken gut?

In jedem Webprojekt gibt es Websites, die sich in Sachen Conversion, Traffic und/oder Ranking als Highlights herauskristallisieren, während ein Großteil der Seiten eher mittelmäßig performt. Diese Highlightseiten gilt es vor dem Relaunch zu identifizieren und danach akribisch zu beobachten. Ein Rankingverlust bei unwichtigen Seiten ist weniger tragisch. Ein Rankingverlust bei der wichtigsten Kategorieseite kann massive Umsatzverluste bedeuten.

Zukünftiges URL-Schema

Das ideale URL-Schema ist: www.domain.de/hauptthema/unterthema/…/detailseite/. Gegebenenfalls wird dieses Schema um ein Sprachverzeichnis ergänzt, also www.domain.de/de-DE/hauptthema/unterthema/…/detailseite/. Dieses URL-Schema eignet sich gut, um die gewünschten Keywords in dem URL unterzubringen (auch wenn das als SEO-Faktor nicht mehr so wichtig ist). In jedem Fall ist es für Nutzer leicht verständlich. Bei einem Onlineshop wäre das perfekte URL-Schema also www.shop.de/oberkategorie/unterkategorie/…/produkt-123/ – richtig? Nein! In der Praxis funktioniert das leider nicht so einfach, denn fast jeder Shop verfügt über Mehrfachkategorisierungen. Das bedeutet, dass dieselben Produkte beispielsweise unter Herren | Hosen | Anzughosen und unter Herren | Anzüge | Anzughosen zu erreichen sind. Welchen URL bekommt das Produkt dann? Die Antwort lautet: einen einmaligen. Von www.shop.de/herren/hosen/anzughosen/ wechselt man per Klick auf www.shop.de/anzughose-xyz/. Sie sehen, das URL-Schema ist immens wichtig. Und wo wir gerade bei Shops sind: Fügen Sie Ihren Kategorie-URLs ein Pseudoverzeichnis wie /c/ und Ihren Produkt-URLs eines wie /p/ hinzu. Dann kann man in der Auswertung der Webtrackingdaten besser segmentieren. Das freut die Kollegen aus dem Onlinemarketing. URL-Schemata sind also für viele Unternehmensbereiche relevant. Bedenken Sie bei der Erstellung des Schemas also Folgendes:

1. Sprechen Sie mit allen Beteiligten, welche Wünsche und Anforderungen sie haben.

2. Machen Sie bei Gesprächen über das URL-Schema klar, dass dieses in Stein gemeißelt ist und nie wieder geändert werden darf (dazu später mehr).

3. Ziehen Sie Sprachverzeichnisse in Betracht – auch wenn Sie erst einmal nur mit einer Sprache starten.

Erzeugung von XML-Sitemaps

Eine Sitemap ist für Suchmaschinen eine wichtige Datei. In ihr sind alle URLs aller Unterseiten enthalten. Somit findet die Suchmaschine auch Seiten, die über das übliche Crawling der internen Links nicht gefunden werden. Für Sitemap-Dateien gibt es zwei Beschränkungen: maximal 10 MB und maximal 50 000 URLs. Für große Webseiten wie Onlineshops kann man die Sitemaps daher in mehrere Dateien aufteilen (zum Beispiel eine Datei pro Hauptkategorie). Dann braucht man nur noch eine Index-Sitemap, die auf die untergeordneten Sitemaps verweist. Die oberste Sitemap wird dann bei der Google Search Console eingereicht. Solche hierarchischen Sitemaps erzeugt zum Beispiel das Yoast SEO Plug-in für WordPress. Die Erzeugung der Sitemaps muss bei jeder Änderung an der Website vollautomatisch erfolgen.

Strukturierte Daten

Um es Suchmaschinen so einfach wie möglich zu machen, den Inhalt einer Seite zu verstehen, sollte man, wenn möglich, strukturierte Daten implementieren. Genauer gesagt: nach Schema.org strukturierte Daten, möglichst im JSON-LD-Format im Head. Schemata gibt es viele, und nur eine Handvoll davon dürften für Ihre Website wichtig sein. Die am häufigsten verwendeten sind wahrscheinlich Breadcrumb, Product, Address, Organisation, Events. Grundsätzlich gilt: Strukturierte Daten müssen fehlerfrei sein. Testen können Sie das mit einem Tool von Google, das unter [3] zur Verfügung steht.

Idealerweise generieren Sie die Daten aus bereits bestehenden Daten Ihres Systems. Wenn nicht, sollten Sie im Backend entsprechende Felder dafür schaffen. Auch die Implementierung von Facebook-Open-Graph- und Twitter-Card-Schemata kann sinnvoll sein.

TLS-Verschlüsselung der ganzen Seite

Bezüglich https:// gibt es aus SEO-Sicht nur eines zu schreiben: Es ist zwingend notwendig – ohne Wenn und Aber. Seiten ohne HTTPS-Verschlüsselung werden von Google schlechter gerankt. In Anbetracht der günstigen Preise für Zertifikate (gratis bei https://letsencrypt.org) gibt es hier keine wirtschaftlichen Hindernisse.

SEO in den redaktionellen Workflow integrieren

Dieser Punkt ist schwer zu verallgemeinern. Zum einen, weil Sie als Entwickler mit dem Inhalt nichts am Hut haben, zum anderen, weil es sehr unterschiedliche Anforderungen gibt. Eine Newsseite hat andere SEO-Bedürfnisse als ein Onlineshop, der seine Produktdaten vielleicht sogar aus einem externen System importiert. Allgemein empfehlen wir Folgendes:

• Geben Sie den Redakteuren im Backend die Möglichkeit, die Meta Description zu verändern.

• Entfernen Sie Meta Keywords (die sind schon sehr lange kein Faktor mehr).

• Bauen Sie ein sinnvolles Template für den Meta Titel, das ggf. manuell überschrieben werden kann. Zum Beispiel [Seitentitel] | [Marke oder Domain].

• Der Titel der Seite sollte die einzige H1-Headline sein. Entfernen Sie im Backend die Möglichkeit, H1-Überschriften im Editor einzufügen. Oder schulen Sie alle Personen mit redaktionellem Zugriff, dass es nur eine H1 pro Seite geben darf.

• Schaffen Sie eine Möglichkeit, die ALT-Attribute von Bildern zu bearbeiten. Idealerweise haben alle Bilder einen sprechenden Dateinamen.

Weiterleitungen

Weiterleitungen sind der allerwichtigste Punkt bei einem Relaunch. Denn hier schlummert das größte Fehlerpotenzial. Eigentlich sollten sich URLs niemals ändern, aber bei einem Relaunch lässt sich das nicht vermeiden. Vielleicht verbessern sich die URLs sogar. Das bedeutet zwangsläufig: Unter den alten URLs vor dem Relaunch sind die Seiten nicht mehr erreichbar – es entstehen 404-Fehler bei Seiten, die Google seit Jahren kennt und liebt. Die Lösung klingt erst einmal simpel: Alle alten URLs per Serverkonfiguration auf den neuen URL weiterleiten und dazu den Statuscode 301 übermitteln. Letzteres ist aus SEO-Sicht sehr wichtig: Bei Weiterleitungen unbedingt 301 als Statuscode ausliefern, keinen anderen.

Der Teufel steckt aber im Detail. Zum einen ist wichtig zu wissen, dass die Weiterleitungen in der .htaccess (oder nginx.conf) der Reihe nach abgearbeitet werden. Falls beim Testen von Weiterleitungen einmal etwas nicht so funktioniert, wie es soll, schauen Sie sich die Reihenfolge an. Grundsätzlich kann man sagen, es geht vom Allgemeinen ins Detail. Das bedeutet: zuerst die Weiterleitungen von HTTP nach HTTPS und ggf. von nicht-www. zu www. Bei Apache sieht das in der .htaccess so aus:

RewriteEngine on
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule (.*) https://www.example.com%{REQUEST_URI} [R=301,L]

Bei dieser Variante erfolgt für beides übrigens nur eine Weiterleitung – die meisten Webmaster machen zwei Weiterleitungen hintereinander; erst https, dann www. Davon merkt der User nichts, aber wer Webseiten mit hohem Traffic betreibt, sollte jeden Request sparen, den man sparen kann.

Darauf folgen die Weiterleitungen von Verzeichnisänderungen (z. B. /produkte/ à /kollektionen/) und danach spezielle Weiterleitungen. Die Weiterleitungen von Verzeichnissen kann man meist mit RegEx ganz gut lösen; hier ein Beispiel aus der Praxis (nginx):

rewrite ^/..../../../(.*)$ https://www.domain.de/$1 permanent;

Das Beispiel stammt aus einem WordPress-Relaunch. Die alten Blogartikel-URLs waren noch nach diesem Schema aufgebaut: www.domain.de/YYYY/MM/TT/blogartikel. Das neue Schema verzichtet auf die unnötigen Jahres-, Monats- und Tagesverzeichnisse (die auch alle von Suchmaschinen gecrawlt werden würden). Dafür war eine Weiterleitung für alle alten Blogartikel notwendig. Diese kann mit nur einer Zeile erreicht werden. Theoretisch hätte man auch jeden URL individuell weiterleiten können, aber das hat zwei Nachteile: Erstens müsste man sämtliche Weiterleitungen erstellen und zweitens sollte eine Serverkonfigurationen mit vielen Weiterleitungen vermieden werden. Wenn mehrere tausend Weiterleitungen hinterlegt werden, prüft der Server jeden Request auf alle möglicherweise passenden Weiterleitungen ab. Dadurch geht die Performance in den Keller. Wer sich mit RegEx (Regular Expressions) nicht so gut auskennt, kann auf folgender Seite experimentieren: https://regexr.com/. Hier zeigt sich auch, warum, wie oben erwähnt, das URL-Schema nie wieder geändert werden sollte. Wenn Ihnen ein paar Monate nach dem Relaunch auffällt, dass Ihre URLs nicht zweckmäßig sind, müssten Sie noch viel mehr Umleitungen einrichten – erst die von der alten Seite und dann nochmals die vom ersten URL-Schema nach dem Launch.

Sehr schwierig ist es, wenn eine sehr große Seite relauncht werden soll, die vorher keine sprechenden URLs hatte, sondern nur Parameter. Beispielsweise von www.domain.de/index.php?p=1 bis www.domain.de/index.php?p=142354. Man kann weder mit RegEx arbeiten noch über 140 000 manuelle Weiterleitungen anlegen. Hier kommt die Liste der wichtigen Seiten von weiter oben ins Spiel. Leiten Sie die wichtigen Seiten mit manuellen Einträgen um. Wichtig sind zum einen die ermittelten Seiten aus der Vorbereitung, zum anderen auch die weiterhin bestehenden Oberseiten wie Kategorien oder die Jobseite. Unwichtig hingegen sind vor allem alte News (es sei denn, sie sind auf der Liste) und paginierte Auflistungen. Hier ist es nicht schlimm, wenn diese beim Relaunch von Google nicht wieder nahtlos indexiert werden. Irgendwann wird die Suchmaschine sie auch so wiederfinden (über Verlinkung und Sitemap) und einfach neu bewerten. Hinweis: Die Sichtbarkeit in den SEO-Tools wird dann sinken. Die Sichtbarkeit ist eine quantitative, keine qualitative Kennzahl. Sehr viele Seiten im Index ergeben eine hohe Sichtbarkeit, egal wie schlecht sie im Einzelnen ranken. Kritisch ist das Ranking der wichtigen Seiten in den SEO-Tools bzw. in der Google Search Console. Alle nicht weitergeleiteten Seiten liefern dem User und der Suchmaschine einen 404-Statuscode. Daher: Nutzen Sie Ihre 404-Seite! Sie muss nicht weiß bleiben. Als Shop positionieren Sie Ihre Bestseller oder aktuelle Angebote. Als Firmenseite verlinken Sie Ihre wichtigsten Produkte oder Leistungen. Bauen Sie ein Suchfeld ein, damit die User auf der Seite nochmals nach dem suchen, was sie auf Google zu finden gehofft hatten.

Performance

Geschwindigkeit ist ein Rankingfaktor bei Google. Wie genau sich die Ladezeit auf das Ranking auswirkt, verrät uns Google aber nicht wirklich – die Aussagen zu dem Thema sind schwammig. Aber auch unabhängig von SEO-Aspekten sollte man einen Relaunch dazu nutzen, die Ladezeiten der neuen Webseite zu optimieren. Bei einer Ladezeit von über drei Sekunden steigt die Absprungrate signifikant. Der Grundsatz lautet: „So wenig Daten wie nötig so schnell wie möglich übertragen.“ Aber nicht nur die reine Datenmenge ist ein Problem, sondern auch die Menge an Requests. Und die Zeit, die ein Browser benötigt, eine Seite zu rendern. Serverseitig empfehlen wir nginx statt Apache. Der Server sollte das HTTP/2-Protokoll unterstützen, das einige Geschwindigkeitsfeatures bietet. Komprimierung mittels gzip oder Brotli ist natürlich obligatorisch. Dynamisch generierte Seiten sollten gut gecached werden – wenn es die Ressourcen und der Server zulassen, dann sogar im RAM mittels Memcache. Statische Ressourcen sollten eine hohe Browsercache-Lebensdauer haben. Gemeint sind damit Bilder, JavaScript und CSS-Dateien, die sich selten ändern und somit lange im lokalen Browsercache des Nutzers verbleiben können. Wer internationale Besucher hat, sollte sich mit dem Thema Content Delivery Network beschäftigen. Diese weltweiten CDNs werden per DNS zwischen den Client und dem Webserver geschaltet und liefern automatisch die statischen Dateien von dem Rechenzentrum, das für den Client am schnellsten ist.

Aber auch in der Programmierung der Seite gibt es viel Optimierungspotenzial: etwa das Zusammenfassen von JS- und CSS-Dateien, das Lazy Loading von Bildern, die noch nicht im Viewport sind usw. Für WordPress gibt es hier ein praktisches Plug-in namens Autooptimize. Alle Optimierungspotenziale für seine Seite kann man sich mit Tools wie www.webpagetest.org oder https://gtmetrix.com anzeigen lassen. Google bietet unter [4] ein eigenes Tool an. Das Google-Tool ist allerdings weniger hilfreich bei der Behebung der Probleme. Bei allen Tools gilt, dass man sich nicht zu sehr auf die Ladezeit in Sekunden fixieren sollte. Zwei direkt aufeinanderfolgende Tests mit demselben Tool ergeben da schon mal Messtoleranzen von über einer Sekunde. Die Google-Tools liefern zwei Werte zwischen 0 und 100 – für die Desktopvariante und die mobile Variante. Letztere simuliert ein Smartphone der Mittelklasse mit schlechter Datenverbindung. Daher weichen die beiden Werte stark voneinander ab.

Folglich sollte dem Mobile-First-Paradigma entsprochen werden. Mehr als die Hälfte aller Google-Suchanfragen kommen von Smartphones. Also sollte eine Website für diese Geräte optimiert werden, nicht für Quadcore-Desktop-CPUs mit Breitband-Internetanschlüssen.

Checks kurz vor und nach dem Relaunch

Zum Abschluss noch einmal eine Liste der wichtigen Punkte, die man im Auge behalten muss:

• robots.txt (alle wichtigen Verzeichnisse crawlbar?)

• GSC Property bestätigen, Probleme beobachten

• Irgendwo noindex gesetzt? Wenn ja, gewollt?

• Weiterleitungen prüfen (mit 301-Status)

• XML-Sitemap in Stichproben prüfen und in Search Console einreichen

• Pagespeed regelmäßig?

• Funktioniert das Responsive Design?

• Tracking-Codes korrekt implementiert?

• 404-Crawling-Fehler?

• Search Console und Analytics im Auge behalten (Userzahlen, Traffic-Einbrüche?)

• Rankings der (wichtigsten) Keywords und Seiten beobachten

• 500er Serverfehler?

Behalten Sie diese Punkte im Auge, sollte einem Relaunch ohne Rankingverluste nichts im Wege stehen.