Vérificateur d’URL Alternatives Mobiles en Lot
Données vérifiéesAlternative mobile
Comment utiliser le vérificateur d’URL alternatives mobiles en lot
Retour à l’outilChaque URL est chargée une fois et chaque balise alternate visant un écran étroit est listée telle quelle. L’adresse mobile qu’elle nomme est chargée à son tour, si bien que la canonique de retour est vérifiée dans la même exécution.
- 01
Saisissez les URL à vérifier
Le mode individuel vérifie une adresse et se lance avec Entrée. Passez à En masse pour coller une liste, une URL par ligne, jusqu’à 30 par exécution. Collez les adresses desktop, pas les adresses mobiles : la paire se suit depuis la page desktop vers l’extérieur, et une page mobile ne déclare pas d’alternative vers elle-même.
- 02
Choisissez le User agent avant de lancer
Un hôte mobile distinct répond différemment selon qui demande. Beaucoup de serveurs ne livrent la balise alternate qu’à un agent desktop et redirigent un agent mobile droit vers le site mobile : mesurer en tant que téléphone peut donc montrer une page qui ne déclare rien du tout, soit l’exact contraire de la vérité. Un agent desktop est ce qui révèle la déclaration ; Googlebot Smartphone est ce que Google envoie réellement, alors relancez ainsi quand vous voulez voir ce que Google voit.
- 03
Lisez la colonne Alternative mobile
Les lignes apparaissent au fur et à mesure. La colonne liste les adresses que la page déclare et ne juge rien : une page sans balise, avec une, ou avec deux s’affichent telles qu’elles sont. — signifie qu’elle n’a rien déclaré — sur un site responsive, c’est la bonne réponse, pas un manque. Deux lignes déclarant chacune une adresse se ressemblent ici même si l’une des paires est cassée, car cette colonne ne voit que la moitié aller.
- 04
Inspectez une ligne et exportez les résultats
Voir ouvre le seul endroit où la paire est jugée, et le seul où la seconde moitié est montrée : la media query de chaque balise et l’endroit où elle est déclarée, puis la page mobile elle-même — où elle aboutit, son statut, et la canonique qu’elle déclare en retour. Copier le tableau copie les lignes séparées par des tabulations ; Exporter en CSV les écrit dans un fichier. Les deux conservent chaque déclaration et le verdict.
Comment lire le rapport d’alternative mobile
Une ligne se lit de gauche à droite : l’adresse vérifiée, où elle a abouti, et l’adresse mobile que cette page déclare pour les écrans étroits. La moitié retour se trouve dans le panneau de détail.
Colonnes du tableau de résultats
- URL
- L’adresse exactement telle qu’elle a été vérifiée — après normalisation, pas toujours ce que vous avez saisi.
- URL résolue
- Où la requête s’est arrêtée et le code de statut à cet endroit. Les redirections sont suivies d’abord, et la balise alternate est lue sur cette page finale.
- Alternative mobile
- Toutes les adresses mobiles déclarées par la page finale, une par ligne, résolues en adresse complète. — signifie qu’elle n’a rien déclaré.
- Résultat
- Si la ligne est terminée, encore en cours, ou arrêtée sur une erreur. Elle ne dit rien de la paire elle-même.
- Actions
- Voir ouvre le panneau de détail de cette ligne ; Réessayer apparaît à la place quand la requête n’a jamais abouti.
Conclusions du panneau de détail
- Aucune alternative mobile déclarée — un site responsive sert une seule URL à tous les appareils et n’a pas besoin de cette balise.
- Aucune balise. Sur un site responsive c’est correct et il n’y a rien à corriger ; sur un site à hôte mobile distinct, c’est tout le bogue.
- Une balise alternate est déclarée, mais aucune media query ne vise un écran étroit.
- Une balise rel=alternate est là, mais sa media query ne vise pas un écran étroit — media="print" est le cas courant. Google évalue la media query, donc une requête qu’il ne peut satisfaire est une balise qu’il ignore.
- La balise d’alternative mobile n’a pas de href.
- La balise vise un écran étroit mais ne porte pas de href. L’intention est sans ambiguïté : c’est donc une déclaration cassée, pas une déclaration absente.
- L’URL mobile n’a pas été demandée lors de cette exécution.
- Il y avait une adresse à interroger, mais l’exécution qui a rempli ce tableau ne l’a pas interrogée — la case a été cochée après coup. Relancez pour compléter la moitié retour.
- Impossible d’atteindre l’URL mobile.
- L’adresse mobile a été demandée et n’a pas répondu : délai dépassé, bloquée, ou hôte non résolu. Une URL mobile que personne ne peut charger est une URL mobile que Google ne peut pas indexer.
- La page mobile ne déclare aucune canonique — deux URL au même contenu et rien qui les relie.
- La page mobile a répondu mais ne déclare aucune canonique. Deux adresses servent le même contenu et rien ne les relie : Google doit donc choisir seul.
- Paire bidirectionnelle complète — cette URL pointe vers la page mobile, et la page mobile pointe en retour.
- La page desktop pointe vers la page mobile et la page mobile pointe en retour vers cette adresse exacte. C’est la configuration complète que Google documente pour les URL séparées.
- La canonique de la page mobile pointe vers une autre URL, pas vers celle-ci.
- La canonique de la page mobile pointe ailleurs. Une barre oblique finale ou une différence http/https compte comme ailleurs, parce que cela compte aussi comme ailleurs pour Google.
D’où peut venir une déclaration
- [html]
- Une balise <link rel="alternate" media="..."> dans le head de la page. L’endroit habituel, et le seul qu’utilisent la plupart des sites.
- [header]
- Un en-tête de réponse Link: ...; rel="alternate". Le seul moyen de déclarer une alternative pour un fichier sans head, et facile à manquer car rien sur la page ne l’affiche.
Collez vos URL desktop et voyez, pour chacune, l’adresse mobile qu’elle déclare avec rel="alternate" et une media query. Chaque adresse mobile trouvée est chargée à son tour, si bien que la canonique de retour est vérifiée dans la même exécution : une paire n’est correcte que si les deux moitiés concordent. Un site responsive ne déclare rien ici, et c’est pour lui la bonne réponse.