Indexar tu web en Google en 2026: guía con mis errores reales

He publicado 435 artículos y he pasado un año entero peleándome con Search Console. Esta es la guía que me habría ahorrado seis meses de pruebas: sitemap, canonical, IndexNow y los fallos que te dejan invisible sin que lo sepas.

🎬 Cómo INDEXAR tu Página Web en Google: 3 métodos — Canal: JulianSEO

Te voy a ahorrar el camino largo. Mi sitio, La Frontera IA, tiene hoy 435 artículos publicados y 432 URLs en el sitemap. Cuando abro Search Console y miro los últimos 90 días, veo 204 páginas con datos, 257 clics y 4.085 impresiones. Y aquí viene lo que me costó entender: la página de inicio se lleva 187 de esos 257 clics. El 73% de todo el tráfico de Google va a una sola URL. Los otros 434 artículos se reparten las migajas.

No te voy a vender que con tres trucos vas a indexar todo en 24 horas, porque es mentira y porque quien te lo promete te está tomando el pelo. Lo que sí puedo contarte es qué funciona de verdad, en qué orden, y sobre todo qué errores cometí yo que hicieron que Google ignorara mi contenido durante meses. Si tu web existe pero "no sale en Google", el problema casi siempre está en uno de estos cinco puntos.

¿Cuánto tarda Google en indexar tu web en 2026?

Primero, ajustemos las expectativas, porque la respuesta corta es "depende" y la respuesta larga tiene números concretos. Google descubre tu página, la rastrea, la procesa y decide si merece entrar en su índice. Ese proceso completo tarda, en el mejor caso, entre 1 y 7 días para páginas de calidad bien enlazadas. En el peor, entre 30 y 90 días. Y hay un tercer grupo que la mayoría no contempla: páginas que Google rastrea y decide no indexar nunca, porque las considera de baja calidad o duplicadas.

Estos plazos no son míos, son los que maneja la industria: puedes ver el desglose en esta guía técnica de indexación. Mi experiencia encaja: cuando empecé, tardé semanas en ver la primera URL indexada. Hoy, con un sitemap que se regenera solo y contenido que Google ya conoce, las páginas nuevas entran en 1 o 2 días.

Un matiz importante: en 2026 ya no se indexa solo para Google. Los buscadores con IA y los asistentes citan contenido propio. Los datos de este año apuntan a que las plataformas de IA citan contenido un 25,7% más fresco que el que aparece en los resultados orgánicos de Google, y ChatGPT tira de URLs una media de 393 días más recientes. Es decir: si tu contenido está desactualizado, te estás perdiendo también ese canal, no solo Google.

Paso 1: comprueba si Google te ha indexado antes de tocar nada

El primer error que cometí fue arreglar cosas sin saber cuál era el problema real. Antes de cambiar nada, haz dos comprobaciones que tardan un minuto:

• Búsqueda site:tudominio.com en Google. Si aparecen páginas, estás indexado. Si solo sale la home o nada, tienes un problema de descubrimiento.
• Search Console, informe "Páginas". Ahí Google te dice el estado exacto de cada URL: "Indexada", "Detectada, aún no indexada", "Rastreada, aún no indexada", "Duplicada sin canónica" o "Excluida por etiqueta noindex". Cada uno de esos estados apunta a un problema distinto.

En mi caso, el informe de páginas me enseñó algo humillante: tenía cientos de artículos en "Detectada, aún no indexada". Google los conocía, los había visto, y había decidido que no merecían entrar. No era un problema técnico de descubrimiento: era un problema de calidad percibida. Eso duele más, porque no se arregla con una etiqueta.

Paso 2: el sitemap.xml no se crea una vez y ya está

El sitemap es el mapa que le entregas a Google para que no tenga que adivinar dónde está tu contenido. Suena básico, y lo es, pero hay una trampa en la que caí durante meses: un sitemap que no se actualiza es peor que no tener sitemap, porque le dices a Google "esto es todo lo que existe" y luego publicas 30 artículos que no están en la lista.

Las reglas que funcionan de verdad:

• El sitemap debe regenerarse automáticamente cada vez que publicas, editas o borras contenido. En mi caso, un script lo reconstruye con cada publicación.
• Solo deben estar las URLs canónicas e indexables. Nada de páginas con noindex, ni de versiones duplicadas.
• Decláralo en el robots.txt con la línea Sitemap: https://tudominio.com/sitemap.xml y envíalo en Search Console > Sitemaps.
• Comprueba de vez en cuando que el XML es válido. Me pasó que el mío usaba un namespace raro y el validador interno de Google lo leía con menos URLs de las que había. Un grep mal hecho me hizo creer durante días que tenía 2 URLs cuando tenía 400.

¿Es obligatorio? No. Google puede descubrir URLs por enlaces internos, backlinks o búsquedas. Pero sin sitemap, el descubrimiento es lento y aleatorio, y para sitios con más de unas pocas decenas de URLs es la diferencia entre días y semanas.

Paso 3: el canonical, el error que más caro me salió

Si solo te quedas con una cosa de esta guía, que sea esta. La etiqueta rel="canonical" le dice a Google cuál es la versión original de una página cuando existen varias copias. Sin ella, Google decide por su cuenta, y no siempre acierta.

Mi caso concreto: mi servidor servía la misma página en dos URLs, /ia/ y /ia/index.html. Google las veía como dos páginas duplicadas, y en Search Console me aparecía el aviso "Página alternativa con etiqueta canónica adecuada". No era un error grave, pero diluía la señal entre dos URLs. Se arregló haciendo que el servidor redirigiera una a la otra y asegurándome de que cada artículo tuviera su canonical apuntando a su URL definitiva.

Y ojo, porque el fallo de canonical tiene una variante mucho más fea que sufrí en mis carnes: artículos con slug nulo. Por un bug en mi generador de contenido, varios artículos se publicaron con slug: null en el JSON. El resultado: enlaces internos apuntando a /articulos/null.html, páginas que devolvían 404, y Google registrando errores de rastreo que consumían confianza. La corrección fue cruzar los slugs contra los archivos reales en el servidor y arreglar los JSON, pero el daño reputacional ante Google ya estaba hecho.

La regla es simple: cada página del sitio debe tener exactamente una URL canónica, y esa URL debe ser la que usas en tus enlaces internos. Si tienes dudas de si lo estás haciendo bien, busca en tu código rel="canonical" y comprueba que apunta a la URL limpia, sin index.html, sin parámetros, sin www si no lo usas.

Paso 4: robots.txt, el bloqueo invisible

El robots.txt es un archivo diminuto que puede dejarte sin indexar y sin que te enteres. Lo que hace es decirle a los rastreadores qué pueden visitar y qué no. El error clásico es usarlo para "ocultar" páginas que no quieres en Google. Error: si quieres que una página no aparezca, usa la etiqueta noindex en el HTML, no el Disallow del robots.txt. Con Disallow bloqueas el rastreo, pero la página puede aparecer en los resultados igualmente, sin contenido, porque Google ya la conocía de antes.

Mi robots.txt es casi un catálogo de paranoia de ex-desarrollador WordPress: bloqueo /wp-admin/, /wp-json/, .env, .git... y al final declaro el sitemap. Esos bloqueos de zonas privadas están bien, porque no son contenido que quieras indexar. Lo que nunca debes bloquear son tus artículos.

También te recomiendo mirar si tu servidor o tu CDN están bloqueando rastreadores legítimos por error. En mi caso, el servidor tenía una regla que bloqueaba a los bots con "curl" en el user agent... y resulta que los tests de Googlebot a veces llevan patrones parecidos. Pasé días pensando que tenía un problema de contenido cuando era mi propio servidor dándose portazos. Revisa los logs de acceso y busca respuestas 403 a Googlebot. Cuesta cinco minutos y descarta medio árbol de problemas.

Paso 5: IndexNow, el atajo que Google no usa

IndexNow es un protocolo para avisar a los buscadores de que has publicado o actualizado una URL. Es un ping HTTP de una línea: "esta URL ha cambiado". Sin él, los buscadores tardan días o semanas en descubrir el cambio, porque no rastrean todo cada día. Con él, lo saben casi al instante.

El detalle que casi nadie dice: Google no soporta IndexNow. El protocolo está respaldado por Bing, Yandex, Seznam, Naver y Yep, pero no por Google. Aun así merece la pena, por dos razones: Bing es el segundo buscador en cuota, y el ping es gratis y tarda un segundo en implementarse. En mi pipeline, cada publicación dispara un ping a IndexNow automáticamente, y en Bing las URLs aparecen en 1 o 2 días en lugar de 2 a 4 semanas. La documentación oficial del protocolo está en indexnow.org.

Para Google, el equivalente manual es la inspección de URL en Search Console, con el botón "Solicitar indexación". Tiene límite de peticiones diarias, así que úsalo con criterio: las URLs nuevas importantes, no las 400 que tienes acumuladas. Y una cosa más que funciona de verdad: compartir la URL nueva en redes sociales. Google rastrea X/Twitter, y un enlace desde ahí acelera el descubrimiento de forma medible.

El error que me dejó invisible sin saberlo: la home solo-JS

Vale, esta es la historia que quiero que te lleves. Durante semanas, mi página de inicio se cargaba perfectamente en el navegador: artículos, imágenes, todo. Pero Google no indexaba casi nada. Un día, haciendo una comprobación de rutina, me di cuenta de que la home se construía entera con JavaScript: el HTML que recibía Googlebot era prácticamente un cascarón vacío. El contenido existía, pero solo después de ejecutar un script que Google a veces ejecuta... y a veces no.

El diagnóstico fue brutal de simple: curl -s https://misdominio.com/ | grep -c "título-de-artículo" devolvía 0. Cero artículos en el HTML. Todo el contenido de la portada estaba generado por JavaScript en el navegador. Google puede renderizar JavaScript, pero lo hace más tarde y con menos prioridad, y si tu sitio depende 100% de él, te conviertes en ciudadano de segunda clase.

La solución fue reescribir la home para que el HTML viniera ya con el contenido dentro: tarjetas de artículos, títulos, enlaces, todo servido en el HTML estático. Cuando volví a comprobar, el número de "títulos de tarjetas" en el HTML pasó de 0 a más de 9, y la indexación empezó a moverse. Si tu web depende de JavaScript para mostrar contenido, ese es tu problema número uno. Sirve el contenido en el HTML, o al menos un resumen con enlaces.

Por qué publicar 35 artículos a la semana no indexa más

Aquí va la parte que me costó más cara. Durante meses, mi sistema automático publicaba hasta 35 artículos por semana. Al final del experimento tenía 422 artículos publicados y Google me había traído 59 clics en 90 días. Cincuenta y nueve. Lo escribí en un postmortem que me dolió redactar, porque el número habla solo: volumen sin calidad no indexa, y lo que indexa no posiciona.

En diciembre de 2025, Google lanzó una actualización de sus sistemas centrales que cambió las reglas del juego para la gente que hacía lo que yo hacía. El core update de diciembre de 2025, desplegado a partir del 11 de diciembre, puso el foco en la calidad percibida y en la frescura real del contenido. La clave que me reventó el esquema: Google detecta el "fake freshness", es decir, cambiar la fecha de un artículo sin mejorar su contenido de verdad. Cambiar la fecha, añadir una frase o reformatear ya no cuenta como actualización: cuenta como manipulación, y se penaliza.

Lo que sí cuenta como frescura real, según el análisis de los sistemas de frescura de Google: datos nuevos, secciones que abordan novedades, metodología actualizada y análisis propio que no estaba antes. Y hay un matiz que cambia la estrategia: la frescura funciona por consulta, no por página. El sistema QDF (Query Deserves Freshness) solo premia contenido reciente en búsquedas donde el usuario espera novedad: lanzamientos, resultados, tendencias. Para búsquedas de definición o referencia, la frescura da igual. Actualizar todo cada mes es tirar el trabajo.

Mi conclusión después de la auditoría de agosto de 2026 es la que ya han adoptado todos los sitios serios: 80% contenido perenne bien hecho, 20% actualidad. Los artículos que posicionan son guías y comparativas con datos propios, no las noticias que caducan en 48 horas. Si quieres el detalle de cómo y por qué cambié el modelo, lo conté en por qué dejé de publicar 35 artículos por semana.

Checklist: indexa tu web en 5 pasos

Resumen ejecutivo de todo lo anterior, en el orden en que deberías atacarlo:

1. Verifica con site:tudominio.com y el informe "Páginas" de Search Console si estás indexado y en qué estado están tus URLs.
2. Arregla el canonical de cada página: una URL canónica por contenido, sin duplicados ni index.html.
3. Regenera el sitemap con cada publicación, decláralo en robots.txt y envíalo en Search Console.
4. Elimina el JavaScript dependiente: que el contenido principal esté en el HTML que recibe Googlebot.
5. Añade IndexNow para Bing y Yandex, y usa "Solicitar indexación" + redes sociales para las URLs nuevas importantes.

Y después de hacer todo esto, ten paciencia. La indexación no es instantánea, y las métricas de Search Console van con retraso de uno o dos días. Mide el antes y el después en el informe de rendimiento, y no toques nada más durante al menos dos semanas. Cada cambio que haces reinicia el reloj de la evaluación.

Preguntas frecuentes

¿Cuánto tarda Google en indexar una página nueva?

Entre 1 y 7 días para páginas de calidad en dominios con historial, y entre 2 y 8 semanas para dominios nuevos. Si llevas más de un mes sin ver nada en Search Console, revisa canonical, robots.txt y si el contenido está en el HTML o depende de JavaScript.

¿Es obligatorio el sitemap.xml para indexar?

No, Google puede descubrir URLs por enlaces internos y externos. Pero sin sitemap actualizado el descubrimiento es lento, y para sitios con muchas URLs es la diferencia entre días y semanas. Es el acelerador más barato que existe.

¿Google soporta IndexNow?

No. IndexNow está respaldado por Bing, Yandex, Seznam, Naver y Yep. Google tiene su propio mecanismo: la inspección de URL con "Solicitar indexación" en Search Console.

¿Por qué Google no indexa mis artículos?

Las causas más comunes: contenido percibido como de baja calidad (thin content o duplicado), canonical apuntando a otra URL, bloqueo por robots.txt, dependencia de JavaScript o errores del servidor. El informe "Páginas" de Search Console te dice exactamente cuál es tu caso.