umairmsm/wp-seo

Étape 5 : SEO et langues

Objectif : les moteurs de recherche et les assistants IA comprennent chaque page. Les anciennes URLs atterrissent au bon endroit. Chaque langue supplémentaire est aussi correcte que l'originale.

Étapes SEO

1. Un propriétaire par tâche.
   • Le plugin SEO (Rank Math par défaut) gère les titres, les meta, les sitemaps et le graphe de schéma principal.
   • Le schema.php du noyau ajoute les propres types du site à ce graphe.
   • Désactivez tout plugin de domaine qui imprime son propre schéma, afin d'avoir un seul graphe, pas deux qui se contredisent.
2. Chaque page dans tests/helpers/site.ts réussit npm run test:seo :
   • titre 10-65 caractères ;
   • description 50-160 ;
   • canonique absolue ;
   • un seul H1 ;
   • attribut lang ;
   • zéro requête Google Fonts. Liste de contrôle et règles d'écriture : references/seo-checklist.md.
3. Données structurées :
   • Organisation (ou LocalBusiness) une fois.
   • Le type d'élément par page (Service, Product, TouristTrip, Course, …).
   • Fil d'Ariane.
   • FAQ uniquement pour les questions réellement répondues sur la page.
   • Jamais d'Offer sans prix.
   • Validez avec le test de résultats enrichis de Google et le validateur Schema.org.
4. Robots, sitemap, llms.txt :
   • le site live autorise le crawling et liste le sitemap ; le site de staging bloque tout (le noyau fait cela) ;
   • /llms.txt est servi par le noyau ;
   • décidez selon l'objectif si les crawlers IA peuvent lire le site, puis vérifiez que la edge ne les bloque pas par défaut (wp-ship > cloudflare-edge.md).
5. Redirections : suivez le docs/reference/REDIRECT_RULES.md du projet. Mappez chaque ancienne URL qui a du trafic ou des backlinks vers sa nouvelle page la plus proche (301, un seul saut), et testez chacune.
6. Parité avant les grands changements. Avant une refonte, migration ou lancement de langue, capturez le titre, la description, le canonique et le H1 pour chaque URL. Après chaque étape, comparez. Recapturez uniquement pour les changements prévus, avec la raison dans le commit.
7. Search Console et Bing :
   • vérifiez les deux ;
   • soumettez le sitemap ;
   • surveillez l'indexation des pages chaque semaine pendant le premier mois ;
   • Search Console ne conserve que 16 mois de données, alors exportez ou activez l'export en bloc tôt.

Étapes langues (chaque langue est d'abord un pilote)

Suivez references/multilingual.md. En résumé :

1. Règle zéro : la langue originale ne change pas. Ses URLs, titres, balises canoniques et texte restent identiques (la vérification de parité le prouve).
2. Pilote : la base de la langue (Polylang, le sélecteur, hreflang, chaînes dans .po/.mo), puis les pages clés et les éléments principaux. Ensuite une relecture native sur le staging, puis publication.
3. Le reste arrive par lots, chacun passant par la même relecture.
4. Une langue non encore publiée répond 302 vers la langue originale, et n'apparaît nulle part : ni dans les sitemaps, ni dans hreflang, ni dans les menus, ni dans le sélecteur.

Porte (cocher dans SITE_STATUS.md)

• npm run test:seo vert sur le staging ; test de résultats enrichis propre sur une page de chaque type
• Sitemap, robots.txt et llms.txt corrects pour le site live
• Plan de redirection des anciennes URLs en place et testé (ou "n/a")
• Chaque langue supplémentaire : pilote réussi, relecture native effectuée, paires hreflang complètes, canonique par langue

Bugs que nous avons déjà livrés une fois, donc vérifiez-les

• Le canonique de la page d'accueil traduite pointait vers la page d'accueil originale, ce qui aurait fait perdre le /fr/ des résultats français par Google. Le canonique d'une page traduite est l'URL traduite.
• Du JSON-LD anglais sur des pages françaises : le schéma doit suivre la langue de la page, ou être omis jusqu'à ce qu'il soit traduit.
• Une porte qui redirigeait en 301 une langue non publiée vers la page d'accueil. Les portes sont des 302.