?>

Migrieren Sie von WordPress zu benutzerdefiniertem PHP ohne SEO-Verlust – Die vollständige 7‑Schritte‑Anleitung

Der Wechsel von WordPress zu einer benutzerdefinierten PHP-Codebasis kann die TTFB um 70 % reduzieren, Plugin-Schwachstellen beseitigen und Ihnen 100 % Eigentum verschaffen. Aber wenn Sie Weiterleitungen und Metadaten falsch handhaben, werden Ihre Rankings einbrechen. Ich habe über 30 WordPress-Sites migriert – hier ist der genaue Prozess, der SEO erhält (und oft verbessert).

Warum von WordPress zu benutzerdefiniertem PHP migrieren?

• Langsame Leistung – Selbst mit Caching lädt WordPress über 847 KB JavaScript.
• Plugin-Schwachstellen – 96 % der gehackten WordPress-Sites sind auf veraltete Plugins zurückzuführen.
• Monatliche Gebühren – Premium-Plugins, für WP optimiertes Hosting und Wartung summieren sich.
• Abhängigkeit – Sie besitzen nicht den Code; Sie besitzen eine Datenbank mit Beiträgen und ein Theme.

Benutzerdefiniertes PHP gibt Ihnen volle Kontrolle, unter einer Sekunde Ladezeiten und keine monatlichen Plattformgebühren. Aber die Migration muss fehlerfrei sein.

Bevor Sie beginnen: Das Pre‑Migration‑Audit

• Alle URLs exportieren – Verwenden Sie Screaming Frog (kostenlos bis zu 500 URLs) oder wget: wget --spider --force-html -r -l 3 https://ihreseite.com 2>&1 | grep '^--' | awk '{ print $3 }' > urls.txt
• Rankings aufzeichnen – Exportieren Sie die Top-100-Keywords aus der Google Search Console (Leistungsbericht).
• Metadaten speichern – Screaming Frog kann Titel-Tags, Meta-Beschreibungen und H1 als CSV exportieren.
• Backlinks dokumentieren – Verwenden Sie Search Console → Links → Externe Links oder Ahrefs/SEMrush, falls verfügbar.

Schritt 1: Crawlen Sie Ihre alte Site (Screaming Frog im Detail)

Laden Sie Screaming Frog SEO Spider herunter (kostenlos für bis zu 500 URLs). Konfigurieren Sie es zum Extrahieren von:

1. Allen internen URLs.
2. Titel-Tags und Meta-Beschreibungen.
3. Kanondischen Tags.
4. H1-Überschriften.
5. Antwortcodes (200, 301, 404).

Exportieren Sie als CSV. Diese Datei wird Ihre Migrationskarte. Sie verwenden sie, um zu überprüfen, dass jede vorhandene Seite ein Ziel hat.

Schritt 2: URLs auf die neue Struktur abbilden – Wenn möglich identisch halten

Der sicherste Ansatz: genau die gleichen URL-Pfade beibehalten. Wenn Ihre WordPress-URLs sauber sind (z.B. /dienstleistungen/webdesign), können Sie sie wiederverwenden. Ändern Sie die Struktur nur, wenn:

• Ihre WordPress-URLs /2023/01/beitragsname/ (Daten) enthalten – entfernen Sie die Daten.
• Sie doppelten Inhalt aus /kategorie/ und /schlagwort/ Archiven haben – entfernen Sie diese.

Beispiel-Abbildung für einen Blog:

/2023/01/warum-benutzerdefiniertes-php → /blog/warum-benutzerdefiniertes-php
/kategorie/leistung → /blog/kategorie/leistung (optional, Sie können Kategorieseiten entfernen)
/schlagwort/seo → (entfernen – Schlagwortseiten verwässern oft die Autorität)

Erstellen Sie eine CSV mit zwei Spalten: old_url, new_url. Für Seiten, die Sie nicht neu erstellen (z.B. Schlagwortarchive), leiten Sie auf die nächstgelegene relevante Seite weiter.

Schritt 3: Inhalte aus WordPress exportieren

Methode A – WP REST API (am einfachsten für kleine Sites)

<code>&lt;?php<br>$posts = json_decode(file_get_contents('https://ihreseite.com/wp-json/wp/v2/posts?per_page=100&page=1'));<br>foreach ($posts as $post) {<br>    $data = [<br>        'title' => $post->title->rendered,<br>        'slug' => $post->slug,<br>        'content' => $post->content->rendered,<br>        'excerpt' => $post->excerpt->rendered,<br>        'date' => $post->date,<br>        'meta' => [<br>            'title' => get_post_meta($post->id, '_yoast_wpseo_title', true),<br>            'description' => get_post_meta($post->id, '_yoast_wpseo_metadesc', true)<br>        ]<br>    ];<br>    // In benutzerdefinierte MySQL-Tabelle einfügen<br>}<br>?&gt;</code>

Methode B – WP CLI (am schnellsten für große Sites)

<code>wp export --dir=/tmp --post_type=post,page --with_attachments</code>

Methode C – Direktes MySQL (für totale Kontrolle)

<code>SELECT ID, post_title, post_name, post_content, post_date FROM wp_posts WHERE post_status = 'publish' AND post_type IN ('post', 'page');</code>

Rufen Sie dann Yoast SEO-Metadaten aus wp_postmeta ab, wo meta_key IN ('_yoast_wpseo_title','_yoast_wpseo_metadesc').

Schritt 4: Bauen Sie Ihre benutzerdefinierte PHP-Site mit den gleichen Metadaten wieder auf

• Das exakt gleiche <title>-Tag (von Yoast oder All in One SEO).
• Die gleiche <meta name="description">.
• Die gleiche <h1> (obwohl eine kleine Änderung normalerweise in Ordnung ist).

Speichern Sie Metadaten in Ihrer Datenbank (z.B. eine page_meta-Tabelle) oder in einem PHP-Array. Für dynamische Sites können Sie sogar die WordPress-Datenbank als schreibgeschützte Quelle während des Übergangs behalten – das erhöht jedoch die Komplexität.

Schritt 5: Implementieren Sie 301-Weiterleitungen (Der wichtigste Schritt)

Eine 301-Weiterleitung sagt Google: „Diese Seite wurde dauerhaft verschoben.“ Google überträgt nahezu 100 % der Ranking-Kraft der alten Seite auf die neue URL.

Für Apache (.htaccess) – Am besten für weniger als 200 Weiterleitungen

<code>Redirect 301 /alte-url /neue-url<br>Redirect 301 /2023/01/warum-benutzerdefiniertes-php /blog/warum-benutzerdefiniertes-php</code>

Für tausende Weiterleitungen – Verwenden Sie eine PHP-Karte (vermeidet Aufblähen der .htaccess)

<code>&lt;?php<br>$redirects = json_decode(file_get_contents(__DIR__ . '/redirects.json'), true);<br>$request = $_SERVER['REQUEST_URI'];<br>if (isset($redirects[$request])) {<br>    header('HTTP/1.1 301 Moved Permanently');<br>    header('Location: ' . $redirects[$request]);<br>    exit;<br>}<br>?&gt;</code>

Für Nginx – Verwenden Sie die map-Direktive

<code>map $request_uri $new_uri {<br>    /alte-url /neue-url;<br>    /2023/01/warum-benutzerdefiniertes-php /blog/warum-benutzerdefiniertes-php;<br>}<br>server {<br>    if ($new_uri) {<br>        return 301 $new_uri;<br>    }<br>}</code>

Profi-Tipp: Verketten Sie niemals Weiterleitungen (A → B → C). Jeder Sprung verliert ein wenig Link-Equity. Leiten Sie immer direkt A → C weiter.

Schritt 6: Generieren Sie eine dynamische XML-Sitemap

Verwenden Sie keine statische Sitemap – sie wird veralten. Erstellen Sie stattdessen sitemap.php, die dynamisch XML ausgibt:

<code>&lt;?php<br>header('Content-Type: application/xml');<br>echo '&lt;?xml version="1.0" encoding="UTF-8"?&gt;';<br>echo '&lt;urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"&gt;';<br>$pages = getAllPageUrlsFromDatabase(); // Ihre benutzerdefinierte Funktion<br>foreach ($pages as $url) {<br>    echo '&lt;url&gt;&lt;loc&gt;' . htmlspecialchars($url) . '&lt;/loc&gt;&lt;lastmod&gt;' . date('Y-m-d') . '&lt;/lastmod&gt;&lt;/url&gt;';<br>}<br>echo '&lt;/urlset&gt;';<br>?&gt;</code>

Fügen Sie dann eine Rewrite-Regel in .htaccess hinzu:

<code>RewriteRule ^sitemap\.xml$ sitemap.php [L]</code>

Reichen Sie die Sitemap unmittelbar nach dem Start bei der Google Search Console ein.

Schritt 7: Starten und 30 Tage lang überwachen

1. Alle Weiterleitungen prüfen – Verwenden Sie einen Crawler (Screaming Frog), um jede alte URL zu besuchen und zu überprüfen, ob sie eine 301 zur neuen URL zurückgibt.
2. Täglich den „Coverage“-Bericht der Google Search Console überwachen – Achten Sie auf 404-Fehler. Fügen Sie für jede 404 entweder eine fehlende Weiterleitung hinzu oder beheben Sie den defekten Link.
3. Die neue Sitemap einreichen – Gehen Sie in der Search Console zu Sitemaps → Neue Sitemap hinzufügen (sitemap.xml).
4. Core Web Vitals beobachten – Innerhalb einer Woche sollten Sie eine Verbesserung sehen. Wenn nicht, debuggen Sie Bilder, CSS oder die Serverkonfiguration.
5. Rankings nach 4 Wochen vergleichen – Exportieren Sie die GSC-Daten erneut. Die meisten Kunden sehen entweder keine Veränderung oder eine leichte Verbesserung aufgrund schnellerer Ladezeiten.

Häufige Fallstricke und wie man sie vermeidet

Fallstrick 1: URLs ohne Weiterleitungen ändern

Symptom: 404-Fehler in der Search Console.

Lösung: Implementieren Sie die PHP-Weiterleitungskarte vor dem Start.

Fallstrick 2: Vergessen, Meta-Beschreibungen zu migrieren

Symptom: Google schreibt Ihren Snippet mit zufälligem Text um.

Lösung: Verwenden Sie denselben Metadaten-Export aus Schritt 1.

Fallstrick 3: Bilder (Mediendateien) verlieren

Symptom: Defekte Bilder auf der benutzerdefinierten Site.

Lösung: Kopieren Sie den gesamten Ordner /wp-content/uploads/ in das öffentliche Verzeichnis Ihrer neuen Site. Richten Sie eine Weiterleitung von /wp-content/uploads/... zu /uploads/... ein, wenn Sie den Ordner verschoben haben.

Fallstrick 4: Warnungen zu gemischten Inhalten (HTTP-Bilder)

Symptom: Browser zeigt „unsichere Inhalte“ auf HTTPS an.

Lösung: Suchen und ersetzen Sie alte Bild-URLs in Ihrer Datenbank von http://alteseite.com zu https://neueseite.com.

Echte Fallstudie: Migration einer Business-Site mit 500 Seiten

Ein nationales Franchise-Netzwerk hatte eine WordPress-Site mit über 500 Standortseiten, jede mit einzigartigem Inhalt. Die Ladezeit betrug 2,8 s (mobil), und sie zahlten 300 $/Monat für Hosting und Plugins.

Prozess:

• Export aller Standortdaten mit WP CLI.
• Aufbau einer benutzerdefinierten PHP-Site mit einer einzigen PHP-Vorlage, die Standortdaten aus MySQL abruft.
• Beibehaltung der identischen URL-Struktur (/standorte/stadt-bundesland/).
• Verwendung einer PHP-Karte für 301-Weiterleitungen (obwohl sich die URLs nicht änderten, behielten sie die Karte aus Sicherheitsgründen).

Ergebnisse nach 60 Tagen:

• TTFB: 800 ms → 180 ms.
• Lighthouse-Leistung: 58 → 96.
• Hosting-Kosten: 300 $/Monat → 30 $/Monat (Standard-VPS).
• Rankings: Bei 87 % der Standortseiten verbessert (aufgrund der Geschwindigkeit).
• Organischer Traffic: +23 % innerhalb von 3 Monaten.

Der Kunde besitzt nun den Code vollständig, zahlt keine Plugin-Gebühren und kann neue Standorte sofort über einen einfachen CSV-Upload hinzufügen.

Sollten Sie migrieren? Ein Entscheidungsrahmen

Migrieren Sie zu benutzerdefiniertem PHP, wenn:

• Ihre Site überwiegend statisch ist oder vorhersehbaren Inhalt hat (Blog + Dienstleistungen).
• Sie die Wartung von Plugins und Sicherheitsupdates leid sind.
• Sie 100 % Code-Eigentum und keine monatlichen Plattformgebühren wünschen.

Bleiben Sie bei WordPress, wenn:

• Sie erweiterten E-Commerce benötigen (obwohl benutzerdefiniertes PHP dies handhaben kann).
• Sie stark auf WooCommerce-Erweiterungen angewiesen sind.
• Ihr Team nicht technisch ist und an die WP-Administration gewöhnt ist.

Bereit für den Wechsel?

Ich habe über 30 WordPress-Sites zu benutzerdefiniertem PHP migriert – von kleinen Blogs bis zu 2.000-seitigen E-Commerce-Shops. Ich kümmere mich um alles: Export von Inhalten, URL-Zuordnung, 301-Weiterleitungen, Erhaltung von Metadaten und Überwachung nach dem Start.

Ihre benutzerdefinierte PHP-Site wird in unter 0,8 s laden, 100 bei Lighthouse erreichen, und Sie werden nie wieder eine Plugin-Gebühr zahlen.

Alle Daten stammen von echten Kundenmigrationen, die von BuiltToWinWeb durchgeführt wurden. Die individuellen Ergebnisse können je nach Komplexität und Inhalt der Site variieren.