Quiere traducir un sitio web y está buscando opciones, pero siempre llega a lo mismo: proxy o API de traducción.
El problema es que ninguno de ellos funciona bien por defecto. Los formularios no se traducen. El contenido dinámico permanece en el idioma original. El SEO no mejora porque Google sigue viendo solo una versión del sitio. Y cuando intentas resolver esto, surgen nuevos problemas.
Este artículo explica cómo funciona cada enfoque, dónde falla cada uno y qué debes considerar antes de elegir.
Cómo funciona una API de traducción
Una API de traducción toma texto y lo devuelve en otro idioma. DeepL, Google Cloud Translation, Amazon Translate. Envías una solicitud y recibes una traducción.
Para usar esto en un sitio web, alguien debe integrar la API en el código:
- Un desarrollador para la integración inicial
- Lógica propia de caché y actualización de traducciones
- Pago por cada llamada (por caracteres o tokens)
- Soporte con cada cambio del sitio web
Lo que no sucede automáticamente: la API no sabe qué texto hay en su sitio web, cuándo cambia y cómo mostrarlo. Esto debe construirse de forma independiente. La API es solo el motor de traducción, todo lo demás es trabajo de integración.
Para proyectos con equipos técnicos propios y requisitos muy específicos, esto puede tener sentido. Para una agencia que necesita lanzar un sitio multilingüe en pocos días, esto es una carga demasiado grande.
Cómo funciona un proxy de traducción
Un proxy de traducción se encuentra entre el servidor de su sitio web y el navegador del usuario. Cuando alguien visita mycompany.com/ru/, la solicitud pasa por el proxy, que traduce el contenido en el servidor y devuelve la página ya traducida.
No es necesario tocar el código del sitio web. La configuración es una cuestión de DNS, no de desarrollo.
En la práctica:
- El contenido estático y dinámico se traduce antes de que llegue al navegador
- Las URL de cada idioma son reales: /ru/, /fr/, /de/
- Cuando se actualiza el contenido original, las traducciones se actualizan automáticamente
- El SEO funciona desde el primer día
Limitaciones reales: no todos los proxies de traducción traducen contenido dinámico. Los que se basan en JavaScript insertan las traducciones en el navegador, lo que significa que el SEO se ve afectado y los formularios permanecen sin traducir. Solo los proxies de traducción que funcionan en el servidor evitan estos problemas.
Problemas reales al traducir un sitio web
Antes de elegir entre un proxy y una API, vale la pena entender dónde falla cada enfoque en situaciones específicas.
Formularios
Los formularios son uno de los puntos más problemáticos. El texto de los campos, los mensajes de error y las confirmaciones suelen generarse dinámicamente. Con una API de cliente, este texto aparece con un retraso o no aparece en absoluto. Con un proxy de JavaScript, lo mismo. Solo un proxy que funciona en el servidor traduce los formularios de forma consistente.
Contenido dinámico (JavaScript)
Catálogos de productos, precios en tiempo real, texto generado por JavaScript, todo esto llega al navegador después de que la página se carga. El API del cliente y el proxy de JavaScript no pueden traducir lo que aún no está en el HTML. Resultado: páginas parcialmente traducidas.
SEO
Según la documentación oficial de Google Search Central, el contenido renderizado a través de JavaScript puede indexarse con un retraso significativo o no indexarse de forma consistente. Si las traducciones dependen de JavaScript, Google podría no verlas, o verlas semanas después.
Con un proxy de servidor, Google recibe una página ya traducida. Cada versión de idioma tiene una URL real, hreflang y un lugar en el índice.
Comercio electrónico
En una tienda online, el catálogo, los precios, los botones de compra y las páginas de confirmación deben estar traducidos. Un proceso de compra a medias en otro idioma no convierte. Y un catálogo que Google no indexa no atrae tráfico orgánico.
Comparación directa
¿Entonces, qué elegir?
Una API directa tiene sentido cuando hay un equipo técnico, tiempo para la integración y requisitos específicos: aplicaciones web complejas, traducción de contenido de usuario, pipelines de traducción de documentos.
Un proxy de JavaScript es fácil de instalar, pero tiene los mismos problemas de SEO y contenido dinámico que una API de cliente. Solo funciona bien para sitios estáticos muy simples.
Un proxy de servidor es la elección natural para sitios existentes que necesitan añadir idiomas sin cambiar el código, con un SEO funcional desde el primer día y soporte para contenido dinámico.
El problema es que la mayoría de los proxies en el mercado funcionan en el navegador, no en el servidor.
¿Hay alguna alternativa?
Algunas soluciones combinan lo mejor de ambos enfoques: funcionan como un proxy de servidor, sin cambiar el código del sitio web, pero utilizan modelos de traducción avanzados que tienen en cuenta el contexto, no solo el texto.
¿Qué significa esto en la práctica?
- Las páginas no se duplican en el CMS
- El contenido dinámico se traduce igual que el estático
- El SEO funciona desde el principio: URL reales, hreflang automático, sitemap para cada idioma
Multify funciona exactamente así. Se conecta a nivel de DNS, traduce todo en el servidor y genera automáticamente la estructura SEO para cada versión de idioma.