Por qué Google no ve el contenido de tu sitio

Tu sitio abre, funciona y muestra todo. Para el buscador puede estar casi vacío — y esa diferencia no se ve en pantalla.

El problema

Abres tu sitio y está todo ahí: los textos, los productos, los testimonios. Buscas tu propio contenido en Google y no encuentras nada.

No es una penalización, probablemente no es cuestión de tiempo, y probablemente no es tu texto. El buscador no recibió la misma página que tú estás viendo.

Por qué ocurre

Cuando alguien entra a un sitio, el servidor envía un archivo HTML. En los sitios antiguos, ese archivo ya traía el contenido dentro.

En los sitios modernos, hechos con herramientas como React, Vue o Angular, el servidor envía un archivo casi vacío — y el contenido se arma después, dentro del navegador, con JavaScript.

Para una persona esto es invisible: tarda milisegundos. Para el buscador no. Puede ejecutar JavaScript, pero no siempre lo ejecuta, no siempre espera, y no en todas las páginas. Lo que guarda puede ser el archivo casi vacío.

El resultado es un sitio que existe para quien lo visita y no existe para quien lo busca.

Cómo saber si es tu caso

La prueba manual más rápida: abre tu sitio, haz clic derecho y elige "Ver código fuente de la página". Eso muestra el HTML servido, antes del JavaScript. Busca ahí un párrafo que ves en pantalla. Si no está en el código fuente, es posible que el buscador no lo esté viendo.

Esa prueba funciona, pero es manual, es una página a la vez, y no te dice qué más falta.

Eso es exactamente lo que hace SiteMerit automáticamente. Abrimos tu página en un navegador real, ejecutamos el JavaScript como lo haría un visitante, y comparamos lo que entregó el servidor con lo que apareció después. El informe muestra los bloques de texto, enlaces, metadatos y datos estructurados que solo existen después de que el JavaScript se ejecuta.

Qué hacer

Si tu contenido solo aparece después del JavaScript, hay tres caminos, del más completo al más simple:

• Renderizar en el servidor. El servidor arma la página terminada y entrega el HTML completo. Es la solución más sólida y la que exige más cambio.
• Generar las páginas por adelantado. Para contenido que cambia poco, las páginas se arman una vez y se sirven listas. Simple y eficaz para blog, documentación y páginas institucionales.
• Asegurar lo esencial en el HTML servido. Si reescribir no es viable ahora, al menos el título, la descripción, el canonical y el texto principal deben estar en el archivo que entrega el servidor.

Mide antes de elegir. Reescribir la arquitectura de un sitio entero por un problema que quizá afecta dos páginas es caro por el motivo equivocado.