Les pages AMP sabotent-elles vos offres d'emploi dans Google ?

Google signale un problème technique spécifique aux pages AMP dans le contexte des résultats de recherche d'emploi. Cette déclaration vise les sites qui utilisent à la fois des pages standards et leurs équivalents AMP pour publier des offres d'emploi.

Le framework AMP, conçu initialement pour accélérer les pages sur mobile, repose sur une architecture en paire : version standard + version AMP. Sauf que dans le cas précis des recherches d'emploi, cette dualité crée des frictions.

Pourquoi les pages AMP posent-elles problème pour les offres d'emploi ?

Le moteur de recherche doit choisir quelle URL présenter dans les résultats enrichis JobPosting. Quand une page AMP existe, Google peut se retrouver à l'indexer ou à la présenter à la place de la version standard — sauf que les balises structurées JobPosting peuvent ne pas être interprétées correctement sur la version AMP.

Concrètement ? Votre offre apparaît tronquée, sans informations salariales, sans bouton de candidature fonctionnel, ou carrément absente des résultats dédiés emploi. Les utilisateurs cliquent, tombent sur une page AMP mal configurée, et repartent. Le taux de rebond explose.

Qu'entend Google par « vérification des configurations d'implémentation » ?

Google demande aux webmasters de s'assurer que leur implémentation AMP n'interfère pas avec le bon affichage des offres d'emploi. Cela implique de contrôler plusieurs points techniques : la présence et la cohérence des balises Schema.org JobPosting sur les deux versions, la directive rel=canonical correctement placée, et l'absence de balises rel=amphtml sur les pages emploi si elles créent des conflits.

En clair, Google ne dit pas de supprimer AMP — mais de vérifier que votre setup technique ne crée pas de cannibalisation d'URL ou d'ambiguïté pour le crawler. Si la version AMP est moins riche en données structurées que la version standard, c'est un problème.

Dans quels cas cette interférence se produit-elle ?

Typiquement, sur les sites qui ont activé AMP globalement sans exclure leurs pages carrière. L'autre cas fréquent : un CMS ou un plugin AMP qui génère automatiquement des équivalents AMP pour toutes les pages, y compris les fiches emploi, sans que les balises structurées soient dupliquées correctement.

Certains sites utilisent aussi des templates AMP allégés qui retirent volontairement des éléments comme les formulaires de candidature — et là, la version AMP devient inutilisable pour un chercheur d'emploi, même si elle s'affiche en premier dans Google.

• Vérifier que les balises Schema.org JobPosting sont présentes et identiques sur les deux versions (standard et AMP).
• Tester l'affichage des offres dans Google Search Console via l'outil Test de résultat enrichi.
• Contrôler les balises rel=canonical et rel=amphtml pour éviter toute ambiguïté d'URL.
• Exclure les pages emploi de la génération automatique AMP si la version AMP ne peut pas intégrer toutes les données structurées nécessaires.
• Monitorer les erreurs JobPosting dans la Search Console, qui signalent souvent ces conflits.

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

Oui, et c'est même un point douloureux pour les sites carrière depuis plusieurs années. On a observé des cas où des pages AMP cannibalisaient les URL standards dans les résultats enrichis emploi, avec des taux de clics en chute libre parce que la version AMP affichait moins d'infos que la version desktop.

Google ne le dit pas explicitement, mais le problème vient souvent du fait que les balises structurées JobPosting ne sont pas testées sur la version AMP. Les développeurs implémentent AMP, copient le HTML, mais oublient de vérifier que le JSON-LD est bien interprété côté AMP. Résultat : Google indexe une version appauvrie.

Quelles nuances faut-il apporter à cette déclaration ?

Google reste vague sur un point : faut-il désactiver AMP pour les pages emploi, ou juste mieux les configurer ? La réponse dépend de votre capacité technique. Si votre stack permet de maintenir des balises structurées identiques sur les deux versions, AMP peut rester. Sinon, mieux vaut exclure les pages emploi du périmètre AMP. [A vérifier] : Google n'a jamais publié de guidance officielle sur la désactivation sélective d'AMP par type de page.

Autre nuance : cette interférence ne touche que les sites qui utilisent AMP et qui publient des offres d'emploi avec Schema.org. Si vous n'avez pas de section carrière, ou si vous n'utilisez pas les balises JobPosting, vous n'êtes pas concerné. Ça semble évident, mais certains SEO paniquent pour rien.

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

Si vous utilisez AMP uniquement pour du contenu éditorial (blog, actualités) et que vos offres d'emploi sont sur un sous-domaine ou un CMS distinct, vous êtes à l'abri. De même, si vous avez désactivé la génération automatique d'AMP et que vous contrôlez manuellement quelles pages ont une version AMP, vous maîtrisez le risque.

Enfin, si votre site n'apparaît jamais dans les résultats enrichis emploi de Google (parce que vos balises JobPosting sont mal implémentées ou inexistantes), l'interférence AMP ne changera rien — vous avez un problème plus profond de données structurées manquantes ou invalides.

Que faut-il faire concrètement si vous utilisez AMP sur des pages emploi ?

Première étape : identifier si vos pages emploi ont effectivement des versions AMP générées automatiquement. Ouvrez le code source d'une fiche emploi type, cherchez la balise <link rel="amphtml">. Si elle existe, vous avez une version AMP. Testez cette URL AMP dans l'outil Google Test de résultat enrichi pour vérifier si les balises JobPosting sont bien détectées.

Si elles ne le sont pas, vous avez deux options. Option 1 : dupliquer manuellement les balises JSON-LD JobPosting sur la version AMP, en vous assurant que toutes les propriétés requises (titre, description, datePosted, validThrough, hiringOrganization, jobLocation) sont présentes. Option 2 : désactiver AMP pour les pages emploi via votre CMS ou votre plugin AMP, en excluant spécifiquement ce type de contenu.

Quelles erreurs éviter lors de l'implémentation AMP sur des pages carrière ?

Erreur classique : copier-coller le HTML standard vers AMP sans vérifier que le JavaScript JSON-LD est bien exécuté. Certains frameworks AMP bloquent ou retardent l'exécution de scripts tiers, ce qui peut empêcher les balises structurées de se charger. Testez toujours avec l'outil Google, pas juste visuellement.

Autre piège : utiliser des templates AMP allégés qui retirent des sections entières de la page, comme le formulaire de candidature ou les détails salariaux. Si votre version AMP affiche moins d'infos que la version standard, Google peut l'indexer quand même — et vous perdez des conversions candidat. Mieux vaut une page standard complète qu'une page AMP vide.

Comment vérifier que votre site est conforme et éviter les interférences ?

Utilisez Google Search Console, section Améliorations, onglet Offres d'emploi. Si des erreurs apparaissent sur des URL AMP, c'est le signe que vos balises structurées ne sont pas correctement lues. Corrigez, puis demandez une réindexation via l'outil d'inspection d'URL.

Ensuite, faites un test de recherche Google sur votre propre marque + « offres d'emploi » ou « recrutement ». Vérifiez quelle URL s'affiche dans les résultats enrichis : standard ou AMP ? Si c'est AMP et que l'affichage est dégradé, vous avez un problème de priorité d'indexation. Ajoutez une directive rel=canonical pointant vers la version standard sur la page AMP pour forcer Google à préférer l'original.

• Auditer toutes les pages emploi pour détecter les balises rel=amphtml non désirées.
• Tester chaque URL AMP dans l'outil Test de résultat enrichi de Google.
• Vérifier que les balises JSON-LD JobPosting sont identiques sur les deux versions.
• Exclure les pages emploi du périmètre AMP si la maintenance des deux versions est trop complexe.
• Monitorer les erreurs JobPosting dans Google Search Console après chaque modification.
• Vérifier que la directive rel=canonical pointe toujours vers la version standard depuis la page AMP.