Mettre un site WordPress en ligne - La méthode propre et efficace

Ce qu’il faut préparer avant d’ouvrir le site

Avant de publier, je fige toujours le contenu. Si des pages changent pendant la migration, on finit vite avec des médias manquants, des liens cassés ou une base de données qui ne reflète plus l’état réel du site. Je vérifie aussi que j’ai bien les accès au panneau d’hébergement, au serveur, à la base MySQL ou MariaDB, et à l’administration WordPress.

Dans un lancement propre, il y a une différence nette entre un site neuf et un site déjà construit en local ou en préproduction. Un environnement de staging, c’est simplement une copie privée du site servant à tester avant le passage en public. Plus la copie est complète, moins la mise en ligne réserve de surprises.

• Nom de domaine prêt à pointer vers le bon hébergement.
• Accès FTP/SFTP ou gestionnaire de fichiers fonctionnel.
• Base de données créée et identifiants enregistrés.
• Sauvegarde complète des fichiers et de la base avant toute opération.
• Certificat SSL activé ou au moins disponible côté hébergeur.
• Liste des extensions et réglages clés pour éviter les oublis au déploiement.

Quand ces bases sont propres, je peux choisir la méthode de passage en ligne qui correspond réellement au point de départ, et c’est là que l’article devient pratique.

Choisir la bonne méthode selon votre point de départ

Il n’existe pas une seule façon de publier un site WordPress. La bonne méthode dépend surtout de l’endroit où le site se trouve au départ et du niveau de complexité du projet. Pour un petit site vitrine, l’opération peut rester simple. Pour un site avec beaucoup de contenus, d’images et d’URL internes, je préfère une méthode plus rigoureuse, même si elle prend un peu plus de temps.

Pour un petit site, l’installation neuve prend souvent moins d’une heure. Une migration propre, elle, prend davantage de temps, parce qu’il faut traiter les fichiers, la base et les URL sans rien casser. La suite logique, c’est donc de déplacer le site de manière méthodique.

Déplacer les fichiers et la base sans casser WordPress

Quand je dois publier un site déjà construit, je pars d’une règle simple : les fichiers et la base doivent rester cohérents. Si l’un des deux manque ou si les URL n’ont pas été réécrites, le site démarre parfois, mais il se comporte comme un chantier incomplet. C’est la raison pour laquelle je préfère suivre la séquence ci-dessous dans le même ordre.

1. Je commence par une sauvegarde complète des fichiers et de la base de données.
2. Je crée, si besoin, une nouvelle base et un nouvel utilisateur avec les bons privilèges.
3. Je transfère les fichiers WordPress vers le serveur cible via SFTP, FTP ou le gestionnaire de fichiers de l’hébergeur.
4. J’importe la base dans l’environnement final.
5. Je mets à jour le fichier wp-config.php avec le nom de la base, l’utilisateur, le mot de passe et l’hôte.
6. Je remplace les anciennes URL par la nouvelle adresse du site dans la base de données.
7. Je rouvre les réglages de permaliens et je sauvegarde une fois pour régénérer les règles d’accès.

Le point le plus sensible reste le remplacement des URL. Les anciens liens peuvent se trouver dans les contenus, les widgets, les options du thème ou les réglages d’extensions. Sur un petit site, on peut le faire avec soin à la main. Sur un site plus dense, je préfère un outil de migration ou une ligne de commande comme WP-CLI, parce qu’elle réduit les oublis.

Si vous voyez des images cassées ou des boutons qui renvoient vers l’ancien site, ce n’est généralement pas un problème de thème : c’est presque toujours un problème d’URL restées figées dans la base. Une fois ce point réglé, on peut passer au domaine et au HTTPS.

Régler le domaine, le HTTPS et les adresses du site

Le passage en ligne n’est pas terminé tant que le domaine n’affiche pas la bonne version du site. Je vérifie donc que l’enregistrement DNS pointe vers le bon hébergement, puis je laisse le temps à la propagation de se faire. Dans la pratique, cela peut aller de quelques minutes à 24 heures, parfois un peu plus selon les DNS utilisés.

Ensuite, je traite le HTTPS. Le certificat SSL doit être actif avant ou au moment de l’ouverture publique, pas après. Sinon, le site peut afficher des avertissements de sécurité, ou pire, mélanger des ressources HTTP et HTTPS. Ce mélange de contenu, souvent appelé mixed content, apparaît quand des images, scripts ou feuilles de style continuent à charger avec l’ancienne adresse non sécurisée.

• Je m’assure que l’adresse publique du site est unique et cohérente.
• Je vérifie les champs WordPress Address (URL) et Site Address (URL) dans les réglages généraux.
• Je force, si possible, la redirection vers la version HTTPS du domaine.
• Je contrôle les anciennes ressources HTTP qui peuvent encore traîner dans la base.
• Je teste l’ouverture du site avec et sans www pour éviter les doublons d’URL.

Sur un site installé dans un sous-dossier ou sur un sous-domaine, je suis encore plus attentif à cette étape. Un simple décalage entre l’adresse de WordPress et l’adresse publique suffit à créer une boucle de redirection. Quand ce socle est stable, je peux enfin vérifier ce que les visiteurs et les moteurs de recherche vont réellement voir.

Vérifier la visibilité, les permaliens et les premiers tests

Juste avant de laisser les visiteurs arriver, je contrôle la visibilité du site. WordPress propose une option dédiée dans les réglages de lecture pour demander aux moteurs de ne pas indexer le site. C’est utile pendant la phase de préparation, mais il faut penser à la décocher au lancement. Je préfère le vérifier moi-même, car une simple mise en maintenance ne suffit pas toujours à bloquer l’indexation.

J’en profite pour faire une passe de contrôle très concrète. Je n’ouvre pas seulement la page d’accueil : je teste une page interne, un article, les médias, les menus, les formulaires et, si le site vend quelque chose, le parcours de commande. Sur mobile, je regarde aussi l’affichage réel, pas seulement la version bureau.

• Décocher l’option de visibilité pour les moteurs de recherche.
• Enregistrer une fois les permaliens pour régénérer les règles de réécriture.
• Vérifier les formulaires, les boutons, les menus et les liens internes.
• Tester les images, les fichiers téléversés et les pages légales.
• Ouvrir le site en navigation privée pour repérer les caches et les redirections gênantes.
• Contrôler les erreurs 404 et les redirections vers l’ancienne adresse.

C’est souvent à ce moment-là que l’on repère les petits détails qui n’étaient pas visibles en préproduction. Une page qui charge lentement, une image qui pointe encore vers l’ancien domaine ou une redirection mal placée ne sont pas des catastrophes, mais elles doivent être corrigées avant que le site commence à recevoir du trafic.

Ce que je contrôle encore dans les 48 heures suivant la mise en ligne

La mise en ligne ne se termine pas à l’instant où le site devient visible. Dans les deux jours qui suivent, je surveille surtout ce que les tests ne peuvent pas toujours prévoir : les erreurs de cache, les liens oubliés, les comportements de navigateur différents et les éventuelles anomalies de formulaire. C’est aussi le moment où les premiers index peuvent être pris en compte par les moteurs.

Voici le contrôle que je garde presque toujours sous la main :

• Vérifier les journaux d’erreurs ou les alertes de l’hébergeur.
• Purger le cache du site, du serveur et, s’il existe, du CDN.
• Contrôler que les sauvegardes automatiques sont actives.
• Observer les pages les plus importantes pour repérer une régression rapide.
• Vérifier qu’aucune extension de maintenance ou de protection n’est restée active.
• Noter les corrections à faire pendant la première fenêtre de maintenance réelle.

En pratique, la méthode la plus fiable reste simple : préparer, copier, corriger les URL, valider le domaine et le HTTPS, puis tester comme un visiteur extérieur. C’est cette discipline qui fait la différence entre un site simplement en ligne et un site vraiment prêt à recevoir du trafic sans mauvaise surprise.