WordPress zu Custom-Entwicklung ohne SEO-Verlust migrieren

Wie Sie eine Website von WordPress auf Custom Development umziehen, ohne SEO-Traffic zu verlieren

Der Umzug weg von WordPress ist kein reines Designprojekt. Wenn Suchtraffic wichtig ist, beginnt die Migration mit den Seiten, die bereits Klicks, Leads und Links bringen. Der Satz „wie man eine Website von WordPress zu einer individuellen Entwicklung verschiebt, ohne SEO-Traffic zu verlieren“ klingt lang, doch die Arbeit dahinter ist praktisch: Was bereits rankt, schützen und die Website dann zuerst um diese Seiten herum neu aufbauen. Genau so lässt sich WordPress zu individueller Entwicklung migrieren ohne SEO-Verlust, ohne später viel Ärger zu riskieren.

Ein häufiger Fehler ist, jede URL als gleich wichtig zu behandeln. Ein Blog-Archiv mit 200 Besuchen im Monat verdient nicht dieselbe Aufmerksamkeit wie eine Produktseite, die 2.000 Besuche und ein Dutzend Backlinks bringt. Wählen Sie die 10, 20 oder 50 wichtigsten URLs aus und schreiben Sie sie auf, bevor irgendeine Codeänderung beginnt. Kleine Liste, großer Effekt.

1. Erfassen Sie die Seiten, die tatsächlich Suchtraffic bringen

Starten Sie mit drei Quellen: Analytics, Search Console und Ihren Backlink-Daten. Ermitteln Sie in Analytics die Landingpages mit organischem Traffic der letzten 12 Monate. Notieren Sie in Search Console die Suchanfragen, die Impressions und Klicks auf diese URLs bringen. Markieren Sie in den Backlink-Daten die Seiten mit den stärksten externen Links, denn eine Seite mit 5 guten Links kann 50 schwache übertreffen.

Verlassen Sie sich nicht auf Ihr Gedächtnis. Eine Seite, die sich „wichtig anfühlt“, ist nicht immer die, der Suchmaschinen am meisten vertrauen. Manchmal ist ausgerechnet die Seite, die man fast gelöscht hätte, diejenige, die eine Long-Tail-Cluster abdeckt und still Umsatz stützt. Das passiert oft genug, um dafür eine Tabelle anzulegen.

Erstellen Sie eine einfache Tabelle mit vier Spalten: aktuelle URL, organischer Traffic, Top-Suchanfragen und Notizen zum geschäftlichen Wert. Hat eine Seite saisonalen Wert, markieren Sie den Monat. Ist sie für die interne Navigation wichtig, markieren Sie auch das. Danach die Liste priorisieren. Die oberste Stufe bekommt die sorgfältigste Migrationsbehandlung.

2. Frieren Sie die aktuelle SEO-Basis vor jeder Codeänderung ein

Bevor ein Entwickler Templates anfasst, exportieren Sie den aktuellen SEO-Stand. Speichern Sie Ranking-Snapshots, die Anzahl indexierter Seiten, Crawl-Fehler, Canonicals, Metadaten, interne Links und die URLs der XML-Sitemap. Wenn möglich, crawlen Sie die WordPress-Seite mit einem Tool, das Statuscodes und Seitentitel aufzeichnet. Sie brauchen ein Bild vom vorherigen Zustand, keine vage Erinnerung.

Sichern Sie die Search-Console-Daten für den aktuellsten Berichtszeitraum. Hat die Website ein tägliches Traffic-Muster, verwenden Sie für den Vergleich denselben Wochentag. Montag mit Montag ist besser als Montag mit Samstag. Diese kleine Entscheidung vermeidet Fehlalarme.

Speichern Sie außerdem eine Kopie der robots.txt-Datei und des aktuellen Sitemap-Index. Diese Dateien wirken langweilig, bis sie Suchmaschinen einen Bereich sperren, den Sie eigentlich behalten wollten. Eine Zeile in robots.txt kann Hunderte URLs beeinflussen. Ein fehlender Sitemap-Eintrag kann einen ganzen Bereich wochenlang verbergen.

Wenn die Website bereits Canonical-Tags hat, dokumentieren Sie sie. Wenn doppelte Title-Tags existieren, notieren Sie, welche Templates sie erzeugen. Diese Details helfen Ihnen, zwischen Migrationsschäden und älteren Problemen zu unterscheiden. Ohne diese Basis wird die Analyse nach dem Launch zum Rätselraten.

3. Erstellen Sie einen URL-Paritätsplan für jede wichtige Seite

Ordnen Sie nun jede wichtige WordPress-URL einer neuen Custom-URL zu. Halten Sie die Beziehung möglichst 1:1. Wenn die alte Seite /services/seo-audit/ heißt, sollte die neue Seite nicht /what-we-do/consulting/audit/ werden, außer es gibt dafür einen klaren geschäftlichen Grund. Saubere Zuordnungen reduzieren die Weiterleitungs-Komplexität und machen die Migration leichter prüfbar.

Sonderfälle verdienen zusätzliche Zeilen im Plan. Seiten mit Paginierung, Kategorie-Archive, gefilterte Ansichten, Tag-Seiten, Autorenarchive und Medien-Anhang-URLs können sich alle anders verhalten. Manche sollten auf eine übergeordnete Seite weiterleiten. Manche sollten indexierbar bleiben. Manche sollten komplett aus der Suche entfernt werden. Prüfen Sie jeden Einzelfall statt zu raten.

Hier zahlt sich eine gute Tabelle aus. Ergänzen Sie Spalten für alte URL, neue URL, Statuscode, Weiterleitungstyp, Canonical-Ziel und die Entscheidung zur Indexierbarkeit. Tragen Sie anschließend den Verantwortlichen für jede Entscheidung ein. Entwickler, SEO-Verantwortliche und Content-Redakteure sollten dieselbe Datei lesen können und wissen, was am Launch-Tag passiert.

Bei großen Websites kann die Paritätsprüfung unschöne Überraschungen offenlegen. Eine WordPress-Tagseite kann für ein nützliches Thema ranken, auch wenn niemand das beabsichtigt hat. Eine Mediendatei kann weiterhin Besucher aus der Bildsuche anziehen. Der Migrationsplan sollte diese Seiten ebenfalls enthalten, denn Suchmaschinen interessiert es nicht, dass eine Seite „nur ein Restbestand“ war.

4. Planen Sie Weiterleitungen, Canonicals und Index-Signale gemeinsam

Weiterleitungen allein reichen nicht aus. Wenn eine Seite auf eine neue URL weiterleitet, das Canonical-Tag aber auf etwas anderes zeigt, werden die Signale unsauber. Wenn eine Seite in robots.txt blockiert, aber in der Sitemap gelistet ist, ist das ebenfalls unsauber. Suchmaschinen bevorzugen eine klare Geschichte. Geben Sie ihnen genau die.

Definieren Sie 301-Weiterleitungen für jede alte URL, die einen neuen Zielort braucht. Vermeiden Sie Weiterleitungsketten. Ein Sprung ist gut. Zwei Sprünge sind im Notfall noch akzeptabel. Bei drei Sprüngen beginnen Traffic und Crawl-Effizienz zu leiden. Eine ausführlichere technische Checkliste finden Sie unter wie man 301-Weiterleitungen einrichtet.

Canonicals sollten auf die bevorzugte Version jeder Seite auf der neuen Website zeigen. Wenn eine gefilterte Seite indexierbar bleiben soll, machen Sie diese Entscheidung ausdrücklich. Wenn eine parameterbasierte Seite nicht indexiert werden soll, sollten die robots-Anweisung und das Canonical zur Absicht passen. Gemischte Signale verschwenden Crawl-Budget und verwässern die Relevanz der Seite.

XML-Sitemaps sollten nur URLs enthalten, die indexiert werden sollen und einen 200-Status zurückgeben. Entfernen Sie alte WordPress-URLs beim Launch aus der Sitemap, nicht erst eine Woche später. Eine Sitemap mit toten URLs ist wie eine Karte mit Straßen, die an einer Mauer enden. Suchbots merken das.

Eine praktische Regel hilft: Wenn die Seite wichtig ist, führen Sie sie über einen eindeutigen Pfad dahin. Leiten Sie alte URLs weiter, setzen Sie das Canonical auf die finale URL und veröffentlichen Sie genau diese finale URL in der Sitemap. Drei übereinstimmende Signale schlagen drei widersprüchliche jedes Mal.

5. Erhalten Sie On-Page-SEO-Elemente beim Nachbau der Templates

Beim Nachbau von Templates gehen viele Migrationen verloren. Ein Designer ändert die Überschriftenstruktur, weil sie „besser aussieht“, oder ein Entwickler kürzt Meta-Descriptions, weil sie scheinbar unsichtbar sind. Suchmaschinen lesen diese Elemente weiterhin. Nutzer indirekt auch, über Snippets und Sitelinks.

Erstellen Sie Title-Tags so neu, dass sie weiterhin für jede Seite spezifisch bleiben. Bewahren Sie Meta-Descriptions, wenn sie noch zum Inhalt passen. Halten Sie eine klare H2- oder H3-Struktur pro Seite ein statt zufälliger Sprünge bei den Überschriften. Wenn das alte WordPress-Template eine beschreibende H1 mit unterstützenden H2s verwendet hat, spiegeln Sie diese Logik im Custom-Build wider.

Auch strukturierte Daten verdienen die gleiche Sorgfalt. Wenn die alte Website Artikel, Produkte, Breadcrumbs oder FAQs ausgezeichnet hat, prüfen Sie, welche Schema-Typen im neuen Build weiterhin relevant sind. Fehlende Schema-Auszeichnung ruiniert Rankings nicht immer, aber das Entfernen eines gültigen Seitentyps kann die Chancen auf Rich Results verringern. Das ist ein echter Verlust, auch wenn er schwer zu messen ist.

Auch Alt-Texte für Bilder sind wichtig. Wenn eine WordPress-Seite benannte Bilder hatte, die Impressionen aus der Bildsuche erhielten, sollten die Alt-Texte weiterhin beschreibend und konkret bleiben. Ersetzen Sie „Team-Meeting in Berlin“ nicht durch „Bild1“. Schon diese eine Änderung kann die Sichtbarkeit in der Bildsuche schnell drücken.

Interne Links sind ebenfalls Teil des On-Page-Bildes. Wenn eine wertvolle Serviceseite von der Startseite, dem Footer und drei verwandten Artikeln aus verlinkt war, behalten Sie diese Links dort, wo sie sinnvoll sind. Eine Migration, die interne Links vergisst, verliert oft Relevanz, selbst wenn der Inhalt korrekt übernommen wurde.

6. Behandeln Sie Content- und Medien-Sonderfälle, die WordPress verdeckt

WordPress versteckt erstaunlich viel Ballast. Anhangsseiten sind ein klassisches Beispiel. Sie können dünne URLs erzeugen, die Suchmaschinen crawlen, indexieren und dann ignorieren. Autoren- und Tag-Seiten können dasselbe tun. Wenn sie nicht nützlich sind, nehmen Sie sie aus der Indexierung oder fassen Sie sie auf stärkeren Seiten zusammen.

Mediendateien brauchen besondere Aufmerksamkeit. Eine Bilddatei kann für sich allein Traffic gebracht haben, vor allem wenn die Website seit Jahren Inhalte veröffentlicht. Prüfen Sie, ob diese Asset-URLs erreichbar bleiben oder zur Seite weiterleiten sollen, die sie verwendet. Hat eine Datei eingehende Links, ist es schlecht, sie einfach kaputtgehen zu lassen.

Verwaiste Inhalte sind eine weitere Falle. In WordPress kann eine Seite noch lange in der Datenbank existieren, nachdem sie aus der Navigation verschwunden ist. Während der Migration kann diese Seite vergessen werden, weil niemand sie im Menü sieht. Suchmaschinen können sie aber weiterhin sehen. Erstellen Sie einen Content-Export, der jede veröffentlichbare URL enthält, nicht nur die Seiten, an die Sie sich namentlich erinnern.

Bei großen redaktionellen Websites kann der Aufräumprozess außerdem doppelte oder nahezu doppelte Beiträge sichtbar machen. Einige davon sollten zusammengeführt werden. Andere brauchen möglicherweise ein Noindex-Tag. Treffen Sie die Entscheidung auf Basis von Traffic, Links und Relevanz, nicht nur nach redaktioneller Vorliebe. Suchmaschinen sind nicht sentimental.

Wenn Sie in dieser Phase zusätzlichen Kontext zur Sicherheit brauchen, lohnt sich ein Blick auf Website-Sicherheit, bevor Sie live gehen. Eine Migration ist nicht der richtige Zeitpunkt, um alte Dateien, freigegebene Uploads oder schwache Berechtigungen offen herumliegen zu lassen.

7. Validieren Sie den Launch mit SEO-orientierter QA

QA sollte zweimal stattfinden: auf der Staging-Umgebung und nach dem Go-live. Crawlen Sie die Staging-Seite mit denselben Regeln, die später öffentlich gelten sollen. Prüfen Sie Statuscodes, Canonicals, interne Links, Metadaten und die Sitemap-Ausgabe. Bestätigen Sie, dass alte WordPress-URLs die gewünschte 301-Antwort liefern und die Zielseite einen 200-Status zurückgibt.

Achten Sie auf Weiterleitungsschleifen, gemischte Protokolle und versehentliche Noindex-Tags. Eine Seite, die ranken sollte, aber mit noindex versehen ist, erholt sich nicht zufällig. Eine Seite, die von HTTP auf HTTPS und dann auf einen anderen Pfad weiterleitet, kann für Nutzer zwar funktionieren, erhöht aber das Risiko. Eine saubere Weiterleitung ist das Ziel.

Vergleichen Sie Staging mit der zuvor eingefrorenen Basis. Hat sich die Zahl indexierbarer URLs deutlich verändert? Hat die Startseite ihr Canonical verloren? Zeigen interne Links noch auf die alten Slugs? Diese Prüfungen sind mühsam. Sie sind günstiger als ein Traffic-Einbruch.

Es hilft, die QA sowohl mit einem Crawler als auch mit einem Menschen durchzugehen. Der Crawler findet fehlende Tags. Der Mensch erkennt merkwürdige Seitentemplates, seltsame Title und eine kaputte Reihenfolge im Inhalt. Ein Entwickler denkt vielleicht, eine Seite sei in Ordnung, weil sie lädt. Suchmaschinen interessieren sich für weit mehr als nur das Laden.

8. Überwachen Sie nach dem Launch die SEO-Signale und beheben Sie Verluste schnell

Beobachten Sie nach dem Launch die Search Console in den ersten 2 bis 4 Wochen täglich. Verfolgen Sie Indexabdeckung, Crawl-Fehler, Ranking-Verschiebungen und den Traffic auf Landingpages. Wenn eine Seite, die früher rankte, aus den Suchergebnissen verschwindet, prüfen Sie zuerst das Ziel der Weiterleitung, den Title-Tag, das Canonical und die internen Links.

Manche Verluste sind einfach. Eine Seite wurde vielleicht auf das falsche Ziel weitergeleitet. Andere nicht. Ein Bereich kann entwertet worden sein, weil zu viele alte URLs auf die generische Startseite statt auf eine passende Ersatzseite zeigen. Suchmaschinen bevorzugen Präzision, nicht Abkürzungen. So behalten Sie SEO-Traffic bei Website-Relaunch behalten, statt ihn durch unklare Signale zu verlieren.

Defekte Landingpages verdienen erste Aufmerksamkeit, weil sie gleichzeitig Traffic und Conversions verlieren können. Wenn eine Seite mit starken Backlinks plötzlich 404 zurückgibt, stellen Sie sie wieder her oder leiten Sie sie korrekt weiter. Wenn sich die URL einer Seite geändert hat, die alte Adresse aber weiterhin rankt, aktualisieren Sie die internen Links, damit die Website nicht weiter den falschen Pfad stützt.

Behalten Sie auch das Crawl-Verhalten im Blick. Wenn Googlebot viel Zeit auf URLs mit geringem Wert verbringt, straffen Sie die Sitemap und prüfen Sie die Indexierungsregeln. Wenn Sie ein breiteres Bild der Messkosten nach dem Launch möchten, hilft was Website-Analytics kostet bei der Einordnung des Monitoring-Budgets. Für Teams, die die neue Website langfristig gesund halten wollen, ist was Website-Wartung kostet eine nützliche Ergänzung.

Eine letzte Gewohnheit zahlt sich aus: Führen Sie nach dem Launch ein Änderungsprotokoll für jede Weiterleitung, Canonical-Anpassung und Template-Änderung. Wenn die Rankings an Tag 9 sinken, wollen Sie wissen, was an Tag 6 geändert wurde. Dieses Protokoll verwandelt Panik in Diagnose und Diagnose in eine Lösung, der Sie vertrauen können.