Parece que con problemas de renderizado la IA aún no nos va a quitar el trabajo

lasapaixa

lasapaixa

Beta
¡Usuario con pocos negocios! ¡Utiliza siempre saldo de Forobeta!
En este caso vengo a contaros sobre un ecommerce en WordPress, el caso de una migración de diseño (cambio de tema a Impreza).

La web se veía perfecta, las fichas cargaban bien y nadie notaba nada raro. Pero la visibilidad en Sistrix bajaba poco a poco desde la migración, las impresiones y los clics desde que se lanzó la migración fueron cayendo a casi 10 diarios y lo que sobre todo me tenía con ansiedad es que el cliente me decía que había pasado a no convertir NADA, que no recibia ni un formulario ni una llamada diaria. Joder es que al final estás jugando con el pan de la gente.

Por mi parte lo había hecho todo correctamente y siguiendo el timeline. en cuanto a SEO, el mapa de redirecciones estaba perfecto y revisado 40 veces, por parte de desarrollo, aunque es cierto que tuvimos varios momentos de descoordinación, todo parecía correcto

Me pasé semanas analizándolo con Claude. Le di datos, capturas y todo lo que se me ocurría, y fuimos probando hipótesis una detrás de otra. Ninguna era la buena. En ningún momento me sugirió algo tan básico como mirar la página con la herramienta de inspección de URL de Search Console. Yo durante la migración por supuesto audité el renderizado: en bulk en SF y alguna que otra URL suelta en la herramienta de inspección de urls de GSC...

Ya desesperada porque el cliente empezó a llamarme desesperado hasta los fines de semana, llamé yo a una amiga, y al final fue ella la me insistió en que eso era un problema serio de usabilidad y rendimiento que estaba pensalizando la web, que no era normal cómo se mostraba la página de lento con ese CLS y FOIT entre otras lindeces. Yo era consciente pero claro, durante toda esta crisis se me había señalado tanto a mi y por tanto al WPO y CWV que yo misma no quería cargar al dev, yo lo achacaba más al SEO técnico. Mi amiga me dijo que no, que fuera a pedir explicaciones al dev (que además mi pobre es junior)

Se me encendió la bombilla después de semanas de niebla mental (donde siendo sincera, después de tanto bloqueo y en este ritmo de trabajo y estrés tan vertiginoso casi había dejado toda mi confianza en Claude y no era capaz de pensar out of the box...), y se me ocurrió pasar una ficha por la inspección de URL y ahí estaba: el texto de las fichas existía en el HTML, pero con opacity: 0. Para Google la ficha estaba en blanco.

De 859 URLs indexables, 851 tenían el problema, y en 750 fichas el 100% del texto quedaba oculto. La causa era la combinación de dos cosas que por separado no hacen nada malo:

las animaciones de entrada del tema, que ponen el contenido en opacity: 0 hasta que un script lo muestra la opción de LiteSpeed Cache de retrasar el JavaScript hasta que el usuario interactúa Googlebot no hace scroll ni mueve el ratón, así que el script nunca se ejecutaba y el contenido nunca aparecía.

Arreglado, y en apenas 10 días Sistrix ya muestra en su índica de visibilidad una subida de más de 200% de subida en la primera semana. Los valores aún son bajos y es pronto, pero la tendencia ha cambiado.

Me quedo con dos cosas. La primera: si usáis LiteSpeed con Delay JS y un tema con animaciones, pasad una ficha por la inspección de URL y mirad la captura, que son dos minutos. La segunda: la IA ayuda mucho, pero si no le haces la pregunta adecuada puede tenerte semanas dando vueltas. A veces hace falta alguien que mire el problema desde fuera.

Esto de hecho me recordó a una frase que leí en Linkedin hace no mucho: "¿alguna vez te has dado cuenta de que la IA es realmente, realmente buena en todo excepto en lo que sabes mucho?"

He aprovechado para hacer un post y lo he explicado más a fondo aquí, con cómo auditar el DOM y qué comparar entre el HTML inicial y el renderizado: https://aliciaruiz.es/dom-seo-renderizado/
 

Adjuntos

  • dom-caso-antes-gsc.webp
    dom-caso-antes-gsc.webp
    33,3 KB · Visitas: 17
  • dom-caso-despues-h1.webp
    dom-caso-despues-h1.webp
    29,6 KB · Visitas: 9
Última edición:
¿Te sirvió? Únete a la conversación

Con tu cuenta gratis puedes responder, escribirle al autor por mensaje privado y comprar con Saldo retenido: el pago se libera cuando recibes lo acordado.

Toma 30 segundos · vuelves a este tema al terminar
Es un caso muy ilustrativo sobre por qué la IA, aunque es una herramienta potente de análisis, no sustituye la capacidad de diagnóstico técnico humano ni la experiencia en campo. Muchas veces, los problemas de renderizado en WordPress tras un cambio de tema pasan desapercibidos porque el navegador humano interpreta bien el CSS/JS, pero el bot de Google encuentra bloqueos o errores críticos que no se ven a simple vista.

El uso de la herramienta de inspección de URL en Search Console es fundamental porque permite ver exactamente qué está renderizando Googlebot. Si el problema era un bloqueo de recursos, un error de ejecución de JavaScript o una carga lenta que Google interpreta como fallo, ninguna IA podrá adivinarlo si no se le proporcionan los logs o la captura del renderizado real que ve el buscador.

Al final, este tipo de situaciones demuestran que el SEO técnico sigue requiriendo una validación manual rigurosa. La automatización ayuda a procesar datos, pero la intuición para verificar el "cómo lo ve Google" sigue siendo una habilidad que marca la diferencia en las migraciones de sitios web.
 
Este caso me deja una lección que vale para cualquier trabajo de diseño: que algo se vea bien en tu pantalla no significa que exista para Google. Las animaciones de entrada quedan preciosas, pero si el contenido arranca en opacity: 0 y solo aparece cuando un script se ejecuta al interactuar, para el rastreador esa página está en blanco. Y lo peor es que el cliente no te dice "mi web se ve mal", te dice "no vendo nada", y uno empieza buscando el problema en cualquier lado menos en lo obvio.

Lo que más me llamó la atención es que la IA tampoco lo vio en semanas. No es que la herramienta sea mala, es que si uno le pregunta por SEO técnico y redirecciones, ella responde sobre eso, no te dice "oye, revisa la captura de Search Console". La inspección de URL con su captura de pantalla es de dos minutos y ahí se veía el problema clarito: el texto estaba en el HTML pero invisible. Desde que trabajo en video pienso igual: antes de entregar algo, hay que verlo como lo va a ver el otro, no como lo veo yo en mi editor.

Para mí la regla queda así: todo efecto que esconda contenido al inicio es sospechoso hasta que se demuestre lo contrario, y si se usa Delay JS, hay que probar con la herramienta de inspección, no solo abriendo la web en el navegador. El arreglo subió la visibilidad más de 200% en diez días, y eso dice todo: el contenido siempre estuvo ahí, solo que nadie lo podía ver.
 
Buen caso, y la lección va más allá de LiteSpeed. Me pasó algo equivalente con una web montada en un constructor que lo sirve todo por JavaScript: en el navegador se veía perfecta, y en la inspección de URL el HTML llegaba casi vacío. Hasta que no metí prerender para bots, Google indexaba páginas en blanco.
Desde entonces hago esto, y en este orden:
1. Ver el código fuente crudo y buscar el H1 y un párrafo del texto. Si no están ahí, dependes del render.
2. Inspección de URL en una plantilla de cada tipo (home, categoría, ficha), mirando captura y pestaña HTML, no una sola URL.
3. Repetir con la caché en frío y en caliente, porque en preview suele ir bien y en producción no.
Lo del opacity: 0 es traicionero precisamente porque si rastreas con render el texto sigue en el DOM y la herramienta te lo cuenta como presente. La captura de Search Console es lo único que te lo canta.
 
Atrás
Arriba