De todas las conversaciones que tengo con clientes, hay una que se repite con una frecuencia sorprendente: "nos está yendo bien en Chile, queremos abrir Perú, ¿qué hacemos con el sitio?". Esa pregunta, que suena a detalle técnico, es en realidad la puerta de entrada al SEO internacional, y la respuesta que elijas va a condicionar tu tráfico orgánico en ambos países por años. Lo sé porque una parte importante de mi trabajo consiste en ayudar a empresas a expandirse entre Chile y Perú, y me ha tocado ver las dos películas: la de los sitios que se estructuraron bien desde el día uno, y la de los que tuvieron que migrar todo dos años después, con la pérdida de tráfico que eso implica.
En esta guía te explico las tres decisiones que importan, en el orden en que hay que tomarlas: cómo estructurar el sitio, cómo implementar hreflang sin romper nada, y cómo validar que funcionó. Con ejemplos de Chile y Perú, porque es el corredor donde más trabajo y donde mejor se ven los matices.
¿Qué es el SEO internacional y cuándo te toca pensarlo?
El SEO internacional es el trabajo de lograr que cada versión de tu sitio posicione en el país que le corresponde: que un usuario en Lima vea tu contenido para Perú y uno en Santiago vea el de Chile, cada uno con sus precios, su moneda y su forma de hablar.
Te toca pensarlo antes de lo que crees. El error más caro que veo es tratarlo como un problema de "cuando seamos grandes": la empresa abre operaciones en el segundo país, duplica el sitio a la rápida o, peor, atiende ambos mercados con las mismas páginas, y recién cuando el tráfico peruano no despega alguien pregunta por qué. A esa altura, ordenar la casa significa migrar URLs, y migrar URLs siempre tiene costo.
La señal de que ya te toca es simple: si tienes precios, stock, equipo o clientes en más de un país, tu sitio debería reflejar esa realidad. Google arma su entendimiento de tu empresa con todas las señales disponibles, y cuando esas señales dicen "esta marca opera en Chile" pero tú quieres vender en Perú, estás compitiendo en desventaja contra cualquier competidor local que sí se ve peruano.
¿Subcarpetas, subdominios o un dominio por país?
Esta es la decisión estructural, y conviene tomarla con calma porque deshacerla es lo caro. Las tres opciones clásicas:
Dominios por país (ccTLD): tuempresa.cl y tuempresa.pe. Es la señal geográfica más fuerte que existe, pero cada dominio parte de cero en autoridad. Todos los enlaces que ganaste en Chile no le sirven de nada a tu dominio peruano. Para una marca grande con presupuesto de marketing en cada país, funciona. Para el resto, es partir el patrimonio en dos.
Subdominios: cl.tuempresa.com y pe.tuempresa.com. En la práctica, Google tiende a tratarlos como sitios semi independientes, así que heredan menos autoridad de la que uno esperaría. Es la opción que menos recomiendo, porque combina lo peor de los dos mundos: la complejidad de administrar sitios separados sin la señal geográfica contundente del ccTLD.
Subcarpetas: tuempresa.com/cl/ y tuempresa.com/pe/. Toda la autoridad vive en un solo dominio, cada enlace que ganas en cualquier país suma para todos, y la segmentación geográfica se resuelve con hreflang. Para la mayoría de las empresas que se expanden entre países de habla hispana, esta es la opción que recomiendo, y es la estructura que más me ha tocado implementar.
Una analogía que uso harto: el ccTLD es como abrir una empresa nueva en cada país, con su propio historial crediticio partiendo de cero. Las subcarpetas son como abrir sucursales de la misma empresa: la reputación acumulada respalda a todas.
¿Y si los dos países hablan español? ¿Necesito versiones separadas?
Esta es la pregunta que más me hacen, y la respuesta honesta es: depende de cuánto difiere tu negocio entre países, no de cuánto difiere el idioma.
Si vendes software con los mismos precios en dólares, las mismas funcionalidades y el mismo discurso en ambos mercados, una sola versión en español puede ser suficiente durante un buen tiempo. Crear /cl/ y /pe/ con el mismo texto y solo cambiar la bandera genera decenas o cientos de páginas casi idénticas que compiten entre sí, y Google va a elegir por ti cuál mostrar en cada país (spoiler: no siempre elige bien).
Si tus precios, medios de pago, despacho, regulación o vocabulario cambian entre países, las versiones separadas se justifican solas. Piensa en una inmobiliaria: en Chile la gente busca "arriendo de departamentos" y en Perú busca "alquiler de departamentos". Son la misma intención, con palabras distintas, y una sola página no puede titularse con las dos de forma natural. Lo mismo pasa con "palta" y aguacate si vendes comida, con UF y soles si publicas precios, con Transbank y Yape si explicas medios de pago.
Mi regla práctica: parte con una sola versión si tu oferta es idéntica, y separa cuando tengas al menos tres diferencias reales de contenido por página (precio, léxico, oferta, regulación). Separar antes de tiempo llena el sitio de páginas duplicadas, y separar demasiado tarde le regala las búsquedas locales al competidor que sí usa las palabras del país.
¿Cómo se implementa hreflang sin romper nada?
Hreflang es la etiqueta que le dice a Google "esta página tiene una versión hermana para otro país". Suena simple y es el lugar donde más implementaciones fallan. Las auditorías que hago suelen encontrar los mismos tres errores, así que vamos directo a cómo hacerlo bien.
Primero, los pares son de ida y vuelta. Si la página chilena declara a la peruana como su versión para Perú, la peruana tiene que declarar a la chilena como su versión para Chile. Si la referencia va en una sola dirección, Google la ignora completa. Este es, lejos, el error más común: se implementa el hreflang en las páginas nuevas y se olvida actualizar las antiguas.
Segundo, cada página se declara a sí misma. La versión chilena lista a Perú y también a Chile (a sí misma). Un set típico para este corredor se ve así: es-CL apuntando a la URL chilena, es-PE apuntando a la peruana, y x-default apuntando a la versión que quieres mostrar al resto del mundo.
Tercero, hreflang se declara entre URLs indexables. Si la versión peruana tiene un noindex, un canonical apuntando a otra página o un redirect, el par se invalida. De nuevo: Google no reclama, simplemente ignora la etiqueta, y tú te enteras meses después cuando notas que en Lima aparece la versión chilena.
Un detalle que confunde harto: hreflang solo decide qué versión se muestra en cada país cuando tu contenido ya está posicionando. Si la página todavía no aparece en los resultados, la etiqueta no la va a empujar; ese trabajo sigue siendo del contenido y de la autoridad del sitio.
¿Qué significa localizar de verdad, más allá de traducir?
Entre dos países que hablan español no hay traducción, y eso hace que la localización floja se note el doble. Localizar de verdad es revisar, por lo menos:
El léxico de búsqueda: arriendo y alquiler, polera y polo, bencina y gasolina. Esto no se resuelve con intuición sino mirando datos de búsqueda por país, porque hay casos donde el término "chileno" también se usa en Perú y viceversa.
La moneda y los precios: publicar precios en pesos chilenos a usuarios peruanos es la forma más rápida de decirles "este sitio no es para ti". Y si trabajas con UF en Chile, en Perú ese concepto directamente no existe.
Las señales locales fuera del sitio: dirección local, perfil de Google Business por país, prensa y directorios locales. Esto pesa cada vez más, y no solo para Google: los asistentes de IA arman el perfil de tu empresa con todo lo que encuentran, y cuando le preguntan "qué empresa me sirve para esto en Perú", una marca cuyas menciones hablan solo de Chile parte perdiendo. La consistencia de entidad por país (que tu empresa se describa igual en tu sitio, en LinkedIn, en la prensa y hasta en las ofertas de trabajo de cada mercado) es parte del SEO internacional moderno, aunque no aparezca en los checklists clásicos.
Un ejemplo ilustrativo para dimensionar el impacto del léxico: si "alquiler de departamentos lima" concentra la demanda peruana y tu sitio entero dice "arriendo", puedes estar optimizado de manual y aun así quedar fuera de la conversación, simplemente porque tu mercado busca con otra palabra.
¿Cómo valido que está funcionando en Search Console?
Aquí es donde la mayoría suelta el volante, y es justo donde se ve si la implementación sirvió. El proceso que uso:
Primero, filtra el informe de rendimiento por país. Search Console te deja ver queries, clics e impresiones de Chile y de Perú por separado, y esa vista separada es la única que importa en un sitio multi país. El promedio combinado esconde todo.
Segundo, revisa qué URLs reciben las impresiones en cada país. Si en el filtro de Perú las impresiones se las lleva la versión /cl/, tu hreflang no está funcionando y hay que auditar los pares. Este chequeo toma diez minutos y detecta el problema antes de que le cueste tráfico a alguien.
Tercero, dale tiempo y mide de nuevo. Los cambios de hreflang y estructura tardan semanas en decantar, no días. Mi estándar es revisar a las cuatro semanas: impresiones por país, la proporción de cada versión en su mercado, y el CTR de las queries con léxico local. Como referencia ilustrativa, en un sitio donde la versión peruana captura el 30% de las impresiones de Perú al momento de partir, verla subir sostenidamente mes a mes es la señal de que el intercambio está operando; si se estanca, casi siempre hay pares rotos o canonicals cruzados.
¿Por dónde parto mañana?
Si tu empresa ya opera en más de un país, el diagnóstico completo toma una tarde y no necesita presupuesto: abre Search Console, filtra por cada país donde vendes y anota qué versión de tu sitio está recibiendo las impresiones ahí. Después toma tus cinco páginas más importantes y revisa tres cosas: que los pares de hreflang existan en ambas direcciones, que ninguna de las URLs declaradas tenga noindex ni canonical hacia otra página, y que el léxico de cada versión sea el del país (búscate a ti mismo con la palabra local y mira quién aparece).
Con ese diagnóstico en la mano ya sabes cuál de las tres decisiones de esta guía te toca revisar. Y si estás recién planificando la expansión, mejor todavía: todas estas decisiones son mucho más baratas de tomar ahora que cuando el sitio ya tiene años de historia que habría que migrar.