Abrís una ficha de servicio y ves título, descripción, preguntas y un botón de consulta. Todo parece estar bien. Sin embargo, la página no recibe impresiones o Google muestra una versión incompleta. Antes de culpar a JavaScript, necesitás separar tres cosas: la respuesta que entrega el servidor, lo que construye el navegador y lo que Google pudo procesar.

Vamos a auditar una página pública como si tuviéramos que dejarle al equipo de desarrollo un problema reproducible. El resultado esperado es una evidencia concreta y una prueba de aceptación, no una recomendación genérica de “hacerla más SEO”.

El caso de trabajo: una ficha que parece completa

Imaginemos una URL ficticia, /servicios/consultoria/. El servidor devuelve una aplicación inicial y después un script pide los datos del servicio. La navegación desde la home funciona, pero algunas visitas directas ven solamente el encabezado. Ese detalle cambia la investigación: no alcanza con comprobar que una persona pudo llegar una vez.

Elegí una frase única del contenido principal, un enlace importante y una señal de la página, como el título SEO o el canonical. Esos tres elementos van a servir como puntos de control entre respuesta inicial, DOM renderizado y prueba de Google. Usar la misma muestra evita comparar partes distintas de la página sin advertirlo.

Guardá también URL exacta, fecha, estado de sesión, dispositivo de prueba y pasos para llegar. Si la falla depende de una cookie, un acceso directo o una respuesta de API, esos datos permiten reproducirla. Sin ellos, “a mí me funciona” y “Google no la ve” pueden ser dos observaciones ciertas de condiciones diferentes.

Primera evidencia: qué respondió el servidor

Abrí la URL directamente en una ventana sin sesión y revisá el documento en Network de las herramientas del navegador. Registrá el estado HTTP, la dirección final y la respuesta HTML. “Ver código fuente” también ayuda a inspeccionar el documento inicial; la pestaña Elements muestra un DOM que ya pudo haber cambiado.

Buscá la frase elegida. Si está en el HTML inicial como contenido de la página, esa parte no depende necesariamente del renderizado del cliente para existir. Si solo aparece dentro de datos serializados o no aparece, necesitás comprobar qué la convierte en contenido visible.

Para una captura sencilla podés usar estos comandos en un entorno donde tengas curl. El primero muestra encabezados de la respuesta inicial sin seguir redirecciones; el segundo guarda el cuerpo final siguiendo la cadena:

curl -sS -D - -o /dev/null https://example.com/servicios/consultoria/
curl -sS -L https://example.com/servicios/consultoria/ -o respuesta.html

El archivo guardado no ejecuta JavaScript y no representa por sí solo lo que Google terminará renderizando. Sirve como evidencia del punto de partida. Si usás un proxy, una protección o una caché, documentá que la respuesta puede variar por condiciones de acceso; cambiar solamente el user agent no convierte curl en Googlebot.

Segunda evidencia: qué aparece después de ejecutar JavaScript

Volvé al navegador y buscá la misma frase en Elements. Compará si el contenido fue insertado, reemplazado o eliminado. Revisá Console para detectar errores y Network para ubicar las solicitudes necesarias: scripts, datos de API y respuestas fallidas.

Desactivar JavaScript y recargar es una prueba de dependencia, no una simulación exacta de Google. Si desaparece todo el contenido, descubriste que la página necesita ejecución para construirlo. Todavía falta comprobar si Google puede realizarla correctamente.

Probá acceso directo a una URL profunda, recarga y navegación interna. Una aplicación puede resolver rutas dentro del navegador y fallar cuando el servidor recibe directamente esa dirección. También comprobá una URL inexistente: devolver una página vacía con estado 200 para cualquier ruta puede producir errores de interpretación y páginas sin utilidad.

Repetí la prueba con almacenamiento limpio. La sesión del equipo puede ocultar una dependencia de autenticación o una API que funciona solo después de visitar otra página. Para contenido que querés publicar en búsqueda, la evidencia debe corresponder a un visitante sin credenciales.

Tercera evidencia: qué pudo procesar Google

Usá Inspección de URLs en Search Console. Distinguí la información disponible de la versión indexada de la prueba en vivo. La primera refleja lo que Google tiene registrado; la segunda comprueba una ejecución actual bajo sus condiciones de prueba. Que la prueba en vivo acceda al contenido no garantiza que la página esté indexada.

Cuando la herramienta permita revisar el HTML obtenido, buscá la misma frase y el enlace elegido. La captura visual es complementaria: una pantalla aparentemente completa no confirma que todos los textos y destinos necesarios estén presentes en el HTML procesado.

Registrá recursos que no pudieron cargarse y comparalos con las solicitudes observadas en tu navegador. Una API rechazada, un script bloqueado o un error de ejecución puede explicar la diferencia. No todos los recursos secundarios omitidos son críticos: priorizá los que construyen contenido, enlaces o señales de indexación.

El ciclo de trabajo queda así: respuesta inicial guardada, DOM observado y resultado de la prueba identificado por fecha. Si los tres contienen lo necesario y no hay una diferencia reproducible, puede que el problema de visibilidad esté en otra capa. La revisión de SEO técnico ayuda a continuar sin adjudicarle cualquier ausencia a JavaScript.

Elegí la rama que coincide con tu hallazgo

La frase no está al inicio, pero aparece en el renderizado de Google

No existe evidencia de invisibilidad de ese contenido en esa prueba. Revisá indexación, canonical, calidad y descubrimiento de la URL. Podés mejorar la entrega del contenido, pero no presentes como demostrado un bloqueo que la evidencia no muestra.

La frase aparece en tu navegador y falta en la prueba de Google

Investigá diferencias de acceso a scripts y datos, bloqueos de recursos, errores de consola y condiciones de sesión. Identificá la solicitud o tarea que debería producir el contenido y documentá qué ocurre en cada entorno.

La frase aparece solo después de hacer clic o desplazarte

El contenido principal está condicionado a una interacción. Revisá cómo se entrega y cómo se activan las cargas diferidas. Para material importante, evitá depender exclusivamente de que el rastreador realice ese gesto.

La frase existe, pero los enlaces no llevan a URLs rastreables

Comprobá que las rutas importantes estén representadas mediante enlaces HTML con un href válido. Un elemento visual con un manejador de clic no sustituye automáticamente un enlace que pueda descubrirse y seguirse.

No te olvides de lo que la página dice sobre sí misma

Compará título, descripción, canonical e instrucciones de indexación entre HTML inicial y DOM final. Un caso delicado es entregar un noindex inicial y confiar en que un script lo retire: Google puede decidir no continuar el renderizado al encontrar esa instrucción. La página que querés indexar debe partir de señales coherentes.

Si la aplicación cambia el canonical, comprobá que no deje múltiples etiquetas ni valores contradictorios. Tampoco debería mostrar el título de la home en todas las rutas mientras espera una petición que a veces falla. Esos errores tienen que investigarse por plantilla y no corregirse página por página a mano.

En sitios multilingües, revisá además que cada ruta mantenga su relación con las traducciones correctas. La implementación de hreflang requiere equivalencias consistentes; una aplicación que intercambia contenido sin actualizar las señales puede dejar una página visualmente correcta y técnicamente ambigua.

Cómo entregar un problema que se pueda resolver

Un ticket útil para el caso ficticio podría escribirse de esta manera:

URL y condición: acceso directo a /servicios/consultoria/, sin sesión y con almacenamiento limpio.

Resultado esperado: descripción del servicio y enlace a contratación presentes en el contenido procesable de esa ruta.

Resultado observado: el documento devuelve 200; la API de contenido responde con error sin una cookie previa; el navegador de una sesión habitual oculta el problema.

Alcance por comprobar: otras fichas que usan la misma plantilla y el mismo endpoint.

Aceptación: acceso directo y recarga muestran el contenido sin sesión previa; la prueba en vivo lo obtiene; una ruta inexistente mantiene el tratamiento de error correspondiente.

Adjuntá respuestas y trazas útiles, eliminando credenciales o datos de sesión antes de compartirlas. La hipótesis “depende de una cookie” debe estar respaldada por pruebas con y sin esa condición; si todavía no lo comprobaste, nombrala como hipótesis.

Elegí la solución según la causa

Si el problema es una API pública mal configurada, corregí ese acceso. Si es una ruta profunda que el servidor no resuelve, arreglá el enrutamiento. Si el contenido depende de acciones del usuario, revisá la estrategia de entrega. Ninguno de esos casos exige automáticamente cambiar todo el framework.

El renderizado del lado del servidor o la generación previa pueden reducir dependencias para páginas públicas. También requieren revisar datos actualizados, errores, caché e hidratación. No los describas como una cura sin costo: elegí la arquitectura según los tipos de página y la capacidad de mantenerla.

Después del arreglo, repetí exactamente los pasos originales y una muestra de páginas hermanas. Verificá contenido, enlaces, señales, estados y funcionamiento para usuarios. Si la solución entrega más contenido al inicio pero empeora la respuesta a interacciones, continuá con el diagnóstico de INP como una tarea diferente.

El cierre de una auditoría es una diferencia demostrable entre antes y después. Guardá qué fallaba, qué cambió y qué pruebas pasaron. Esa evidencia permite al negocio entender el alcance del trabajo y al equipo detectar una regresión cuando cambie la siguiente versión.