Maintenance sans perdre son SEO

Q: Que faire si la maintenance dure plus longtemps que prévu ?

Mettez à jour le header Retry-After avec une nouvelle estimation réaliste. Évitez d'enchaîner des Retry-After courts non respectés.

Q: Mon hébergeur impose sa propre page de maintenance, comment faire ?

Contactez le support pour demander l'ajout du header Retry-After. Si impossible, envisagez Cloudflare en mode maintenance ou changez d'hébergeur.

Le guide complet pour les webmasters exigeants

Mise à jour, migration, refonte : protégez votre référencement à chaque intervention.

Le paradoxe de la maintenance

Vous devez mettre votre site hors ligne pour l’améliorer. Mais chaque minute d’indisponibilité est un risque : visiteurs perdus, ventes manquées, et potentiellement… des positions Google qui s’envolent.

La bonne nouvelle : une maintenance bien préparée est totalement transparente pour les moteurs de recherche. Google sait que les sites ont besoin d’évoluer. Il suffit de lui parler correctement.

Ce guide vous donne la méthode complète, étape par étape.

Les 3 règles d’or

1. Le bon code HTTP

Toujours retourner un 503 Service Unavailable, jamais un 200, jamais une redirection 302. C’est le seul code qui dit à Google : « C’est temporaire, reviens plus tard. »

Comprendre les codes HTTP →

2. Le header Retry-After

Indiquer à Google quand revenir avec le header Retry-After. Sans lui, Google devine. Avec lui, Google obéit.

Configurer le Retry-After →

3. La durée minimale

Moins de 6 heures : aucun risque. Moins de 24 heures : risque minimal. Au-delà : chaque heure compte.

Impact SEO détaillé →

Configuration technique pas à pas

Étape 1 : Préparer la page de maintenance

Créez une page HTML autonome (pas de dépendance au CMS) :

/var/www/html/maintenance.html

<!DOCTYPE html>
<html lang="fr">
<head>
    <meta charset="UTF-8">
    <meta name="viewport" content="width=device-width, initial-scale=1.0">
    <title>Maintenance en cours - Votresite.com</title>
    <style>
        * { margin: 0; padding: 0; box-sizing: border-box; }
        body {
            font-family: -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif;
            background: linear-gradient(135deg, #1a1a2e 0%, #16213e 100%);
            color: #fff;
            min-height: 100vh;
            display: flex;
            align-items: center;
            justify-content: center;
            text-align: center;
            padding: 20px;
        }
        .container { max-width: 600px; }
        h1 { font-size: 2.5rem; margin-bottom: 1rem; }
        .icon { font-size: 4rem; margin-bottom: 1.5rem; }
        p { font-size: 1.2rem; opacity: 0.9; margin-bottom: 2rem; }
        .eta { 
            background: rgba(255,153,0,0.2); 
            border: 1px solid #ff9900;
            padding: 1rem 2rem; 
            border-radius: 8px;
            display: inline-block;
        }
        .eta strong { color: #ff9900; }
    </style>
</head>
<body>
    <div class="container">
        <div class="icon">??</div>
        <h1>Maintenance en cours</h1>
        <p>Nous améliorons votre expérience. Le site sera de retour très bientôt.</p>
        <div class="eta">
            Retour prévu : <strong>14h00</strong>
        </div>
    </div>
</body>
</html>

Pourquoi une page statique ? Si votre CMS est en maintenance, il ne peut pas servir la page. Un fichier HTML simple fonctionne toujours.

Besoin d’une page plus élaborée ? Notre générateur de page maintenance crée des templates professionnels avec compte à rebours et capture d’emails.

Étape 2 : Configurer le serveur

Choisissez votre configuration selon votre environnement :

.htaccess

# ============================================
# MODE MAINTENANCE - À ACTIVER QUAND NÉCESSAIRE
# ============================================

RewriteEngine On

# 1. Votre IP (pour continuer à travailler)
RewriteCond %{REMOTE_ADDR} !^123.456.789.012$
# Ajoutez d'autres IPs si besoin :
# RewriteCond %{REMOTE_ADDR} !^111.222.333.444$

# 2. Exclure les fichiers statiques (optionnel, pour le style)
RewriteCond %{REQUEST_URI} !.(css|js|png|jpg|gif|svg|ico|woff2?)$

# 3. Exclure la page maintenance elle-même
RewriteCond %{REQUEST_URI} !^/maintenance.html$

# 4. Tout le reste → 503
RewriteRule ^(.*)$ /maintenance.html [R=503,L]

# 5. Header Retry-After (2 heures = 7200 secondes)
Header always set Retry-After "7200"

# 6. Empêcher la mise en cache de la maintenance
Header always set Cache-Control "no-store, no-cache, must-revalidate"

/etc/nginx/sites-available/monsite.conf

server {
    listen 80;
    server_name monsite.com www.monsite.com;

    # Variable de maintenance (1 = activé)
    set $maintenance 1;

    # Exclure votre IP
    if ($remote_addr = "123.456.789.012") {
        set $maintenance 0;
    }

    # Page de maintenance
    error_page 503 @maintenance;

    location @maintenance {
        root /var/www/html;
        add_header Retry-After 7200 always;
        add_header Cache-Control "no-store, no-cache" always;
        rewrite ^(.*)$ /maintenance.html break;
    }

    # Laisser passer les fichiers statiques (optionnel)
    location ~* .(css|js|png|jpg|gif|svg|ico|woff2?)$ {
        # Configuration normale
    }

    # Toutes les autres requêtes
    location / {
        if ($maintenance = 1) {
            return 503;
        }
        # Configuration normale (proxy_pass, fastcgi, etc.)
    }
}

maintenance-check.php

<?php
/**
 * À inclure en tout premier dans index.php ou config
 * Fonctionne avec WordPress, PrestaShop, Laravel, etc.
 */

// Fichier flag : créez-le pour activer la maintenance
$maintenance_flag = __DIR__ . '/.maintenance';

if (file_exists($maintenance_flag)) {
    
    // IPs autorisées (vous + votre équipe)
    $allowed_ips = [
        '123.456.789.012',
        '111.222.333.444',
    ];
    
    // Laisser passer les IPs autorisées
    $client_ip = $_SERVER['REMOTE_ADDR'];
    if (in_array($client_ip, $allowed_ips)) {
        return; // Continue normalement
    }
    
    // Lire la durée depuis le fichier (optionnel)
    $retry_after = trim(file_get_contents($maintenance_flag)) ?: 7200;
    
    // Envoyer les headers
    http_response_code(503);
    header('Retry-After: ' . $retry_after);
    header('Cache-Control: no-store, no-cache, must-revalidate');
    header('Content-Type: text/html; charset=UTF-8');
    
    // Afficher la page
    readfile(__DIR__ . '/maintenance.html');
    exit;
}

Pour activer/désactiver :

# Activer (avec durée en secondes)
$ echo "7200" > .maintenance

# Désactiver
$ rm .maintenance

Étape 3 : Tester AVANT de lancer

Ne lancez jamais une maintenance sans avoir testé la configuration :

# 1. Vérifier le code HTTP (depuis une IP non autorisée, ou via proxy)
$ curl -I https://votresite.com
HTTP/1.1 503 Service Unavailable
Retry-After: 7200
# ✅ Parfait

# 2. Vérifier que votre IP est bien exclue
$ curl -I https://votresite.com
HTTP/1.1 200 OK
# ✅ Vous pouvez travailler

# 3. Vérifier une page profonde
$ curl -I https://votresite.com/categorie/produit/123
HTTP/1.1 503 Service Unavailable
# ✅ Toutes les URLs retournent 503

Test crucial : Vérifiez depuis une autre connexion (4G, VPN, Status Checker) que la 503 s’affiche bien. Votre IP locale est exclue, vous ne verrez pas l’erreur.

Durée optimale selon le type de maintenance

Intervention	Durée typique	Retry-After	Risque SEO
Mise à jour plugin/module	5-15 min	`900`	Nul
Mise à jour CMS mineure	15-30 min	`1800`	Nul
Mise à jour CMS majeure (WP 6.x, PS 8.x)	1-2h	`7200`	Très faible
Migration de thème	2-4h	`14400`	Faible
Migration de serveur	2-6h	`21600`	Modéré si > 4h
Migration de base de données	4-12h	`43200`	Élevé
Refonte complète	12-48h	—	Très élevé

Au-delà de 6 heures : Envisagez une approche alternative (maintenance partielle, staging avec bascule DNS, déploiement progressif). La maintenance longue n’est plus une bonne pratique.

Stratégies pour les maintenances longues

Quand l’intervention dépasse la fenêtre de sécurité, adoptez une approche différente :

Option 1 : Maintenance nocturne

Planifiez entre 2h et 6h du matin (heure locale de votre audience principale). Le trafic est minimal, et vous avez une marge avant le réveil de vos visiteurs.

Statistique : Un site français B2C reçoit en moyenne 3% de son trafic quotidien entre 2h et 6h. C’est 97% de risque en moins.

Option 2 : Maintenance partielle

Ne mettez en 503 que les sections concernées :

# Maintenance uniquement sur /admin et /checkout
RewriteCond %{REQUEST_URI} ^/(admin|checkout) [NC]
RewriteRule ^(.*)$ /maintenance.html [R=503,L]

Le reste du site reste accessible et indexable.

Option 3 : Environnement de staging + bascule DNS

Préparez la nouvelle version sur un serveur de staging
Testez complètement
Basculez le DNS (TTL réduit au préalable)
Downtime réel : quelques minutes (propagation DNS)

Cette approche est recommandée pour les migrations majeures. Foxop accompagne ce type d’infrastructure.

Option 4 : Déploiement blue-green

Pour les sites à très fort trafic :

flowchart LR
    LB[Load Balancer] --> A[Serveur Blue
Version actuelle]
    LB -.-> B[Serveur Green
Nouvelle version]
    
    subgraph "Pendant la migration"
    LB2[Load Balancer] --> B2[Serveur Green
Nouvelle version]
    LB2 -.-> A2[Serveur Blue
Rollback si besoin]
    end

Aucune interruption de service. Rollback instantané si problème.

Après la maintenance : les vérifications

La maintenance est terminée, le site est revenu. Ne partez pas tout de suite :

Immédiatement (< 5 min)

# 1. Vérifier que le 503 a disparu
$ curl -I https://votresite.com
HTTP/1.1 200 OK  # ✅

# 2. Vérifier plusieurs pages
$ curl -I https://votresite.com/page-importante
$ curl -I https://votresite.com/categorie/produit

# 3. Vérifier que le Retry-After a disparu
$ curl -sI https://votresite.com | grep -i retry
# (aucun résultat = ✅)

Dans l’heure

[ ] Navigation complète du site (liens, formulaires, panier)
[ ] Test de paiement si e-commerce
[ ] Vérification des logs d’erreur
[ ] Monitoring : temps de réponse normaux ?

Dans les 24-48h

[ ] Google Search Console : erreurs d’exploration ?
[ ] Statistiques d’exploration : crawl normal ?
[ ] Analytics : trafic organique stable ?

Si vous constatez une baisse de crawl ou d’indexation, soumettez à nouveau votre sitemap et demandez une indexation des pages principales via Search Console.

Cas pratiques par CMS

WordPress

Le mode maintenance natif de WordPress (fichier .maintenance) ne gère pas le header Retry-After. Utilisez plutôt :

wp-content/mu-plugins/maintenance-seo.php

<?php
/**
 * Plugin Must-Use : Maintenance SEO-friendly
 * Activer : créer wp-content/.maintenance-seo
 */

add_action('init', function() {
    $flag = WP_CONTENT_DIR . '/.maintenance-seo';
    
    if (!file_exists($flag)) return;
    if (current_user_can('administrator')) return;
    
    $retry = (int) file_get_contents($flag) ?: 3600;
    
    http_response_code(503);
    header("Retry-After: $retry");
    
    wp_die(
        '<h1>Maintenance en cours</h1><p>Nous revenons bientôt !</p>',
        'Maintenance',
        ['response' => 503]
    );
}, 1);

WPHelp247 peut gérer vos maintenances WordPress de A à Z.

PrestaShop

PrestaShop a un mode maintenance intégré (back-office > Paramètres > Général), mais sans Retry-After. Complétez avec :

override/classes/controller/FrontController.php

<?php
class FrontController extends FrontControllerCore
{
    public function init()
    {
        parent::init();
        
        if (!Configuration::get('PS_SHOP_ENABLE')) {
            $maintenance_ip = Configuration::get('PS_MAINTENANCE_IP');
            $allowed = array_map('trim', explode(',', $maintenance_ip));
            
            if (!in_array(Tools::getRemoteAddr(), $allowed)) {
                header('Retry-After: 7200');
            }
        }
    }
}

N’oubliez pas de vider le cache après modification. Pour les migrations PrestaShop critiques, IllicoPresta vous accompagne.

Planifiez votre prochaine maintenance

Checklist interactive, configuration générée, timing optimisé.

Lancer le Maintenance Planner

Questions fréquentes

Puis-je faire une maintenance sans aucun impact SEO ?

Oui, absolument. Une maintenance de moins de 6 heures avec un code 503 et un header Retry-After correctement configurés n’a aucun impact mesurable sur le référencement. Google comprend et attend sagement.

Faut-il prévenir Google avant une maintenance ?

Non, ce n’est pas nécessaire. Le code 503 + Retry-After est le « langage » prévu pour ça. Google n’offre pas de mécanisme pour annoncer une maintenance à l’avance. Votre configuration technique suffit.

Que faire si la maintenance dure plus longtemps que prévu ?

Mettez à jour le header Retry-After avec une nouvelle estimation réaliste. Google reviendra à l’heure initialement prévue, recevra le nouveau délai, et attendra à nouveau. Évitez d’enchaîner des Retry-After courts non respectés : c’est pire que d’annoncer une durée plus longue d’emblée.

Mon hébergeur impose sa propre page de maintenance, comment faire ?

Contactez le support pour demander l’ajout du header Retry-After. Si impossible, envisagez une solution intermédiaire (Cloudflare en mode maintenance avec page personnalisée) ou changez d’hébergeur pour un qui vous donne le contrôle total.