Pourquoi analyser le crawl de vos pages web ?
Si votre page HTML dépasse 2 MB, Googlebot la tronque silencieusement. Pas d'erreur dans la Search Console, pas d'avertissement : le contenu en bas de page disparaît de l'index Google (source : documentation Google). Et ce n'est qu'une partie du problème : robots.txt mal configuré, sous-ressources excessives, redirections JavaScript invisibles et mauvaise compression consomment votre crawl budget sans que vous le sachiez.
Cinq raisons d'analyser le crawl de vos pages :
- Éviter la troncature - Les pages avec du HTML inline lourd (SVG, CSS, JSON-LD volumineux) dépassent souvent la limite sans que vous le sachiez
- Vérifier l'accès Googlebot - Un robots.txt mal configuré peut bloquer le crawl de pages importantes
- Optimiser le crawl budget - Des pages plus légères avec moins de sous-ressources = plus de pages crawlées par Google dans le temps imparti
- Détecter les redirections invisibles - Les meta refresh et redirections JavaScript ne sont pas toujours suivis par Googlebot
- Comparer mobile vs desktop - Le mobile-first indexing signifie que la version smartphone est celle qui compte pour l'indexation
Comment utiliser le page crawl checker en 3 étapes
Étape 1 : Entrer l'URL de la page
Saisissez l'URL complète de la page à analyser dans le champ ci-dessus. L'outil accepte toute URL publique accessible, y compris les fichiers PDF :
https://www.captaindns.com/fr
Testez vos pages les plus longues en priorité : pages catégories, pages produits avec beaucoup de variantes, articles de blog avec de nombreuses images inline.
Étape 2 : Choisir le User-Agent et les options
Sélectionnez le User-Agent pour simuler le crawl :
- Googlebot smartphone (recommandé) : simule le crawl mobile-first, celui que Google utilise pour l'indexation principale
- Googlebot desktop : utile pour comparer la version desktop si votre site sert un HTML différent
- Mode comparaison : testez les deux User-Agents simultanément pour détecter les différences de contenu, de taille et de headers
Dans les options avancées, vous pouvez ajouter des headers HTTP personnalisés. Utile pour tester un site derrière un CDN, un reverse proxy, ou pour envoyer un cookie d'authentification spécifique.
Étape 3 : Consulter le rapport complet
Le rapport affiche :
- KPI en tête de page : taille, score crawl budget, nombre de sous-ressources, temps de réponse, redirections client
- Barre de progression : ratio visuel par rapport à la limite de 2 MB (ou 64 MB pour les PDF)
- robots.txt : vérification que Googlebot est autorisé à crawler l'URL, crawl-delay et sitemaps détectés
- Headers HTTP : Content-Type, Content-Encoding, Cache-Control, X-Robots-Tag, et vos headers personnalisés envoyés
- Analyse HTML : balises méta, headings, liens, données structurées, ressources inline
- Sous-ressources : inventaire complet des scripts, CSS, images, fonts, iframes avec taille et statut
- Crawl budget : score sur 100 avec détail des facteurs et impact individuel
- Redirections client : meta refresh et JavaScript détectés dans le HTML
- Empreinte de contenu : hash SHA-256 pour détecter les changements entre analyses
- Simulation de troncature : si applicable, visualisez exactement où Googlebot couperait
- Recommandations : actions concrètes priorisées par impact
Qu'est-ce que la limite de 2 MB de Googlebot ?
Google documente une limite de taille pour le crawl : Googlebot peut télécharger et indexer les premiers 2 097 152 octets (2 MB) du code source HTML d'une page. Au-delà, le contenu est tronqué. Pour les fichiers PDF, la limite est de 64 MB.
Ce que cela signifie concrètement :
| Type de contenu | Limite | Conséquence si dépassement |
|---|---|---|
| HTML | 2 MB (2 097 152 octets) | Troncature : contenu en fin de page ignoré |
| 64 MB | Troncature du contenu textuel extrait |
Attention : la limite HTML s'applique au contenu décompressé. La compression gzip/brotli ne change rien : un HTML de 3 MB compressé en transit sera toujours tronqué à 2 MB après décompression.
Pages à risque :
- Pages e-commerce avec des centaines de produits listés en HTML
- Landing pages avec du SVG inline ou du CSS embarqué volumineux
- Pages avec du JSON-LD structuré très détaillé (ex: FAQ de 50+ questions)
- Pages générées côté serveur avec du JavaScript inline abondant
Qu'analyse exactement l'outil ?
Analyse de taille
| Élément | Description |
|---|---|
| Taille brute | Poids exact du HTML retourné par le serveur, en octets |
| Taille décompressée | Taille après décodage gzip/brotli (celle qui compte pour Googlebot) |
| Ratio limite | Pourcentage de la limite consommé (2 MB pour HTML, 64 MB pour PDF) |
| Type de contenu | Détection automatique HTML, PDF ou autre avec badge visuel |
Vérification robots.txt
| Élément | Ce que l'outil vérifie |
|---|---|
| Accès Googlebot | L'URL testée est-elle autorisée ou bloquée par robots.txt ? |
| Agent matché | Quelle règle s'applique (Googlebot, *, etc.) |
| Crawl-delay | Délai imposé entre les requêtes de crawl |
| Sitemaps | Fichiers sitemap déclarés dans robots.txt |
Headers HTTP
| Header | Pourquoi c'est important |
|---|---|
| Content-Type | Confirme que le serveur renvoie bien du HTML (ou un PDF) |
| Content-Encoding | Indique si la compression est active (gzip, br) |
| X-Robots-Tag | Détecte un éventuel noindex/nofollow au niveau HTTP |
| Cache-Control | Configuration du cache qui impacte la fréquence de crawl |
| Headers personnalisés | Vos headers envoyés sont affichés pour confirmation |
Analyse HTML
| Élément | Ce que l'outil vérifie |
|---|---|
| Balises méta | Présence et contenu de title, description, robots, canonical |
| Structure | Hiérarchie des headings (H1-H6) avec position en octets |
| Liens | Nombre de liens internes, externes et nofollow détectés |
| Données structurées | JSON-LD détecté avec taille et types identifiés |
| Ressources inline | Scripts, styles, SVG et data URIs embarqués dans le HTML |
Sous-ressources
| Élément | Ce que l'outil vérifie |
|---|---|
| Scripts | Fichiers JavaScript externes chargés par la page |
| CSS | Feuilles de style externes |
| Images | Images référencées dans le HTML |
| Fonts | Polices web chargées |
| Iframes | Contenus tiers embarqués |
| Ressources tierces | Sous-ressources chargées depuis d'autres domaines |
| Erreurs de chargement | Ressources retournant une erreur HTTP (404, 500, etc.) |
Score crawl budget
| Élément | Ce que l'outil évalue |
|---|---|
| Score global | Note sur 100, pondérée par l'importance de chaque facteur |
| Taille de la page | Impact du poids HTML sur le budget de crawl |
| Nombre de sous-ressources | Chaque requête consomme du budget |
| Ressources tierces | Les domaines externes ajoutent de la latence |
| Temps de réponse | Une réponse lente réduit le nombre de pages crawlées |
| Compression | L'absence de compression gaspille la bande passante |
Redirections côté client
| Élément | Ce que l'outil détecte |
|---|---|
| Meta refresh | Balises <meta http-equiv="refresh"> avec URL et délai |
| JavaScript | Patterns window.location, document.location, location.href |
| Position dans le HTML | Localisation en octets de la redirection détectée |
Empreinte de contenu
| Élément | Description |
|---|---|
| Hash SHA-256 | Empreinte unique du contenu de la page |
| Détection de changements | Comparez le hash entre deux analyses pour savoir si le contenu a changé |
| Comparaison mobile/desktop | Si les deux versions ont le même hash, le contenu est identique |
Comparaison mobile vs desktop
| Élément | Ce que l'outil compare |
|---|---|
| Taille | Différence de poids HTML entre les deux versions |
| Headers | Différences de Content-Type, compression, cache, X-Robots-Tag |
| Balises méta | Title, description, canonical, robots différents ? |
| Structure | Nombre de headings, liens, données structurées |
| Empreinte | Même hash = contenu identique, hash différent = contenu distinct |
| Verdict | Synthèse : identique, différences mineures ou critiques |
Entrez votre URL ci-dessus pour obtenir l'analyse complète de votre page.
Cas d'usage concrets
Cas 1 : Page e-commerce avec des milliers de produits
Symptôme : Votre page catégorie liste 500 produits en HTML. Le bas de page (pagination, FAQ, liens vers les sous-catégories) n'apparaît pas dans les résultats Google.
Diagnostic avec l'outil : La page fait 3,2 MB de HTML. Googlebot tronque à 2 MB, perdant les 200 derniers produits, la FAQ et tous les liens de navigation en pied de page.
Action : Passer à une pagination avec chargement dynamique (lazy load), limiter le listing initial à 50 produits, déplacer la FAQ en haut de page.
Cas 2 : Score crawl budget faible à cause des sous-ressources
Symptôme : Google crawle peu de pages de votre site malgré un contenu régulièrement mis à jour. Vos nouvelles pages mettent des semaines à apparaître dans l'index.
Diagnostic avec l'outil : Chaque page charge 85 sous-ressources dont 40 scripts tiers (analytics, widgets, AB testing). Le score crawl budget est de 35/100. Les ressources tierces représentent 60 % des requêtes.
Action : Charger les scripts tiers en différé (defer/async), supprimer les scripts inutilisés, regrouper les fichiers CSS et JS, utiliser le lazy loading pour les images sous le fold.
Cas 3 : Redirection JavaScript invisible pour Googlebot
Symptôme : Votre page redirige correctement les utilisateurs vers la nouvelle URL, mais l'ancienne page reste indexée dans Google et la nouvelle n'apparaît pas.
Diagnostic avec l'outil : L'outil détecte un window.location.href dans le HTML. C'est une redirection JavaScript que Googlebot ne suit pas systématiquement. Aucune redirection HTTP (301/302) n'est configurée.
Action : Remplacer la redirection JavaScript par une redirection HTTP 301 côté serveur. Si une transition est nécessaire, ajouter une balise <link rel="canonical"> pointant vers la nouvelle URL.
Cas 4 : robots.txt bloque une section importante
Symptôme : Vos pages /fr/blog/ ne sont plus indexées depuis la mise à jour de votre robots.txt. Aucune erreur visible dans la Search Console.
Diagnostic avec l'outil : L'analyse robots.txt affiche "URL bloquée" avec la règle Disallow: /fr/ qui bloque tout le contenu francophone. Le robots.txt visait à bloquer /fr/admin/ mais la règle est trop large.
Action : Corriger robots.txt en remplaçant Disallow: /fr/ par Disallow: /fr/admin/. Vérifier avec l'outil que les pages importantes sont autorisées.
Cas 5 : Contenu différent entre mobile et desktop
Symptôme : Votre classement Google baisse alors que votre contenu desktop est complet et bien optimisé.
Diagnostic avec l'outil : Le mode comparaison révèle que la version smartphone sert un HTML allégé : la FAQ, les avis clients et 3 sections de contenu sont absents. Les empreintes SHA-256 sont différentes. Google indexe la version mobile, qui est incomplète.
Action : S'assurer que la version mobile contient le même contenu SEO que la version desktop. Utiliser le responsive design plutôt que du contenu conditionnel côté serveur.
Cas 6 : Migration avec perte de compression
Symptôme : Après une migration de serveur, vos pages chargent plus lentement et Google crawle moins de pages.
Diagnostic avec l'outil : Le header Content-Encoding est absent. Le serveur ne compresse plus le HTML. Le score crawl budget passe de 78/100 à 52/100.
Action : Réactiver la compression gzip/brotli sur le nouveau serveur. Vérifier la configuration nginx/Apache.
Testez vos pages avec l'outil ci-dessus pour identifier les problèmes spécifiques à votre site.
❓ FAQ - Questions fréquentes
Q : Quel est le poids moyen d'une page web ?
R : En 2025, le poids médian d'une page web est d'environ 2,5 MB (tous types de ressources confondus). Mais le HTML seul pèse généralement entre 50 KB et 500 KB. C'est la taille du HTML qui compte pour la limite de crawl Googlebot, pas le poids total incluant images, CSS et JavaScript.
Q : Que se passe-t-il quand une page dépasse 2 MB ?
R : Googlebot tronque le HTML au-delà de 2 097 152 octets. Tout le contenu après ce point est ignoré pour l'indexation. Concrètement : liens internes, FAQ structurée, texte SEO en bas de page ne sont plus pris en compte pour le classement dans les résultats de recherche.
Q : Qu'est-ce que le crawl budget ?
R : Le crawl budget est le nombre de pages que Googlebot peut crawler sur votre site dans un temps donné. Des pages lourdes avec beaucoup de sous-ressources consomment plus de ressources serveur et réseau, réduisant le nombre total de pages crawlées. Notre outil calcule un score sur 100 pour évaluer l'efficacité de chaque page.
Q : Pourquoi les sous-ressources impactent le crawl ?
R : Chaque sous-ressource (script, CSS, image, font) nécessite une requête HTTP supplémentaire. Googlebot a une capacité de crawl limitée par domaine. Une page chargeant 80+ sous-ressources consomme beaucoup plus de budget qu'une page en chargeant 20. Les ressources tierces ajoutent de la latence et des dépendances externes.
Q : Qu'est-ce qu'une redirection côté client ?
R : C'est une redirection effectuée par le navigateur via une balise meta refresh ou du JavaScript (window.location). Contrairement aux redirections HTTP (301, 302), Googlebot ne les suit pas toujours. Si votre seule redirection est côté client, la page de destination peut ne jamais être indexée.
Q : L'outil vérifie-t-il le fichier robots.txt ?
R : Oui. L'outil récupère automatiquement le robots.txt du domaine et vérifie si Googlebot est autorisé à crawler l'URL testée. Il détecte aussi le crawl-delay et les sitemaps déclarés. Si robots.txt bloque l'URL, un avertissement s'affiche, mais l'analyse de la page continue pour que vous puissiez voir le contenu quand même.
Q : L'outil fonctionne-t-il avec les fichiers PDF ?
R : Oui. L'outil détecte automatiquement les fichiers PDF et adapte la limite de taille : 64 MB au lieu de 2 MB pour le HTML. Un badge PDF s'affiche dans le rapport et l'analyse HTML est désactivée (non applicable aux PDF).
Q : À quoi sert l'empreinte de contenu (hash) ?
R : L'outil génère un hash SHA-256 du contenu de la page. Cette empreinte permet de détecter si le contenu a changé entre deux analyses, ou si les versions mobile et desktop servent un contenu identique. Utile pour surveiller les modifications non intentionnelles après un déploiement.
Q : Pourquoi choisir Googlebot smartphone plutôt que desktop ?
R : Google utilise le mobile-first indexing depuis 2019 : c'est la version smartphone de votre page qui est indexée en priorité. Testez avec le User-Agent smartphone pour voir exactement ce que Google indexe. Le mode comparaison permet de vérifier que les deux versions sont cohérentes.
Q : Pourquoi comparer les versions mobile et desktop ?
R : Google utilise le mobile-first indexing depuis 2019 : c'est la version smartphone qui est indexée en priorité. Si votre version mobile sert un contenu différent (moins de texte, FAQ absente, liens manquants), votre classement en souffre. Le mode comparaison détecte ces différences et les classe par sévérité.
Q : Comment réduire le poids d'une page web ?
R : Les actions les plus efficaces :
- Supprimer le CSS/JS inline inutile - Déplacer dans des fichiers externes
- Activer la compression - gzip ou brotli au niveau serveur
- Minifier le HTML - Supprimer espaces et commentaires
- Externaliser les SVG - Remplacer les SVG inline par des balises
img - Lazy loading - Charger le contenu volumineux à la demande
Q : La compression gzip/brotli compte-t-elle dans la limite de 2 MB ?
R : Non. La limite de 2 MB s'applique au HTML décompressé. Un HTML de 3 MB compressé à 500 KB pendant le transfert réseau sera quand même tronqué à 2 MB une fois décompressé par Googlebot. La compression améliore la vitesse de transfert mais ne contourne pas la limite de taille.
Q : À quoi servent les headers HTTP personnalisés ?
R : Les headers personnalisés permettent de tester des configurations spécifiques : envoyer un cookie pour accéder à un site protégé, simuler un header Accept-Language particulier, ou reproduire les conditions d'un CDN. L'outil affiche les headers envoyés dans le rapport pour confirmation.
Outils complémentaires
| Outil | Utilité |
|---|---|
| Recherche DNS | Vérifier les enregistrements DNS de votre domaine |
| Vérificateur de propagation DNS | Confirmer que vos modifications DNS sont propagées globalement |
| Audit de délivrabilité email | Analyser MX, SPF, DKIM et DMARC de votre domaine |
| Vérificateur SPF | Analyser et valider votre enregistrement SPF |
| Hash Generator | Calculer les empreintes SHA-256 pour comparer le contenu de vos pages |
| Redirection de domaine | Remplacer les redirections JavaScript par des 301/302 HTTPS propres |
Ressources utiles
- Google - Documentation sur les limites de crawl (documentation officielle Googlebot)
- Google - Mobile-first indexing (guide du mobile-first indexing)
- Google - Crawl budget management (gestion du crawl budget pour les sites volumineux)
- HTTP Archive - State of the Web (statistiques sur le poids des pages web)
- Web.dev - Optimize Largest Contentful Paint (optimisation des performances web)