Una página puede responder HTTP 200 y permitir indexación mientras falta contenido importante en la vista renderizada de Google. Esta distinción afecta a precios, catálogos y otras páginas que solicitan datos públicos después del HTML inicial.
La guía explica el diagnóstico con un problema de Sitelemetry confirmado en septiembre de 2026. El resultado demostró que el renderizado se corrigió; no que Google hubiera indexado la página ni que mejoraran posiciones, tráfico o ventas.
Alcance de la auditoría
Qué se puede medir
- Respuesta de la página, directivas de indexación y reglas pertinentes de robots.txt.
- Recursos públicos necesarios para producir contenido significativo.
- Comparación de la observación inicial, el cambio acotado y la posterior prueba en directo de Google.
Qué no demuestra
- Una auditoría estática no demuestra el renderizado de Google ni su índice actual.
- Robots.txt controla el rastreo cooperativo; no es autenticación ni control de acceso.
- Mapas del sitio y solicitudes no garantizan inclusión, plazos, posiciones o tráfico.
La lista manual puede usarse sin suscripción. La auditoría SEO de Sitelemetry pertenece a las áreas de pago; la inspección de Search Console requiere acceso a la propiedad.
El caso de la página de precios
La página /pricing de Sitelemetry respondía HTTP 200 y era apta para indexación, pero la prueba en directo de Google no mostraba correctamente el catálogo. La página dependía de la respuesta pública /api/plans. La regla amplia Disallow: /api/ también bloqueaba esa dependencia: permitir solo la página no bastaba.
El 12 de septiembre de 2026 se añadió una excepción limitada: Allow: /api/plans$. La siguiente prueba mostró las tarjetas de precios e indicó que la página era indexable. Después se envió una solicitud de indexación. La evidencia permite afirmar “se corrigió el bloqueo del renderizado”, pero no “ya está indexada” ni atribuirle crecimiento de tráfico. No fue necesario abrir endpoints privados de cuentas.
Formula tres preguntas diferentes
¿Se puede rastrear? Las reglas indican qué rutas pueden obtener los rastreadores compatibles. ¿Se puede renderizar el contenido? Scripts, estilos y dependencias públicas también deben estar disponibles. ¿Está indexada? Es una decisión diferente del buscador que una respuesta HTTP correcta no resuelve.
La introducción de Google a robots.txt explica que impedir el rastreo no es una forma fiable de retirar una URL de resultados. Si necesitas excluirla del índice, usa una directiva noindex adecuada y permite obtenerla: un bloqueo robots puede impedir que Google la vea. Lee la guía de noindex antes de combinar ambos mecanismos. Protege la información sensible mediante controles de acceso reales e independientes.
Audita página y dependencias
- Inspecciona URL exacta, destino final de redirección, estado y tipo de contenido. Revisa tanto meta robots como cabeceras pertinentes.
- Lee el robots del origen correcto. Identifica el grupo de user-agent y las reglas coincidentes; no te bases solo en una línea
Allow: /. - Compara el HTML entregado con el contenido significativo del navegador. Enumera scripts, estilos y solicitudes públicas que generan las secciones ausentes.
- Usa la prueba en directo de Google para esa URL y revisa HTML renderizado, captura y fallos de recursos disponibles.
Una comprobación estática puede revelar una regla sospechosa, pero no ejecuta el renderizador de Google. La documentación de SEO JavaScript separa rastreo, renderizado e indexación. Utiliza ese modelo para identificar qué evidencia falta.
Haz el cambio mínimo justificado
Decide primero si el recurso bloqueado es realmente público y necesario para comprender una página indexable. Aquí era un catálogo público de planes, no información de clientes. El fragmento relevante quedó así:
User-agent: *
Disallow: /api/
Allow: /api/plans$Es un ejemplo acotado, no un archivo robots completo. Google utiliza la ruta coincidente más específica y $ indica coincidencia al final. No presupongas que la excepción cubre variantes con parámetros o rutas hijas. Comprueba la URL solicitada con la especificación de robots de Google.
No sustituyas el bloqueo general por permiso para todos los endpoints API. Otra opción es entregar el contenido público esencial en el HTML inicial. Decide según las dependencias y conserva intacta la autorización de la aplicación.
Repite la prueba del comportamiento, no solo del archivo
Verifica que el robots actualizado sea accesible y contenga las reglas previstas. Confirma que el recurso público necesario siga devolviendo los datos esperados. Repite la prueba en directo e inspecciona el contenido real: ¿aparecen las tarjetas o solo un contenedor vacío y un mensaje de carga?
Registra fechas y evidencias anteriores y posteriores. Comprueba si quedan fallos de recursos. Si la prueba funciona, solicitar indexación puede ser el siguiente paso, pero vigila el resultado indexado por separado. La prueba en directo describe las condiciones actuales de descarga y renderizado, no acredita indexación completada. Repetir solicitudes no garantiza un calendario. Informa con precisión sobre la corrección sin transformar un resultado intermedio en una promesa de posicionamiento.
Elige el siguiente paso SEO según la evidencia
Aplica primero este diagnóstico a páginas cuyo contenido ausente explica el producto o ayuda a decidir una compra. Un catálogo de precios roto merece atención aunque aún no haya tráfico suficiente para estimar el impacto SEO. Revisa después otras plantillas con la misma dependencia en vez de modificar reglas ajenas por intuición.
Mantén las URL públicas importantes accesibles mediante enlaces internos y un sitemap correcto. La guía de sitemaps de Google aclara que ayudan al descubrimiento, pero no garantizan rastreo o indexación. Considera el sitemap, la respuesta correcta, la página renderizada y la URL indexada como evidencias distintas. Juntas forman un diagnóstico útil; ninguna promete impresiones, clics ni compras.
| Observación | Prioridad según el contexto | Evidencia que confirmar | Siguiente acción |
|---|---|---|---|
| Falta contenido esencial de precios en el renderizado | Alta en la página donde se toma la decisión | Contenido del test en directo y dependencia pública bloqueada | Aplicar la corrección limitada justificada y repetir la prueba |
| Una ruta API privada está bloqueada | No es por sí sola un defecto SEO | Determinar si el contenido público necesita ese recurso | Mantener el control de acceso; no abrir datos privados |
| HTTP 200 sin evidencia de indexación | Estado que debe investigarse por separado | Contenido renderizado y estado real de indexación | Comprobar el índice aparte; no afirmar mejoras supuestas |
Preguntas frecuentes
¿HTTP 200 significa que Google puede indexar toda la página?
No. Confirma una respuesta correcta, pero también importan los recursos bloqueados, el renderizado, las directivas y la decisión de Google.
¿Debo permitir todas las URL /api/?
No. Identifica la dependencia pública exacta y aplica la excepción mínima justificada, o entrega el contenido esencial en HTML. Protege los datos privados con autenticación.
¿La corrección de Sitelemetry demostró más tráfico?
No. Demostró que la prueba en directo mostraba el catálogo y que la página era indexable en ese momento. No se acreditaron indexación ni resultados de tráfico.
Fuentes y lecturas
- Google: introducción a robots.txtdevelopers.google.com
- Google: especificación de coincidencias robots.txtdevelopers.google.com
- Google: fundamentos de SEO JavaScriptdevelopers.google.com
- Google: excluir páginas con noindexdevelopers.google.com
- Google: introducción a los sitemapsdevelopers.google.com
El equipo de Sitelemetry ha contrastado el contenido con el alcance del producto y las fuentes primarias enlazadas. Los ejemplos son ilustrativos salvo que se identifique un caso observado.
