WPML vs GOOGLEBOT: Google no indexa mi web [Conflicto Plugin WPML]

Bienvenidos de nuevo al Blog de BuscoSEO, un espacio en el que queremos compartir con vosotros algunos consejos, curiosidades y cualquier aspecto que ataña al SEO y el posicionamiento orgánico.
En el post de hoy analizamos a fondo un problema de indexación (y su solución) provocado por WPML, el archiconocido plugin multilingüe para WordPress. Aunque no se trate puramente de un ‘conflicto’, veremos cómo este plugin, tan querido y utilizado dentro de la comunidad WordPress, puede costarnos la vida (o la presencia si más no) en las SERPs de Google.

A continuación os mostramos las distintas fases por las que discurrió este periplo SEO y el feliz desenlace (esta vez sí es de película) de todo el ‘percal’.

Resumen del problema:

1. Antes de la tormenta: Sin altibajos, creciendo lento pero seguro
2. Detección del problema: Pérdida drástica de visitas, visibilidad y posicionamiento
3. Origen del problema: Houston, tenemos un problema. ¿Pero donde?
4. Solución: ¡Eureka! Un simple clic y todo arreglado
5. Después de la tormenta: Siempre viene la calma (¡O un récord de visitas SEO!)

Sin altibajos: El tráfico SEO crece lento pero seguro

La web de la que hoy hablamos tuvo, durante el año 2015, una media de 1.400 visitas SEO mensuales y un tráfico orgánico con un crecimiento contenido pero constante.

Fuente: Google Analytics

Perdemos visitas, visibilidad y posicionamiento

A continuación vemos cómo, mes a mes, a inicios de 2016 y de forma repentina, el tráfico SEO caía sin cesar. Desde el estallido hasta la solución del problema en septiembre, registró una media de 636 visitas mensuales y tocó fondo en agosto con menos de 500 visitas.

Fuente: Google Analytics

Con esta situación, empezamos a investigar tratando de descubrir el motivo de la repentina y tan acusada caída de este canal de acceso.

Houston, tenemos un problema. ¿Pero dónde?

En este punto, Google Search Console refleja el problema pero no arroja la luz que andábamos buscando. Viendo los principales indicadores que nos ofrece la herramienta, el problema se hace evidente: nuestro site se está desindexando.

¡En una semana pasamos de tener casi 400 URL indexadas a tan sólo 100!

Y no solo eso, sino que de estas 100 iríamos perdiendo más y más URL hasta quedarnos en menos de 50.

Fuente: Google Search Console

Pero, ¿por qué no se indexa mi web?

Estaba claro que el bot de Google no podía rastrear el site. Pero, ¿por qué? Detectado el problema, era hora de encontrar el origen y ponerle solución.

Comprobamos el estado y la evolución de la indexación durante semanas a través Google Search Console, Sistrix.com y otras herramientas.

Fuente: Sistrix.com

Una vez más, Google Search Console nos revela nueva información. Utilizando la opción de Rastreo > Explorar como Google, la herramienta nos notifica que el site entero está redirigido hacia su versión inglesa. (*Aunque no siempre detecta esta redirección. Luego veremos por qué.)

Fuente: Google Search Console

De ahí que el estado de indexación fuera: inglés 27/29 páginas, español 2/46, alemán 4/22 y francés 6/22. Pero si nos fijamos con detenimiento, el código que devuelve la página rastreada es un código 200.

¿Google detecta redirecciones que no existen?

Fuente: Google Search Console

Después de buscar estas redirecciones en multitud de sitios no encontramos ni rastro.

Google detectaba unas redirecciones fantasma.

Habiendo registrado de arriba abajo el log del servidor, el archivo .htaccess, la base de datos y otros en busca de cualquier indicio de estas redirecciones no encontramos rastro alguno. Por si fuera poco, ninguna otra herramienta aparte de Google Search Console detectaba estas redirecciones.

¡Eureka! La solución a un solo clic

Como a Arquímedes, el problema se reveló ante nuestros ojos. La solución residía en la incoherencia de que Google detectara las redirecciones unas veces sí y otras no como comentábamos antes.

Fuente: Google Search Console

Esto sucedía dependiendo de la solicitud que hiciéramos a la herramienta: Obtener u Obtener y procesar.

Fuente: Google Search Console

Según Google, entre una y otra opción la diferencia es, básicamente, que en la primera no se ejecutan los recursos de la página. Tal como vemos en la información del propio Google Search Console:

Fuente: Google Support

Con la opción de ‘Obtener’, Google es capaz de acceder a la página sin problemas:

Fuente: Google Search Console

En cambio, cuando utilizamos la opción de ‘Obtener y procesar’, Google nos detecta una redirección. Esta vez, en el código de la página nos aparece un <script> generado por el plugin WMPL.

Fuente: Google Search Console

Habiendo descubierto esto, nos centramos en ver qué sucedía con el plugin. Al dirigirnos al soporte de WPML, efectivamente, vimos que no fuimos ni los únicos ni los primeros en sufrir este problema. La solución, muy sencilla.

De forma casi instantánea, al desactivar la opción de ‘redirección de idioma del navegador’, la indexación del site empezó a realizarse de forma correcta y las URL volvieron a sus posiciones habituales.

Fuente: WMPL para WordPress

Y no solo eso, sino tanto el índice de visibilidad el posicionamiento de palabras clave y el volumen de tráfico orgánico aumentaron (y siguen haciéndolo) de forma MUY positiva.

Después de la tormenta siempre viene la calma

Comúnmente se dice que una vez capeado el temporal todo vuelve a su cauce. Cierto, muchas veces eso es exactamente lo que sucede.

No obstante, algunas otras, la situación se asemeja más al dicho de: ‘Aquello que no te mate te hará más fuerte‘. Y así ha sido.

Durante todo el proceso, y hasta que dimos con el problema, revisamos, rehicimos y mejoramos muchos otros aspectos SEO (y no tan SEO) para ir estrechando el cerco del problema. Y eso, amigos, tuvo (y sigue teniendo) su recompensa en forma de récord histórico de tráfico orgánico y visibilidad.

Tráfico orgánico 01/01/2016 – 15/01/2017

Fuente: Google Analytics

Tráfico orgánico 01/02/2016 – 15/01/2017

Fuente: Semrush.com

Índice de visibilidad 01/01/2016 – 15/01/2017

Fuente: Sistrix.com

Palabras clave posicionadas en Top 100 01/01/2016 – 15/01/2017

Fuente: Sistrix.com

Esperamos que este caso os sirva de ayuda si os sucede algo parecido. Y si no, no dudéis en dejarnos vuestras dudas en los comentarios y os echaremos un cable en aquello que podamos.

¿Problemas con la indexación de tu site u otros aspectos SEO? Puedes contactar con nosotros aquí.

La entrada ¿Problemas de indexación con un WordPress Multilanguage? se publicó primero en BuscoSEO.

Existen varios motivos por los que es recomendable y/o necesario añadir el archivo robots.txt a la raíz del dominio de nuestra web.

La orden más habitual añadida es el “disallow” que viene a decirle al Googlebot que no debería visitar y por tanto no indexar, las páginas o conjunto de páginas que le indiquemos seguidamente.

Las típicas páginas como /wp-admin o /acceso que permiten el login al site o en casos de páginas que ya no existen o por motivos de contenido duplicado generado por filtros,…

¿Cómo funciona el robots.txt?

Un ejemplo:

User-agent: *

Disallow: /categoría-A

La primeria línea indica a qué robot afecta dicha orden, en este caso el asterisco (*) significa a todos. Podríamos elegir si Google (Googlebot), Bing (MSNbot),…

La segunda, “/categoría-A” significa que toda URL que empiece por midominio.com/categoría-A no debe ser visitada por el bot y, por tanto, no indexada.

¿Cómo enviar y verificar el archivo robots.txt?

El archivo siempre debe subirse en la raíz de la web. Es decir, midominio.com/robots.txt.

Si queréis verificar si vuestro archivo robots.txt está bloqueando las páginas que realmente deseamos, simplemente tendréis que dar de alta vuestro site en la herramienta Google Webmasters Tool -que es gratuita-.

Dentro de esta herramienta, en de la sección Rastreo encontramos el Probador de robots.txt:

Al acceder nos encontraremos con la siguiente página:

Aquí veremos la última versión del archivo robots.txt -la herramienta nos muestra la fecha de procesamiento- y nos indicará si hay errores o advertencias en el archivo.

En la parte inferior podremos ir probando URLs y Google nos irá diciendo si el acceso a ese página lo tiene PERMITIDO o BLOQUEADO. En el caso de que este bloqueado nos indicará porque línea del archivo se produce el bloqueo.

Además, podemos editar el archivo en la misma herramienta y probar nuestras correcciones. Es importante remarcar que esta edición no actualiza el archivo real robots.txt, sólo es de prueba. Si refrescáis la página volveréis al archivo real.

La entrada ¿Cómo comprobar el archivo robots.txt? se publicó primero en BuscoSEO.