Por qué tu plugin de traducción podría estar destruyendo tu SEO en silencio (lo descubrimos en nuestro propio sitio)
Durante los últimos meses, algo empezó a sentirse raro en nuestras analíticas. Los visitantes de habla hispana (históricamente nuestro segmento internacional más fuerte) habían estado disminuyendo de forma constante. Al principio lo achacamos a la estacionalidad. Luego al clima económico general en Latinoamérica. Después a "Google probablemente cambió algo".
Ninguna de esas era la respuesta real.
Cuando finalmente nos sentamos a auditar nuestra propia configuración multilingüe, descubrimos que el plugin de traducción que habíamos estado usando durante años había estado dañando silenciosamente nuestro SEO en cada página en español del sitio. Nombres de marca distorsionados en los metadatos. Entidades de Schema apuntando a URLs incorrectas. Declaraciones hreflang que Google probablemente ignoraba por completo. Etiquetas canónicas inconsistentes con el resto del sitio. Migas de pan enviando a visitantes hispanohablantes de vuelta a páginas en inglés.
Llevamos 25 años gestionando sitios web. Diseñamos nuestra propia infraestructura, gestionamos nuestros propios servidores de correo, escribimos nuestro propio monitoreo, y aun así nos perdimos esto. Porque el resultado de un plugin de traducción se ve bien en la superficie. El daño está en las partes de la página que los visitantes no ven y que la mayoría de los propietarios de sitios nunca revisan.
Si tienes un sitio WordPress multilingüe, hay una probabilidad real de que algunos de estos problemas estén ocurriendo en el tuyo ahora mismo. Aquí te explicamos qué buscar, por qué importa cada uno y cómo verificarlo.
Los cinco problemas
Abre tu sitio en español (o en el idioma que ofrezcas) y ve al código fuente de la página. Busca application/ld+json para encontrar tus datos estructurados. Revisa los campos de entidad: name, alternateName, caption, description.
Si tu nombre de marca aparece traducido, por ejemplo, "Cloud Notable" en lugar de "RemarkableCloud", o "Nube Notable", tu plugin de traducción ha cruzado una línea que no debería cruzar. Los nombres de marca son sustantivos propios. No se traducen. Pero muchos plugins de traducción tratan todo el texto por igual y pasan las cadenas de marca por su motor de traducción, enviando la versión traducida a tus datos estructurados.
Google lee los datos estructurados como metadatos autoritativos sobre tu sitio. Cuando el campo de marca no coincide entre idiomas, la comprensión que tiene Google de tu negocio como una entidad única se fragmenta. Peor aún, tu entrada en el knowledge graph (ese panel de negocio que aparece en los resultados de búsqueda) puede mostrar nombres inconsistentes o incorrectos dependiendo de qué versión de idioma indexó Google por última vez.
Tu nombre de marca debe aparecer de forma idéntica en cada versión de idioma de tu sitio. Ve al código fuente de tus páginas traducidas y busca tu nombre de marca en los datos estructurados. Los únicos campos que deben cambiar son el contenido descriptivo alrededor de la marca, no el nombre de la marca en sí.
Hreflang le dice a los motores de búsqueda "esta página existe en inglés en la URL A, en español en la URL B". Bien implementado, consolida la autoridad SEO entre versiones de idioma y evita penalizaciones por contenido duplicado. Mal implementado, confunde activamente a Google.
Encontramos tres problemas distintos en nuestro propio sitio:
- Declaraciones hreflang duplicadas. Tanto el plugin de traducción como nuestro plugin SEO emitían sus propios conjuntos, por lo que Google veía cada par dos veces. Algunos motores de búsqueda tratan los duplicados como una señal de que algo está roto y se retiran.
- Anotaciones recíprocas faltantes en el sitemap. Las entradas del sitemap en inglés no referenciaban sus contrapartes en español, y viceversa. Teníamos hreflang en el encabezado de la página, pero el sitemap estaba incompleto en cuanto al idioma.
- Apuntando a URLs con redireccionamiento 301. Nuestro hreflang indicaba que la versión en español estaba en /es/page/ (con barra final) pero la URL canónica real era /es/page (sin barra). La URL del hreflang redirigía, lo que Google trata como ambiguo.
Abre tu página traducida, ve al código fuente y busca hreflang. Deberías ver exactamente una declaración por par de idiomas, apuntando a URLs que devuelvan HTTP 200 directamente sin ningún redireccionamiento intermedio.
Este es sutil pero dañino para el SEO. Muchos plugins SEO de WordPress detectan que tu página de inicio traducida se sirve desde un objeto de post o página regular y por defecto la marcan como og:type="article" en los metadatos de OpenGraph. También añaden el schema Article a los datos estructurados.
Una página de inicio no es un artículo. El marcado Article le dice a Google "este es contenido sensible al tiempo con una fecha de publicación y un autor". Tu página de inicio no es ninguna de esas cosas. Los motores de búsqueda ponderan el contenido etiquetado como Article de forma diferente al contenido etiquetado como WebPage, y una página de inicio incorrectamente etiquetada como Article tiende a tener un rendimiento inferior en búsquedas de marca.
Teníamos esto en nuestra página de inicio en español pero no en la inglesa. Las dos páginas estaban enviando señales diferentes a Google sobre el mismo negocio.
Ve al código fuente de tu página de inicio traducida. Busca og:type: debe ser website (o business.business para sitios B2B), no article. Busca "@type":"Article". No debería haber uno en una página de inicio.
Algunos sitios WordPress usan barras finales (ejemplo.com/sobre/). Otros no (ejemplo.com/sobre). Cualquiera está bien, siempre que seas consistente. Los plugins de traducción frecuentemente no lo son.
Encontramos que el canónico de nuestra página de inicio en español se emitía sin barra final, pero las entradas en español dentro de nuestros datos estructurados referenciaban la misma página de inicio con barra final. Google las ve como URLs diferentes aunque ambas resuelvan al mismo contenido. La autoridad de la URL se divide. Las señales de enlazado interno se confunden.
Elige cualquier página de tu sitio. Compara la URL de <link rel="canonical">, las entradas de tu sitemap para esa página, cualquier enlace interno que apunte a ella, y el campo url en cualquier dato estructurado. Si no son todos idénticos (con o sin barra, coincidiendo exactamente), tienes una inconsistencia que necesita corrección.
Los plugins de traducción a menudo traducen el texto visible de las migas de pan ("Home" se convierte en "Inicio") pero se olvidan de traducir el enlace subyacente. Los visitantes hispanohablantes que hacen clic en "Inicio" aterrizan en la página de inicio en inglés en lugar de la española. A mitad de sesión, cambian de idioma sin previo aviso.
Esto rompe la confianza del usuario y daña la señal de tasa de rebote que Google usa para posicionar páginas. Una página en español de alta calidad con una miga de pan rota rinde peor que una página en español mediocre con una navegación intacta.
Abre la versión en español de tu sitio y navega a cualquier página interna. Haz clic en la miga de pan "Inicio" o equivalente. Debería llevarte a la página de inicio en español, no a la inglesa. Luego ve al código fuente y revisa los datos estructurados de las migas de pan: la URL de item dentro del primer ListItem debe coincidir exactamente con la URL de tu página de inicio traducida.
Por qué los plugins de traducción siguen haciendo esto
No es que los desarrolladores de plugins de traducción sean descuidados. Es que los plugins de traducción están diseñados para un trabajo (traducir texto visible) y la infraestructura SEO es un trabajo completamente diferente. Los dos se agrupan juntos porque la mayoría de los propietarios de sitios quieren un solo plugin que gestione "todo lo multilingüe", pero esa combinación genera compromisos que nadie advierte.
- Tratan los datos estructurados como texto a traducir, en lugar de reconocerlos como metadatos legibles por máquina con sus propias reglas
- Construyen sus declaraciones hreflang a partir de una lista estática en el momento de la instalación, no desde tu estructura de URLs activa
- Codifican de forma rígida las convenciones de barra final que pueden no coincidir con la convención existente de tu sitio
- Se configuran por defecto con los ajustes de OpenGraph y schema que emite tu plugin SEO, en lugar de sobreescribirlos correctamente para las páginas traducidas
El daño se acumula lentamente. Cada problema individual puede costarte una o dos posiciones en el ranking. Cinco de ellos apilados durante seis meses (que es lo que medimos en nuestro propio sitio) suman el tipo de caída gradual de tráfico que no aparece como una bajada repentina que investigarías. Aparece como una erosión gradual que asumes que es el mercado.
Qué hicimos al respecto
Cuando la auditoría confirmó lo que estaba pasando, tomamos una decisión: en lugar de intentar parchear el plugin existente, construiríamos nuestra propia infraestructura de traducción que se integrara correctamente con nuestra arquitectura SEO. Posts nativos en español en WordPress (no basados en proxy). Intercepción de Schema que preserva los nombres de marca. Hreflang bidireccional en nuestros sitemaps. Grafos de datos estructurados personalizados. Migas de pan que respetan el contexto del idioma. Lógica de redirección unidireccional donde la URL se trata como sagrada: si escribiste una URL en español, te quedas en español, sin excepciones.
Tiempo total de desarrollo: aproximadamente 12 horas de trabajo concentrado, de especificación a despliegue en producción.
Esa velocidad no es para presumir: es el punto central del artículo. Cuando entiendes tu infraestructura lo suficientemente bien como para especificar la solución correcta, las herramientas modernas te permiten entregar lo correcto más rápido de lo que puedes configurar un parche. Llevamos haciendo esto desde 2001. Sabemos cómo se ve una buena infraestructura.
Hoy, nuestras páginas en español sirven datos estructurados limpios, hreflang válido, canónicos correctos y navegación en español. Nuestro SEO en español se está recuperando. Nuestro nombre de marca se preserva en todos los idiomas. Y toda la arquitectura nos cuesta menos de $50 al año para operar.
Qué deberías revisar esta semana
Si tienes un sitio WordPress multilingüe, tómate 15 minutos para verificar los cinco puntos anteriores en tus páginas traducidas. La auditoría no requiere más herramientas que ver-código-fuente y un navegador. La mayoría de los sitios que hemos auditado para clientes tienen al menos dos de los cinco problemas activos en este momento.
- Nombre de marca en los datos estructurados: verifica que aparezca de forma idéntica en cada versión de idioma
- Declaraciones hreflang: una por par de idiomas, apuntando a URLs con respuesta 200 OK, con entradas recíprocas en el sitemap
- og:type de la página de inicio: debe ser "website", no "article"
- Consistencia de barras finales: el canónico, el sitemap, los datos estructurados y los enlaces internos deben coincidir todos
- Enlaces de migas de pan: texto traducido, URL de destino traducida
Si encuentras problemas que tu hosting actual o tu proveedor de traducción no puede o no quiere solucionar, esa es una señal que vale la pena atender. Una traducción bien hecha es la diferencia entre un sitio en español que posiciona al nivel de tu versión en inglés y un sitio en español que pierde tráfico silenciosamente durante meses mientras todos se preguntan qué pasó.
Migramos sitios de cPanel, WHM, Plesk, DirectAdmin y WordPress independiente a nuestra infraestructura de hosting administrado sin costo, incluyendo una auditoría completa de SEO multilingüe durante la transición. Si quieres que revisemos tu configuración, nuestro equipo responde en menos de una hora.
Habla con nuestro equipo →Migración gratuita. Auditoría de SEO multilingüe gratuita.
Movemos tu sitio a un Cloud Cube administrado sin costo y revisamos tu configuración multilingüe como parte de la transición. Si algo está roto, te decimos exactamente qué y por qué.
Inicia la conversación
