Diagnóstico de SEO técnico: sigue una página desde la petición hasta el índice

Empieza por la ruta de rastreo

Empieza con la URL exacta y pregunta si un rastreador puede alcanzarla. Lee robots.txt del sitio en la raíz del host. Una regla Disallow controla si el rastreador puede solicitar una ruta; es sobre todo una herramienta para gestionar tráfico. No elimina de forma fiable una página HTML o PDF de Google Search, porque otra página puede exponer la URL aunque no se pueda recuperar su contenido. Una página que debe mantenerse fuera de búsquedas necesita una directiva noindex o control de acceso, y el rastreador debe poder obtener la directiva.

Trata la capa perimetral como parte de esta primera comprobación. Un WAF, una regla para bots, un limitador de tasa o una pantalla de inicio de sesión puede devolver un desafío, un 403 o una respuesta diferente a Googlebot, Bingbot o un navegador. Una petición con un User-Agent conocido solo sirve como prueba rápida: no demuestra que la red real del rastreador esté permitida. Revisa los eventos de seguridad del WAF, el tratamiento de bots verificados y los logs del origen con quien administra la configuración perimetral. Prueba una URL importante, su hoja de estilos y sus imágenes, porque bloquear un recurso necesario puede cambiar lo que ve el renderizador. Registra hora, host, ruta, respuesta y acción del perímetro antes de cambiar una regla.

Revisa la respuesta HTTP antes de leer la página

Después inspecciona el estado de la respuesta y la cadena de redirecciones. Un 200 significa que el servidor devolvió una representación, no que la página sea útil o indexable. Un 301 o 308 puede ser correcto cuando una URL antigua tiene un destino permanente equivalente; prueba la URL antigua, cada salto y la URL final. Un 404 o 410 es apropiado cuando el contenido desapareció de verdad. Un 500, 502, 503 o un tiempo de espera repetido es un problema de servicio, y los fallos 5xx o de red prolongados pueden hacer que el rastreo disminuya y que URL ya indexadas salgan del índice.

Usa una petición HEAD para revisar encabezados rápidamente y después una petición GET para obtener el cuerpo real. En una terminal, curl -I https://example.com/page muestra estado y encabezados, mientras curl -L -A Mozilla/5.0 https://example.com/page sigue las redirecciones y permite guardar el HTML recibido para inspeccionarlo. No tomes un comando exitoso como prueba de todas las rutas de User-Agent; compara un navegador normal, una prueba de rastreador cuando corresponda y los logs del proveedor. Busca tipo de contenido, caché, compresión, X-Robots-Tag y URL final. Una página de error con marca que devuelve 200 es un soft 404: la persona ve un error, pero el estado le dice al rastreador que existe una página real.

Separa noindex de canonical

Noindex y canonical responden preguntas diferentes. Una etiqueta robots con noindex, o un encabezado X-Robots-Tag con noindex, pide a Google que no incluya esa URL en búsquedas. No impide que una persona abra la URL y solo funciona cuando el rastreador puede obtener la respuesta. Si robots.txt bloquea la ruta, Google no puede ver de forma fiable la regla noindex. Busca cada elemento robots en el HTML original y cada valor X-Robots-Tag en los encabezados; una aplicación o plugin puede añadirlo después.

Un enlace canonical identifica la URL que prefieres entre versiones duplicadas o casi duplicadas. Es una señal, no una orden que anule todos los demás datos. Coloca un canonical único, absoluto y autorreferente en la página preferida; mantén enlaces internos y sitemap alineados con él, y no dirijas una página indexable a una portada que no sea equivalente. No uses noindex para elegir un canonical dentro de un grupo si la página debe seguir siendo buscable. Comprueba el canonical en el HTML fuente, en el HTML renderizado y en el canonical elegido por Google en Search Console. Un cambio de JavaScript que contradice el HTML original crea un diagnóstico evitable.

Usa el sitemap como inventario

Un sitemap debería contener las URL absolutas que quieres que se descubran y se consideren para búsquedas, normalmente las versiones canonical. Es una señal, no un comprobante de envío ni una garantía de indexación. Compara sus filas con el inventario de rutas, los enlaces internos y las páginas que el negocio realmente quiere conservar. Elimina hosts de staging, variantes con parámetros, URL redirigidas, páginas noindex y estados utilitarios delgados, salvo que exista una razón deliberada para listarlos.

Abre el sitemap por HTTPS y confirma una respuesta exitosa, XML válido y un host consistente. Comprueba que cada URL listada devuelve el estado y canonical esperados, y que las páginas traducidas apuntan a su propia versión de idioma cuando ese sea el diseño del proyecto. Si hay más de 50.000 URL o el archivo sin comprimir supera 50 MB, usa un índice y divide los archivos hijos. Envía el sitemap mediante Search Console después de alinear las señales del servidor y de las páginas, y luego observa las cantidades descubiertas, rastreadas e indexadas. Un sitemap enviado puede revelar un desajuste; no puede repararlo.

Compara el HTML inicial con el HTML renderizado

Inspecciona dos documentos. El HTML inicial es el cuerpo que devuelve la primera petición de página, antes de que se ejecuten los scripts. El HTML renderizado es el DOM después de que el navegador o el renderizador del rastreador cargó scripts y recursos. Una página renderizada en servidor o prerenderizada puede exponer de inmediato su título, encabezados, texto, enlaces, canonical y datos estructurados. Una página basada en app shell puede entregar casi nada de texto útil hasta que JavaScript llama a una API. Google puede renderizar muchas páginas JavaScript, pero renderizar es un paso posterior, consume recursos y no todos los buscadores o rastreadores sociales tienen esa capacidad.

Abre Ver código fuente o la respuesta GET guardada y busca el encabezado principal, el texto significativo, los enlaces internos, el canonical y las directivas robots. Después usa la inspección del navegador o la prueba de URL en vivo de Search Console para ver el HTML renderizado y los recursos cargados. Si un párrafo, enlace o campo de metadatos existe solo después de un fallo de API, una barrera de consentimiento o un error de hidratación, la verificación de fuente encontró un riesgo de indexación real. Mantén coherentes las versiones renderizada y fuente; usa JavaScript como mejora, no como único mecanismo que entrega el significado de la página. Corrige datos de servidor ausentes, recursos bloqueados o errores de ejecución y repite ambas inspecciones.

Sigue un árbol de decisión pequeño

Escribe el diagnóstico como un árbol de decisión que otra persona pueda ejecutar:

1. ¿El rastreador previsto puede alcanzar la URL y sus recursos necesarios? Si no, inspecciona DNS, TLS, autenticación, robots.txt, eventos del WAF y errores de red. Restablece el acceso o documenta el bloqueo intencional.

2. ¿La respuesta final tiene el estado previsto? Si es una redirección, prueba el destino. Si es 4xx, confirma si el contenido debería existir. Si es 5xx o se agota el tiempo, corrige la capacidad de servicio y vuelve a intentar. Si es 200 con un mensaje de error, devuelve un 404 real o repara la página.

3. ¿La respuesta contiene noindex? Si sí, decide si la exclusión es intencional. Elimínala solo cuando la página sea realmente elegible; no ocultes por accidente una página de staging o privada.

4. ¿Hay un solo canonical y coincide con redirecciones, enlaces y sitemap? Si no, elige la URL representante correcta y haz que todas las señales coincidan.

5. ¿El contenido útil está en el HTML inicial o aparece de manera fiable después del renderizado? Si no, repara el renderizado del servidor, el acceso a la API o los errores de JavaScript, y vuelve a probar el resultado renderizado.

6. Después de corregir, ¿la prueba de URL en vivo de Search Console muestra una página rastreable e indexable? Eso demuestra acceso y señales detectadas, no promete que Google la indexe o posicione. Conserva la respuesta anterior, la corrección, la nueva prueba y la persona responsable en el registro de la incidencia.

Convierte la evidencia en un orden de corrección

Prioriza los fallos que impiden obtener o entender la página: DNS, TLS, autenticación, bloqueos del WAF, errores del servidor y noindex accidental. Después corrige señales contradictorias de canonical, redirecciones y sitemap. Luego mejora la fiabilidad del HTML inicial y del renderizado, y por último los enlaces internos, metadatos y mejoras menos urgentes. Acompaña cada hallazgo con la URL, el User-Agent o herramienta usada, la hora, el estado o encabezado sin alterar, y una captura o HTML guardado cuando aporte valor, además de una nueva prueba reproducible. Así evitas declarar sano el SEO técnico porque un navegador cargó una página bonita. Un diagnóstico estable le dice al siguiente desarrollador qué recibió el rastreador, qué vio la persona y qué incertidumbre restante todavía necesita medición.