Una URL puede estar publicada, cargar bien en tu navegador y seguir sin aparecer en Google. Cuando pasa, no empezaría enviando la URL una y otra vez a Search Console. Primero intentaría saber en qué punto se ha roto el recorrido.
Google tiene que descubrir la URL, poder rastrearla y decidir si merece incluirla en su índice. Un sitemap ayuda en el primer paso. Un HTML accesible ayuda en el segundo. Ninguna de las dos cosas obliga a que la página acabe en los resultados.
En este portfolio he montado una base que favorece ese recorrido: Astro genera el HTML de cada ruta, el sitemap toma artículos y proyectos desde las colecciones, y el componente SEO construye la canonical y los alternates de idioma. Es una buena salida de producción, no una garantía de indexación. Si una URL nueva no apareciera, este sería mi orden de trabajo.
Empiezo por la URL exacta, no por una búsqueda genérica
El comando site:midominio.com puede dar una pista, pero no es un informe de diagnóstico. Puede mostrar resultados desactualizados, omitir una URL que Google conoce o enseñar una variante distinta de la que estoy mirando.
Abriría la herramienta Inspección de URL de Search Console y pegaría la dirección canónica exacta, incluida la barra final si esa es la versión que publica el sitio. Ahí buscaría tres respuestas muy concretas:
- Si Google conoce la URL.
- Si pudo recuperarla sin problemas.
- Qué motivo da para no indexarla o qué canonical ha elegido.
No lo trataría como un veredicto aislado. La inspección indica el estado que Google tiene registrado para esa URL y da una hipótesis mucho mejor que cambiar etiquetas a ciegas. Si se ha corregido algo, también permite probar la URL publicada, no el HTML que tengo abierto en local.
Aclaro qué versión debería existir
Antes de revisar Google, confirmaría que no estoy persiguiendo una URL equivocada. Es más habitual de lo que parece cuando hay redirecciones, parámetros, una migración o versiones por idioma.
En este sitio, por ejemplo, las URLs públicas usan barra final. /blog/mi-articulo/ es la forma que debe aparecer en el sitemap, en los enlaces internos y en la canonical. Si una ruta responde con una redirección, revisaría el destino final. Si quiero posicionar una página nueva, ese destino debe devolver un 200 y contener el contenido real.
También comprobaría el HTML que llegó a producción. Un artículo puede existir como MDX en el repositorio y no haberse incluido en el build por un error de colección, una fecha mal escrita o una condición que lo deja fuera del listado. En una web con renderizado en cliente, miraría además la respuesta inicial y no solo lo que aparece después de ejecutar JavaScript en mi navegador.
Compruebo que Google puede leer la respuesta
La siguiente pregunta es menos glamurosa y suele resolver problemas reales. ¿Qué recibe un robot cuando pide esa URL?
Buscaría un estado 200 en la página que quiero indexar. Un 404, un 410, un error 5xx o una cadena de redirecciones cambia por completo el diagnóstico. También revisaría si la respuesta parece una página vacía, una página de error que devuelve 200 o una URL que muestra prácticamente lo mismo que otra. Son casos que pueden acabar pareciendo un soft 404 o contenido duplicado para Google.
Después miraría dos lugares donde puede esconderse una orden de no indexar:
- La etiqueta
<meta name="robots" content="noindex">dentro del HTML. - La cabecera HTTP
X-Robots-Tag: noindex.
No basta con buscar noindex en el código fuente. Hay que revisarlo en la respuesta desplegada, porque un middleware, una configuración del hosting o una regla para previsualizaciones también pueden añadir cabeceras. La documentación de Google sobre robots meta y X-Robots-Tag confirma además una trampa frecuente. Google necesita poder rastrear la página para leer esa directiva. Bloquear una URL en robots.txt no es una forma fiable de retirar una página ya indexada y puede impedir que Google vea un noindex nuevo.
Canonical no significa que Google tenga que obedecerme
Una canonical le dice a Google qué URL considero principal cuando hay varias versiones parecidas. No convierte una página en única por escribir una etiqueta rel="canonical".
Revisaría que la canonical absoluta apunte a la propia URL si el contenido es realmente distinto. Si una ficha apunta sin querer a la home, o si todas las paginaciones comparten la misma canonical, estoy enviando una señal contradictoria. Search Console también puede mostrar una canonical elegida por Google diferente de la declarada.
En una web bilingüe añadiría una comprobación más. hreflang conecta equivalentes en español e inglés, pero no sustituye a la canonical. Cada versión indexable necesita su propia canonical y los alternates deben formar un grupo coherente. En mi implementación de hreflang con Astro explico cómo mantengo esa relación entre las rutas y el sitemap.
La guía de Google sobre consolidar URLs duplicadas es útil aquí porque presenta la canonical como una señal, no como una orden absoluta. Si Google elige otra, antes de forzar cambios miraría si de verdad existen duplicados, enlaces inconsistentes o redirecciones que expliquen su decisión.
El sitemap y los enlaces cumplen trabajos distintos
El sitemap de este proyecto se genera desde las páginas estáticas, los artículos y los proyectos. Cada entrada nueva queda incluida junto con sus versiones de idioma. Eso permite a Google descubrir URLs que quizá todavía no tengan muchos enlaces.
Pero no lo usaría como una lista de aprobados. Un sitemap dice “esta URL existe y me importa”. No explica por qué un lector debería llegar a ella ni por qué Google debería conservarla en el índice.
Por eso revisaría las dos cosas:
- Que la URL final esté en el sitemap publicado y no sea una redirección o una variante antigua.
- Que reciba enlaces internos desde páginas que tratan un tema relacionado.
Este artículo, por ejemplo, enlaza desde el SEO técnico del portfolio y desde una explicación concreta de hreflang. Esos enlaces no son un truco para empujar una URL. Dan contexto y crean un camino real de navegación. Cuando una página solo existe en el sitemap y nadie puede llegar a ella navegando por el sitio, me preguntaría primero si su arquitectura tiene sentido.
También puede faltar una razón para conservar esa página
Aquí es donde muchas revisiones técnicas se quedan cortas. Una página puede devolver 200, no tener noindex, aparecer en el sitemap y aun así no aportar suficiente contenido distinto.
No lo resolvería alargando el texto con definiciones que ya aparecen en cien artículos. Revisaría la intención. ¿La URL responde una pregunta concreta? ¿Aporta un ejemplo, una decisión, datos o una explicación que no esté repetida en otra página del mismo sitio? ¿Su título y su contenido prometen lo mismo?
En el blog intento partir de decisiones que ya existen en el proyecto. Este artículo puede hablar de HTML estático, canonicals, sitemap y versiones de idioma porque esas piezas están implementadas aquí. Eso no hace que Google deba indexarlo. Sí evita publicar una guía que podría pertenecer a cualquier web y no demuestra nada.
Si la inspección indica una página duplicada o Google no la ha indexado tras haberla rastreado, compararía esa URL con sus competidoras internas antes de tocar el sitemap. A veces el arreglo correcto es fusionar dos artículos, redirigir una versión antigua o reescribir la página para que responda una necesidad más precisa.
Solicitar indexación llega al final
Una vez corregida la causa, usaría la Inspección de URL para solicitar el rastreo de una página prioritaria. Lo haría una vez y anotaría qué he cambiado. Mandar la misma solicitud durante varios días no acelera el proceso.
Google explica que el rastreo puede tardar días o semanas y que pedirlo no garantiza una aparición inmediata ni siquiera la inclusión en resultados. El sistema prioriza contenido útil y de calidad. La guía oficial para solicitar un nuevo rastreo también diferencia las solicitudes para unas pocas URLs del envío de un sitemap para muchas.
Esa distinción cambia el orden de trabajo. Si he publicado un solo artículo importante, inspecciono la URL, corrijo lo que encuentre y solicito el rastreo. Si acabo de migrar o publicar muchas páginas, compruebo el sitemap y la arquitectura antes de ir una por una.
Lo que consideraría una revisión terminada
No daría el caso por cerrado al pulsar “Solicitar indexación”. Dejaría anotados la URL canónica, el estado HTTP, las directivas de robots, la canonical que Google ha elegido, la presencia en sitemap y los enlaces internos que llevan hasta ella. Después volvería a Search Console con tiempo suficiente para ver si el estado cambia y qué consultas empieza a recibir.
Ese registro evita dos errores bastante comunes. El primero es atribuir una mejora a la última etiqueta que hemos tocado cuando el cambio real era una redirección o un enlace interno. El segundo es convertir cada URL que tarda en indexarse en una urgencia técnica, cuando quizá el problema es que todavía no tiene una función clara.
La parte útil del SEO técnico no es acumular comprobaciones. Es descartar causas en un orden que te permita intervenir con sentido. Si quieres ver la base desde la que hago esas comprobaciones, puedes leer cómo he planteado el SEO técnico de este portfolio con Astro.