Esta web funcionó en inglés y español mediante la localización nativa de Framer, con la versión española bajo /es/. Configurarlo lleva una tarde. Mantenerlo bien, conseguir que Google indexe correctamente ambas versiones y que cada idioma genere tráfico propio exige un proceso continuo con puntos de fallo muy concretos.
Este artículo documenta ese proceso: qué automatiza la plataforma, qué deja silenciosamente en tus manos y qué comprobaciones detectan la distancia entre ambas cosas.
Qué automatiza Framer y hace bien
La capa técnica del SEO internacional es la parte que Framer resuelve casi sin intervención. Según la documentación de Framer, el atributo lang cambia automáticamente para coincidir con el idioma seleccionado y se añade una etiqueta hreflang cuando una página tiene una versión en otro idioma.
Ambas etiquetas se gestionan internamente y no pueden editarse desde la interfaz. Esto elimina toda una categoría de errores humanos.
Es importante porque hreflang resulta especialmente fácil de implementar mal a mano. La documentación de Google sobre versiones localizadas exige anotaciones recíprocas: si la página inglesa apunta a la española, la española debe apuntar de vuelta, y ambas deben referenciarse a sí mismas. Las implementaciones manuales rompen estas relaciones constantemente.
Que Framer genere ambos lados desde una sola fuente de verdad es el argumento más sólido para utilizar la función nativa en lugar de construir una solución improvisada.
Hay otras dos automatizaciones relevantes. Automatic Locale redirige según las preferencias de idioma del navegador y la zona horaria del dispositivo, no mediante geolocalización, y solo funciona sobre el dominio canónico. Además, Framer puede traducir las rutas de cualquier página, no solamente del CMS, eliminando la antigua necesidad de duplicar páginas para localizar slugs.
Lo que sigue siendo manual: aquello que decide si /es/ posiciona
Todo lo anterior es fontanería. El trabajo que determina si la versión española merece tráfico sigue dependiendo de ti.
Metadatos localizados. Títulos y descripciones no se adaptan solos. Una traducción automática se reconoce fácilmente en la SERP, justo donde se decide el CTR. Cada idioma necesita metadatos escritos para las consultas que las personas realmente hacen, que rara vez son traducciones literales.
Calidad por idioma. La traducción automática es un borrador. Una revisión independiente de configuraciones multilingües en Framer llegó a la misma conclusión: la capa técnica solo funciona cuando cada idioma tiene contenido revisado, metadatos localizados y una estructura limpia de URLs. Mi enfoque va un poco más lejos: la versión española puede comenzar y argumentar de otra manera porque se dirige a otro lector.
Datos estructurados. Cualquier schema que introduzcas debe tener en cuenta el idioma, la URL y los valores visibles. Desarrollo el planteamiento completo en SEO estructural y JSON-LD en Framer.
El proceso del CMS y el detalle que casi nadie documenta
En Framer, el contenido localizado del CMS vive como traducciones asociadas al elemento del idioma predeterminado: misma colección, mismo registro y valores distintos por idioma. En el trabajo diario resulta cómodo. Editas un elemento y cambias de locale dentro de la misma vista.
El problema aparece al construir un flujo sobre CSV. Exportas una colección y obtienes únicamente el idioma predeterminado; los valores españoles no viajan dentro del archivo. Lo confirmé con la exportación de esta misma web mientras construía el pipeline que explico en cómo importar contenido automáticamente en Framer.
Las consecuencias prácticas son:
El CSV es un canal exclusivo del idioma predeterminado. Úsalo como columna vertebral de la lengua principal, no como backup multilingüe.
El contenido español debe introducirse mediante la interfaz de localización, así que el checklist editorial necesita un segundo paso explícito por artículo o el locale se quedará atrás silenciosamente.
El backup fuera de Framer de tus traducciones será exactamente aquello que hayas guardado por tu cuenta. Conserva los documentos fuente.
El QA que detecta la deriva
Después de publicar o reestructurar, dedica cinco minutos a cada idioma:
abre el código fuente de una página clave y confirma que los pares hreflang existen y son recíprocos;
comprueba que la URL localizada resuelve correctamente y no vuelve al idioma predeterminado a mitad de página;
verifica que el sitemap contiene ambos idiomas;
segmenta Search Console por ruta para que
/es/no desaparezca dentro del promedio general;busca cadenas inglesas olvidadas dentro del contenido español.
Las páginas con idiomas mezclados son la deriva más común y la más dañina para la confianza. Una frase inglesa escondida dentro de un artículo largo puede pasar todas las verificaciones técnicas y seguir comunicando que nadie revisó la experiencia.
Cuándo la localización nativa deja de ser suficiente
Para un sitio con dos idiomas, un solo autor y una estrategia centrada en contenido, la localización nativa puede ser la herramienta adecuada. El límite honesto aparece con un volumen editorial alto, muchos idiomas o un equipo con etapas formales de traducción y revisión. En ese punto probablemente necesitas un servicio dedicado, con sus propios costes y renuncias de control.
La idea que merece conservarse es la división del trabajo: Framer controla las etiquetas; tú controlas el idioma. Una web puede superar todos los validadores de hreflang y seguir teniendo una segunda versión que nadie busca, porque sus metadatos y su contenido fueron traducidos en lugar de escritos.
La herramienta resolvió la parte que antes era difícil para que la parte editorial pudiera convertirse en el verdadero trabajo.