Un cliente vino a mí en 2021 con un sitio de comercio electrónico WordPress dirigido a siete países. Habían contratado una agencia de traducción, conectaron todo en WPML, y lo dieron por terminado. El tráfico orgánico en cinco de esos siete mercados era esencialmente cero. No bajo. Cero. Las páginas en alemán estaban canibalizando las páginas en inglés. Las páginas en árabe no tenían el atributo dir="rtl" en ningún lugar. ¿Y las etiquetas hreflang? Apuntando a URLs que redirigían con 301 a páginas completamente diferentes.
Ese fue un trabajo de recuperación de tres meses. Cobré justamente, pero he pensado en ello desde entonces, porque cada problema en ese sitio era prevenible con una lista de verificación decente ejecutada antes del lanzamiento.
Entonces aquí está la mía. El orden exacto en que la trabajo, las herramientas que realmente abro, y las cosas que aún atrapan a los desarrolladores experimentados.
---
Comienza con la estructura de URLs (antes de tocar cualquier otra cosa)
Esta decisión es permanente. O lo suficientemente cercana a permanente como para tratarla así. He visto agencias cambiar estructuras de URL en sitios multilingües en vivo y ver cómo se evapora seis meses de equity de links.
Tienes tres opciones: subdirectorios (/fr/), subdominios (fr.), o ccTLDs (site.fr). La propia documentación de Google sobre orientación internacional es bastante clara en que las tres funcionan, pero los trade-offs son reales.
Para la mayoría de mis clientes, uso subdirectorios. Un dominio, un pool de autoridad, un presupuesto de rastreo para gestionar. Los subdominios tienen sentido cuando tienes equipos genuinamente separados ejecutando operaciones separadas (Seahawk tuvo un cliente SaaS una vez donde los productos de EE.UU. y UE eran en realidad productos regulatorios diferentes, los subdominios eran lo correcto). Los ccTLDs son para empresas con presencia de marca local seria y el presupuesto para construir autoridad de dominio por separado para cada uno.
Elige uno. Documéntalo. Obtén aprobación antes de que alguien escriba una sola línea de código de plantilla.
El Error del Subcarpeta Único que Sigo Viendo
La gente anida el idioma predeterminado bajo /en/ sin configurar una redirección adecuada desde la raíz. Entonces site.com/ devuelve un 200 sin hreflang, site.com/en/ tiene todo el contenido, y Google indexa ambos como páginas thin separadas. Configura tu raíz para redirigir a la locale apropiada basándote en Accept-Language, o simplemente haz que la raíz sirva la locale predeterminada directamente. No la dejes colgando.
---
Hreflang: Hazlo Bien o No lo Hagas
Hreflang es la parte que pone nerviosos a la mayoría de desarrolladores. Con razón. Es caprichoso.
La especificación de hreflang de Google te dice que uses códigos de idioma-región (en-GB, fr-FR), hagas que las etiquetas sean auto-referenciales (cada página se referencia a sí misma), y hagas que la relación sea bidireccional (si /fr/ apunta a /en/, entonces /en/ debe apuntar de vuelta a /fr/). Si te pierdes cualquiera de esas cosas, todo se rompe silenciosamente. Google no lanzará una acción manual. Simplemente ignora tus etiquetas y adivina.
Así es mi flujo de trabajo real:
- Construyo la matriz completa de URLs en una hoja de cálculo primero. Cada locale, cada URL de página equivalente.
- Implemento a través del
<head>en lugar de sitemaps siempre que sea posible. Los sitemaps funcionan, pero la implementación en<head>es más fácil de auditar simplemente viendo el código fuente. - Ejecuto Screaming Frog sobre el sitio de staging con auditoría de hreflang habilitada. Exporto el reporte de problemas.
- Valido cruzadamente con la auditoría de sitio de Ahrefs para encontrar páginas de locale huérfanas (páginas en un idioma sin hreflang apuntando a equivalentes en otros idiomas).
- Verifico manualmente 10-15 páginas. Solo veo el código fuente. Busco el patrón.
Una cosa que la gente se equivoca constantemente: x-default. No es "la versión en inglés". Es el fallback para usuarios cuyo idioma no coincide con ninguna de tus etiquetas de locale. Si estás dirigiéndote específicamente a en-GB y en-US, un hablante de inglés canadiense necesita un lugar donde aterrizar. Eso es x-default. Apúntalo a tu página catch-all más relevante, generalmente la raíz o una página de selector de idioma.
---
Presupuesto de rastreo e indexación
En sitios pequeños esto no importa mucho. En un sitio con 50,000 páginas en 8 idiomas, definitivamente sí.
La matemática es simple: si tu sitio en inglés tiene 6,000 páginas y añades 7 idiomas, potencialmente tienes 48,000 páginas que todas necesitan crawling e indexación. La mayoría de sitios no tienen la autoridad ni la estructura de enlaces internos para soportar eso eficientemente.
Lo que hago:
- Auditar qué páginas realmente justifican traducción. No todo lo hace. Posts de blog de 2017 que reciben 3 visitas al mes en inglés no necesitan una versión en francés.
- Usar sitemaps separados específicos por locale (sitemap-fr.xml, sitemap-de.xml) y referenciarlos todos desde
sitemap-index.xml. Google Search Console te permite enviar y monitorear cada uno por separado, lo cual es mucho más fácil de debuggear. - Revisar estadísticas de crawl en Search Console por propiedad si estás en subdominios o ccTLDs. Para subdirectorios en un dominio, usa el reporte de cobertura filtrado por ruta de URL.
- Noindex páginas delgadas o machine-translated que aún no has revisado. En serio. Una página que Google indexa como contenido de calidad spam lastima el dominio completo.
Allá en 2019 un cliente en el sector de viajes lanzó 12 versiones de idioma, todas machine-translated por DeepL sin ninguna revisión humana. Tráfico sólido en inglés, destruido en 8 semanas en cada otro idioma. DeepL es una herramienta excelente (aún la uso como borrador inicial) pero output sin revisar a escala es una pesadilla de señal de confianza.
---
Traducción vs Transcreación
Esta distinción importa más de lo que la mayoría de SEOs técnicos admiten.
Traducción es convertir palabras. Transcreación es convertir intención, tono y contexto cultural. Para páginas de destino, descripciones de productos y cualquier cosa en la que estés gastando dinero para posicionarte, quieres transcreación.
El elemento práctico de la lista de verificación aquí: para cada mercado objetivo, haz que un hablante nativo revise al menos las 20 páginas principales por potencial de tráfico. No solo por gramática. Por si el texto suena como una persona real en ese idioma o como una máquina que aprendió el idioma de manuales de instrucciones.
La investigación de palabras clave es separada por locale. Yo uso Ahrefs para esto. La palabra clave en alemán para un concepto no es solo la palabra alemana para la palabra clave en inglés. El comportamiento de búsqueda difiere. En algunos mercados, los usuarios buscan de forma más formal. En otros, usan abreviaturas o jerga que nunca aparecerían en una traducción directa. Construye mapas de palabras clave específicos por locale. Toma más tiempo. Vale la pena.
Qué Hacer Con Mercados Que No Puedes Permitirte Transcreate Correctamente
Sé honesto contigo mismo. Si no puedes hacer alemán correctamente ahora, no lances alemán. Una presencia multilingüe mediocre es peor que no tener presencia multilingüe. Googlebot no te da crédito por intentarlo.
---
Verificaciones Técnicas On-Page Por Locale
Esta es la parte poco glamorosa. Pero es donde están las ganancias.
- Atributo `lang ` en el elemento `<html>`. Debe coincidir con el locale de la página. <html lang="es-MX">. Verifica cada plantilla, no solo la página principal.
- Atributo `dir ` para idiomas RTL. Árabe, hebreo, urdu, persa:
<html dir="rtl">. Y verifica que tu CSS realmente lo soporte, no solo el atributo HTML. - Etiquetas canónicas. Cada página localizada debe auto-canonicalizarse. La página en francés se canonicaliza a sí misma, no al equivalente en inglés. He visto esto mal más veces de las que puedo contar.
- Títulos meta y descripciones. Traducidos y adaptados por locale. No dejados en inglés. No auto-generados a partir de una plantilla con [Nombre de página] | [Nombre del sitio] y un eslogan traducido por máquina.
- Datos estructurados. Si estás usando marcado Schema.org, la propiedad
inLanguagedebe reflejar el idioma de la página. Para comercio electrónico, verifica quepriceCurrencycoincida con la moneda esperada del locale. - Texto alternativo de imágenes. Traducido. A menudo se pasa por alto porque no es visible. Siempre verificado.
Uso una Google Sheet simple con todos estos como encabezados de columna. Una fila por locale. Marca cuando esté verificado. Comparte con el cliente para que entienda qué fue verificado.
---
Búsqueda local y Google Business Profile
Para clientes con ubicaciones físicas en múltiples mercados, el SEO multilingüe no se detiene en el sitio web.
Google Business Profile admite múltiples idiomas para la descripción del negocio y listados de servicios. Establece el idioma principal por ubicación correctamente. Si tienes una oficina en París, el GBP para esa ubicación debe estar en francés, con una descripción en francés, no copiada textualmente del perfil de la HQ en inglés.
La consistencia de NAP (nombre, dirección, teléfono) en directorios de citaciones locales importa por mercado también. En Alemania significa asegurar que el listado sea correcto en Das Örtliche y Gelbe Seiten, no solo en Google. En Francia, PagesJaunes. Cada mercado tiene su propio ecosistema de citaciones. Dedicar una tarde a mapear las 10 principales fuentes de citaciones por país objetivo es tiempo bien invertido.
---
Monitoreo Post-Lanzamiento
El lanzamiento no es el final. Es el comienzo de descubrir qué se te pasó por alto.
Mi configuración de monitoreo post-lanzamiento para sitios multilingües:
- Configura Google Search Console por separado para cada locale (subdominio o ccTLD) o usa la propiedad de prefijo de URL por ruta de subdirectorio.
- Revisa el reporte de Orientación Internacional en Search Console bajo "Herramientas heredadas". Te mostrará errores de hreflang dentro de algunas semanas después del lanzamiento.
- Configura el rastreo de posiciones en Ahrefs por locale, usando la orientación correcta de país/idioma. Una palabra clave rastreada en "English, US" te dará posiciones diferentes que la misma palabra clave rastreada en "German, Germany".
- Monitorea la cobertura de rastreo mensualmente durante los primeros 6 meses. Las páginas de nuevas locales a veces quedan atrapadas en "Descubierto, no indexado" durante semanas. Normalmente es un problema de presupuesto de rastreo o enlazado interno.
- Revisa canibalización trimestralmente. Dos páginas de locale compitiendo por la misma consulta en el mismo país es señal de que algo salió mal en la configuración de URL o hreflang.
Una cosa que añadí a mi lista de verificación después de una experiencia dolorosa con un cliente de fintech: verifica que los redireccionamientos basados en IP no estén anulando hreflang. Si tu CDN o servidor está redirigiendo usuarios según la geolocalización por IP, Googlebot (que típicamente rastrea desde IPs de EE.UU.) podría nunca ver tus páginas que no son en inglés. Ese cliente de fintech tenía reglas de CloudFront que redirigían agresivamente las IPs que no eran de EE.UU. Nos tomó dos semanas diagnosticar por qué las páginas europeas tenían cero indexación.
---
FAQ
¿Necesito una propiedad separada en Google Search Console para cada idioma?
No necesariamente. Si usas subdirectorios en un dominio (como site.com/fr/), puedes usar una propiedad de prefijo de URL por subdirectorio, o simplemente usar la propiedad del dominio raíz y filtrar por ruta de URL. Si estás en subdominios o ccTLDs separados, las propiedades separadas valen la sobrecarga administrativa porque obtienes datos más limpios por mercado.
¿Es suficientemente buena la traducción automática para SEO en 2024?
Para un borrador inicial, sí. Para publicar sin revisión humana, no. DeepL y Google Translate han mejorado genuinamente, pero producen contenido gramaticalmente correcto y tonalmente plano. Los motores de búsqueda son cada vez mejores para distinguir contenido que se lee naturalmente en un idioma del contenido que ha sido traducido. Usa traducción automática para avanzar rápido, luego haz que un hablante nativo revise las páginas de alto valor antes de indexar.
¿Cómo manejo un mercado donde solo tengo cobertura de traducción parcial?
Aplica noindex a las páginas no traducidas o parcialmente traducidas hasta que estén listas. No publiques páginas de locale incompletas solo para tenerlas en vivo. El daño a las señales de confianza por contenido delgado en un idioma es más difícil de revertir que la demora en el lanzamiento.
¿Cuál es el error de hreflang más común?
Falta la etiqueta de autorreferencia. Cada página necesita una etiqueta hreflang que apunte a sí misma además de apuntar a todos sus equivalentes. Los desarrolladores frecuentemente implementan las referencias cruzadas correctamente y olvidan la autorreferencia. Screaming Frog lo detectará en aproximadamente 30 segundos, ejecútalo antes de cada lanzamiento.
¿Debo traducir las URLs o mantenerlas en inglés?
Tradúcelas. /es/zapatos/ supera a /es/shoes/ en búsquedas en español porque el slug contribuye a las señales de relevancia. También se ve más confiable para usuarios hispanohablantes. El esfuerzo de implementación adicional (necesitas enrutamiento específico por idioma y traducción de slugs en tu CMS) vale la pena para cualquier mercado que estés enfocándote en serio.
---
El SEO multilingüe no es una casilla que marcas una sola vez. Es una disciplina. La lista de verificación anterior me ha salvado de trabajos de emergencia costosos después del lanzamiento más veces de las que quisiera admitir, y sigue evolucionando. Cada nuevo proyecto me enseña algo. Recientemente: siempre verifica qué está haciendo el CDN con las solicitudes de locales no predeterminados antes de declarar que un sitio está listo. Siempre.