Sites multilingues simplifiés : ajoutez l’anglais et l’espagnol

Ce que vous allez construire (et ce qu’il faut traduire en premier)

Ajouter l’espagnol (ou l’anglais) a généralement du sens lorsque vous observez des signaux clairs : une part croissante de visiteurs parlant cette langue, des demandes de vente répétées depuis un marché précis, ou des tickets de support qui s’éternisent à cause d’allers-retours. Bien fait, la localisation peut aussi réduire la charge du support : quand les clients peuvent s’auto-servir dans leur langue, ils ouvrent moins de tickets « petite question ».

« Multilingue » vs « Traduit » (la différence pratique)

Un site multilingue n’est pas seulement vos pages passées dans un traducteur. Il inclut :

• Navigation et UI : menus, boutons, en-têtes/pieds de page, bandeaux cookies
• Métadonnées : titres de pages, meta descriptions, textes Open Graph
• Texte système : erreurs de formulaire, messages de confirmation, emails transactionnels
• Visibilité : chaque langue doit avoir ses propres pages crawlables que l’on peut partager et mettre en favori

Si vous ne traduisez que le corps du texte, les utilisateurs trouvent encore des menus en anglais, une recherche cassée, ou des formulaires en lesquels ils n’ont pas confiance. Ça donne une impression d’inachevé.

Définir un périmètre réaliste pour la “Version 1”

Commencez par les pages qui impactent directement le revenu et le support. Une première version solide comprend souvent :

1. Page d’accueil (ce que vous faites, pour qui)
2. Pages produit/service (fonctionnalités, bénéfices, indications tarifaires)
3. Tarification ou page « Demander un devis »
4. Pages de conversion principales : /contact, /demo, /signup
5. Pages de confiance clés : témoignages, études de cas, « à propos »
6. Essentiels du support : articles d’aide principaux ou une FAQ courte

Les éléments « agréables à avoir » (archives de blog, anciennes pages presse) peuvent venir plus tard une fois la base cohérente.

Décidez qui est responsable des mises à jour (avant de traduire)

Les sites bilingues échouent quand une langue cesse d’être mise à jour. Attribuez des responsabilités claires :

• Marketing gère les pages principales, les campagnes et les métadonnées SEO
• Produit gère les termes in-app et les notes de version (si publiées sur le site)
• Support gère le contenu d’aide et les réponses types

Choisissez une règle simple : quand l’anglais change, l’espagnol est mis à jour dans un délai défini (par exemple, 3–5 jours ouvrés). Cette décision évite le problème des « deux sites qui divergent ».

Choisir une structure d’URL simple pour l’anglais et l’espagnol

Votre structure d’URL est le « système d’adressage » pour vos deux langues. Choisissez-la tôt et tenez-vous-y : la changer plus tard signifie redirections, perte de positions et liens partagés cassés.

Les trois options communes

1) Sous-dossiers (recommandé pour la plupart des sites) :

• Anglais : / ou /en/
• Espagnol : /es/

2) Sous-domaines :

• Anglais : www.example.com
• Espagnol : es.example.com

3) Domaines séparés :

• Anglais : example.com
• Espagnol : example.es

Pourquoi les sous-dossiers sont généralement les plus simples

Pour le SEO et la maintenance, les sous-dossiers sont souvent les moins compliqués :

• Les signaux SEO restent ensemble : les liens et l’autorité pointent vers un seul domaine, au lieu d’être partagés.
• La gestion de contenu est plus simple : un seul CMS, un seul déploiement, une seule configuration de sécurité.
• L’analyse est plus propre : comparez le trafic /es/ avec celui qui n’a pas /es/ sans consolider des rapports.

Les sous-domaines et domaines séparés ne sont pas « mauvais »—ils ajoutent juste de la charge opérationnelle. Si votre objectif est une traduction simple anglais/espagnol, les sous-dossiers sont souvent le choix le plus pratique.

Comment votre choix influence le partage, l’indexation et le suivi

• Partage de liens : les utilisateurs collent l’URL sur laquelle ils se trouvent. Avec des sous-dossiers, il est évident qu’un lien est en espagnol : /es/....
• Indexation par les moteurs : les moteurs peuvent indexer n’importe quelle structure, mais la cohérence aide. Séparez clairement chaque langue pour éviter que les crawlers confondent des doublons.
• Analytics et reporting : décidez comment vous segmenterez le trafic par langue (par exemple, chemins commençant par /es/). Votre structure d’URL détermine la facilité de cette tâche.

Gardez les noms d’URL cohérents (choisissez une approche)

Décidez si les URLs en espagnol seront traduites ou non, et appliquez la règle partout :

• Slugs traduits : /es/precios, /es/contacto
• Mêmes slugs que l’anglais : /es/pricing, /es/contact

Les deux conviennent—ce qui compte, c’est la cohérence. Mélanger les approches embrouille les utilisateurs, les éditeurs et le reporting, et rend le site multilingue plus difficile à maintenir.

Ajouter un sélecteur de langue que les utilisateurs comprennent

Un site bilingue ne paraît « simple » que si les visiteurs peuvent changer de langue sans réfléchir. Le sélecteur de langue est un petit élément d’UI qui influence discrètement la confiance, les conversions et les demandes au support.

Rendez-le évident (sans être intrusif)

Placez un sélecteur de langue visible à un endroit cohérent—généralement l’en-tête (idéal pour la découverte) ou le pied de page (acceptable si l’en-tête est encombré). Si vous l’intégrez au menu, gardez-le près de la navigation pour éviter que les utilisateurs aient à chercher.

Utilisez des étiquettes claires : English et Español. Évitez les abréviations comme EN/ES sauf si l’espace est vraiment restreint.

Utilisez les drapeaux avec prudence

Les drapeaux sont tentants, mais la langue n’est pas la même chose que le pays. Un hispanophone peut être aux États-Unis, et l’anglais est utilisé dans de nombreux pays. Si vous affichez des drapeaux, associez-les toujours à du texte (« English », « Español ») pour ne pas prêter à confusion.

Souvenez-vous du choix de l’utilisateur

Quand quelqu’un passe en Español, évitez de lui faire répéter l’opération sur chaque page.

• Stockez sa préférence avec un cookie (pour les visiteurs anonymes)
• Si l’utilisateur a un compte, enregistrez-la dans les paramètres du profil

Ceci est important si vous redirigez des utilisateurs vers les deux langues depuis des publicités, des emails ou les réseaux sociaux.

Évitez les redirections forcées qui piègent les gens

Rediriger automatiquement selon la langue du navigateur ou l’IP peut se retourner contre vous : les utilisateurs bilingues, les voyageurs et les personnes avec VPN tombent souvent sur la « mauvaise » langue.

Si vous suggérez une langue, faites-le léger (une bannière réductible) et offrez toujours un moyen en un clic pour revenir.

Enfin, rendez le sélecteur accessible : navigation clavier, lisibilité mobile, et libellé clair (par exemple « Langue »).

Bien faire le SEO multilingue : hreflang, canonicals et métadonnées

Si vous ne traduisez que le texte visible, les moteurs peuvent s’embrouiller sur la version à positionner—surtout quand les pages anglaises et espagnoles se ressemblent. Quelques bases SEO font une grande différence, et ce sont surtout des réglages « mettre en place et maintenir ».

1) Utilisez hreflang pour connecter les paires linguistiques

Ajoutez hreflang pour que Google comprenne quelle page anglaise correspond à quelle page espagnole (et serve la bonne version selon la langue et la région).

Au minimum, chaque paire devrait se référencer mutuellement :

• /en/pricing devrait pointer vers /es/precios
• /es/precios devrait pointer vers /en/pricing

Si vous avez des versions génériques (pas spécifiques à un pays), utilisez en et es. Si vous ciblez des pays, vous pouvez utiliser en-US, es-ES, es-MX, etc. Beaucoup de sites ajoutent aussi une version x-default (souvent en anglais) pour les utilisateurs sans correspondance claire.

2) Configurez correctement les balises canonical

Les balises canonical évitent les problèmes de contenu dupliqué, mais elles sont faciles à mal configurer sur les sites multilingues.

Règle d’or : chaque page linguistique doit canonicaliser vers elle-même.

• Pages anglaises : la canonical doit être l’URL anglaise.
• Pages espagnoles : la canonical doit être l’URL espagnole.

Évitez de pointer les pages espagnoles vers des canonicals anglaises « parce que c’est l’original ». Cela indique à Google que la page espagnole n’est pas la version préférée, ce qui peut nuire à sa visibilité.

3) Traduisez les métadonnées (pas seulement le contenu)

Les extraits de recherche et les aperçus sociaux proviennent souvent des métadonnées, pas des titres de page.

Assurez-vous de traduire et localiser :

• Balises title (gardez un naturel, pas une traduction mot à mot)
• Meta descriptions (rédigez pour obtenir des clics dans la langue cible)
• Champs Open Graph (og:title, og:description) et Twitter card

Astuce : gardez le nom de la marque constant, mais adaptez les formulations à ce que recherchent réellement les hispanophones.

4) Soumettez les deux langues dans votre sitemap

Aidez les moteurs à découvrir chaque version :

• Incluez les URLs /en/ et /es/ dans le même sitemap, ou
• Publiez des sitemaps séparés par langue

Dans tous les cas, assurez-vous que les nouvelles pages apparaissent dans les deux langues au fil du temps — des URLs espagnoles manquantes ou obsolètes expliquent souvent les contre-performances SEO multilingues.

Localisez l’expérience complète, pas seulement le texte des pages

Traduire des paragraphes est la partie évidente. L’« expérience » englobe tout autour du texte : navigation, boutons, erreurs, formats et même les assets. Si ces éléments restent dans une langue, votre site semble inachevé et les utilisateurs perdent confiance.

Texte UI : les petits éléments cliqués par les utilisateurs

Commencez par les libellés de navigation, les CTA et les éléments répétés (en-tête, pied de page, bandeau cookies). Puis traitez les messages système : erreurs de validation, états vides, confirmations, et texte « chargement ».

Cela compte surtout pour les formulaires. Une page en espagnol avec des erreurs de champ en anglais (« Please enter a valid email ») casse la confiance et provoque des abandons. Assurez-vous que les placeholders, aides et emails automatiques correspondent à la langue de la page.

Images contenant du texte

Captures d’écran, bannières, infographies et promos avec du texte cachent souvent du contenu non traduit. Vous avez deux options :

• Remplacer l’asset par une version espagnole (meilleur pour la clarté).
• Reconcevoir pour que le texte soit du HTML réel (meilleur pour l’accessibilité et le SEO).

Si vous ne pouvez pas refaire une image rapidement, évitez d’inclure des informations clés (prix, échéances, instructions) dans le visuel.

Ponctuation, accents et polices pour l’espagnol

L’espagnol nécessite un support complet des caractères : accents (á, é, í, ó, ú), ñ, et ponctuation inversée (¿ ¡). Vérifiez que vos polices rendent bien ces glyphes à toutes tailles—surtout dans les boutons et menus où l’espacement peut tronquer des caractères.

Dates, heures, monnaies et nombres

Choisissez des formats adaptés à votre audience et utilisez-les de façon cohérente. Exemples :

• Dates : « 12/03/2025 » peut signifier le 12 mars ou le 3 décembre—écrivez le mois quand c’est ambigu.
• Nombres : l’anglais utilise souvent 1,234.56 tandis que l’espagnol utilise fréquemment 1.234,56.
• Monnaie : affichez le symbole et le contexte (USD, MXN, EUR) si pertinent.

Quand ces détails sont alignés, votre site anglais/espagnol paraît vraiment bilingue—pas juste traduit.

Créez un flux de traduction qui ne cassera pas tout plus tard

Un site bilingue reste « simple » seulement si vous pouvez le mettre à jour sans chaos. L’objectif n’est pas un processus parfait—c’est une voie répétable du nouveau texte à la page publiée dans les deux langues.

1) Commencez par un glossaire partagé (avant de traduire)

Créez un glossaire vivant que tous utiliseront—rédacteurs, traducteurs et relecteurs. Incluez :

• Noms de produit et fonctionnalités (ce qui ne se traduit jamais)
• Phrases marketing clés et leur rendu souhaité
• Décisions de ton, en particulier « tú » vs « usted » (et si vous utiliserez un espagnol neutre d’Amérique latine ou un style régional)

Cela évite le problème classique où le même bouton devient « Empezar », « Comenzar » et « Iniciar » à travers le site.

2) Choisissez une méthode de traduction adaptée au risque

Adoptez une approche et documentez-la pour être cohérent :

• Traduction humaine : meilleure pour les pages de marque, la tarification et le contenu juridique
• Machine + revue : rapide pour les articles d’aide et le contenu longue traîne—si un relecteur est responsable de la qualité
• Agence : utile quand vous avez besoin de capacité, de délais et d’application du style

Règle simple : tout ce qui affecte la conversion ou la confiance mérite une attention humaine plus poussée.

3) Définissez un flux d’approbation clair

Évitez le « tout le monde révise tout ». Utilisez un pipeline réduit :

Brouillon → Relecture → Publication

Décidez qui valide :

• L’exactitude (le sens est correct)
• Le ton et la formalité (tú/usted)
• La mise en forme finale (titres, boutons, labels courts)

4) Suivez les changements pour éviter la dérive

La plupart des sites bilingues échouent silencieusement : l’anglais est mis à jour, l’espagnol non. Prévenez la dérive en suivant ce qui change :

• Ajoutez un statut « besoin de traduction » à chaque page
• Enregistrez la date de dernière mise à jour par langue
• Tenez un court changelog (ce qui a changé et pourquoi)

Si vous faites ça dès le départ, l’ajout de nouvelles pages plus tard ne se transformera pas en panique.

Options d’implémentation : CMS, code ou plugins (comparaison simple)

Trois façons courantes de livrer un site anglais/espagnol : un CMS, une construction en code (souvent un générateur de site statique), ou un plugin ajouté à ce que vous avez déjà. Le meilleur choix est souvent celui qui maintient les traductions organisées et faciles à mettre à jour.

Option 1 : un CMS avec locales intégrées

Si vous publiez régulièrement (blogs, landing pages, articles d’aide), un CMS qui gère plusieurs locales est souvent le plus simple. Cherchez des fonctionnalités comme des URLs par langue, des champs SEO par langue (title/description), et un workflow éditorial propre.

À surveiller : que le CMS gère non seulement le texte des pages mais aussi les labels de navigation, boutons et composants réutilisables.

Option 2 : Code / générateur de site statique (SSG)

Si votre site est majoritairement constitué de pages marketing et que vous voulez vitesse et contrôle, un SSG ou framework peut bien fonctionner—à condition qu’il ait un support i18n solide.

Règle clé : ne codez pas des chaînes anglaises dans les templates. Centralisez les textes dans des fichiers de traduction (JSON/YAML) pour que le même composant puisse s’afficher en espagnol sans dupliquer les layouts.

Option 3 : Plugins (plus rapide, mais attention aux compromis)

Les plugins peuvent être un moyen rapide d’ajouter l’espagnol sur un site existant, surtout sur des builders et CMS populaires. Ils sont utiles quand vous avez besoin d’un résultat rapide.

Compromis à évaluer : est-ce que le plugin génère des URLs propres ? Permet-il d’éditer manuellement les traductions (pas seulement la traduction automatique) ? Supporte-t-il les bases SEO (métadonnées et signaux de langue) ?

Où stocker les traductions (et les garder en sécurité)

Quel que soit l’approche, conservez les traductions de façon structurée :

• Fichiers (JSON/YAML) : parfait pour le code/SSG, facile à versionner
• Champs en base de données : courant dans les CMS ; bien pour les éditeurs, mais pensez aux exports/sauvegardes
• Plateforme de traduction : idéale quand plusieurs personnes traduisent/revoient ; conserve l’historique et les approbations

Raccourci pratique de construction : générez d’abord la structure multilingue

Si vous construisez (ou reconstruisez) le site plutôt que de le traduire, il aide souvent de scaffolder d’abord le routage sensible aux langues, les chaînes UI réutilisables et les champs SEO avant toute traduction. Des outils comme Koder.ai peuvent accélérer cette fondation : vous pouvez décrire la structure d’URL souhaitée (par exemple /en/ et /es/), le comportement du sélecteur de langue, et la disposition des fichiers i18n dans un flux de planification guidé, puis itérer rapidement avec snapshots/rollback pendant que vous validez l’UX et le SEO.

Prévoyez plus de deux langues

Même si vous n’avez besoin que de l’anglais et de l’espagnol maintenant, définissez des conventions évolutives : codes de locales (en, es), règles d’URL réplicables, et une source unique de vérité pour les copies UI partagées. Ainsi, ajouter le français plus tard devient une extension—pas une reconstruction.

N’oubliez pas le support et les formulaires

Un site bilingue, ce n’est pas seulement la page d’accueil et la tarification. Dès que quelqu’un s’inscrit, oublie un mot de passe ou rencontre une erreur, il n’est plus « en train de naviguer »—il cherche à résoudre un problème. Si ces points de contact sont en anglais, les hispanophones abandonnent souvent.

Traduisez le contenu sur lequel les utilisateurs comptent quand ils sont bloqués

Commencez par les éléments qui réduisent les tickets et débloquent les clients rapidement :

• Centre d’aide et FAQ (surtout « démarrage » et facturation)
• Emails d’onboarding et emails lifecycle clés (vérification, réinitialisation, reçus)
• Microcopies in-app : états vides, tooltips, confirmations et avertissements

Si vous avez déjà une zone d’aide, liez-y depuis les deux langues en utilisant des chemins relatifs comme /help. Il en va de même pour /contact.

Localisez les formulaires de bout en bout

Les formulaires sont souvent l’endroit où les sites multilingues cassent. Ce n’est pas suffisant de traduire « Nom » et « Email ». Localisez aussi :

• Messages de validation (« Please enter a valid email ») et indices inline
• Messages de succès et étapes suivantes après soumission
• Formats de date, téléphone et adresse (et exemples dans les placeholders)

Testez ensuite le parcours complet dans les deux langues : soumettez chaque formulaire, provoquez des erreurs communes, et confirmez ce que voit l’utilisateur sur l’écran de confirmation.

Mettez en place un support en espagnol—or indiquez clairement les attentes

Si vous pouvez supporter des clients en espagnol, dites-le clairement et proposez une option de contact en espagnol (une boîte mail en espagnol, routage chat, ou horaires dédiés). Si vous ne le pouvez pas encore, ne le cachez pas—indiquez-le sur /contact et dans vos réponses automatiques.

Approche simple : offrez d’abord de l’aide en self-serve en espagnol, puis ajoutez du support humain au fur et à mesure que le volume augmente.

Vérifications de qualité avant le lancement

Un site bilingue peut sembler « terminé » et pourtant livrer de petits défauts qui désorientent les utilisateurs ou nuisent au SEO. Une checklist courte pré-lancement vous aide à attraper les problèmes coûteux à corriger plus tard—surtout après indexation.

1) Vérifications visuelles et de layout (appareils réels)

L’espagnol est souvent plus long que l’anglais, ce qui peut casser des mises en page que vous ne voyez pas sur un aperçu desktop.

• Vérifiez les layouts : les chaînes plus longues peuvent déborder des boutons et menus
• Scannez en-têtes, éléments de navigation, cartes produits, CTA et bandeaux cookies
• Recherchez des textes tronqués, des sauts de ligne gênants et des éléments qui se chevauchent

Si possible, testez sur un petit écran de téléphone et au moins une largeur desktop large.

2) Navigation et intégrité des liens entre langues

Les utilisateurs ne doivent jamais « tomber » dans la mauvaise langue en cliquant.

• Testez les liens entre langues ; évitez de mélanger les chemins EN/ES
• Cliquez sur le sélecteur de langue sur plusieurs types de pages (accueil, article de blog, page produit, contact)
• Confirmez que le sélecteur garde l’utilisateur sur la page équivalente, pas systématiquement la page d’accueil

Testez aussi les pieds de page, les breadcrumbs et les modules « articles recommandés ».

3) Contrôles SEO rapides (importants mais rapides)

Avant le lancement, confirmez que les moteurs peuvent comprendre la relation entre vos pages.

Choses pratiques à vérifier :

• Chaque page anglaise pointe vers sa contrepartie espagnole (et vice versa)
• Les canonicals ne pointent pas par erreur vers l’anglais
• Titles et meta descriptions sont traduits (pas dupliqués entre langues)
• Votre /sitemap.xml (ou sitemaps par langue) inclut les deux langues

Si vous avez un environnement de staging, assurez-vous qu’il est bloqué de l’indexation tandis que la production est indexable.

4) Relecture humaine rapide (ton et crédibilité)

La traduction automatique peut être un bon départ, mais une relecture humaine évite les erreurs de crédibilité.

Concentrez-vous sur les pages à haute visibilité : page d’accueil, tarification, landings principales et parcours checkout/contact. Portez une attention particulière au langage légal, aux affirmations marketing, aux devises, aux dates et aux instructions de champs.

Si vous voulez un filet de sécurité final, faites un « test tâche de cinq minutes » : demandez à quelqu’un de trouver une page clé en espagnol, passer en anglais, et soumettre un formulaire—sans aide.

Lancement, mesure et maintien des deux langues

Un site bilingue n’a pas besoin d’être lancé en une seule fois. Un déploiement par phases permet d’obtenir rapidement des retours utilisateurs tout en maîtrisant la charge de travail.

Lancer par phases (commencez où ça compte)

Commencez par les pages qui génèrent le plus de valeur—souvent page d’accueil, pages produit/service, tarification et contact. Si votre blog est volumineux, ne traduisez d’abord que les articles les plus visités.

Approche pratique :

• Phase 1 : Pages de conversion cœur (ce qu’il faut pour acheter ou vous contacter)
• Phase 2 : Pages de confiance (à propos, témoignages/études de cas, FAQ)
• Phase 3 : Contenu longue traîne (blog, guides), selon la demande réelle

Laissez le trafic guider vos priorités. Si des visiteurs espagnols atterrissent sur une page de service spécifique, montez-la dans la file.

Mesurez la performance par langue (pas seulement « site global »)

Configurez des rapports pour comparer l’anglais vs l’espagnol côte à côte. Suivez au minimum :

• Trafic (sessions et pages d’atterrissage par langue)
• Conversions (soumissions de formulaire, achats, appels—ce que vous considérez comme succès)
• Taux de rebond / engagement (pour repérer un contenu mal adapté ou une traduction confuse)

Si le trafic espagnol augmente mais que les conversions stagnent, vérifiez que les pages espagnoles ont les mêmes CTA, signaux de confiance, clarté tarifaire et comportement de formulaire que les pages anglaises.

Surveillez Search Console pour l’indexation et les problèmes hreflang

Après le lancement, utilisez Google Search Console pour surveiller :

• Pages non indexées (souvent causées par des balises noindex accidentelles ou des redirections)
• Avertissements hreflang (liens retour manquants, codes de langue/région erronés)
• Problèmes de duplication ou de canonical (comme des canonicals anglaises sur des pages espagnoles)

Repérer ces problèmes tôt évite des semaines de « pourquoi l’espagnol ne se positionne pas ? ».

Empêchez les pages espagnoles de devenir obsolètes

La façon la plus rapide de perdre la confiance est d’avoir des pages anglaises à jour tandis que les pages espagnoles semblent datées.

Mettez en place un plan de maintenance simple :

• Mensuel : passez en revue les pages d’atterrissage principales dans chaque langue et mettez à jour ce qui est sensible au temps
• Trimestriel : auditez formulaires, tarifications, promotions et navigation dans les deux langues
• En continu : à chaque modification d’une page anglaise, enregistrez-la pour mise à jour de la version espagnole suivante

Une petite habitude—comme une checklist partagée « mise à jour traduction »—empêche votre site anglais/espagnol de dériver lentement.

Erreurs courantes (et corrections rapides)

Même un site multilingue bien intentionné peut frustrer les utilisateurs (et embrouiller Google) quand quelques détails manquent. Voici les problèmes que l’on voit le plus souvent sur un site anglais/espagnol—et comment les corriger vite.

1) Redirections automatiques par IP sans option d’annulation

L’erreur : détecter la localisation d’un utilisateur et le renvoyer immédiatement vers /es ou /en—sans moyen de revenir. Voyageurs, bilingues, utilisateurs VPN et chercheurs tombent dans la mauvaise langue.

Correction rapide : gardez la géolocalisation comme suggestion, pas comme redirection forcée.

• Affichez une bannière (« Préférez-vous Español ? ») avec un bouton clair.
• Fournissez toujours un sélecteur visible.
• Mémorisez le choix par cookie ou paramètre de compte.

2) Utiliser uniquement des drapeaux pour indiquer la langue

L’erreur : les drapeaux représentent des pays, pas des langues. Un drapeau seul n’est pas accessible pour les lecteurs d’écran.

Correction rapide : utilisez des étiquettes textuelles : English / Español (éventuellement avec un drapeau en décoration secondaire).

• Placez-le là où les utilisateurs l’attendent (en-tête ou coin supérieur droit).
• Gardez-le identique sur toutes les pages, y compris le checkout et le support.

3) Traduire seulement le texte des pages (pas les champs SEO ni les messages système)

L’erreur : le corps est traduit, mais les titles, meta descriptions, slugs, erreurs 404 et emails restent en langue d’origine.

Correction rapide : faites une checklist pour « tout ce qui parle » :

• Titles, meta descriptions, champs Open Graph
• Slugs/URLs si pertinent (et cohérent)
• Labels de navigation, boutons, messages d’erreur
• Pages de remerciement et emails transactionnels

4) Pages dupliquées sans hreflang/canonicals

L’erreur : publier des versions anglaises et espagnoles sans indiquer aux moteurs qu’il s’agit d’alternatives. Le mauvais langage peut être positionné ou être perçu comme dupliqué.

Correction rapide : implémentez hreflang entre versions linguistiques et fixez les canonicals correctement (généralement auto-référents pour chaque langue).

• Assurez-vous que chaque page anglaise pointe vers sa contrepartie espagnole et réciproquement.
• Ajoutez un x-default quand cela a du sens (par ex. une page de sélection de langue).

Ces corrections ne requièrent pas une reconstruction—juste une structure plus claire et un processus de traduction plus complet.