[CASO REAL] Crónica de un desplome en Google (con pronta recuperación)

Desplome en Google

Proyecto del sector de la salud, consolidado, con responsable interesado en el SEO y con una estrategia editorial bien definida, orientada tanto a posicionar palabras clave long tail como a aprovechar ese tráfico para convertirlos en clientes de carne y hueso de su clínica privada. Es decir: un cliente implicado, que se informa bien y que actúa de forma inteligente. Hasta aquí todo ok.

Contacta para solucionar un tema importantísimo: reducir el tiempo de carga de la página web para que en 1-2 segundos el cliente la tenga delante, por completo. Además, comenta que también le interesa corregir la visualización de algunas imágenes y textos en versión mobile.

Lo primero que piensa alguien es: si un tiempo de carga de 2 segundos le parece hasta aceptable, ¿en cuanto le está cargando la web…?

Por lo tanto entramos y pasamos los test de velocidad pertinentes, para hacernos una idea de lo que tenemos entre manos. ¿Eres capaz de adivinar el tiempo de carga?

Ojo: hablamos de una web que estaba recibiendo un flujo de tráfico considerable, de unas 4.000 visitas diarias en las que más de un 80% era tráfico orgánico (venía de Google).

Aquí los resultados de aquella web:

Pre-optimización

Casi 5 segundos en cargar una home nada fuera de lo normal: sin animaciones, sin vídeos y compuesta por 700 palabras (si contamos también menú, footer, migas de pan…).

¿Qué estaba pasando? ¿Qué había debajo del capó de aquella web?

La importancia de tener un buen tema para WordPress

Evidentemente, había 2 malas decisiones que se habían tomado en aquella web que eran las culpables de esta lentitud. El primero, el tema utilizado.

Estaban usando un tema multipropósito tan grande y pesado como lo es Bridge, para tener en una web corporativa de lo más normal y corriente que únicamente utilizaba algunos formularios de suscripción metidos en medio del contenido de la página y un formulario de contacto. ¡Nada más! Diseño limpio, coherente, imagen de marca fuerte… A nivel visual no había nada que pudiera chirriarte demasiado del proyecto. 

MORALEJA: Puedes tener 2 webs visualmente iguales y que una sea un completo despropósito de ejecución, y que otra sea un proyecto a destacar.

Pero aquí no acaba la anécdota con respecto a por qué este cliente estaba utilizando un tema como Bridge. Y agárrate, porque vienen curvas:

Resulta que estaba utilizando Génesis junto con un tema hijo desarrollado a medida. La crème de la crème para muchos desarrolladores, vaya. Pero cuando contrataron a un SEO para dar un empujón al posicionamiento de su web y este les dio ciertas mejoras a implementar en el código del tema para mejorar el SEO On page… Los desarrolladores del tema se negaron a hacerlo en cierta forma, alegando que no sabían de SEO ni querían saber.

Es un caso paradójico, ¿no?

A los desarrolladores se nos llena la boca muchas veces hablando de que la mejor opción es, siempre que el cliente se lo pueda permitir, el contratar un desarrollo a medida. Pero nadie habla de lo bien que está dicho desarrollo, si por el mero hecho de ser un desarrollo a medida ya es un trabajo superior en calidad a temas del mercado ni de si esos desarrollos tienen un código que se mantiene actualizado en el tiempo o no…

Con lo cual nos encontramos a un cliente queriendo mejorar su posicionamiento, a un profesional del SEO diciéndole que con un tema que no trabaje bien los encabezados ni las secciones poco puede hacer y a unos desarrolladores que no quieren saber nada más del proyecto. ¿Cómo acabó la cosa? Pues efectivamente, con el consejo del SEO: “métele Bridge y nosotros te lo apañamos con un plugin“.

Cómo Visual Composer afecta a la velocidad de carga de tu WordPress

Por si ya fuera poca la fiesta que teníamos armada en este proyecto, para coronarla habían maquetado las páginas interiores con un plugin tan odiado por unos y amado por otros como Visual Composer (o WPBakery Page Builder, como queráis llamarle).

No era una web que tuviese excesivos plugins (menos de 10), pero este ya contaba tanto como los restantes.

La combinación tema Bridge + Visual Composer estaban dando como resultado una web lenta.

En cuanto al “pequeño” problema que tenían en móvil, tenía una explicación realmente sencilla: en lugar de trabajar las imágenes de cabecera por un lado y los encabezados situados encima de las mismas por otro, como texto puro, lo que habían hecho había sido preparar una imagen que ya contuviera el texto en ella.

¿Cuál es el problema de esto? 

Que en pantallas pequeñas puede ser interesante que la imagen se muestre en la parte superior de la pantalla, y el texto en la parte inferior (fuera de la imagen) a un tamaño lo suficientemente grande como para que sea legible sin tener que acercar la pantalla a la nariz.

Si no se hace eso y se trabaja únicamente como imágenes, lo habitual es que el ancho de la imagen ocupe el ancho de la pantalla… Y que por lo tanto el texto se quede bastante pequeño en comparación con el resto del contenido de la web.

Cómo salimos de todo este sarao y la “gran cagada”

Por límite de presupuesto y de tiempo, la ejecución de un tema a medida no era viable. Por lo tanto lo que decidimos hacer fue recuperar ese tema desarrollado a medida (que conservaban todavía en un subdominio de pruebas), hacer los retoques a nivel SEO On Page pertinentes y utilizar un maquetador como Beaver Builder para rehacer las páginas principales (y que de esta forma el cliente pudiera variar su contenido cuando quisiera).

Tras ver cosas como que las migas de pan se habían incrustado manualmente en cada página de la web, en lugar de utilizar directamente en el tema el código de Yoast, y otros detalles del estilo… Esto fue lo que logramos:

Post-optimización

Sin variar el hosting ni un ápice, y utilizando WP Rocket como plugin de caché. Sin mucha más optimización que la lógica (imágenes). Evidentemente, ese “Performance grade” se podría continuar mejorando, pero eso ya requeriría meternos mucho más a fondo a revisar el tema y tocaría presupuestar aparte. Pero no es un mal resultado, ¿verdad?

Pues bien, lanzamos. Y en unos 4 días, la web se desplomó en tráfico orgánico hasta rozar las 1.000 visitas diarias aprox. ¿Qué había sucedido?

La importancia de los H1 y de no ocultarlos en el front

Llámalo error básico, llámalo despiste, llámalo como quieras. Habíamos comprobado leyendo el código fuente de las páginas que los encabezados (H1 incluido) se correspondían con los planteados en la web original. Pero pasamos por alto un detalle importantísimo: el H1 en realidad no se veía en el frontend de la web, estaba oculto. 

Esto fue lo que hizo desplomarse la web. ¿Cómo lo solucionamos?

  • Evidentemente, mostrando el H1 en la parte visual de la web. ¡Que no te queríamos engañar, Google!
  • Revisando el archivo robots.txt por si veíamos algo raro. Tenían un archivo incompleto, que permitía a la araña de Google rastrearlo absolutamente todo. Por lo tanto, decidimos completarlo prohibiendo el rastreo de algunas páginas internas y aprovechamos para indicarle aquí las URLs de los sitemaps de la web.
  • Enviando de nuevo los sitemaps de la web.
  • Solicitando re-indexación de las páginas principales.
  • Eliminando URLs internas que no debían de haberse indexado nunca.

Tras una semana de seguimiento vimos cómo la web no sólo regresó a tener el tráfico habitual, sino que logró mejorar estadísticas de tiempo de permanencia en página, reducir el porcentaje de rebote y aumentar el número de páginas vistas.

 

Deja un comentario

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *





Lúa Louro te informa que los datos de carácter personal que proporciones cubriendo este formulario serán tratados por Lúa Louro González como responsable de esta web. La finalidad de la recogida y tratamiento de los datos personales que te solicito es para gestionar los comentarios que realizas en este blog. Legitimación: Consentimiento del interesado. El hecho de que no introduzcas los datos de carácter personal que aparecen en el formulario como obligatorios podrá tener como consecuencia que no atender pueda tu solicitud. Como usuario e interesado te informo que los datos que me facilitas estarán ubicados en los servidores de Raiola (mi proveedor de hosting) dentro de la UE. Ver la política de privacidad de Raiola. Legitimación: Consentimiento del interesado. El hecho de que no introduzcas los datos de carácter personal que aparecen en el formulario como obligatorios podrá tener como consecuencia que no atender pueda tu solicitud. Podrás ejercer tus derechos de acceso, rectificación, limitación y suprimir los datos en hola@lualouro.com así como el derecho a presentar una reclamación ante una autoridad de control.Puedes consultar la información adicional y detallada sobre Protección de Datos en https://lualouro.com, así como consultar mi política de privacidad.