Pourquoi Google crawle-t-il vos images sans extension deux fois avant de les indexer ?

Comment Google identifie-t-il qu'une URL est une image ?

Googlebot prend plusieurs décisions de routage avant même de crawler une URL. L'extension fichier (.jpg, .png, .webp, .svg) constitue le premier signal — le plus évident — pour déterminer le type de ressource. Si cette extension manque, le bot n'a aucune certitude a priori sur la nature du contenu.

Il existe trois voies possibles : l'URL paraît être une page HTML classique, un fichier image, ou un autre type de média. Sans extension, Google penche par défaut vers la recherche web, car statistiquement la majorité des URLs sans extension renvoient à des pages HTML générées dynamiquement (CMS, frameworks modernes). Le moteur effectue donc une requête HTTP, analyse les en-têtes de réponse, et constate — trop tard — que le Content-Type indique image/jpeg ou image/png.

Que se passe-t-il lors du premier crawl raté ?

Lorsque Googlebot traite l'URL comme une page web, il applique les règles du crawl budget web : timeout plus long, parser HTML activé, recherche de liens sortants. Le serveur répond avec un Content-Type image, ce qui déclenche une erreur de traitement — le contenu n'est pas du HTML valide.

Google marque cette tentative comme échec partiel et reprogramme l'URL pour un second passage, cette fois avec les paramètres du crawler Images. Ce second crawl arrive souvent plusieurs jours après le premier, selon la priorité du domaine et le crawl budget alloué. Entre-temps, l'image reste invisible dans Google Images, même si la page qui l'héberge est indexée.

Quel impact sur le crawl budget et l'indexation ?

Chaque URL crawlée deux fois consomme deux slots de crawl budget au lieu d'un seul. Sur un site hébergeant 10 000 images sans extension, cela représente 20 000 requêtes au lieu de 10 000 — soit un doublement du temps nécessaire pour indexer l'intégralité du catalogue visuel.

Les sites e-commerce générant des URLs d'images dynamiques (CDN avec paramètres, URLs de resize automatique) sont particulièrement touchés. Le délai d'apparition dans Google Images peut atteindre plusieurs semaines contre quelques jours avec extensions explicites. Les images de produits nouveaux ou saisonniers perdent en visibilité pendant leur période de pertinence maximale.

• Extensions reconnues : .jpg, .jpeg, .png, .webp, .gif, .svg, .bmp — routage immédiat vers Google Images
• URLs dynamiques sans extension : crawl web d'abord, échec, puis recrawl Images différé
• Content-Type seul insuffisant : Google ne fait pas de requête HEAD préalable pour vérifier le type MIME avant de crawler
• Impact crawl budget : doublement du nombre de requêtes pour les images sans extension
• Délai d'indexation Images : de quelques jours à plusieurs semaines selon la priorité du site

Cette déclaration est-elle cohérente avec les observations terrain ?

Oui, et c'est documenté depuis des années dans les logs serveur. Les sites migrant vers des CDN avec URLs paramétrées (type /media?id=12345&w=800) constatent systématiquement un effondrement temporaire du trafic Google Images, puis une récupération progressive sur 2-4 semaines. Les crawls apparaissent bien en double : premier passage avec user-agent Googlebot classique, second avec Googlebot-Image.

La nuance — et Mueller ne la mentionne pas — c'est que Google détecte parfois l'image dès le premier crawl si le Content-Type est envoyé avant le corps de la réponse HTTP. Dans ce cas, le bot peut interrompre la requête et la reprogrammer immédiatement en mode Images, évitant le délai de plusieurs jours. Mais ce scénario reste minoritaire et dépend de la configuration serveur.

Quelles limites techniques faut-il connaître ?

[A vérifier] : Mueller ne précise pas si les URLs avec extension mais Content-Type contradictoire (ex: .jpg renvoyant text/html) subissent le même traitement en double passe. Les tests montrent que oui, mais Google ne l'a jamais officialisé. L'extension reste un hint, pas une vérité absolue.

Autre angle mort : les formats d'images modernes comme .avif ou .jxl ne sont pas mentionnés. Google les supporte en affichage, mais le routage automatique par extension n'est peut-être pas actif pour ces formats émergents — aucune confirmation publique à ce jour. Les tests terrain suggèrent qu'ils sont traités comme des URLs sans extension, donc double crawl.

Dans quels cas cette règle ne s'applique-t-elle pas ?

Les sitemaps Images court-circuitent partiellement ce problème : si vous déclarez explicitement une URL comme image dans le sitemap XML (balise <image:image>), Google la route directement vers le pipeline Images sans tentative web préalable. Mais cela ne dispense pas d'ajouter l'extension pour les images découvertes via crawl classique.

Les images embarquées en base64 dans le HTML ne sont pas crawlées séparément, donc non concernées. Idem pour les sprites CSS. En revanche, les images lazy-loadées via JavaScript avec URLs dynamiques sans extension cumulent deux handicaps : détection tardée + double crawl. C'est un vrai gouffre à crawl budget sur les sites lourds.

Que faut-il modifier concrètement sur vos URLs d'images ?

Première étape : auditer les URLs d'images actuelles via Google Search Console (rapport Couverture, filtrer sur les erreurs liées aux images) et via un crawl Screaming Frog ou Oncrawl en mode "Images". Identifier toutes les URLs sans extension fichier visible — typiquement celles passant par des scripts de resize (/thumb.php?id=X) ou des CDN avec paramètres (/img?file=produit).

Deux solutions techniques : soit réécrire les URLs pour inclure l'extension réelle (URL rewriting Apache/Nginx), soit configurer le CDN pour qu'il ajoute l'extension en suffixe même si le fichier backend n'en a pas. La plupart des CDN modernes (Cloudflare, Fastly, Cloudinary) permettent cette transformation via rules ou workers. L'objectif est que l'URL vue par Googlebot se termine par .jpg, .png ou .webp.

Comment vérifier que Google traite correctement vos images ?

Utilisez l'outil d'inspection d'URL dans Search Console : collez une URL d'image, demandez une inspection en direct. Si Google retourne "Page non indexée" avec un message d'erreur HTML, c'est le signe que le bot l'a crawlée en mode web. Vérifiez ensuite les logs serveur pour confirmer un double passage Googlebot + Googlebot-Image.

Autre indicateur : le délai d'apparition dans Google Images après publication. Avec extension, comptez 24-72h sur un site crawlé régulièrement. Sans extension, le délai grimpe à 7-21 jours. Si vos images récentes n'apparaissent pas dans Images alors qu'elles sont visibles dans la recherche web, c'est probablement un problème d'extension manquante.

Quelles erreurs éviter lors de la migration ?

Ne vous contentez pas d'ajouter l'extension dans le nom de fichier backend — Google crawle l'URL publique, pas le filesystem serveur. Si votre CMS génère /media/12345 qui pointe vers /var/www/images/produit.jpg, Googlebot ne voit que /media/12345 et applique la double passe.

Autre piège : les redirections 301 vers des URLs avec extension. Google suit la redirection mais indexe l'URL finale, pas l'URL source. Si vos liens internes et externes pointent vers l'URL sans extension, vous continuez à gaspiller du crawl budget sur le premier crawl avant redirection. Mieux vaut réécrire directement les URLs canoniques.

• Auditer toutes les URLs d'images via Search Console et crawler tiers
• Identifier les URLs sans extension (.jpg, .png, .webp visible en fin d'URL)
• Configurer le serveur/CDN pour réécrire les URLs avec extension explicite
• Mettre à jour les sitemaps Images avec les nouvelles URLs
• Vérifier dans les logs serveur que Googlebot-Image crawle directement sans passage web préalable
• Monitorer le délai d'indexation dans Google Images (doit redescendre sous 72h)