Un cliente llegó a mí en 2021 con un producto SaaS que había estado activo en cinco idiomas durante dos años. Tráfico desde Alemania: 38 sesiones al mes. Desde Francia: 22. Sus páginas en inglés se estaban posicionando bien, pero cada versión localizada era prácticamente invisible. Habían pagado a una agencia para traducir el contenido, alguien había instalado WPML, y luego todos asumieron que el trabajo estaba hecho.
Ni siquiera estaba cerca de estar hecho.
El SEO de localización es una de esas áreas donde hacer el 60% del trabajo correctamente es casi idéntico a hacer 0%. Pierdes hreflang. Eliges la estructura de URL equivocada. Omites señales locales. Resultado: Google ignora tus páginas traducidas completamente o, peor aún, las trata como contenido duplicado y las filtra. He solucionado este problema en cientos de sitios durante los últimos nueve años en Seahawk, y el patrón de fallo es casi siempre el mismo.
Así que repasemos qué realmente funciona.
---
La Traducción No Es Localización
Es lo primero que le digo a cada cliente. La traducción es convertir palabras de un idioma a otro. La localización es reconstruir la intención de una página para un mercado específico.
Tomemos un cliente de comercio electrónico del Reino Unido que tuvimos a finales de 2022. Vendían cuchillos de cocina premium. Sus páginas en alemán eran una traducción palabra por palabra del texto en inglés, incluyendo frases como "perfect for Sunday roasts". Los alemanes no hacen asados de domingo. El texto era gramaticalmente correcto y completamente equivocado.
Pero más allá de la cultura, las implicaciones de SEO son reales. Los volúmenes de palabras clave no se traducen. La búsqueda en inglés "best chef knife" obtiene aproximadamente 8,100 búsquedas al mes en el Reino Unido. El equivalente alemán "bestes Kochmesser" obtiene muchas menos, pero "Kochmesser Test" (aproximadamente "chef knife test/review") es enorme. Si tu página traducida se enfoca en la traducción literal de tu palabra clave en inglés, estás optimizando por la cosa equivocada.
Antes de escribir una sola palabra de contenido localizado, ejecuta investigación de palabras clave en el idioma de destino, en la región de destino usando Google Keyword Planner con el país configurado correctamente, o Ahrefs con el filtro de país aplicado. Estos no son lo mismo que ejecutar investigación en inglés. Trata cada mercado como un sitio nuevo desde una perspectiva de palabras clave.
Qué Significa "Localizado" en la Práctica
- Precio en moneda local, con referencias a métodos de pago locales
- Fechas, direcciones y unidades formateadas para ese país (DD/MM vs MM/DD importa)
- Ejemplos, modismos y referencias que resuenen localmente
- Señales de confianza específicas del país (los compradores alemanes confían en certificaciones locales; los compradores franceses responden a prueba social diferente que los brasileños)
---
Estructura de URL: Equivócate en esto y nada más importará
He visto este debate descarrilar muchos proyectos. ccTLD vs subdominio vs subdirectorio. La gente se vuelve religiosa al respecto.
Aquí está mi opinión honesta después de construir y migrar cientos de sitios internacionales: los subdirectorios suelen ser la opción correcta para la mayoría de negocios. Algo como yoursite.com/de/ en lugar de de.yoursite.com o yoursite.de. Las razones son prácticas: toda tu autoridad de dominio se consolida, es más fácil de gestionar en un solo lugar, y Google lo maneja bien cuando hreflang está configurado correctamente.
Los ccTLD (yoursite.de, yoursite.fr) envían una señal local fuerte. Si eres un jugador serio en un mercado específico y puedes comprometerte a ejecutar esencialmente sitios separados, vale la pena. Seahawk tuvo un cliente fintech que insistió en ccTLD separados para seis países en 2020, y sí, funcionó bien en esos mercados. Pero su overhead de desarrollo se triplicó. Para la mayoría de agencias que construyen para clientes, eso no es realista.
Los subdominios (de.yoursite.com) son lo peor de ambos mundos en la mayoría de casos. Más difíciles de mantener que los subdirectorios, señal de autoridad más débil que los ccTLD. Los evitaría a menos que tu arquitectura de CMS genuinamente lo obligue.
Lo que elijas: sé consistente. No mezcles estructuras. He heredado sitios con páginas /fr/ y un subdominio fr. ejecutándose simultáneamente, ambos indexados. Es una pesadilla.
---
Hreflang: La parte más comúnmente rota del SEO internacional
Si sacas una cosa de este artículo, que sea esta.
Hreflang le dice a Google qué versión de una página mostrar a cada usuario en su idioma y país. Si lo haces mal, terminarás con tus páginas en inglés de EE.UU. apareciendo en Alemania, tus páginas en alemán sin ranking alguno, o, mi desastre favorito personal, tu x-default apuntando a una página que redirige a otro lugar completamente.
El formato de la etiqueta se ve así en tu <head>:
`` <link rel="alternate" hreflang="de" href="https://yoursite.com/de/page/" /> <link rel="alternate" hreflang="en-GB" href="https://yoursite.com/en-gb/page/" /> <link rel="alternate" hreflang="x-default" href="https://yoursite.com/page/" /> ``
Hay algunas cosas que constantemente confunden a la gente:
- Cada página debe referenciar todas sus alternativas, incluyéndose a sí misma. Si tu página en alemán no enlaza de vuelta a la página en inglés, y la página en inglés no enlaza de vuelta a alemán, la implementación está rota.
- Códigos de idioma versus idioma-región.
hreflang="en"significa "inglés, cualquier región".hreflang="en-GB"significa "inglés, Reino Unido específicamente". Si estás intentando dirigirte a Reino Unido versus EE.UU. por separado, necesitas el código de región. - Etiquetas de retorno. La página en alemán debe contener una etiqueta que apunte a la página en inglés. La página en inglés debe contener una etiqueta que apunte de vuelta a alemán. Ambas. Siempre.
- Consistencia con etiquetas canónicas. Tu URL alternativa de hreflang y tu URL canónica para esa página deben coincidir. Exactamente. Incluyendo barras finales.
Uso el generador de etiquetas hreflang de Aleyda Solis cuando configuro estos manuales. Y siempre audito con Screaming Frog después. Siempre.
---
Señales Locales: El Detalle Que Todos Olvidan Después del Lanzamiento
Un hreflang correcto y una página bien localizada te llevan quizás el 50% del camino. El otro 50% es señal: ¿tiene Google alguna razón para creer que eres una entidad genuina en ese mercado?
Para la mayoría de sitios, esto significa:
- Enlaces locales. Un enlace desde un dominio alemán .de a tus páginas
/de/tiene peso significativo. Enlaces desde medios franceses a tus páginas en francés, lo mismo. Un enlace desde un blog estadounidense a tu contenido en alemán no ayuda ni remotamente tanto como la gente asume. - Google Business Profile. Si hay cualquier presencia física, incluso una dirección registrada, configura un GBP para esa ubicación. Complétalo correctamente. Esto es lo básico para visibilidad en el pack local.
- Schema local. Agrega schema
LocalBusinesscon el país correcto, formato de dirección y formato de número telefónico. No simplemente copies tu schema en inglés y traduzcas la descripción. Los datos estructurados deben coincidir con las especificidades de la región. - Ubicación del hosting. Menos importante que antes dados los CDN, pero si estás usando un CDN (y deberías), confirma que tus nodos edge sirven usuarios europeos desde servidores europeos. El plan gratuito de Cloudflare lo maneja. No es un factor de ranking enorme pero contribuye a TTFB en esa región, que importa.
En 2019 tenía un cliente en el espacio de suplementos de salud intentando rankear en España. Su localización era buena. Su hreflang era correcto. Pero tenían cero enlaces españoles, su GBP para su dirección en Madrid estaba sin reclamar, y su schema aún listaba un número de teléfono del Reino Unido. Arreglando esas tres cosas durante aproximadamente cuatro meses los llevó de página 4 a página 1 para tres de sus términos objetivo.
---
La Profundidad del Contenido Varía por Mercado
Esto es algo que la investigación de palabras clave no te dirá completamente. Algunos mercados tienen hambre de información; otros convierten con páginas de producto minimalistas.
Alemania es notoriamente exhaustiva. Los buscadores alemanes tienden a querer contenido detallado de comparación, tablas de especificaciones y políticas de devolución claras antes de comprar cualquier cosa. Una página de producto de 300 palabras que convierte en Reino Unido podría necesitar 900 palabras con una sección de preguntas frecuentes para funcionar en Alemania.
Japón es otro caso. Los resultados de búsqueda japoneses para consultas comerciales a menudo presentan contenido de formato largo extremadamente detallado. El SERP se ve diferente, el comportamiento del usuario es diferente, y las expectativas de contenido reflejan eso.
No estoy diciendo que escribas 2.000 palabras para cada mercado solo porque puedas. Estoy diciendo: mira lo que realmente está posicionándose en ese país, en ese idioma, para tu consulta objetivo. Abre una ventana incógnita, establece tu país de Google manualmente, y mira los tres primeros resultados. ¿Qué extensión tienen? ¿Tienen video? ¿Tienen tablas? ¿Tienen reseñas de usuarios incrustadas? Ese es tu punto de referencia, no lo que funciona en inglés.
---
Lista de verificación de auditoría técnica antes de lanzar
Antes de que cualquier sitio internacional se lance desde Seahawk, lo revisamos en este orden:
- Confirmar que la estructura de URL es coherente en todas las locales
- Validar etiquetas hreflang en cada tipo de página (inicio, categoría, producto, blog) usando Screaming Frog
- Verificar que las etiquetas canónicas se alineen exactamente con las URLs alternas de hreflang
- Verifica que x-default esté configurado y apunte a una página activa sin redirecciones
- Prueba la configuración de segmentación geográfica en Google Search Console (Informe de segmentación internacional, en Herramientas heredadas)
- Confirma que el mapa del sitio XML incluye todas las URLs localizadas y se envía por región si usas propiedades separadas
- Revisa la velocidad de la página desde las regiones objetivo usando WebPageTest con un nodo europeo o asiático
- Valida el esquema LocalBusiness con la herramienta Rich Results Test de Google en al menos una página representativa por región
Estos no son todos los controles que hacemos. Pero si estos ocho están limpios, la base es lo bastante sólida para empezar a construir sobre ella.
---
El Juego de la Paciencia: Cronogramas y Expectativas
Hay algo que desearía poder poner en un cartel para cada cliente que viene a nosotros para SEO internacional: esto toma más tiempo que el SEO en inglés. Mucho más tiempo, a veces.
Cuando lanzas una nueva sección localizada, esencialmente estás lanzando un sitio nuevo desde la perspectiva de Google en ese mercado. No tienes historial de enlaces locales. No tienes señales de participación local. No tienes historial de búsquedas. Google es cauteloso.
Cronograma realista: 3 meses para ver algún movimiento, 6 meses para empezar a sacar conclusiones, 12 meses para evaluar realmente si la estrategia de localización está funcionando. Sé que no es lo que nadie quiere oír. Pero los clientes que entran con esa expectativa tienen muchas menos probabilidades de abandonar en el mes 4 cuando aún no están en la página 1.
El cliente SaaS que mencioné al inicio? Reconstruimos toda su configuración internacional en Q1 de 2022. Para Q4 de 2022, su tráfico alemán había pasado de 38 sesiones al mes a alrededor de 1.400. Francia estaba en 800. Tomó nueve meses de trabajo consistente. Sin atajos. Solo arquitectura correcta, contenido realmente localizado, y link building paciente en cada mercado.
---
FAQ
¿Necesito una propiedad de Google Search Console separada para cada idioma?
No si estás usando subdirectorios. Una propiedad de GSC cubre todo el dominio, y puedes filtrar por prefijo de URL para ver datos por región. Si estás usando ccTLDs, entonces sí, cada dominio necesita su propia propiedad. Los subdominios pueden configurarse como separados o cubiertos bajo una propiedad de dominio. Prefiero separados para datos más limpios.
¿Puedo usar traducción automática para contenido localizado?
Respuesta corta: no, no como resultado final. Google puede detectar contenido traducido automáticamente y está cubierto bajo sus Políticas de Spam como contenido generado automáticamente. Usa DeepL o similar para obtener un borrador inicial, luego haz que un hablante nativo lo edite correctamente. El pase de edición es donde realmente ocurre la localización.
¿Cómo manejo un idioma hablado en múltiples países? Como español de España vs México?
Usas códigos hreflang separados: es-ES para España y es-MX para México. E idealmente tienes contenido genuinamente diferente para cada uno, o como mínimo metadata diferente dirigida a consultas locales. No simplemente apuntes ambos códigos hreflang a la misma página. Google se dará cuenta de lo que estás haciendo.
¿Y si mi CMS no soporta hreflang de forma nativa?
La mayoría lo hace con plugins. WPML y Polylang manejan bien hreflang en WordPress. Para desarrollos personalizados, puedes enviar las etiquetas a través de tu sitemap XML en lugar del <head>, que Google acepta. El método del sitemap es más fácil de mantener a escala. Solo asegúrate de que valide correctamente.
---
La SEO de localización es lenta, complicada y a menudo tiene recursos insuficientes. La mayoría de los sitios que he auditado tienen el contenido traducido pero la capa técnica está ausente o rota. Arregla la arquitectura primero. Luego construye las señales locales. El contenido es la parte fácil, honestamente. Lo aburrido es lo que marca la diferencia.