Home / Leistungen / SEO / SEO Relaunch / SEO Relaunch Checkliste

SEO Relaunch Checkliste - Erfolg ist planbar

Der Relaunch einer Website ist meist mit einem großem Arbeitsumfang, hohen Erwartungen und einem sehr engen Zeitplan verbunden. Häufig wirken viele verschiedene Menschen und nicht selten auch mehrere Agenturen an einem solchen Projekt mit – da ist gute Planung wichtig! Zudem können sich bei Ihrem Relaunch-Projekt immer auch mal kleine Fehler einschleichen, die dazu führen, das gute Rankings verloren gehen oder sich deutlich verschlechtern.

Ein neues Content-Management-System, wechselnde URLs, neue Inhalte-Strukturen, veränderte Templates und Inhalte – ein Relaunch bietet so einige Herausforderungen und potenzielle Fallstricke. Doch auch kleine handwerkliche Fehler können den Wechsel von der alten Website zur neuen Webseite erschweren oder bestehende Google-Rankings gefährden. Es empfiehlt sich daher insbesondere in der Relaunch-Phase, also bei der Umstellung auf die neue Website, besonders vorsichtig zu agieren, um Fehler zu vermeiden.

Doch mit guter Planung und einem kontrollierten Projektablauf bekommen Sie Ihr Relaunch-Projekt auch in Sachen SEO in den Griff und mit einer professionellen Checkliste für den Relaunch können Sie die typischen Fehler leicht vermeiden!

Profitieren Sie jetzt von einem kompetenten SEO-Partner im Rhein-Main-Gebiet - Ob in Darmstadt, Frankfurt, Mainz, Wiesbaden oder der kompletten DACH-Region - wir sind für Sie da!

Profitieren Sie bei Ihrem Relaunch von unserer Checkliste

Der Relaunch einer neuen Website ist meist schon ein größeres Projekt. Neue Ziele, neues Design, neue oder modifizierte Inhalte, eine veränderte URL-Struktur, vielleicht auch eine veränderte technische Basis? Alle diese Änderungen stellen auch an den Relaunch-Prozess erhöhte Anforderungen im Kontext von SEO!

Vermeiden Sie beim Relaunch grobe SEO-Fehler und sichern Sie Ihre Rankings! Mit unserer kostenlosen SEO-Relaunch-Checkliste haben Sie in Sachen SEO für Ihre Website alles im Griff.

Unsere Relaunch-Checkliste ist chronologisch aufgebaut und orientiert sich an den erforderlichen Schritten eines Relaunch-Projektes. Wir behandeln in dieser Liste nicht die SEO-Konzeption (Keyword-Strategie, Informationsarchitektur, Content-Strategie und Erstellung) und auch nicht das Anforderungsmanagement während der Design- und Entwicklungsphase. In unserer Liste geht es um die wichtigen Aspekte rund um den Relaunch selbst, also die Umschaltung von der alten auf die neue Website.

Wir erklären Ihnen nachfolgend, was Sie in den einzelnen Phasen beachten sollten und welche Dinge aus SEO-Sicht erforderlich sind, damit Ihre Website mit dem Relaunch ein voller Erfolg wird.

Viele der nachfolgenden Punkte sind selbsterklärend. Sollten Sie einmal gar nicht weiterkommen oder benötigen Sie grundsätzlich Hilfe zum Thema Relaunch SEO, so können Sie uns selbstverständlich gerne kontaktieren.

Alle Inhalte der SEO Relaunch Checkliste

1. Pre-Relaunch

1.1 Zugriffsbeschränkungen für das Entwicklungssystem einrichten

Um spätere Probleme mit einer mehrfachen Indexierung und Duplicate Content zu vermeiden, sollte das Entwicklungs- bzw. Testsystem und ggf. die dafür genutzte neue Domain oder Subdomain sofort nach dem Aufsetzen des Systems zuverlässig gesperrt werden.

1.1.1 IP Sperre

Wurde für die Entwicklung der neuen Website eine IP-Sperre eingerichtet, welche nur eigenen IPs und denen berechtigter Dienstleister Zugang zu Test- und Dev-Systemen gewährt? Durch entsprechende Sperren wird eine ungewollte Indexierung des Entwicklungssystems durch Google und andere Crawler verhindert. Diese ist auf jeden Fall zu vermeiden, um die Rankings des Produktiv-Systems nicht zu gefährden. Durch einen Eintrag in der .htaccess-Datei kann eine solche IP-Sperre eingerichtet werden. Beispielhafter Code dazu lautet:

//Block users by IP order allow,deny deny from allow from 192.168.1

In diesem Fall werden IPs aus dem Bereich 192.168.1.x zugelassen.

1.1.2 Passwortschutz

Existiert ein Passwort-Schutz, um neue Inhalte und Systeme vor unberechtigtem Zugriff zu schützen?

Ein Passwort-Schutz kann auf verschiedene Arten mit Hilfe der .htaccess-Datei eingerichtet werden. Eine Möglichkeit ist die Erstellung einer .htpasswd-Datei mit htpasswd (Apache) oder htpasswd.exe (Windows), welche danach in der .htaccess-Datei referenziert wird und Username sowie Passwort enthält.

Der in der .htaccess-Datei einzufügende Code lautet:

//Password Protect file AuthName „Prompt“ AuthType Basic AuthUserFile /home/user/.htpasswd Require valid-user

1.1.3 Robots.txt Sperre

Ist eine Robots.txt-Sperre für das komplette Testsystem und alle Crawler eingerichtet?

# Ganze Website für alle Robots sperren
User-agent: *
Disallow: /

1.1.4 Einsatz von Noindex / Nofollow

Sind die Inhalte sämtlicher Dokumente mit noindex / nofollow versehen? Der folgende Abschnitt muss im <head> der entsprechenden Dokumente eingefügt werden:

<meta name="robots" content="noindex, nofollow"></code

1.2 Weiterleitungen

Werden alle URLs von HTTP auf HTTPS per 301-Redirect weitergeleitet?
Sind alle URLs ausschließlich mit oder ohne „www“ erreichbar und wird von der einen Version (z.B. ohne „www“) grundsätzlich auf die andere Version (mit „www“) per 301-Redirect weitergeleitet?
Werden URL-Änderungen durchgeführt?
Wurden alle Bestands-URLs z.B. per Crawl erhoben?
Wurden Weiterleitungen aller alten auf neue URLs per 301 eingerichtet?

301-Weiterleitungen sollten in der .htaccess-Datei angelegt werden. Sofern zu viele Weiterleitungen eingerichtet werden müssen, können diese zur Wahrung einer schnellen Ladegeschwindigkeit auch in verzeichnisspezifische .htaccess-Dateien aufgeteilt werden.

Besonders wichtig sind:

allgemeine Änderungen der URL-Struktur
extern häufig verlinkte URLs
trafficstarke Seiten
URLs mit vielen Zugriffen über Suchmaschinen
intern stark verlinkte URLs
zukünftig gelöschte Seiten/Inhalte
Wurde die komplette Liste alter URLs abgefragt?
Wurden sämtliche URLs, deren Statuscodes nicht 200 oder 301 lautet, manuell geprüft und nachträglich per 301 weitergeleitet?
Werden intern ausschließlich URLs mit dem Statuscode 200 verlinkt? Hierzu kann die Prüfung mit einem Crawler wie bspw. Screaming Frog erfolgen.
Werden korrekt funktionierende Canonicals genutzt?
Sofern Seiten mit noindex oder nofollow existieren, gibt es dafür jeweils eine gute Begründung?
Sind nicht-HTML-Dokumente wie PDF, DOC, XLS usw. mit dem X-Robots-Tag oder dem X-Canonical-Tag im HTTP-Header von der Indexierung ausgeschlossen?

1.3 Stabilität und Verfügbarkeit

Findet ein Serverumzug statt?
Ist der Parallelbetrieb für die Umstellungsphase auf den neuen Server gewährleistet, um möglichst permanente Verfügbarkeit der Website zu garantieren?

Ein Serverumzug ist in den meisten Fällen zu empfehlen, da so zum Zeitpunkt des Relaunches nur noch die Einträge im DNS-Server geändert werden müssen, so dass die URL auf die neue IP aufgelöst wird. Auf diese Art können Downtimes meist verhindert werden.
Wurden Lasttests zur Prüfung der Stabilität der Website durchgeführt
Wurden Tests zur Prüfung der Zuverlässigkeit der Hardware durchgeführt?

1.4 Quelltext und HTML

Wird auf Text in Bildern verzichtet?
Werden H-Tags korrekt eingesetzt?
Wird Semantic-Markup (z.B. nach schema.org) korrekt eingesetzt?
Existieren crawlbare Fallbacks für JavaScript-Funktionalitäten?
Gemeint sind bspw. HTML-Links, die bei Ausfall von JS greifen.
Ist der Quelltext kompakt und enthält nur eine annehmbare Menge an Kommentaren?
Wird auf den Einsatz von umfangreichem Inline-CSS / JS verzichtet?
Wurde der Quelltext erfolgreich auf Validität geprüft?
HTML etc.: https://validator.w3.org/
CSS: http://www.css-validator.org/
Sind alle Inhalte einheitlich mit UTF-8 korrekt formatiert?
Ist der Content möglichst weit oben im HTML-Code platziert?
Wurden Seiten und Features erfolgreich hinsichtlich Funktionalität und Design in allen relevanten Browsern getestet?

1.5 Mobile Darstellung

Ist die Website responsiv? Stimmt die Darstellung auf den wichtigsten Endgeräten?
Erfüllt die mobile Seite die Anforderungen der Core Web Vitals?

1.6 Interne Verlinkung

Enthalten die meisten Seiten weniger als 50 Links?
Sofern Seiten mit mehr als 100 Links existieren, handelt es sich dabei um begründete Ausnahmen?

Ein Beispiel wären Übersichts- und Themenseiten, welche auf „noindex/follow“ stehen und nur dazu dienen, dem Crawler alle existierenden URLs zugänglich zu machen.
Sind alle Schlüssel- und Verteilerseiten korrekt verlinkt?
Sind die Linktexte für die wichtigsten Seiten jeweils inhaltlich konsistent?
Wird darauf geachtet, dass unterschiedliche Seiten nicht mit dem gleichen Linktext verlinkt sind?
Sind alle Seiten mit maximal 6 Klicks erreichbar?

1.7 Fehlerseiten

Sind 404- und andere Fehlerseiten optimiert?
Wurde eine Null-Treffer-Seite für die interne Suche eingerichtet?
Helfen diese Seiten dem Nutzer weiter?

Idealerweise geben die optimierten Fehlerseiten dem Nutzer einen Zugriff auf die wichtigsten Kategorien.

1.8 Performance

Wurde die Komprimierung mittels brotli und als Fallback via gzip für alle Ressourcen aktiviert?
Sind CSS-Sprites korrekt und sinnvoll strukturiert?
Sind Bilder so gut wie möglich komprimiert?
Werden Bilder via HTML5 alternativ in modernen Bildformaten (webp) bereitgestellt?
Kommt Prefetching / Preloading zum Einsatz?
Wurde die Komprimierung für bereits optimierte Medieninhalte (Bilder, usw.) deaktiviert?
Ist in der neuen Serverumgebung die Auslieferung via http/2 aktiviert?
Wurde beim Einsatz von JS und CSS darauf geachtet, den Anteil an ungenutzten CSS und JS Ressourcen auf den Seiten zu minimieren?

1.9 Tracking

Wurden Google Analytics, Search Console und ggf. auch weitere Tracking-Tools implementiert?
Statt Google Analytics kann auch ein anderes Analytics Tool, wie bspw. Matomo, zum Einsatz kommen.
Sind alle notwendigen Anpassungen der Tracking-Codes abgeschlossen?
Ist der Tracking-Code auf allen Seiten implementiert?
Sofern Modifikationen je Template notwendig sind, wurden diese korrekt durchgeführt?

1.10 Google Search Console

Ist der Zugang zur Google Search Console verfügbar und eingerichtet?
Die Search Console ist eine wichtige Quelle für die Erkennung der wichtigsten Keywords, welche der Seite wertvollen organischen Traffic zuführen. Auch Fehlerhinweise, Tipps und Informationen zum Crawling werden über das kostenlose Google-Tool übermittelt.
Sind Google Search Console Profile auf Verzeichnisebene und für beide Protokolle (http/https) angelegt?

Sie haben Fragen zu unserer Checkliste - Kontaktieren Sie uns jetzt

2. Relaunch: Prüfung während des Launches

Wird der Launch zu einem verkehrsgünstigen Zeitpunkt durchgeführt (z.B. nachts)?
Wird während der Umstellung Status 503 mit korrektem Retry-After im Header verwendet?
Ist das Tracking korrekt installiert?
Ist die Crawlbarkeit sichergestellt?
Ist die Robots.txt in der Minimalkonfiguration ohne Sperren und Crawl-Delay eingerichtet?

User-agent: *
Disallow: Sitemap: http://domain.com/sitemap_location.xml
Ist die Firewall so konfiguriert, dass Crawler der Suchmaschinen alle Seiten auch bei intensivem Crawling erreichen können?
Wurden die neue(n) XML Sitemap(s) in der Google Search Console eingereicht?
Wurde die Noindex-Anweisung der Testumgebung auf zu indexierenden Seiten entfernt?

3. Post-Relaunch

3.1 Indexierung

Wird die Anzahl der indexierten Seiten beobachtet?
Werden durch Prüfung des Google-Cache-Dates Hinweise auf die Geschwindigkeit, mit der Änderungen im Index vollzogen werden, geprüft?https://google.com/search?q=cache:www.adresse.de
Werden weitergeleitete URLs aus dem Index der Suchmaschinen entfernt?
Crawlen die Bots der Suchmaschinen regelmäßig die Website?
Die Zugriffe können mit Hilfe der Log-Files geprüft werden.

3.2 Fehler

Werden Fehler in der Google Search Console überwacht?
Ist die CSS- und HTML-Validität im Live-System gesichert?
Ist die Darstellung von JS im Live-System in der Google Search Console geprüft worden?
Werden Error-Logs überwacht?
Wird die Entwicklung der Sichtbarkeit in gängigen SEO-Tools überwacht?

3.3 Meta Daten

3.3.1 Seitentitel

Ist die Meta-Angabe <title> im neuen Template vorhanden?
Hat jede zu indexierende Seite einen einzigartigen Title?
Sofern neue Seitentitel geplant sind, wurden diese auch eingepflegt?
Werden bei automatisch generierten Seiten sinnvolle Seitentitel erstellt?
Können automatisch generierte Seitentitel manuell optimiert werden?

3.3.2 Meta Description

Enthält das Template ein Feld für die Meta-Description?
Können Descriptions nach einmaliger Einpflege erneut verändert werden?
Sofern neue Descriptions geplant sind, wurden diese auch eingepflegt?
Wird das Meta-Description Feld des Systems korrekt übergeben?
Werden auch bei automatisch generierten Seiten sinnvolle Descriptions erstellt?
Können automatisch generierte Descriptions manuell optimiert werden?

3.3.3 Robots Meta Tag

Ist das Robots-Meta-Tag vorhanden?
Lautet das Robots-Meta-Tag: index, follow?
Noindex sollte bis auf wenige begründete Ausnahmen nicht zum Einsatz kommen.
Sofern Seiten wie beispielsweise Suchergebnisseiten existieren, wurden diese auf „noindex, follow“ gestellt?
Für den Fall, dass Seiten aus rechtlichen Gründen nicht gecacht und im archive.org gespeichert werden sollen, wird „noarchive“ verwendet?
<meta http-equiv=""cache-control"" content=""no-cache"" />

3.4 Caching

Wenn Seiten nicht gecacht werden sollen, sind die folgenden Werte gesetzt?

<meta http-equiv=""cache-control"" content=""no-cache"" />

<meta http-equiv=""pragma"" content=""no-cache"" /

Wurde das Caching entsprechend des Website-Inhaltes angepasst? So sollten beispielsweise Nachrichtenseiten kürzere Caching-Zeiten haben. Das Caching kann wie folgt festgelegt werden: <meta http-equiv="expires" content="900" />
Werden permanente Redirects für einen angemessenen Zeitraum gecacht?

3.5 Canonical URL

Existiert jeder Inhalt nur einmal?
Besitzt jede Seite zur Sicherheit ein Canonical, welches auf die Originalseite weist?
Sofern die jeweilige Seite selbst die Originalseite ist, weist das Canonical auf sie selbst?

3.6 Interne Verlinkung / externe Verlinkung

Zeigen alle internen Links ausschließlich auf interne URLs mit dem Statuscode 200?
Zeigen alle externen Links ausschließlich auf externe URLs mit dem Statuscode 200?
Wurden neben wichtigen Verlinkungen im Menü auch diejenigen in weniger augenfälligen Bereichen wie dem Footer geprüft?
Sind Verlinkungen auf Spezial- und Partnerseiten weiterhin korrekt?

3.7 Externe Links

Konnte verhindert werden, dass externe Verlinkungen der alten Seite für die neue Seite verloren gehen, d.h. z.B. auf nicht existente Seiten zeigen?
Wird in den Wochen nach dem Relaunch die Google Search Console (ehemals Google Webmaster Tools) hinsichtlich 404-Fehlermeldungen regelmäßig geprüft?
Wurden 404-Seiten mit Backlinks per 301 auf sinnvolle Inhalte weitergeleitet?

3.8 HTTP-Header

Kommen folgende HTTP-Header-Codes zum Einsatz?

200: Hierbei handelt es sich um den Standard-Statuscode für URLs, die mit einzigartigem Content gefüllt sind und von denen keine weitere Variante existiert.
301: Die alten URLs von Inhalten, die während des Relaunches auf neue URLs umgezogen wurden, müssen mit Hilfe einer 301-Weiterleitung auf die neue URL zeigen.
302: Auf den Einsatz von 302-Weiterleitungen sollte in jedem Fall verzichtet werden.
404: Ist eine Seite nicht verfügbar oder eine URL ungültig, muss immer eine 404-Fehlermeldung ausgegeben werden. Die Gestaltung der Fehlerseite sollte individuell sein und dem Nutzer möglichst auf weitere relevante Teile der Seite verweisen.
410: Ist es möglich, dass Seiten bei Bedarf den Status 410 Gone liefern?
503: Der Code 503 kann dazu genutzt werden, temporäre Downtimes während des Relaunches zu kommunizieren.

3.9 Robots.txt

Ist die robots.txt vorhanden?
Wird folgender Eintrag in der robots.txt genutzt?
User-agent: * Disallow: Sitemap: http://domain.com/sitemap_location.xml
Sofern in der robots.txt „Disallow“-Einträge stehen, handelt es sich dabei um gut begründete Ausnahmefälle?

3.10 XML-Sitemap

Wurden die Sitemaps nach dem Relaunch komplett neu erstellt?
Sind in den Sitemaps ausschließlich aktuelle URLs mit dem Status 200 zu finden?

Ausnahmen bilden sogenannte „301-Sitemaps“, welche ausschließlich nicht mehr existente Seitenbeinhalten, um so den Suchmaschinen die Deindexierung zu erleichtern.
Werden neue Seiten auch nach dem Relaunch in der Sitemap erfasst?
Wird das Datum nach dem Relaunch weiterhin bei allen Seitentypen korrekt eingefügt?
Kommen unterschiedliche Prioritäten zum Einsatz?
Wird die „changefreq“ in der Sitemap korrekt eingesetzt?

Üblicherweise gilt, dass Startseiten auf always, Kategorien auf hourly und weitere Seiten auf daily gestellt werden sollten.

3.11 Mehrsprachige Seiten

Wurden das Meta-tag „language“ korrekt eingesetzt?
Die Sprachangabe kann beispielsweise wie folgt hinterlegt werden:

<meta http-equiv=”language” content=”de”>
Wird das hreflang-Attribut fehlerfrei genutzt?
Ein Verweis auf die spanische Version einer Internetseite lautet z.B. wie folgt:

<link rel="alternate" hreflang="es" href="http://es.example.com/" />

Nutzen Sie unsere SEO Checkliste für Ihren Relaunch

Alle oben aufgelisteten Fragen und Informationen sind Bestandteil unserer SEO-Checkliste für den Relaunch. Damit haben Sie alle SEO-Anforderungen für die Relaunch-Phasen Ihrer Website im Blick!

IHRE VORTEILE ALS KUNDE VON TAKEVALUE

Expertise

Wir sind zertifizierte und geprüfte Partner der größten Online-Anbieter. Wir sind immer auf dem neuesten Stand in allen relevanten Online-Themen. Profitieren Sie von unserem Fachwissen und unserer Expertise.

ERFAHRUNG

Erfahrung

Wir sind Experten, die Sie bei der digitalen Transformation Ihrer Marketing- und Vertriebsaktivitäten begleiten. Wir haben langjährige Erfahrung aus zahlreichen Projekten – auf Unternehmens- und auf Beratungsseite.

Erkenntnis

Unsere Strategien, Konzepte und Maßnahmen basieren auf fundierten Analysen, belastbaren Daten und nachvollziehbaren Auswertungen. Diese Erkenntnisse bilden die Basis unserer Arbeit.