Al internacionalizar tu WordPress, un plugin de idiomas puede ampliar la superficie de ataque sin que resulte evidente: usuarios con permisos excesivos, redirecciones manipulables, traducciones automáticas que exponen datos o una restauración que afecta a todos los mercados. Un fallo aislado puede comprometer SEO, ventas y contenidos de varios países a la vez.
La seguridad en sitios multilingües no depende solo del plugin elegido: exige una arquitectura correcta, permisos mínimos, redirecciones controladas, actualizaciones verificadas y copias restaurables por idioma. WPML, Polylang, TranslatePress y Multisite pueden ser seguros si se configuran bien, con controles adaptados a cada idioma, país y rol de usuario.
Índice
Anuncio
La arquitectura define el alcance de una brecha
La arquitectura decide qué ocurre cuando falla una cuenta, un plugin o una regla del servidor. Los subdirectorios por idioma comparten instalación, usuarios y extensiones; los dominios por país separan más, pero multiplican las tareas de mantenimiento de WordPress. Piensa en ello como una oficina: compartir edificio simplifica la gestión, pero una llave maestra perdida abre más puertas.
No existe una opción segura para todos los casos. Una empresa con un catálogo común en España, Francia y Portugal puede trabajar bien con subdirectorios. Una marca con equipos, precios, datos de clientes y requisitos legales distintos por país suele necesitar un aislamiento mayor.
El error más frecuente en este punto es decidir solo por SEO internacional. El SEO importa, pero también debes decidir quién administra DNS, hosting, certificados SSL/TLS, cuentas de usuario y restauraciones cuando existe una incidencia.
Subdirectorios para una gestión centralizada
Los subdirectorios, como ejemplo.com/es/ y ejemplo.com/fr/, permiten gestionar contenidos y actualizaciones desde una sola instalación. Reducen el trabajo repetido, porque WordPress, tema y plugins se actualizan una vez, pero una vulnerabilidad en plugins compartidos alcanza a todos los idiomas.
Esta opción encaja cuando entre 2 y 8 idiomas usan el mismo catálogo, el mismo equipo técnico y unas reglas de privacidad similares. La copia debe incluir la base de datos completa, los medios y los ajustes del plugin de idiomas, porque las traducciones suelen estar relacionadas dentro de esas piezas.
Subdominios, dominios y multisite
Los subdominios, como fr.ejemplo.com, permiten separar caché, reglas de firewall y despliegues sin mantener dominios completos. Aun así, pueden compartir servidor, base de datos o instalación, así que no son un muro automático frente a una intrusión.
Los dominios por país, como ejemplo.fr o ejemplo.de, dan más separación operativa. Exigen controlar renovaciones, DNS, HTTPS, consentimiento de cookies y copias en cada mercado. WordPress Multisite centraliza muchos sitios bajo una red, pero el superadministrador, la cuenta con control de toda la red, puede modificar todos los portales.
| Arquitectura | Alcance de un fallo común | Copias y recuperación | Cuándo elegirla |
|---|---|---|---|
| Subdirectorios | Alto si comparten plugins y usuarios | Una copia global con pruebas por idioma | Catálogo y equipo comunes |
| Subdominios | Medio, depende de hosting e instalación | Revisar DNS, SSL y reglas por subdominio | Reglas técnicas diferenciadas |
| Dominios por país | Bajo si también se separan hosting y accesos | Copias, cuentas y dominios por mercado | Equipos o datos nacionales separados |
| WordPress Multisite | Alto ante fallo del superadministrador | Más compleja, con prueba por sitio | Red con soporte técnico especializado |
Como especialista en mantenimiento WordPress para empresas, profesionales y tiendas online, he visto un patrón verificable: cuando varios mercados comparten cuentas de administrador, la baja de una agencia deja accesos activos en más de un idioma. En consecuencia, revocar una sola cuenta ya no basta para cerrar el riesgo.
WPML, Polylang y TranslatePress seguros
WPML, Polylang y TranslatePress no son inseguros por sí mismos. El riesgo aumenta cuando se instalan versiones no oficiales, se acumulan extensiones sin uso o se actualizan WordPress, el plugin multilingüe y WooCommerce sin comprobar compatibilidad previa. Una actualización es como cambiar una pieza del motor: debe probarse antes de salir a carretera.
Descarga WPML desde su proveedor oficial y Polylang o TranslatePress desde WordPress.org o sus webs oficiales. Evita versiones nulled, es decir, copias modificadas para saltar licencias: pueden contener malware, puertas traseras o código que roba credenciales.
WordPress.org, Wordfence y Sucuri publican avisos sobre vulnerabilidades conocidas. INCIBE también difunde alertas y pautas para empresas españolas; conviene revisar sus avisos antes de aplicar cambios urgentes en producción.
Actualiza en un orden comprobado
Un entorno de staging es una copia privada del sitio para hacer pruebas sin afectar a ventas ni visitas. Actualiza allí el núcleo de WordPress, el plugin principal de idiomas, sus complementos, el tema y WooCommerce siguiendo el orden que documente el proveedor.
Comprueba entre 3 y 5 recorridos críticos por idioma: inicio, ficha de producto, carrito, formulario y acceso de usuario. Revisa también que no aparezcan textos mezclados, errores 500, URLs rotas o variaciones de precio mal traducidas.
Elimina código y extensiones sobrantes
Cada extensión activa añade código que necesita mantenimiento. Borra plugins inactivos, temas que no uses, módulos de traducción duplicados y fragmentos personalizados sin responsable conocido.
Los archivos .po y .mo guardan cadenas traducidas para WordPress. Deben proceder de fuentes fiables y tener permisos de archivo normales: no conviene permitir que usuarios del sitio los suban o modifiquen desde formularios públicos. Una carga de archivo mal filtrada puede convertirse en una puerta de entrada.
Lista de revisión para cada plugin
Antes de aprobar un plugin traductor WordPress gratis o de pago, revisa su última actualización, soporte de tu versión de PHP, compatibilidad declarada y número de extensiones necesarias. Un plugin con menos funciones puede ser más seguro si cubre el flujo editorial sin añadir cinco complementos extra.
- WPML: revisa sus complementos de cadena, WooCommerce y traducción automática antes de actualizar el núcleo.
- Polylang: confirma la compatibilidad de Polylang Pro o WooCommerce con el tema y las plantillas de producto.
- TranslatePress: limita quién puede editar traducciones visuales y protege sus claves de servicios automáticos.
- Cualquier plugin: consulta el registro de cambios y los avisos de vulnerabilidades antes de subir una versión mayor.
Roles mínimos para traductores y agencias
El principio de mínimo privilegio significa dar a cada persona solo el acceso que necesita para su tarea. Un traductor puede editar una página asignada, pero no necesita instalar plugins, ver pedidos, cambiar DNS ni crear administradores. Esta separación evita que un error de contenido se convierta en una incidencia de seguridad web.
Los permisos de WordPress no se deben asignar por confianza personal, sino por función. Una agencia puede ser excelente en traducción y no tener por qué entrar en ajustes técnicos, claves API o datos de clientes. Las cuentas compartidas impiden saber quién hizo un cambio y deben evitarse.
La Agencia Española de Protección de Datos recuerda que el acceso a datos personales debe estar limitado y justificado. En una tienda online, pedidos, direcciones, mensajes de soporte y facturas no deben quedar visibles para un traductor si no los necesita.
Permisos según el trabajo real
Un traductor debería crear o editar traducciones asignadas y enviar textos a revisión. Un editor regional puede aprobar contenido comercial en su idioma. Un administrador técnico gestiona plugins, seguridad, copias y servidor; no debe usar esa cuenta para publicar una entrada diaria.
| Rol | Acceso necesario | Acceso que debe quedar bloqueado |
|---|---|---|
| Traductor | Textos y medios asignados | Plugins, usuarios, pedidos y ajustes |
| Editor regional | Revisión y publicación de su mercado | Claves, temas y cambios globales |
| Agencia externa | Proyecto concreto y durante plazo definido | Cuenta compartida o acceso indefinido |
| Administrador técnico | Mantenimiento y recuperación | Uso diario para editar contenido |
Cuentas protegidas y con caducidad
Las cuentas con permisos altos deben usar contraseñas únicas y autenticación de dos factores, o 2FA. El 2FA pide una segunda prueba, como un código temporal, igual que un banco pide confirmar una operación desde el móvil.
Crea cuentas personales para cada profesional, registra sus cambios y fija una fecha de revisión. Al acabar una campaña o contrato, desactiva la cuenta ese mismo día. Un registro de actividad permite ver qué usuario cambió una redirección, modificó una traducción o creó un rol nuevo.
Como especialista en mantenimiento WordPress para empresas, profesionales y tiendas online, he visto un caso recurrente: una agencia recibió perfil de administrador para editar textos y mantuvo acceso tras terminar el proyecto. La consecuencia verificable fue la necesidad de auditar usuarios, renovar contraseñas y rotar claves de servicio antes de poder confirmar que el sitio estaba cerrado.
Redirecciones de idioma sin bucles ni cloaking
Las redirecciones automáticas deben sugerir un idioma, no encerrar al visitante en él. Una redirección segura acepta solo destinos internos validados, no actúa sobre bots y deja un selector visible para cambiar de idioma. Así evitas bucles, phishing y problemas de indexación.
Una redirección abierta ocurre cuando una URL acepta un destino externo manipulable, por ejemplo, un parámetro que envía al visitante a otra web. Es como dejar un cartel de tu negocio que, según lo que escriba cualquiera, puede apuntar a la puerta de un tercero.
El cloaking consiste en mostrar o enviar contenidos distintos a buscadores y personas de forma engañosa. Google necesita que cada URL por idioma sea accesible por sí misma y que las etiquetas hreflang indiquen qué versión corresponde a cada público.
Usa el navegador solo como pista
La cabecera Accept-Language comunica las preferencias de idioma del navegador. Puede servir para una primera sugerencia, pero no identifica con certeza el país, la residencia ni el idioma elegido por una persona.
Guarda una elección expresa con una cookie funcional y permite cambiarla desde un selector visible. Si una persona vive en España y prefiere navegar en inglés, no debe volver a /es/ en cada página. Revisa el consentimiento de cookies conforme al RGPD y la LSSI-CE cuando la cookie no sea estrictamente necesaria.
Valida destino, dominio y protocolo
Permite redirigir solo a rutas previstas, como /es/, /fr/ o /de/. Rechaza URLs completas enviadas por parámetros, dominios externos, protocolos distintos de HTTPS y rutas que incluyan caracteres inesperados.
Excluye a rastreadores conocidos de la redirección automática y no bloquees el acceso directo a una URL. Comprueba, al menos en móvil, escritorio y modo privado, que no haya cadenas de más de una redirección, porque cada salto aumenta la carga y puede confundir a los buscadores.
Antes de publicar un idioma nuevo o cambiar reglas de geolocalización, utiliza una matriz de auditoría que combine idioma, país de acceso, rol y dispositivo. Por ejemplo, prueba una visita desde móvil en francés con el navegador configurado en inglés, un editor regional que intenta acceder a contenidos de otro mercado y un traductor que carga un archivo PDF. Comprueba que el selector conserva la elección, que las redirecciones por idioma no crean bucles, que cada URL devuelve el código HTTP esperado y que los formularios muestran los textos legales correctos.
Incluye también pruebas de login, recuperación de contraseña, carrito, APIs y enlaces a dominios por país, y registra el responsable, el resultado y la fecha de cada validación.
APIs, formularios y monitorización por idioma
Las claves API de traducción automática, geolocalización o formularios deben vivir fuera del código público y tener permisos limitados. Si envías textos con nombres, direcciones, tickets o pedidos a un proveedor externo, existe tratamiento de datos personales y debes revisarlo conforme al Reglamento General de Protección de Datos.
Una API es una vía para que dos servicios intercambien datos. La clave API es su contraseña técnica; dejarla en JavaScript, en un repositorio público o en una captura es como pegar la llave del almacén en el escaparate.
La protección no termina en el plugin de traducción. Formularios, archivos PDF, medios, REST API y XML-RPC pueden abrir vías de spam, inyección o acceso indebido en cualquier idioma.
Claves API y traducción automática
Guarda secretos en variables de entorno del servidor, ficheros privados fuera de la carpeta pública o un gestor de secretos. Restringe cada clave por dominio, cuota y servicio, y crea una clave distinta para pruebas y producción.
Revisa el contrato de encargado de tratamiento, la ubicación del proveedor y las transferencias fuera de la Unión Europea o del Espacio Económico Europeo. La LOPDGDD complementa el RGPD en España, y la Agencia Española de Protección de Datos puede orientar en tratamientos complejos.
Una llave de seguridad USB añade una segunda prueba física para entrar en cuentas críticas de WordPress. Resulta útil para administradores y responsables técnicos que gestionan varios idiomas o mercados.
- Reduce el riesgo de acceso si se filtra una contraseña de administrador
- Evita depender solo de códigos SMS para cuentas técnicas de alto privilegio
- Permite separar la protección de administradores, agencias y editores regionales
WAF, login y archivos públicos
Un firewall de aplicaciones web o WAF filtra peticiones antes de que lleguen a WordPress. Configúralo para frenar fuerza bruta, intentos de XSS, que consisten en inyectar código en una página, y patrones de bots maliciosos, sin bloquear a usuarios legítimos de otros países.
Activa 2FA en perfiles privilegiados, límites de intentos de acceso y alertas ante nuevas cuentas de administrador. Revisa qué endpoints de la REST API son necesarios y restringe XML-RPC si ninguna integración verificada lo requiere. Mantén HTTPS en todos los idiomas y añade cabeceras de seguridad coherentes, sin romper recursos externos que necesite el sitio.
Alertas que merecen una revisión humana
Monitoriza cambios de archivos, malware, nuevos administradores, modificaciones de redirecciones y picos de errores 404 por idioma. Wordfence o Sucuri pueden avisar, pero una alerta no sustituye el análisis de una persona que conozca el sitio y sus flujos normales.
Al comparar varias fuentes especializadas, se repite que las vulnerabilidades conocidas se explotan con rapidez cuando un plugin queda sin actualizar, especialmente si el sitio expone login o administración sin 2FA. La Directiva NIS2 y el Esquema Nacional de Seguridad también refuerzan una idea útil: prevenir incluye detectar, responder y recuperar.
Las copias de seguridad deben diseñarse según la arquitectura y no limitarse a una exportación periódica de la base de datos. Define una frecuencia para archivos, base de datos, configuraciones del servidor y registros DNS, con retención suficiente para detectar una intrusión tardía. En una instalación con subdirectorios por idioma, la restauración por idioma puede requerir recuperar tablas, medios y relaciones de traducción sin sobrescribir cambios legítimos de otros mercados; por eso debe ensayarse primero en staging.
Documenta quién autoriza la recuperación, cuánto tiempo máximo puede estar caído cada mercado y cómo se verifica después que funcionan pagos, formularios, enlaces hreflang y permisos de usuario.
Anuncio
Copias y pruebas antes de abrir cada mercado
Una copia de seguridad útil en una web con idiomas debe permitir recuperar contenido, medios y ajustes de un idioma concreto sin dañar los demás. No basta con comprobar que existe un archivo de backup: hay que restaurarlo en un entorno aislado y verificar el resultado.
Mantén entre 3 y 7 puntos de restauración, según la frecuencia de cambios y ventas. Para una tienda con pedidos diarios, combina una copia de base de datos frecuente con una copia completa diaria y una copia externa cifrada. El plazo de retención debe cubrir al menos el tiempo razonable para detectar un problema oculto.
Una restauración granular no siempre es posible en una instalación compartida. Si las traducciones están en las mismas tablas que el resto del contenido, recuperar solo francés puede requerir primero restaurar una copia completa en staging y exportar los elementos correctos.
Prueba la recuperación de cada idioma
Elige una página, una imagen, un formulario y una configuración de idioma para cada mercado. Restaura esa muestra en pruebas y confirma que enlaces, medios, SEO, menús y relaciones de traducción siguen funcionando.
Un caso habitual: se restaura una base de datos global para recuperar una ficha alemana y se pierden pedidos recientes de la tienda española. La medida correcta es separar primero la recuperación en staging, extraer el contenido validado y llevarlo a producción con control de cambios.
Matriz de auditoría de lanzamiento
Antes de publicar, prueba por idioma, país, rol y dispositivo. Esta matriz evita el error de verificar solo la portada en español y descubrir semanas después que el formulario francés envía datos a una cuenta antigua.
- Idioma: comprueba URLs, selector, hreflang, textos legales, precios, formularios y medios en cada versión.
- País: revisa dominio, HTTPS, cookies, moneda, reglas de envío y destinatarios de formularios.
- Rol: valida qué ven y qué pueden cambiar traductores, editores, agencias y administradores.
- Dispositivo: prueba móvil, escritorio y navegación privada para detectar bucles de redirección y caché.
- Recuperación: restaura una muestra de contenido y un medio sin tocar el sitio público.
Para una auditoría previa al lanzamiento o una migración de WPML, Polylang o TranslatePress, un servicio especializado de mantenimiento WordPress puede revisar compatibilidades, roles, copias y reglas de redirección antes de que lleguen visitantes reales.
Resuelve tus dudas
¿Es seguro usar WPML en WordPress?
Sí, WPML puede ser seguro si procede de su fuente oficial, se mantiene actualizado y se prueba con WordPress, PHP y WooCommerce antes de publicar cambios. El riesgo crece si se usan complementos obsoletos o cuentas de administrador compartidas.
¿Qué es mejor, WPML o Polylang?
Depende del flujo de traducción, integraciones y soporte que necesites. WPML y Polylang pueden ser opciones seguras si el plugin elegido es compatible con tu tema y puedes probar sus actualizaciones en staging.
¿Un plugin multilenguaje WordPress gratis es seguro?
Puede serlo si se descarga desde WordPress.org, tiene mantenimiento activo y cubre tus necesidades sin extensiones de origen dudoso. Gratis no significa inseguro, pero tampoco elimina la necesidad de revisar avisos y compatibilidades.
¿Debo dar acceso de administrador a mi traductor?
No, salvo una necesidad técnica temporal y supervisada. Un traductor suele necesitar acceso a entradas, páginas o productos asignados, pero no a usuarios, plugins, pedidos ni claves API.
¿Cómo evito bucles al redirigir por idioma?
Guarda la elección explícita del usuario, limita el destino a rutas internas válidas y deja un selector visible. Prueba la navegación en modo privado y confirma que una URL de idioma carga con cero o una redirección.
¿Las traducciones automáticas cumplen el RGPD?
Solo si el tratamiento de datos está evaluado y el proveedor ofrece garantías adecuadas. Si envías datos personales fuera de la Unión Europea, revisa contrato, transferencias internacionales y medidas de seguridad antes de activar el servicio.
¿Puedo restaurar solo un idioma de WordPress?
A veces, pero depende de cómo guarde las traducciones tu plugin y de si compartes base de datos. La forma segura es restaurar primero en staging, validar el contenido y trasladar solo los elementos necesarios.
¿Necesito un WAF si ya tengo un plugin de seguridad?
Sí, puede ser recomendable porque un WAF filtra ataques antes de que carguen WordPress. Debe configurarse y revisarse, ya que una regla demasiado estricta puede bloquear formularios o usuarios de un país concreto.
Tu siguiente paso antes del lanzamiento
Protege primero las cuentas y la arquitectura, después el plugin de idiomas. Define qué comparten los mercados, da permisos mínimos, guarda las claves fuera del código, prueba redirecciones y valida una restauración antes de abrir cada versión pública.
La decisión más prudente es documentar responsables, accesos y copias antes de añadir el siguiente idioma. Un sitio web multilingüe bien mantenido no depende de una única herramienta: depende de controles que sigan funcionando cuando cambian personas, plugins o mercados.
La seguridad multilingüe no consiste en bloquear más: consiste en limitar el alcance de cada error y saber recuperar el servicio sin perder el control de los demás idiomas.
- Al restaurar backups, puedes borrar cambios recientes
- El error al restaurar WordPress que duplica usuarios
Josu Barrios
Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online. Contamos con experiencia en seguridad web, optimización de rendimiento, actualizaciones, copias de seguridad y resolución de incidencias técnicas, ayudando a que cada sitio funcione de forma rápida, estable y protegida. Nuestro enfoque combina soporte técnico profesional, buenas prácticas de seguridad y seguimiento continuo para ofrecer un servicio fiable, transparente y orientado a resultados reales.