?>

Migrer de WordPress vers PHP personnalisé sans perdre de SEO – Le guide complet en 7 étapes

Passer de WordPress à une base de code PHP personnalisé peut réduire le TTFB de 70 %, éliminer les vulnérabilités des plugins et vous donner 100 % de propriété. Mais si vous gérez mal les redirections et les métadonnées, vous allez faire chuter votre classement. J’ai migré plus de 30 sites WordPress – voici le processus exact qui préserve (et souvent améliore) le SEO.

Pourquoi migrer de WordPress vers PHP personnalisé ?

• Performance lente – Même avec le cache, WordPress charge plus de 847 Ko de JavaScript.
• Vulnérabilités des plugins – 96 % des sites WordPress piratés sont dus à des plugins obsolètes.
• Frais mensuels – Les plugins premium, l’hébergement optimisé pour WP et la maintenance s’accumulent.
• Dépendance – Vous ne possédez pas le code ; vous possédez une base de données d’articles et un thème.

Le PHP personnalisé vous donne un contrôle total, des temps de charge inférieurs à la seconde et zéro frais mensuel de plateforme. Mais la migration doit être irréprochable.

Avant de commencer : L’audit pré‑migration

• Exporter toutes les URL – Utilisez Screaming Frog (gratuit jusqu’à 500 URL) ou wget : wget --spider --force-html -r -l 3 https://votresite.com 2>&1 | grep '^--' | awk '{ print $3 }' > urls.txt
• Enregistrer les classements – Exportez les 100 mots clés principaux depuis Google Search Console (rapport de performance).
• Sauvegarder les métadonnées – Screaming Frog peut exporter les balises titre, méta descriptions et H1 en CSV.
• Documenter les backlinks – Utilisez Search Console → Liens → Liens externes, ou Ahrefs/SEMrush si disponible.

Étape 1 : Analyser votre ancien site (Screaming Frog en profondeur)

Téléchargez Screaming Frog SEO Spider (gratuit jusqu’à 500 URL). Configurez‑le pour extraire :

1. Toutes les URL internes.
2. Les balises titre et méta descriptions.
3. Les balises canoniques.
4. Les en‑têtes H1.
5. Les codes de réponse (200, 301, 404).

Exportez en CSV. Ce fichier devient votre carte de migration. Vous l’utiliserez pour vérifier que chaque page existante a une destination.

Étape 2 : Mapper les URL vers la nouvelle structure – Gardez‑la identique si possible

L’approche la plus sûre : conserver exactement les mêmes chemins d’URL. Si vos URL WordPress sont propres (ex. /services/conception-web), vous pouvez les réutiliser. Ne modifiez la structure que si :

• Vos URL WordPress incluent /2023/01/nom-de-article/ (dates) – supprimez les dates.
• Vous avez du contenu dupliqué provenant des archives /categorie/ et /etiquette/ – supprimez‑les.

Exemple de mapping pour un blog :

/2023/01/pourquoi-php-personnalise → /blog/pourquoi-php-personnalise
/categorie/performance → /blog/categorie/performance (optionnel, vous pouvez supprimer les pages de catégorie)
/etiquette/seo → (supprimer – les pages d’étiquettes diluent souvent l’autorité)

Créez un CSV avec deux colonnes : old_url, new_url. Pour les pages que vous ne recréez pas (ex. archives d’étiquettes), redirigez vers la page pertinente la plus proche.

Étape 3 : Exporter le contenu de WordPress

Méthode A – WP REST API (plus facile pour les petits sites)

<code>&lt;?php<br>$posts = json_decode(file_get_contents('https://votresite.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>    // Insérer dans une table MySQL personnalisée<br>}<br>?&gt;</code>

Méthode B – WP CLI (plus rapide pour les grands sites)

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

Méthode C – MySQL direct (pour un contrôle total)

<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>

Ensuite, récupérez les métadonnées Yoast SEO depuis wp_postmeta où meta_key IN ('_yoast_wpseo_title','_yoast_wpseo_metadesc').

Étape 4 : Reconstruire votre site PHP personnalisé avec les mêmes métadonnées

• La même balise <title> exacte (de Yoast ou All in One SEO).
• La même <meta name="description">.
• Le même <h1> (bien qu’un changement mineur soit généralement acceptable).

Stockez les métadonnées dans votre base de données (ex. une table page_meta) ou dans un tableau PHP. Pour les sites dynamiques, vous pouvez même conserver la base de données WordPress comme source en lecture seule pendant la transition – mais cela ajoute de la complexité.

Étape 5 : Implémenter les redirections 301 (L’étape la plus critique)

Une redirection 301 indique à Google : « Cette page a été déplacée de façon permanente. » Google transfère près de 100 % de la puissance de classement de l’ancienne page vers la nouvelle URL.

Pour Apache (.htaccess) – Idéal pour moins de 200 redirections

<code>Redirect 301 /ancienne-url /nouvelle-url<br>Redirect 301 /2023/01/pourquoi-php-personnalise /blog/pourquoi-php-personnalise</code>

Pour des milliers de redirections – Utilisez une carte PHP (évite de gonfler .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>

Pour Nginx – Utilisez la directive map

<code>map $request_uri $new_uri {<br>    /ancienne-url /nouvelle-url;<br>    /2023/01/pourquoi-php-personnalise /blog/pourquoi-php-personnalise;<br>}<br>server {<br>    if ($new_uri) {<br>        return 301 $new_uri;<br>    }<br>}</code>

Conseil pro : N’enchaînez jamais les redirections (A → B → C). Chaque saut perd une petite quantité de valeur de lien. Redirigez toujours directement A → C.

Étape 6 : Générer un plan de site XML dynamique

N’utilisez pas un plan de site statique – il deviendra obsolète. Créez plutôt sitemap.php qui génère du XML dynamiquement :

<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(); // votre fonction personnalisée<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>

Ajoutez ensuite une règle de réécriture dans .htaccess :

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

Soumettez le plan de site à Google Search Console immédiatement après le lancement.

Étape 7 : Lancer et surveiller pendant 30 jours

1. Vérifier toutes les redirections – Utilisez un crawler (Screaming Frog) pour visiter chaque ancienne URL et vérifier qu’elle renvoie une 301 vers la nouvelle URL.
2. Surveiller quotidiennement le rapport « Couverture » de Google Search Console – Recherchez les erreurs 404. Pour chaque 404, soit ajoutez une redirection manquante, soit corrigez le lien cassé.
3. Soumettre le nouveau plan de site – Dans Search Console, allez dans Sitemaps → Ajouter un nouveau sitemap (sitemap.xml).
4. Observer les Core Web Vitals – En une semaine, vous devriez voir une amélioration. Sinon, déboguez les images, le CSS ou la configuration du serveur.
5. Comparer les classements après 4 semaines – Exportez à nouveau les données GSC. La plupart des clients ne voient aucun changement ou une légère amélioration grâce à des temps de chargement plus rapides.

Pièges courants et comment les éviter

Piège 1 : Changer les URL sans redirections

Symptôme : Erreurs 404 dans Search Console.

Solution : Implémentez la carte PHP de redirections avant le lancement.

Piège 2 : Oublier de migrer les méta descriptions

Symptôme : Google réécrit votre extrait avec un texte aléatoire.

Solution : Utilisez la même exportation de métadonnées de l’Étape 1.

Piège 3 : Perdre les images (fichiers médias)

Symptôme : Images cassées sur le site personnalisé.

Solution : Copiez tout le dossier /wp-content/uploads/ vers le répertoire public de votre nouveau site. Configurez une redirection de /wp-content/uploads/... vers /uploads/... si vous avez déplacé le dossier.

Piège 4 : Avertissements de contenu mixte (images HTTP)

Symptôme : Le navigateur affiche « contenu non sécurisé » en HTTPS.

Solution : Recherchez et remplacez les anciennes URL d’images dans votre base de données de http://anciensite.com à https://nouveausite.com.

Étude de cas réelle : Migration d’un site professionnel de 500 pages

Un réseau de franchises national avait un site WordPress avec plus de 500 pages d’emplacements, chacune avec un contenu unique. Le temps de chargement était de 2,8 s (mobile), et ils payaient 300 $/mois pour l’hébergement et les plugins.

Processus :

• Exportation de toutes les données d’emplacement à l’aide de WP CLI.
• Reconstruction d’un site PHP personnalisé avec un seul modèle PHP qui extrayait les données d’emplacement de MySQL.
• Conservation de la structure d’URL identique (/emplacements/ville-etat/).
• Utilisation d’une carte PHP pour les redirections 301 (bien que les URL n’aient pas changé, ils ont gardé la carte par sécurité).

Résultats après 60 jours :

• TTFB : 800 ms → 180 ms.
• Performance Lighthouse : 58 → 96.
• Coût d’hébergement : 300 $/mois → 30 $/mois (VPS standard).
• Classements : Améliorés pour 87 % des pages d’emplacement (grâce à la vitesse).
• Trafic organique : +23 % en 3 mois.

Le client possède désormais le code en totalité, ne paie aucun frais de plugin et peut ajouter de nouveaux emplacements instantanément via un simple téléchargement CSV.

Devriez‑vous migrer ? Un cadre de décision

Migrez vers PHP personnalisé si :

• Votre site est principalement statique ou a un contenu prévisible (blog + services).
• Vous en avez assez de la maintenance des plugins et des mises à jour de sécurité.
• Vous voulez 100 % de propriété du code et aucun frais mensuel de plateforme.

Restez sur WordPress si :

• Vous avez besoin de commerce électronique avancé (bien que PHP personnalisé puisse le gérer).
• Vous dépendez fortement des extensions WooCommerce.
• Votre équipe n’est pas technique et est habituée à l’administration WP.

Prêt à faire le changement ?

J’ai migré plus de 30 sites WordPress vers PHP personnalisé – des petits blogs aux boutiques e‑commerce de 2 000 pages. Je gère tout : exportation de contenu, mapping d’URL, redirections 301, préservation des métadonnées et surveillance post‑lancement.

Votre site PHP personnalisé se chargera en moins de 0,8 s, obtiendra 100 à Lighthouse et vous ne paierez plus jamais de frais de plugin.

Toutes les données proviennent de migrations réelles de clients effectuées par BuiltToWinWeb. Les résultats individuels peuvent varier en fonction de la complexité et du contenu du site.