Blog · 2026-08-30

¿Tu sitio nuevo no tiene ni una página indexada? Revisa si el canonical y el sitemap se contradicen

Antes de correr a cambiar el contenido: usa la API de inspección de URL y mira lastCrawlTime. Si viene vacío en todas, tus señales se están contradiciendo. Alinea canonical, og:url, JSON-LD y sitemap, verifica uno por uno que devuelvan 200 y reenvía el sitemap. Con eso casi siempre se resuelve.

El sitio lleva semanas publicado, ya enviaste el sitemap, el contenido no es de páginas delgadas, y Search Console sigue mostrando 0 páginas indexadas. La reacción más común es volver a los artículos, cambiar títulos, o consolarse con que "un dominio nuevo tarda". Espera un momento: cuando no hay ni una sola página indexada, por lo general no es un problema de calidad, es que el sitio le está diciendo dos cosas contradictorias al buscador. Eso no se arregla cambiando contenido, se arregla mirando en el lugar correcto.

Empieza por lastCrawlTime: vacío significa que Google nunca vino, no que vino y no le gustó

Pasa todas las URLs del sitio por la API de inspección de URL de Search Console (urlInspection().index().inspect()) y fíjate en dos campos: coverageState y lastCrawlTime. Esos dos campos separan "no está indexada" en dos enfermedades completamente distintas:

• lastCrawlTime con valor y estado "Rastreada, actualmente sin indexar": Google vino, la vio y decidió no incluirla por ahora. Recién aquí entran en juego la calidad del contenido y la repetición de plantilla.
• lastCrawlTime vacío y estado atascado en "Detectada, actualmente sin indexar" o incluso "URL desconocida para Google": Google ni siquiera la rastreó. Por muy bien escrito que esté el contenido, nunca lo vio. El problema está en las señales técnicas, no en el artículo.

En el sitio nuevo con "cero indexación total" que nos tocó, el escaneo devolvió lastCrawlTime vacío en absolutamente todas. En cuanto ese campo sale vacío, puedes saltarte la ansiedad por el contenido e ir directo a revisar las señales.

Así se ve el culpable: el sitemap dice A, el canonical dice B, y B devuelve un 308 hacia A

El caso real, anonimizado, se entiende en tres líneas:

sitemap <loc>     →  https://example.com/reviews/foo        (sin extensión)
canonical página  →  https://example.com/reviews/foo.html   (con .html)
foo.html medido   →  devuelve 308, redirige a /reviews/foo sin extensión

Recorre el camino desde el punto de vista de Google: sigue el sitemap y rastrea A; el canonical de A dice "la versión oficial es B"; va a rastrear B y un 308 lo devuelve a A. Las dos señales se pasan la pelota, y Google no va a adivinar cuál manda. Lo que hace es posponer el procesamiento, o directamente renunciar a indexar.

Esta mina es muy fácil de pisar en plataformas de hosting estático. Cloudflare Pages, por ejemplo, redirige automáticamente /foo.html con un 308 hacia /foo. En el sistema de archivos está foo.html, pero la URL oficial hacia afuera es /foo sin extensión. El generador emite el canonical con .html porque se guía por el nombre de archivo, y el sitemap emite el loc sin extensión. Cada pedazo de código, mirado por separado, "no está mal". El error es la inconsistencia.

Los cuatro lugares que hay que alinear, y si falta uno siguen peleándose

La URL oficial de una página aparece más de una vez en el sitio, y estos cuatro lugares tienen que ser idénticos carácter por carácter:

1. <link rel="canonical">
2. <meta property="og:url">
3. El "url" de los nodos WebPage o Article dentro del JSON-LD
4. El <loc> del sitemap.xml

La corrección no consiste en abrir cuatro archivos y editar cada uno. Consiste en definir en el generador una única función de "URL oficial" y que los cuatro lugares salgan de ese mismo valor. Si sincronizas cuatro cadenas a mano, tarde o temprano vuelven a contradecirse.

Un problema vecino bastante común: que el loc del sitemap arrastre el prefijo de ruta del directorio de compilación, con lo cual devuelve 404 en producción. Nosotros pisamos una versión todavía más traicionera: una línea "bienintencionada" de fallback dentro del script de verificación quitaba el prefijo automáticamente antes de comparar, así que los loc mal escritos pasaban la revisión en cada ronda y estuvieron en verde muchísimas rondas seguidas sin que nadie lo notara. La lección: un fallback solo puede absorber diferencias de forma conocidas y correctas (como las URLs sin extensión de la plataforma), nunca errores. Antes de escribir cada línea de fallback, pregúntate: ¿esto tolera un caso válido o está tapando un bug?

La verificación tiene un solo criterio: cada loc devuelve 200 directo

Después de corregir no basta con ver que "la página abre". El navegador y curl con -L siguen las redirecciones automáticamente, así que un 308 ni se nota. Hay que desactivar el seguimiento automático para medir:

# Sin -L, que es la única forma de ver el código de estado real
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/reviews/foo"

El criterio: cada <loc> del sitemap tiene que devolver 200 cuando se pide directo. Un 308 cuenta como fallo, porque significa que el loc no está escrito en la forma oficial; un 404 ni se discute. Además, toma algunas páginas de muestra y confirma la trinidad: la URL que pediste, el canonical de la página y el og:url tienen que ser exactamente iguales.

El último paso es el que más gente se salta: volver a Search Console y reenviar el sitemap. Si no lo reenvías, Google sigue con el archivo viejo, la señal contradictoria se queda en su cola de procesamiento y todo lo anterior no sirvió de nada.

¿Ya alineaste todo y sigue en "Detectada"? Revisa los enlaces internos

Alinear los cuatro lugares resuelve el "no rastreo porque las señales se contradicen". Si las señales ya están limpias y la página sigue atascada mucho tiempo en "Detectada, actualmente sin indexar", el siguiente sospechoso habitual es que los enlaces internos son demasiado escasos: la página solo cuelga del sitemap, casi ninguna otra página del sitio la referencia, y Google concluye que no es importante y no la pone en la fila de rastreo.

En un sitio de contenido de un sector muy competido hicimos un equilibrado de enlaces internos: antes había 49 páginas con un solo enlace entrante, y después de llevar las 116 páginas del sitio a 4 o más enlaces entrantes cada una, la tasa de indexación llegó a 153 de 173 páginas (alrededor del 88%). El método también fue automatizado: tratar "cuántas veces se referencia cada página" como un indicador de control en el momento de compilar, calcularlo antes de generar la salida y hacer que las páginas por debajo del umbral reciban enlaces automáticos desde páginas relacionadas, en lugar de depender de que el editor se acuerde de enlazar.

Cierre: convierte esta revisión en un script dentro de tu pipeline de despliegue

Recapitulando el orden de la investigación: mirar lastCrawlTime con la API de inspección de URL; si está todo vacío, alinear canonical, og:url, url del JSON-LD y loc del sitemap; verificar uno por uno que cada loc devuelva 200 con el seguimiento de redirecciones desactivado; reenviar el sitemap; y si sigue atascado, revisar los enlaces internos. Cada paso es una verificación programable, así que vale la pena escribirla como script y colgarla del flujo de despliegue para que corra sola en cada publicación, en lugar de acordarse a mano después de publicar. Si tu sitio nuevo también está en cero indexado, o quieres automatizar este tipo de revisión y dejar de investigar lo mismo una y otra vez, escríbenos. Sacando la respuesta real de la API de inspección de URL, por lo general se ubica rápido qué capa es la que se está contradiciendo.

El lanzamiento de un sitio nuevo lo convertimos en servicio

Que el canonical y el sitemap se peleen es solo una de las formas de morir. Casi nunca hay una sola razón por la que un sitio nuevo no se indexa, y hay que descartarlas una por una.

• Arquitectura del sitio y SEO técnico: canonical, sitemap, robots y datos estructurados alineados de una vez
• Monitoreo de indexación: revisar el estado de indexación página por página, y para las que no entraron, encontrar la causa y reenviarlas
• Producción de contenido: sin contenido original no hay motivo para ser indexado, y este es el paso que más se salta

Entrega en cuatro semanas, con resultados cada semana. Las especificaciones están en Servicio de construcción SEO para iGaming.