Webs multilingües para agencias: la guía práctica

Esta es nuestra guía de arquitectura para sitios web multilingües, desde la estrategia de URL hasta la localización de esquemas.

TL;DR. Un stack multilingüe sostenible para pyme descansa sobre cuatro decisiones: URLs en subdirectorios (ejemplo.com/es/, ejemplo.com/en/), slugs localizados por clave de página, una política clara de idioma por defecto y alternativa, y un flujo de traducción adaptado a un equipo pequeño. Sumados a localización por campo y hreflang automático, el CMS asume el trabajo que el editor repetiría a mano en cada cambio.

TL;DR (versión rápida)

• Utilice subdirectorios (/es/, /en/) en lugar de subdominios o TLDs separados para mejorar el SEO y simplificar el mantenimiento.
• Localice a nivel de campo (p. ej., texto) en lugar de a nivel de documento para evitar cargas de mantenimiento masivas.
• Un CMS debe manejar las etiquetas hreflang y la vista previa específica del idioma de forma automática para evitar errores humanos.

En España, en el resto de la UE y en cualquier mercado con presencia turística relevante, “¿admite varios idiomas?” no es una funcionalidad opcional: es una expectativa básica. Un web de hotel sin versión en inglés pierde clientes. Una clínica sin página en árabe deja fuera a pacientes. Una cartera de agencia pequeña que no gestiona bien el multilingüismo está operando por debajo de su capacidad. Por eso un CMS multitenant resulta especialmente ventajoso para agencias que atienden estos mercados.

Las cuatro decisiones previas

Las estrategias exitosas de i18n requieren cuatro decisiones arquitectónicas por adelantado: estructura de URL, convenciones de nombres de slugs, un idioma de respaldo y el modelo de flujo de trabajo de traducción.

Estrategia de URL. Hay tres opciones. El subdirectorio (ejemplo.com/es/, ejemplo.com/en/) es la opción recomendada para casi todos los casos. Un solo dominio, un solo certificado SSL, una sola propiedad de analítica, hreflang sencillo. El subdominio (es.ejemplo.com) es aceptable pero requiere más configuración. El ccTLD (ejemplo.es, ejemplo.fr) solo es útil si se dirige a mercados de país distintos de forma diferenciada. Para webs multilingües de pyme, use subdirectorios por defecto.

Slugs localizados. ejemplo.com/es/servicios/ suena natural a un visitante hispanohablante. ejemplo.com/es/services/ resulta tomado prestado. Los slugs localizados son mejores para la experiencia del usuario nativo, mejores para el SEO en el idioma nativo y señalan a los buscadores que cada versión de idioma tiene autoría independiente. El coste de implementación es un mapa de slugs por clave de página y por idioma: trabajo menor con una mejora de experiencia significativa.

Idioma por defecto y alternativa. Elija un idioma por defecto, normalmente el mercado de origen de la agencia o el inglés para un producto orientado a la UE. A continuación, decida qué ocurre cuando no existe una versión localizada de una página. Un error 404 estricto es correcto cuando cada página debe estar creada en cada idioma. La alternativa al idioma por defecto es aceptable cuando se empieza con una nueva variante de idioma que aún no está completa: muestre un aviso. La redirección es la opción más limpia para el SEO, pero puede resultar brusca.

Flujo de trabajo de traducción. Para webs de pyme con una agencia pequeña, hay tres patrones que funcionan. Traducir al inicio y editar por idioma después (el más habitual). Editar solo en el idioma principal con traducción automática en el momento de renderizado (económico, calidad variable). Equipo editorial por idioma (raro en webs gestionados de pyme).

hreflang en la práctica

Los buscadores necesitan saber qué página en qué idioma es la versión canónica del mismo contenido. El mecanismo es el atributo hreflang (documentado en Google Search Central), configurado en el encabezado de la página como link rel="alternate" hreflang para cada versión de idioma, más hreflang="x-default" apuntando a la alternativa. También en el mapa del sitio con xhtml:link rel="alternate" hreflang por entrada de URL. Un CMS multilingüe moderno gestiona ambos de forma automática.

Granularidad de la localización

No es necesario traducir todos los campos. Un modelo de contenido tipado permite a la agencia decidir campo a campo. Siempre localizados: títulos, cuerpo de texto, preguntas frecuentes, texto alternativo de imágenes, metatítulos y metadescripciones de SEO. A veces localizados: nombres de producto, cargos de miembros del equipo. Nunca localizados: opciones de maquetación, alineación, fechas (renderizadas de forma consciente del idioma en el momento de la vista), estructura de bloques, referencias de imágenes.

Un CMS que permite a la agencia marcar cada campo como localizable o no está haciendo gran parte del trabajo multilingüe de forma gratuita. Los indicadores de idioma a nivel de campo son la diferencia entre “traducir el web” y “traducir el contenido”.

Consideraciones para el mercado hispanohablante

Hay algunas cuestiones relevantes para webs dirigidas al mercado español. El registro formal con usted (no tú) en todo el contenido B2B en español de España; en mercados latinoamericanos puede convivir con un registro más cercano según el sector. El uso de vocabulario preciso de gestión empresarial - “gestionar” en lugar de “manejar”, términos propios del sector sin anglicismos innecesarios. El formato de fecha espera “9 de mayo de 2026”, no “May 9, 2026”. El formato numérico: 1.000,50 (punto como separador de miles, coma como decimal). El aviso legal y la política de privacidad son obligatorios por la LSSI-CE y el RGPD, y la política de cookies es necesaria si se establecen cookies no estrictamente técnicas - páginas legales por idioma, no solo una copia traducida de una única página. Si la web sirve a varios países hispanohablantes, considere hreflang="es-ES", es-MX, es-AR etc., para evitar que Google muestre el contenido del país equivocado.

Qué evitar

Una instalación de CMS por idioma: patrón antiguo que se convierte en una rueda de mantenimiento. Traducción automática solo en el momento de renderizado: válido para contenido de poco impacto, problemático para el SEO. Cuerpo HTML libre traducido en su conjunto: cualquier edición de contenido vuelve a desencadenar la revisión de toda la traducción del cuerpo.

La base de herramientas

Una agencia pequeña con webs multilingües necesita habitualmente un CMS que gestione campos localizados a nivel de esquema, slugs de URL localizados sin conciliación manual, hreflang automático en el encabezado y en el mapa del sitio, vista previa consciente del idioma, estado de borrador y publicación por idioma, y ganchos de API de traducción si se desea traducción asistida por IA. Según nuestra experiencia, Kernset incluye todas estas funcionalidades. Consulte el listado completo de funcionalidades para más detalles.

Para un web de pyme típico, espere un tiempo de carga de contenido adicional del 30 al 50 por ciento por cada idioma añadido en el lanzamiento. Las ediciones en estado normal son ligeramente más costosas por cambio porque el cliente edita en dos lugares. El beneficio es un web que habla genuinamente a su audiencia en su idioma, que en la mayoría de los mercados europeos es lo que cierra el trato.

Preguntas frecuentes

¿Debería utilizar dominios separados (por ejemplo, .es y .co.uk) para un sitio web multilingüe?

Por lo general, no para clientes de pymes. A menos que tenga equipos de marketing y presupuestos separados dedicados a construir la autoridad de dominio en cada región de forma independiente, el uso de subdirectorios (/es/, /en/) consolida toda su autoridad SEO en un solo dominio.

Compárelo con su cartera

Si su cartera mezcla hoteles, clínicas o servicios que necesitan sonar naturales en dos o tres idiomas, la forma más rápida de saber si Kernset encaja es compararlo con su web multilingüe actual más complicada. Solicitar acceso anticipado - cada mensaje lo lee una persona.