La qualité d’une mise en ligne se juge sur la production après la bascule, pas sur la recette de la veille. Le fait qui compte : https://example.com/robots.txt ne contient pas Disallow: /, WP_DEBUG est à false dans wp-config.php, et l’accueil répond 200 en HTTPS avec un certificat au nom de cet hôte. Tant que ces trois points ne sont pas notés, le site n’est pas en ligne. Il est seulement joignable.
Avant de toucher au DNS
La copie a été parcourue avec le fichier hosts ou l’URL temporaire. Vous avez une sauvegarde de l’ancienne production identifiable par une heure. Vous savez qui peut revenir en arrière. Le robots.txt de la copie de travail a souvent servi à bloquer les robots pendant la recette : il doit être remplacé par celui de production avant la bascule, pas juste après , parce que juste après est le moment où tout le monde regarde ailleurs.
Listez les hôtes qui ne doivent plus apparaître dans le HTML : l’URL de staging, l’adresse IP, le domaine temporaire de l’hébergeur. Une recherche dans la base et dans les fichiers les trouve. Sur WordPress, un remplacement d’URL se fait avec un outil qui respecte les données sérialisées (wp search-replace), pas avec un remplacer brut dans SQL, qui casse les widgets et les réglages.
La liste, dans l’ordre, le jour même
- Certificat : le nom du site est dans le certificat, pas seulement un autre sous-domaine. La date d’expiration est au-delà du mois.
- Variantes : http, https, avec www et sans www. Une seule répond 200. Les autres répondent 301 vers elle. Pas de chaîne de deux redirections sur l’accueil.
- robots.txt : pas de
Disallow: /. Le sitemap indiqué pointe vers le domaine de production et répond 200. - Trois pages : accueil, page de demande, une page intérieure. Code 200, pas de balise noindex résiduelle, canonique égale à l’URL affichée.
- Une URL inconnue répond 404, pas 200. Une page introuvable en 200 est un soft 404.
- Formulaire : un envoi vers la boîte de test de l’agence arrive. Le message de succès à l’écran ne suffit pas.
- Administration : connexion possible,
WP_DEBUGà false, pas d’erreurs PHP affichées aux visiteurs. - Recherche du nom d’hôte de staging dans le HTML de l’accueil et d’une page intérieure : zéro occurrence.
- Search Console : propriété du bon hôte, sitemap soumis. L’inspection d’URL de l’accueil, en test en direct, voit la page.
- Retrait du 503 s’il a été posé. Nouveau contrôle de l’accueil après ce retrait.
Cochez sur le procès-verbal, avec l’heure de chaque bloc. Une case vide est un contrôle non fait.
Ce qui se joue souvent mal
Le fichier robots.txt de recette recopié tel quel. Le détail des lignes qui bloquent trop large est dans robots.txt : configuration et pièges. La redirection http vers https incomplète, ou seulement posée sur l’accueil, laisse des URL intérieures en double. Le bon réflexe de contrôle est celui de rediriger HTTP vers HTTPS.
Le formulaire testé sur le staging et plus en production, alors que le SMTP de production a un mot de passe différent. L’admin qui affiche des notices PHP parce que le wp-config.php de développement a suivi le dépôt. Les médias qui pointent encore vers l’ancien hôte : la page répond 200, les images non.
Demander l’indexation de l’accueil a un sens une fois ces points verts, pas avant. Le geste dans Search Console est décrit dans demander l’indexation. L’exiger dix fois ne corrige pas un noindex.
Le procès-verbal
Une page : site, heure de bascule DNS, heure de fin des contrôles, nom, cases, incidents restants (aucun, ou une liste datée). Le client la reçoit le jour même. Elle est le livrable. Une mise en ligne sans procès-verbal est une conversation. Vous ne pourrez pas montrer, plus tard, que le robots.txt a été lu.
La charte de mise en production peut porter cette liste pour toute l’agence, afin que le dixième site du mois ne dépende pas de la mémoire du chef de projet. La charte sans le procès-verbal du jour ne prouve rien sur ce site-là. Les deux se rangent ensemble.