Los Errores Polylang y hreflang suelen aparecer cuando una URL de idioma ya no coincide con su destino real: el plugin genera enlaces, pero el servidor devuelve un 404, una redirección o una versión distinta de la página. En la práctica, el problema casi siempre está en la combinación de URLs cambiadas, slugs duplicados, canonicals o redirecciones mal resueltas.
La causa exacta puede estar en Polylang, en la configuración del servidor o en la implementación de hreflang, y se identifica separando primero si el fallo es un 404 real o una redirección. La validación con Screaming Frog y Search Console permite comprobar si hay 404, duplicados, canonicals contradictorios o sitemaps multilingües mal construidos.
Qué hacer primero al ver 404 y fallos
- Comprueba si la URL rota responde con 404 real o con redirección, porque no se arregla igual.
- Revisa si el fallo afecta a un idioma, a varios o solo a URLs cambiadas.
- Abre la página en modo incógnito y mira si el navegador te lleva a otra versión.
- Anota la URL antigua, la nueva y la versión de idioma que falla.
- No toques todavía Polylang ni los plugins SEO, porque el origen puede estar en el servidor.
Un 404 no siempre significa que la página desapareció. A veces es como una dirección postal vieja: la casa existe, pero el cartero ya no encuentra la entrada correcta.
Si la URL devuelve 301 o 302 antes del 404, el problema está en la cadena de redirecciones, no solo en Polylang.
Señales de alarma iniciales
Si ves 404 en una traducción reciente, piensa primero en cambios de slug, idioma o permalink. La señal más útil es simple: compara la URL que enlaza el menú con la URL que devuelve el navegador.
Lo habitual es que el fallo aparezca justo después de cambiar una traducción o activar un plugin SEO. Como Somos especialistas en mantenimiento WordPress para empresas, profesionales y tiendas online, he visto casos en que una página en español seguía indexada con la URL antigua mientras la versión en inglés ya apuntaba a otra ruta, algo que termina en 404 y en señales contradictorias para Google.
Revisar URLs antiguas y nuevas
Abre la versión rota y copia la URL exacta. Luego compárala con la que aparece en la edición de la entrada, en el menú y en el sitemap.
Si una URL antigua sigue entrando por enlaces internos, necesitas una redirección 301. Google y los usuarios pueden seguir llegando a la ruta vieja durante semanas, y si no hay 301 perderás señales y visitas.
Comprobar idioma por defecto
Mira cuál es el idioma por defecto en Polylang. Ese idioma suele actuar como base para muchas URLs y para la forma en que el plugin genera enlaces.
Si cambiaste el idioma principal después de publicar contenido, revisa cada traducción. Este detalle bloquea más incidencias de las que parece, sobre todo en sitios con muchas páginas antiguas.
Distinguir 404 de redirección
Abre la URL con una herramienta de cabecera o con el propio navegador y mira el código final. Un 404 dice que no existe la página; una redirección dice que la página existe, pero en otra dirección.
Si el 404 aparece tras una redirección, el problema está en el destino final. Si el destino final responde bien, la incidencia está antes, en la ruta de entrada.
Para separar si el problema nace en Polylang, en el servidor o en la configuración de hreflang, conviene seguir una secuencia muy simple. Primero prueba la URL exacta en el navegador y en una herramienta de cabeceras para ver si responde 200, 301, 302 o 404; si la respuesta cambia según el método, el servidor o la caché pueden estar interviniendo. Después desactiva temporalmente la capa SEO solo para comprobar si el conflicto desaparece, porque un plugin puede estar alterando canónicas o idiomas.
Revisa si la URL rota coincide con una versión traducida real o si es un enlace interno viejo. En sitios con muchas URLs de idioma, este orden evita confundir un fallo de permalinks con un error de indexación o con una redirección mal aplicada.
Por qué fallan polylang y hreflang
El fallo suele aparecer cuando hreflang dice una cosa y la canónica dice otra. Hreflang le dice a Google qué versión va para cada idioma, y la canónica señala qué URL debe considerarse la principal.
Si ambas señales se contradicen, Google puede ignorar la internacionalización. John Mueller ha repetido varias veces que las señales inconsistentes se degradan o se descartan, y eso encaja con lo que se ve en sitios reales.
Canonical mal alineado
La canónica es la forma de decir: “esta es la versión que quiero que se tome como referencia”. Si la canónica apunta a otra lengua, estás enviando un mensaje confuso.
Esto se nota mucho en tiendas con fichas de producto parecidas. Una traducción bien hecha puede quedar sin fuerza si la canónica arrastra a la página base.
Slugs duplicados entre idiomas
Un slug es la parte final de la URL, por ejemplo “servicios” o “services”. Si dos idiomas acaban con el mismo slug mal gestionado, el sistema puede generar rutas ambiguas.
Esto pasa mucho cuando se clona contenido y luego se traduce a mano. El problema no es solo estético; también puede romper enlaces internos y mapas del sitio.
Permalinks y reglas del servidor
Los permalinks son la estructura de URLs de WordPress. Cuando se guardan mal o el servidor no reescribe bien las reglas, aparecen 404 aunque la entrada exista.
Traducciones incompletas o huérfanas
Una traducción huérfana es una página que existe, pero no está bien enlazada con su pareja de idioma. Polylang necesita esa relación para generar enlaces y señales coherentes.
Cuando falta esa conexión, el hreflang puede no salir o salir con una URL equivocada. Eso crea huecos en la navegación y problemas de indexación.
En los casos avanzados, el problema no siempre está en la traducción visible, sino en señales técnicas que se pisan entre sí. Una canonical mal definida puede hacer que la versión inglesa canonice a la española, o que dos páginas de idiomas distintos se autodeclaren copia de una sola URL. También es frecuente encontrar slugs duplicados entre idiomas, sobre todo después de clonar páginas o crear versiones manuales sin revisar los permalinks. Si a eso se suman redirecciones 301 y redirecciones 302 mal usadas, Google puede rastrear rutas que terminan cambiando de destino o perdiendo autoridad.
Y cuando el sitemap multilingüe sigue listando URLs antiguas, la indexación se contamina con rutas que ya no deberían existir, generando más errores de rastreo y señales confusas para el buscador.
Cómo auditar el sitio paso a paso
Haz un rastreo con Screaming Frog y luego cruza el resultado con Search Console. Esa combinación permite separar el fallo visible del fallo que Google ya ha registrado.
En la práctica, esto significa revisar tres capas: lo que responde el servidor, lo que ve el rastreador y lo que Google está procesando. Si una capa contradice a otra, ahí está el problema.
Rastreo en screaming frog
Abre Screaming Frog y rastrea el dominio completo. Luego filtra por Internal, Response Codes y hreflang para ver las páginas afectadas.
Comprueba si la URL devuelve 200, 301 o 404. Si una URL con hreflang devuelve 301 o 404, ya tienes una señal de fallo técnico.
Revisar etiquetas hreflang
En Screaming Frog, abre la pestaña de hreflang y comprueba si cada URL apunta a su versión equivalente. Cada idioma debe referenciarse a sí mismo y a las demás versiones válidas.
Si ves una URL que apunta a sí misma pero no a su pareja de idioma, falta reciprocidad. Si apunta a una ruta que redirige o cae en 404, esa señal no sirve.
Validar canonicals y 404
Busca en el rastreo las canónicas que no coinciden con el idioma de la página. Si la traducción inglesa canoniza a la española, hay una contradicción clara.
Después filtra los 404 y cruza esos errores con las URLs que aparecen en hreflang. Ese cruce te dice qué señal está enviando la URL rota al resto del sitio.
Comprobar XML sitemap multidioma
Abre el sitemap y mira si incluye todas las variantes de idioma. Un XML sitemap multidioma bien hecho ayuda a descubrir páginas nuevas y a mantener el mapa limpio.
Si el sitemap incluye URLs antiguas o redireccionadas, elimínalas. Un sitemap con basura es como un plano con calles que ya no existen.
Cruce con search console
En Search Console, revisa Indexación, Páginas y los informes de idioma si los tienes disponibles. Busca URLs excluidas, redireccionadas o detectadas como duplicadas.
Luego compara esas URLs con el rastreo de Screaming Frog. Si ambas herramientas muestran el mismo problema, ya no es una sospecha: es una causa real.
Mi recomendación práctica es esta: revisa primero el código HTTP, después la canónica y por último el hreflang. Si haces ese orden al revés, puedes corregir la etiqueta de idioma y dejar vivo el fallo de fondo, que volverá en cuanto Google vuelva a rastrear. Cuando haya dudas, valida siempre con Screaming Frog y Search Console, y no des por bueno nada que redirija o responda con 404.
La validación de hreflang no debería quedarse en revisar el código fuente. En Screaming Frog puedes rastrear el sitio y revisar el informe de hreflang para detectar URLs que apuntan a destinos rotos, versiones no recíprocas o páginas que devuelven 301 y 404. En Search Console, el informe de Páginas ayuda a ver si Google está excluyendo traducciones por duplicadas, redireccionadas o con canonicals contradictorios. Si una URL aparece como válida en Screaming Frog pero excluida en Search Console, normalmente hay una discrepancia entre lo que muestra el rastreador y lo que Google considera indexable.
Esa diferencia es clave para detectar problemas reales de contenido multilingüe antes de que afecten al tráfico.
Cómo corregir el conflicto sin romper URLs
Corrige primero la base técnica y después la señal SEO. Si cambias el orden, puedes dejar al sitio en peor estado que antes.
Ajustar canonicals correctos
En el plugin SEO o en el tema, revisa que cada versión de idioma canonice a sí misma salvo que haya una razón clara para lo contrario. La canónica debe reflejar la versión que quieres indexar.
Si estás usando Yoast o un plugin parecido, comprueba que no esté forzando una canónica global para todas las lenguas. Eso rompe la lógica multidioma.
Crear redirecciones 301
Si cambiaste slugs, crea redirecciones 301 desde las URLs antiguas a las nuevas. Una 301 le dice al navegador y a Google que el cambio es permanente.
No uses 302 salvo que el cambio sea temporal. En migraciones de idioma o cambios de estructura, 301 es lo normal.
Corregir slugs y permalinks
Asegúrate de que cada idioma tiene un slug claro y distinto si el contenido lo necesita. Si dos idiomas comparten una ruta que no debería compartirse, corrígelo en la edición de la página.
Después vuelve a guardar los permalinks para regenerar reglas. Este paso parece simple, pero suele arreglar rutas que no responden por caché de reglas.
Reasignar traducciones en polylang
Abre cada contenido afectado y verifica que su traducción esté vinculada al original. Polylang necesita esa relación para construir la navegación y las señales internas.
Si una traducción quedó sin asignar, elimínala o relínkala antes de publicar. Una traducción suelta genera huecos en el interlinking.
Limpiar caché y regenerar reglas
Vacía la caché de WordPress, del plugin de caché y del servidor si existe. Si el sitio usa CDN, limpia también esa capa.
Después vuelve a comprobar la URL en incógnito y en Screaming Frog. Si sigues viendo la versión vieja, la caché aún está sirviendo contenido antiguo.
Casos avanzados que suelen pasar desapercibidos
Los fallos más caros no suelen estar en la página principal. Aparecen en páginas internas, sitemaps viejos o enlaces que nadie revisa hasta que Google deja de mostrar el idioma correcto.
Hreflang a páginas redireccionadas
Si un hreflang apunta a una URL que redirige, la señal pierde calidad. Lo ideal es que apunte siempre a la URL final que responde 200.
Canónicas que pisan idiomas
A veces una versión traducida hereda la canónica de la página original. Eso es como decirle a Google que la copia es la principal, aunque no lo sea.
Sitemaps con URLs desfasadas
Un sitemap viejo puede seguir enviando URLs eliminadas durante días o semanas. Si Google encuentra primero el sitemap, rastreará esas rutas rotas más veces de las necesarias.
Los menús, migas de pan y enlaces del contenido también pueden apuntar a la URL equivocada. Si una página traduce el slug pero el menú no se actualiza, el usuario salta a una ruta vieja.
Duplicado de contenido por idioma
Cuando dos versiones muestran el mismo texto sin cambios reales, el problema ya no es solo técnico. Google puede ver duplicidad y escoger una sola versión para indexar.
Lo más útil aquí es ordenar el sitio como una red limpia: una URL final por idioma, una canónica coherente, un hreflang recíproco y un sitemap sin restos viejos. Si haces solo una de esas cosas, el fallo puede volver en el siguiente rastreo. Cuando la causa viene de Polylang, del SEO plugin o del servidor, la prueba definitiva siempre es la misma: la URL debe responder 200, coincidir con su idioma y aparecer igual en Screaming Frog y Search Console.
Esto no aplica si tu sitio no tiene versiones multilingües, si no usas Polylang o si el problema es solo de contenido. Tampoco es prioritario si no hay 404, duplicados, redirecciones raras ni señales hreflang incoherentes.
Preguntas frecuentes sobre mantenimiento WordPress
¿Cómo solucionar errores 404 en polylang?
Primero comprueba si la URL antigua redirige a la nueva o cae en 404 directo. Si cambiaste slugs, crea una 301 y luego limpia caché y permalinks.
¿Cómo comprobar si hreflang está bien configurado?
Mira que cada URL apunte a su versión equivalente, que sea accesible con 200 y que la referencia sea recíproca. Screaming Frog es la forma más rápida de verlo.
¿Qué pasa si hreflang y canonical entran en
Google puede ignorar la señal de idioma o elegir otra versión para indexar. La canónica suele pesar mucho cuando la configuración está mal alineada.
¿Debo usar hreflang en todas las páginas?
Solo en las páginas que tienen equivalentes reales en otros idiomas. Si una URL no tiene traducción, no inventes una referencia.
¿Cada idioma necesita su propio XML sitemap?
No siempre, pero sí necesita un sitemap limpio y coherente con las URLs reales. Lo importante es que el sitemap no mezcle páginas antiguas, redirecciones o traducciones incompletas.
¿Qué hago si search console muestra duplicados?
Compara la URL duplicada con su canónica, su hreflang y su estado HTTP. Si alguna apunta a una ruta vieja, ahí tienes la causa.
¿Cuánto tarda en notarse la corrección?
La parte técnica puede quedar bien el mismo día, pero Google puede tardar desde unos días hasta varias semanas en reflejarlo. Depende del tamaño del sitio y de la frecuencia de rastreo.
Cierra la causa y valida el cambio
Cuando el sitio ya responde bien, repite el rastreo y compara los informes. Si Screaming Frog, el navegador y Search Console muestran la misma versión, la incidencia está cerrada de forma sólida.
No te quedes solo con “ya abre”. En multidioma, abrir no basta: tiene que abrir la URL correcta, con la canónica correcta y sin señales que se contradigan.
Si dudas entre tocar el plugin, el servidor o el SEO técnico, empieza por la evidencia. Eso ahorra tiempo y evita romper tráfico por una corrección precipitada.
