WordPress enterprise multilingüe que tus equipos regionales pueden operar

No hay una única respuesta, y quien te da una no hizo suficientes preguntas. Elegimos contra el volumen de contenido, la estructura editorial y tu stack.

• WPML: centralizado, potente, muy adoptado, compatible con ACF y con contenido en bloques. Costo: peso en performance y una curva de aprendizaje real.
• Polylang: liviano y simple, gratis en su versión base. Costo: varias funciones que vas a querer están solo en la versión Pro.
• MultilingualPress: un sitio por idioma sobre Multisite. Separación limpia, buena performance, amigable con el SEO. Costo: requiere Multisite y es el más técnico de operar.
• TranslatePress: editor visual de traducción, fácil para los editores, se integra con DeepL y Google Translate. Costo: menos flexible en sitios complejos.
• Weglot: hosteado, el más rápido de implementar, muy visual. Costo: precio, una dependencia externa y ningún control total sobre tu salida de SEO.

Acá usamos Polylang Pro, y por eso nuestras páginas en español se sirven bajo /. Esa es nuestra elección para nuestro stack, no un default para el tuyo.

Depende de qué tan separados están tus mercados de verdad. Un solo sitio con un plugin de traducción mantiene un único modelo de contenido, una biblioteca de medios y un admin, y eso es más simple de mantener sincronizado. Multisite con MultilingualPress le da a cada idioma su propio sitio: separación limpia, performance por locale y ningún riesgo de que el cambio de un mercado afecte a otro.

Multisite cuesta más operar: más entornos, más superficie de actualización. Lo recomendamos cuando los mercados tienen contenido genuinamente distinto y no traducciones de lo mismo, o cuando los equipos regionales necesitan límites duros. Si no, el camino del plugin es más liviano. Más sobre esto en nuestra página de soluciones multisite.

Sobreviven si alguien los revisa. Lo que más se rompe: los bloques renderizados del lado del servidor con un render callback, los valores de Advanced Custom Fields, los custom post types, los términos de taxonomía y las etiquetas y confirmaciones de Gravity Forms. Nada de eso se traduce por instalar un plugin.

Cada caso se trata de forma explícita y después se prueba en staging: el texto traducido cambia de largo, y las cadenas largas rompen layouts que en inglés se veían bien.

Para borradores, sí. Como versión publicada, no.

Varias de estas herramientas soportan integraciones con DeepL y Google Translate, y sirven para poner una primera pasada frente a un revisor. Lo que no pueden hacer es sostener la voz de tu marca ni detectar un término técnico que en tu industria significa otra cosa.

La salida automática se publica solo después de una revisión humana, y esa revisión es responsabilidad de alguien con nombre y apellido. Si nadie puede revisar un idioma, lanzá menos idiomas.

En tres lugares, y los tres son configuración más que contenido. La estructura de URLs determina si Google puede distinguir tus locales. El hreflang determina qué versión llega a cada mercado. Los metadatos traducidos determinan si a ese resultado vale la pena hacerle clic.

El modo de falla no es una penalización. Es Google mostrándole tu página en inglés a un visitante hispanohablante, o dos locales compitiendo por la misma consulta. Las dos cosas son más baratas de prevenir que de arreglar, y por eso esto corre en paralelo al SEO para WordPress enterprise y no después.