SEO Relaunch Checkliste - Erfolg ist planbar

Mit unserem Google Analytics Audit unterstützen wir Sie beim Analytics Setup und sorgen für eine aktuelle und individuelle Anpassung Ihrer Datenanalysen.

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 Heraus­forderungen und potenzielle Fall­stricke. Doch auch kleine hand­werkliche 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 Projekt­ablauf 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!

Sie haben Fragen zu Ihrem Relaunch - kontaktieren Sie uns jetzt

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 Anfor­de­rungen 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 selbst­erklärend. Sollten Sie einmal gar nicht weiter­kommen oder benötigen Sie grundsätzlich Hilfe zum Thema Relaunch SEO, so können Sie uns selbst­verstä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 ver­meiden, 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 Entwicklungs­systems 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 funk­tionierende 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?
  • Wurde die mobile Seite mithilfe des entsprechenden Google-Tests erfolgreich geprüft?

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 verkehrs­gü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 Crawl­barkeit sichergestellt?
  • Ist die Robots.txt in der Minimal­konfiguration ohne Sperren und Crawl-Delay eingerichtet?

    User-agent:   *
    Disallow:
    Sitemap: http://domain.com/sitemap_location.xml
  • Ist die Firewall so konfiguriert, dass Crawler der Such­maschinen 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 Test­um­gebung 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 Such­maschinen 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 Such­ergebnis­seiten 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 Nachrichten­seiten 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 augen­fä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 sinn­volle 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
OK
Profitieren Sie von unserer Expertise.
Expertise
OK

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
OK
Wir haben langjährige Erfahrung in SEO und digitalem Marketing.
Erfahrung
OK

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
OK
Fundierte Analysen, belastbare Daten und nachvollziehbare Auswertungen bilden die Basis von Erkenntnis
Erkenntnis
OK

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

jetzt ein unverbindliches Angebot einholen

jetzt ein unverbindliches Angebot einholen 

Michael Buschmann - Geschäftsführer takevalue Consulting GmbH, Darmstadt

Michael Buschmann
Geschäftsführer