Un préfixe /en anglais peut être valide
Un site multilingue peut utiliser /en pour l'anglais, tout comme il peut utiliser /he pour l'hébreu. Une autre conception valide place l'anglais à la racine. Le problème, c'est la duplication non gérée et les signaux contradictoires : par exemple, les deux /services et /en/services servant la même page anglaise tandis que les liens, les canoniques et les sitemaps se contredisent.
Ce projet utilise l'anglais à la racine et préfixe les autres langues prises en charge, dont le bengali, l'hébreu et l'arabe. C'est une convention de projet, pas une règle SEO universelle. Ses chemins anglais préfixés redondants redirigent vers les chemins racine correspondants. Un site déjà organisé de manière cohérente autour de /en n'a pas besoin de migrer juste pour suivre cette convention. Voir les recommandations de Google sur les structures d'URL multilingues.
Mappez explicitement les pages équivalentes
Chaque véritable traduction devrait normalement se canoniser vers sa propre URL préférée. Reliez les versions équivalentes par des hreflang réciproques, incluant une référence à la page actuelle. Utilisez des URL absolues et un code de langue valide. x-default identifie un repli pour les langues sans correspondance spécifique ; cela ne signifie pas que chaque page est en anglais.
Par exemple, une page de service en anglais peut pointer vers ses équivalents en bengali, en hébreu et en arabe, et chaque équivalent renvoie le même groupe. Un lien vers la page d'accueil dans une autre langue ne remplace pas une traduction de service manquante.
Une navigation traduite autour d'un article anglais inchangé ne crée pas un article traduit. Sur ce site, une traduction d'article reçoit sa propre URL canonique et des liens de langue réciproques uniquement lorsque le contenu principal traduit est disponible. Une URL de langue affichant encore la source anglaise pointe vers la canonique anglaise et est exclue du groupe de traduction. La référence sur les versions localisées de Google explique les annotations réciproques et le contenu principal non traduit.
Vérifiez le HTML et le sens de lecture
Renvoyez un attribut lang pertinent avec le HTML du serveur. L'hébreu et l'arabe nécessitent dir="rtl"; utilisez des propriétés logiques de début/fin pour la mise en page. Isolez les valeurs de gauche à droite telles que les adresses e-mail, les URL et les noms de produits là où elles se réordonneraient autrement de façon déroutante. Les métadonnées de langue ne remplacent pas un contenu lisible et correctement traduit.
Une revue de version pratique
- Demandez une URL représentative dans chaque langue sans le JavaScript du navigateur et inspectez le titre, la canonique, la langue et les titres.
- Suivez les liens de langue alternative dans les deux sens et confirmez qu'ils aboutissent correctement à un contenu équivalent.
- Ne conservez dans le sitemap que les URL préférées et publiées. Excluez les variantes de suivi, les collections vides et les brouillons.
- Confirmez qu'un hôte de prévisualisation délivre
noindexdans un en-tête HTTP ou une balise meta HTML, tandis que la production reste indexable. Autorisez les robots d'exploration à récupérer la page de prévisualisation afin qu'ils puissent lire cette directive. - Testez le changement de langue sur un service, un article et le formulaire de demande, y compris les chargements directs et les préférences mémorisées.
Le comportement noindex suit les recommandations de Google sur le contrôle de l'indexation. Ces vérifications favorisent une découverte cohérente ; elles ne promettent pas de classements. Pour une aide à l'implémentation, voir le développement web et le service secondaire de SEO technique.
