10 000 pages produit importées en une seule opération via WP All Import, dans le cadre de l’ouverture d’un nouveau catalogue pour un site e-commerce spécialisé : l’opération technique s’est déroulée sans incident, jusqu’à ce que le serveur mutualisé hébergeant le site commence à répondre avec des erreurs 503 par intermittence, deux jours après l’import.
Le diagnostic initial : un pic de trafic mal identifié
Le premier réflexe a été de vérifier les statistiques de fréquentation humaine, en supposant un afflux de visiteurs lié à l’ouverture du nouveau catalogue. Les chiffres d’audience réelle ne montraient pourtant aucune hausse significative sur la période concernée. C’est l’analyse des logs serveur bruts, filtrés sur les user-agents robots, qui a révélé la cause réelle : le nombre de requêtes journalières de Googlebot avait été multiplié par plus de dix par rapport à la moyenne des semaines précédentes, au point de représenter la majorité du trafic total reçu par le serveur sur cette période.
awk '{print $1}' access.log | sort | uniq -c | sort -rn | head -5
grep -c "Googlebot" access.logPourquoi Googlebot a réagi aussi fortement
La publication simultanée de 10 000 URL nouvelles, toutes référencées d’un coup dans un plan de site XML régénéré en une seule fois, a été interprétée par Googlebot comme un signal fort justifiant une intensification immédiate et soutenue de l’exploration du site — un comportement documenté par Google lui-même dans sa documentation sur la gestion du budget d’exploration, qui indique que le taux d’exploration s’ajuste dynamiquement à la disponibilité perçue du serveur et à la fraîcheur du contenu détectée.
Le serveur mutualisé, dimensionné pour la charge habituelle du site, n’a pas supporté ce pic soutenu combinant les requêtes de Googlebot et le trafic humain existant, d’où les erreurs 503 intermittentes qui, si elles avaient persisté, auraient fini par pousser Google à réduire drastiquement son taux d’exploration du site dans son ensemble, contenu ancien compris.
La solution : échelonner plutôt qu’importer en masse
La solution retenue pour les imports suivants a consisté à échelonner la publication des nouvelles pages sur plusieurs jours plutôt que de les publier en une seule opération, en s’appuyant sur la fonctionnalité de planification native de WP All Import combinée à un script de contrôle du rythme de publication :
wp cron event schedule publier_lot_produits \
"+1 hour" --hook="importer_lot_suivant"Ce script publiait environ 500 nouvelles fiches produit par heure plutôt que 10 000 en une seule fois, laissant au serveur le temps d’absorber la charge combinée du crawl et du trafic humain sans dégradation de performance perceptible.
Un second levier : la remontée en priorité auprès de l’hébergeur
En parallèle, une discussion avec l’hébergeur a permis d’ajuster temporairement les limites de ressources allouées au compte pendant la période de montée en charge du catalogue, une mesure ponctuelle plus simple à obtenir qu’une migration complète vers une offre supérieure, suffisante pour couvrir la fenêtre de vulnérabilité.
- Échelonner tout import de plus de 1 000 pages sur plusieurs jours, jamais en une seule opération.
- Surveiller les logs serveur pendant les 72 heures suivant un import massif, pas seulement les outils d’audience classiques.
- Prévenir l’hébergeur en amont d’un import volumineux prévu, pour anticiper un éventuel ajustement de ressources.
Un pic de contenu publié en une seule fois n’est jamais neutre pour un serveur : Googlebot réagit à la nouveauté détectée par une intensification du crawl, que l’infrastructure doit être capable d’absorber avant même de penser au référencement des nouvelles pages elles-mêmes.
En résumé
Un import massif de contenu sur WordPress ne pose pas seulement une question de structure de données ou de mapping de champs : il déclenche une réaction de Googlebot proportionnelle au volume de nouveauté détecté, que l’infrastructure serveur doit pouvoir encaisser. Échelonner la publication sur plusieurs jours, plutôt que de tout publier d’un bloc, reste la mesure la plus simple pour éviter qu’un pic de crawl ne se transforme en incident de disponibilité.
