Cuando una URL deja de aparecer en Google, el primer sospechoso suele ser robots.txt, pero ese archivo no explica todos los casos. En WordPress, una caída de tráfico, una página sin indexar o un aviso en Search Console puede venir de un bloqueo de rastreo, de una canonical mal definida o de una etiqueta noindex aplicada sin querer.
Si Google no indexa tus páginas, robots.txt puede estar bloqueando el rastreo, pero no siempre es la causa real. Primero conviene revisar en Search Console si el problema afecta al rastreo, a la indexación o a la canonicalización; después, comprobar si están bloqueados /wp-admin/, sitemap.xml o archivos CSS/JS. Con un diagnóstico ordenado se corrigen los errores de indexación y se confirma el cambio sin poner en riesgo el tráfico.
Resumen del proceso
- Comprueba en Search Console si la URL está bloqueada por robots.txt, marcada como noindex o desplazada por una canonical.
- Revisa el archivo robots.txt y busca reglas Disallow que afecten a la URL, al sitemap o a recursos CSS/JS.
- Corrige la regla exacta en WordPress, sin tocar más rutas de las necesarias.
- Valida el cambio con la inspección de URL y con el sitemap XML.
- Vigila el estado durante varios días hasta ver rastreo e indexación normales.
Si Google puede rastrear la URL pero no la indexa, el problema ya no suele estar en robots.txt. En ese caso, toca mirar canonical, noindex, duplicidad o calidad de contenido.
Comprueba en search console si el bloqueo existe de verdad
Search Console te dice si el fallo viene de rastreo, de indexación o de una señal contradictoria. Esa diferencia ahorra horas. Si ves "bloqueada por robots.txt", Google no ha podido entrar. Si ves "rastreada, pero no indexada", el archivo robots.txt no suele ser el culpable principal.
Mira el estado exacto de la URL
Abre la inspección de URL en Search Console y pega la dirección afectada. Fíjate en el estado de cobertura, en la última exploración y en el motivo exacto del problema. Esta revisión tarda entre 3 y 5 minutos por URL, si ya tienes acceso a la propiedad correcta.
El error más frecuente aquí es cambiar robots.txt sin mirar antes el estado real. Eso lleva a corregir donde no toca. Una URL puede estar bloqueada, pero también puede estar excluida por noindex o por una canonical que apunta a otra página.
Distingue rastreo
El rastreo es la visita de Googlebot. La indexación es cuando Google decide guardar la página en su base de datos. La canonical es la señal que dice qué versión considera principal. Son cosas distintas, y se mezclan más de lo que parece.
Una URL bloqueada por robots.txt puede seguir apareciendo un tiempo si ya estaba indexada antes. Por eso existe el caso de "indexado aunque bloqueado por robots.txt". No es magia. Es que Google conserva la URL hasta que la revisa otra vez.
Diagnostica primero si el fallo es de rastreo
Cuando una URL da problemas, conviene seguir un orden fijo para no mezclar causas. Primero abre Search Console y usa la inspección de URL: si el estado dice que está bloqueada por robots.txt, el bloqueo está en el rastreo; si aparece como rastreada, pero no indexada, el archivo robots.txt ya no es el principal sospechoso; y si Google muestra una canonical distinta, el problema está en la canonicidad. Por ejemplo, una ficha de producto puede ser rastreable pero quedar fuera del índice porque el sitio la duplica en varias categorías y Google elige otra versión como principal.
Ese flujo evita tocar el archivo robots.txt cuando en realidad el problema es una etiqueta noindex o una señal de contenido duplicado.
Revisa el archivo robots.txt y detecta bloqueos de URLs
El archivo robots.txt decide qué puede rastrear Googlebot y qué no. En WordPress suele vivir en la raíz del dominio, por ejemplo https://tudominio.com/robots.txt. Su revisión suele tardar entre 10 y 15 minutos si hay pocas reglas, y algo más si el plugin de SEO ha escrito varias líneas automáticas.
Busca Disallow que afecten a la URL
Abre el archivo y busca líneas con Disallow. Si la URL afectada cae dentro de una carpeta bloqueada, ya tienes una pista clara. Por ejemplo, una regla para /blog/ bloquea todo lo que cuelga de esa ruta.
También conviene revisar si el bloqueo afecta al sitemap. Un Disallow: /sitemap.xml puede romper la lectura del mapa del sitio, y eso complica la validación posterior en Search Console.
Un caso habitual: un sitio en WordPress migra a un nuevo plugin de seguridad, hereda reglas antiguas y bloquea una carpeta que antes solo servía para pruebas. Resultado: Google deja de rastrear varias URLs sin que nadie lo vea al momento.
Comprueba si bloquea recursos CSS y JS
Google necesita ver la página casi como una persona. Si le quitas CSS o JavaScript esenciales, la lectura se queda coja. Piénsalo como taparle los ojos al rastreador: puede seguir entrando, pero no interpretar bien el contenido ni el diseño de la página.
Corrige la regla exacta sin romper WordPress
La solución correcta es tocar solo la línea que bloquea el problema. Así evitas abrir puertas que deberían seguir cerradas. En WordPress, esta corrección suele hacerse desde el plugin de SEO, desde un plugin de seguridad o desde el archivo en el servidor.
Ajusta solo la ruta afectada
Si la URL afectada está dentro de una carpeta concreta, corrige esa ruta y no toda la raíz. Si bloqueas demasiado, generas un efecto dominó. Si bloqueas demasiado poco, sigues dejando fuera la página que sí querías recuperar.
La forma rápida es editar el archivo y probar. La forma correcta es guardar una copia del estado actual antes de tocar nada. Esa copia evita sustos cuando el plugin reescribe el archivo al guardar.
Revisa /wp-admin/ con cabeza
Bloquear /wp-admin/ suele ser normal. El problema aparece cuando la regla se escribe mal y arrastra rutas útiles del backend o recursos que necesita el propio sitio. En WordPress, una línea equivocada aquí puede provocar efectos raros en plugins, previsualizaciones o procesos internos.
En la práctica, la mayoría de guías dicen “bloquea /wp-admin/”. Lo que no mencionan es que hay instalaciones donde esa regla convive con excepciones necesarias. Si un plugin carga archivos desde esa zona, el bloqueo agresivo puede romper funciones internas.
Valida el cambio con Search Console y el sitemap XML
Una corrección sin validación deja dudas abiertas. Search Console confirma si Google ya puede entrar otra vez, y el sitemap XML confirma si el sitio vuelve a presentar las URLs correctas. Esta comprobación suele ocupar entre 15 y 20 minutos, más el tiempo de propagación.
Inspecciona la URL cambiada
Vuelve a pegar la URL en la inspección de Search Console. Mira si ya no aparece bloqueada por robots.txt y si la versión en vivo responde bien. Si la URL sigue fallando, el problema puede estar en otra capa, como un noindex o una canonical que sigue apuntando fuera.
En la captura de más abajo se aprecia claramente la diferencia entre una URL bloqueada y una URL rastreable. Esa comparación ayuda mucho cuando se revisa el cambio con prisas.
Comprueba el sitemap XML
El sitemap debe abrirse sin bloqueo y mostrar URLs válidas. Si el sitemap está tapado por robots.txt, Google pierde una guía útil para descubrir páginas. No siempre deja el sitio fuera del índice, pero sí ralentiza el rastreo y la revisión.
La guía de Google sobre robots.txt deja claro que bloquear recursos o rutas críticas puede afectar a cómo Google entiende y rastrea el sitio. Verifica también que el sitemap siga accesible y que incluya las URLs correctas tras el cambio.
Evita los errores que más rompen la indexación
El fallo más caro no es el bloqueo. Es tocar una parte y romper dos más. En WordPress, eso pasa cuando se corrige robots.txt sin mirar el resto de señales. La salida buena empieza con el síntoma exacto y termina con una comprobación limpia.
No confundas robots.txt con noindex
Robots.txt decide si Google puede entrar. Noindex le dice que no guarde la página. Son puertas distintas. Si el sitio tiene noindex, cambiar robots.txt no arregla la exclusión.
Si una página está rastreable, pero no aparece en el índice, mira primero esa etiqueta. Luego revisa canonical y contenido. Solo después vuelve a robots.txt si ves un bloqueo real.
No uses reglas heredadas sin revisar
Muchos sitios arrastran reglas de una instalación antigua, una migración o un staging. Eso funciona mal cuando el dominio cambia, porque el contexto ya no es el mismo. Un sitio en pruebas no necesita la misma protección que una web en producción.
Un caso habitual: un ecommerce pequeño clona su web para hacer cambios, copia también el robots.txt y olvida que el archivo bloquea carpetas que en producción sí hacen falta. Resultado: el sitio público queda medio ciego para Google durante días.
Cuándo no funciona este método
Este método no sirve si la URL ya está indexada y el problema real está en el contenido, en el enlazado interno, en la autoridad o en una penalización. Tampoco sirve si el bloqueo viene de noindex o de una canonical, porque ahí robots.txt no es la causa principal. Si el sitio no usa WordPress, la lógica cambia y hay que revisar otra capa.
Preguntas frecuentes sobre errores de indexación por
¿Robots txt impide la indexación?
Impide el rastreo, no siempre la indexación inmediata. Google puede conservar una URL en el índice un tiempo si ya la conocía. Por eso aparece a veces “indexado aunque bloqueado por robots.txt”. La corrección buena empieza por identificar si el problema está en rastreo, noindex o canonical. Después se valida en Search Console con la URL exacta.
¿Qué significa “bloqueada por robots.txt” en
Significa que Googlebot no ha podido entrar a esa URL por una regla de bloqueo. La página puede existir y estar activa, pero Google no la rastrea. Si la URL es importante, revisa el archivo robots.txt, la ruta afectada y el sitemap XML. Después confirma el cambio con la inspección de URL.
¿Por qué una URL sigue indexada si robots.txt la
Porque Google ya la conocía antes y aún no ha actualizado su estado. El bloqueo frena el rastreo nuevo, pero no borra al instante una URL ya guardada. Este caso confunde mucho. La forma correcta de actuar es corregir la regla, esperar el nuevo rastreo y revisar Search Console otra vez.
¿Qué reglas de WordPress se rompen más?
Las más problemáticas son las que bloquean /wp-admin/, sitemap.xml o carpetas con CSS y JS. También fallan las reglas copiadas de staging a producción. En WordPress, un Disallow mal escrito puede tocar más rutas de las previstas. Por eso conviene revisar el archivo entero antes de guardar.
¿Cómo sé si el problema es canonical y no
Si Google puede rastrear la URL pero no la indexa, la canonical es una sospecha fuerte. Mira si la página apunta a otra versión como principal. Si es así, Google sigue esa señal. Cambiar robots.txt no corrige eso. La revisión debe incluir canonical, noindex y duplicidad.
¿Cuánto tarda Google en notar el cambio?
Suele tardar desde unas horas hasta varios días. Depende del tamaño del sitio, del rastreo previo y de la frecuencia con la que Google visita esa URL. Search Console ayuda, pero no acelera todo por arte de magia. Lo normal es confirmar primero el acceso y vigilar después el nuevo estado.
¿Puedo bloquear /wp-admin/ sin riesgo?
Sí, pero con cuidado. Bloquear /wp-admin/ suele ser correcto en un WordPress público, aunque algunas instalaciones usan excepciones o rutas auxiliares. La regla debe ser limpia y no debe arrastrar recursos útiles. Si hay plugins de seguridad, conviene revisar que no añadan bloqueos extra.
Revisa el bloqueo y corrige solo la causa real
La salida más segura es simple: identifica el estado en Search Console, comprueba si robots.txt bloquea la ruta, separa el caso de noindex y canonical, corrige una sola pieza y vuelve a validar. Ese orden evita errores tontos y deja la web estable. En mantenimiento WordPress, el orden importa casi tanto como la corrección.
Inspección de URL en Search Console ayuda a confirmar si Google ya puede rastrear la página tras el cambio. Esa comprobación cierra el círculo y evita volver a tocar el archivo sin motivo.
⚠️ Si cambias robots.txt y luego vuelves a cambiarlo varias veces el mismo día, puedes perder la pista de qué arreglo ha funcionado de verdad.
