Cuando un sitio WordPress no aparece en Google, la reacción habitual sigue siempre el mismo guion: regenerar el sitemap, instalar un plugin SEO, solicitar la indexación. A veces basta con eso. Cuando no basta, se repiten los mismos gestos, porque no se sabe dónde más mirar. Ahí está la trampa: acumular acciones cuando Google Search Console ya ha emitido su veredicto. Su informe «Indexación de páginas» asigna un motivo preciso a cada URL descartada, y en WordPress esos motivos remiten casi siempre a un puñado de ajustes identificables: una casilla marcada en Ajustes > Lectura que deja todo el sitio en «Excluida por la etiqueta noindex», un interruptor de plugin que decide la suerte de familias enteras de páginas, archivos generados en serie que Google rastrea y luego descarta. ¿Qué ajuste produce qué estado? ¿Cuáles son normales y cuáles delatan un error? ¿Y cómo comprobar, más allá de unas cuantas URLs inspeccionadas a mano, lo que Google ha decidido para todo el sitio?
Por qué tus páginas WordPress no aparecen en Google
Una página WordPress ausente de Google o bien es desconocida para Google, o bien es conocida pero ha quedado fuera del índice. El informe «Indexación de páginas» de Search Console distingue ambos casos y muestra el motivo exacto: etiqueta noindex, bloqueo por robots.txt, página considerada sin interés propio, duplicado. Ese motivo es el punto de partida del diagnóstico.
Esa lectura cambia el orden de las operaciones. Las guías de indexación para WordPress repasan casi todas la misma lista: crear una cuenta de Search Console, enviar el sitemap, revisar el robots.txt, instalar Yoast o Rank Math. Son pasos útiles, pero describen un sitio sano que espera su turno. No dicen nada del sitio cuyas páginas Google ya conoce y sigue descartando, con el motivo a la vista. Y ese motivo señala directamente el ajuste que hay que examinar: no tiene sentido rehacer el sitemap cuando el informe indica una etiqueta noindex.
WordPress añade una particularidad que los consejos genéricos pasan por alto: la plataforma crea páginas en serie que tú nunca has redactado. Cada etiqueta añadida a una entrada genera una página de archivo, cada autor tiene la suya, cada mes de publicación también, y cada archivo multimedia puede tener su página de adjunto. Google lo rastrea todo, emite un veredicto por URL, y su propia documentación advierte de que no hay que esperar una indexación completa: «Don't expect every URL on your site to be indexed». El objetivo no es alcanzar el 100 % de páginas indexadas, sino comprobar que la frontera entre lo indexado y lo no indexado pasa exactamente por donde tú decidiste.
Rastrear e indexar: lo que muestra el informe «Indexación de páginas»
Google procesa cada URL en dos tiempos. Primero el rastreo: Googlebot descarga la página y lee su contenido. Después la indexación: Google decide si esa página merece una entrada en su índice. Una página puede ser rastreada y no indexada, y cada etapa tiene sus estados en el informe «Indexación de páginas» (sección Indexación > Páginas de Search Console).
En un sitio WordPress, algunos estados aparecen con más frecuencia que el resto. «Descubierta, actualmente no indexada»: Google conoce la URL pero aún no la ha rastreado. «Explorada, actualmente no indexada»: Google ha leído la página y no la ha retenido. «Excluida por la etiqueta noindex»: la página lleva una instrucción explícita de no indexación y Google la ha respetado. Añade los bloqueos por robots.txt y los estados de duplicado, cuando varias URLs sirven el mismo contenido, y tienes lo esencial del paisaje en la mayoría de los sitios WordPress. Existen otros motivos; estos son los que dan forma al informe.
Para una URL concreta, la herramienta de inspección de URLs de Search Console ofrece el detalle completo: el estado, la canónica que Google ha seleccionado y la fecha del último paso de Googlebot. Es la referencia del diagnóstico, con una limitación conocida: procesa una URL cada vez.
Cada problema de WordPress tiene su estado: la tabla de lectura
Los ajustes y automatismos de WordPress dejan cada uno una huella reconocible en el informe de indexación. Estas son las correspondencias más frecuentes; una misma familia de páginas puede recibir otros estados según la configuración.
| Problema de WordPress | Estado más frecuente | Cómo leerlo |
|---|---|---|
| Casilla «Disuade a los motores de búsqueda de indexar este sitio» marcada | «Excluida por la etiqueta noindex» en todo el sitio | Error casi seguro |
| noindex del plugin SEO en etiquetas o archivos | «Excluida por la etiqueta noindex» en esas familias | Normal si es deliberado |
| Etiquetas y archivos indexables pero pobres | «Explorada, actualmente no indexada», duplicados | Decisión pendiente |
| Páginas de adjuntos | «Soft 404», duplicados | Herencia a redirigir |
Paginación de archivos (/page/2/) |
«Explorada, actualmente no indexada» | Normal casi siempre |
| Sitio reciente o voluminoso | «Descubierta, actualmente no indexada» | Cola de rastreo |
| Plugin de seguridad, staging, reglas heredadas | «Bloqueada por robots.txt» | Conviene revisar |
La casilla «Disuade a los motores de búsqueda de indexar este sitio»
Está en Ajustes > Lectura, sección «Visibilidad en los motores de búsqueda». Desde WordPress 5.3, marcarla inserta una etiqueta <meta name="robots" content="noindex,nofollow"> en todas las páginas del sitio (las versiones anteriores servían una regla Disallow: / a través del robots.txt virtual). En Search Console, el resultado no deja lugar a dudas: las páginas van pasando a «Excluida por la etiqueta noindex», URL tras URL, al ritmo de las visitas de Googlebot.
El escenario típico lo conoce cualquier profesional: la casilla se marcó con toda la razón durante el desarrollo o un rediseño, y el sitio salió a producción sin que nadie la desmarcara. El sitio funciona, los visitantes directos no notan nada, y el índice se va vaciando en silencio durante semanas. La documentación de WordPress recuerda además que la casilla es una petición dirigida a los buscadores, no un bloqueo de acceso («it is up to search engines to honor your request»): las páginas siguen accesibles, simplemente van saliendo de los resultados a medida que los rastreos descubren la etiqueta. Esa lentitud es justo lo que hace el problema tan discreto.
Etiquetas, categorías y archivos: las páginas que WordPress crea por ti
Una entrada publicada con cinco etiquetas crea cinco páginas de archivo, y algunas no listarán nunca más de una entrada. Los archivos de autor y de fecha siguen la misma mecánica. Estas páginas no son defectos: son funciones de navegación. Pero cada una es una URL que Google descubre y juzga.
Dominan dos desenlaces. Si el plugin SEO las pone en noindex, se alinean en bloque bajo «Excluida por la etiqueta noindex»: una elección habitual y perfectamente sana, siempre que sea deliberada. Si siguen indexables, Google decide por su cuenta: los archivos pobres acaban en «Explorada, actualmente no indexada», y los que repiten los mismos extractos pueden derivar hacia estados de duplicado como «Página duplicada sin URL canónica». Audita un blog en masa y verás que estas familias generadas concentran casi la totalidad de ambos estados; las entradas en sí apenas los llevan.
La decisión merece tomarse familia por familia. Una página de categoría trabajada, con un texto de introducción y una demanda de búsqueda real, tiene su sitio en el índice. Una etiqueta usada una sola vez no aporta nada. El objetivo no es indexarlo todo ni excluirlo todo, sino decidir, y comprobar después que el informe refleja esa decisión.
Adjuntos y paginación: la herencia de los ajustes por defecto
Históricamente, WordPress creaba una página dedicada para cada archivo multimedia subido: la página de adjunto, una URL casi vacía alrededor de una imagen. Google las trata como lo que son: cascarones vacíos. Veredicto habitual: «Soft 404» o un estado de duplicado. WordPress 6.4 desactivó estas páginas en las instalaciones nuevas, y tanto Yoast como Rank Math saben redirigir la URL del adjunto al propio archivo. En un sitio antiguo, sin embargo, cientos de estas páginas pueden seguir abultando el informe.
La paginación de los archivos (/page/2/, /page/3/) responde a otra lógica: esas páginas hacen de sumario intermedio, y su estado más frecuente, «Explorada, actualmente no indexada», es normal en la mayoría de los casos. La tabla completa de veredictos de la paginación, señales de alarma incluidas, tiene su artículo dedicado.
Sitio reciente o voluminoso: la cola de rastreo
«Descubierta, actualmente no indexada» significa que Google conoce la URL pero todavía no la ha rastreado. En un sitio lanzado hace dos semanas es la norma, no una anomalía: la propia documentación de Google anuncia una semana o más antes de los primeros rastreos de un sitio nuevo («It can take a week or so for Google to start crawling and indexing a new page or site»), y el llenado del índice se prolonga mucho más allá.
El mismo estado cambia de sentido en un sitio consolidado y voluminoso. Cuando las entradas recientes se acumulan en «Descubierta» durante semanas, lo probable es que Googlebot esté gastando su presupuesto de rastreo en otra parte, a menudo en las familias generadas: etiquetas, archivos, variantes de URL creadas por el tema. El diagnóstico pasa entonces por el enlazado interno y por el volumen de URLs que el sitio expone al rastreo.
Robots.txt: plugins de seguridad, staging y bloqueos heredados
«Bloqueada por robots.txt» en páginas que deberían estar indexadas tiene casi siempre una causa mecánica: un plugin de seguridad o de mantenimiento que reescribió el archivo, un robots.txt de staging (Disallow: /) copiado a producción, o una regla histórica que nadie volvió a revisar.
La trampa es más retorcida de lo que parece, porque el robots.txt bloquea el rastreo, no la indexación. La documentación de Google es explícita: para que una etiqueta noindex funcione, la página no debe estar bloqueada por robots.txt («For the noindex rule to be effective, the page or resource must not be blocked by a robots.txt file»); de lo contrario, Googlebot nunca verá la instrucción y la URL puede permanecer en los resultados. Bloquear por robots.txt una página que se quería desindexar produce así el efecto contrario, hasta llegar al estado paradójico «Indexada aunque bloqueada por robots.txt». Los usos legítimos del archivo están detallados en nuestro artículo sobre el estado «Bloqueada por robots.txt».
Yoast y Rank Math: lo que sus ajustes producen del lado de Google
En la mayoría de los sitios WordPress, la indexación no la pilota el núcleo del CMS sino el plugin SEO. Yoast y Rank Math funcionan con el mismo principio: en sus ajustes de apariencia en el buscador, cada tipo de contenido y cada taxonomía dispone de un interruptor del tipo «¿Mostrar las etiquetas en los resultados de búsqueda?». Responder que no coloca una etiqueta noindex sobre toda la familia, y cada página afectada irá a parar a «Excluida por la etiqueta noindex» en el informe.
Esa arquitectura es a la vez la fuerza y el riesgo de estos plugins. Un solo interruptor gobierna cientos de URLs: poner en noindex las etiquetas de un blog con una sola acción es una comodidad real. Pero el mismo interruptor, cambiado en la familia equivocada, saca del índice páginas que traían tráfico. Las circunstancias clásicas: una importación de ajustes, un cambio de tema o de plugin SEO, un rediseño en el que las opciones se reprodujeron de memoria. La diferencia entre el noindex deliberado y el noindex involuntario no se ve en la interfaz del plugin; se ve en el informe, cuando una familia entera cambia de estado.
Hay que añadir tres matices que los tutoriales de plugins no tocan. Primero, el plugin escribe la etiqueta, pero no emite el veredicto: Search Console sigue siendo el único lugar que dice qué hizo Google con la instrucción. Segundo, la etiqueta realmente servida puede diferir de la que el plugin cree haber puesto: un tema u otra extensión que inserte su propia meta robots puede entrar en conflicto con la del plugin SEO. Lo que manda es el HTML renderizado y el informe de indexación, no la pantalla de ajustes. Tercero, los sitemaps que generan estos plugins excluyen normalmente las familias en noindex: un sitemap que lista URLs con noindex envía a Google señales contradictorias, y ese tipo de incoherencia se detecta precisamente cruzando la lista del sitemap con los estados.
💡 Un interruptor de plugin se aplica a familias enteras de URLs, pero el veredicto cae URL a URL. Nadie revisa 2.000 etiquetas a mano en el inspector. Descubre IndexProbe en acceso anticipado →
Identificar las páginas afectadas en el conjunto de tus URLs WordPress
La inspección de URLs da el veredicto exacto de una página; el informe «Indexación de páginas» da volúmenes por motivo. Entre los dos falta la vista esencial para un sitio WordPress: la vista por familia. El informe no se puede filtrar por tus patrones de URL: imposible aislar «todas mis páginas /tag/» o «todos mis archivos de autor» para ver su reparto de estados.
El método que funciona consiste en inspeccionar en masa una lista de URLs que tú controlas. Esa lista ya existe: es el sitemap que genera tu plugin SEO, una exportación de tus contenidos, o una selección construida desde Search Console con un patrón de URL (una expresión regular sobre /tag/, /author/, /page/). Eso es exactamente lo que permite IndexProbe: le entregas esa lista, o la construyes desde tu GSC, y consulta la API oficial de inspección para cada URL. Obtienes el estado de indexación, la canónica seleccionada por Google y la fecha del último rastreo, para cada página, en una tabla filtrable.
Con una segmentación por familia (generada por IA o definida a mano: artículos, páginas, categorías, etiquetas, archivos, adjuntos), la lectura se vuelve inmediata. Un sitio WordPress sano muestra un perfil característico: un bloque indexado sostenido por los artículos y las páginas, y un bloque de «Excluida por la etiqueta noindex» y «Explorada, actualmente no indexada» sostenido por las familias generadas. Ese equilibrio no tiene nada de inquietante. Lo que debe alertar es que la frontera se mueva: categorías estratégicas que aparecen en el bloque noindex, artículos que se deslizan hacia «Explorada, actualmente no indexada», un sitio entero volcado en un único estado.
Corregir según el estado
Una vez conocido el reparto, cada veredicto pide su corrección, y algunas situaciones no piden ninguna.
Todo el sitio en «Excluida por la etiqueta noindex»: desmarcar la casilla en Ajustes > Lectura y acelerar después el regreso de las páginas estratégicas solicitando su indexación, como se detalla en nuestra guía para enviar tu sitio web a Google. El resto del sitio volverá al ritmo de los rastreos, primero las páginas visitadas con frecuencia.
Una familia útil en «Excluida por la etiqueta noindex»: devolver el interruptor correspondiente a su posición en Yoast o Rank Math y comprobar después la etiqueta realmente servida en el HTML, con las cachés purgadas. Si la familia además faltaba en el sitemap, reintegrarla le da a Google una razón más para volver.
Archivos en «Explorada, actualmente no indexada»: decidir antes de corregir. Una categoría que apunta a una búsqueda real merece inversión (texto de introducción, enlaces desde los artículos); una etiqueta sin demanda de búsqueda está mejor con un noindex asumido. Este estado en páginas sin ambición no es un problema que resolver: es el funcionamiento normal.
Adjuntos en «Soft 404» o en duplicado: activar en el plugin SEO la redirección de las URLs de adjuntos hacia el archivo. Los estados irán desapareciendo a medida que Google registre las redirecciones.
Entradas recientes en «Descubierta, actualmente no indexada»: en un sitio joven, dar tiempo. En uno consolidado, recortar lo que malgasta el rastreo (familias generadas inútiles, variantes de URL) y reforzar el enlazado hacia los contenidos en espera.
Páginas útiles en «Bloqueada por robots.txt»: retirar la regla causante, sin perder de vista el orden de las operaciones. Si el objetivo final es la desindexación, el noindex tiene que ser legible, así que el bloqueo de robots.txt debe levantarse primero.
Comprobar que la corrección ha funcionado
Un ajuste corregido no cambia nada en Search Console mientras Googlebot no vuelva a pasar por las páginas afectadas. Ese plazo se cuenta en días para las páginas activas y en semanas para los archivos poco rastreados. La comprobación se hace por tanto en dos tiempos: verificar de inmediato la etiqueta servida en el HTML, y confirmar más tarde que el veredicto de Google ha cambiado.
Para ese segundo tiempo, el método es el mismo que para el diagnóstico: relanzar el análisis sobre la misma lista de URLs y comparar. Tras corregir un noindex involuntario, la familia afectada debe ir saliendo de «Excluida por la etiqueta noindex» hacia el índice a lo largo de las semanas; tras redirigir los adjuntos, los «Soft 404» deben apagarse. La vista Comparación de IndexProbe pone los dos análisis frente a frente, estado por estado, y el relanzamiento programado con resumen por correo convierte esa comprobación en vigilancia: un interruptor devuelto a la posición equivocada por una actualización de plugin se detecta por el cambio de veredicto, antes de la caída de tráfico.
El recorrido completo: leer el veredicto actual de Google sobre cada familia de páginas WordPress, corregir el ajuste que ese veredicto señala, y comprobar después que ha cambiado. Prueba IndexProbe en acceso anticipado y lee esos veredictos sobre el conjunto de tus URLs WordPress, en un solo análisis.
Preguntas frecuentes
¿Cuánto tarda Google en indexar un sitio WordPress?
La documentación de Google habla de una semana o más antes de los primeros rastreos de un sitio nuevo, y la indexación se prolonga después durante semanas. Ningún ajuste garantiza un plazo: enviar el sitemap y solicitar la indexación de las páginas clave acelera el descubrimiento, no la decisión.
¿Hay que indexar las etiquetas y categorías de WordPress?
Se decide familia por familia, según la demanda de búsqueda. Una categoría trabajada que apunta a una búsqueda real tiene su sitio en el índice; una etiqueta añadida sobre la marcha no suele aportar nada y puede ponerse en noindex sin remordimientos. Lo esencial es que el informe de indexación refleje tu decisión, no un ajuste por defecto.
¿La casilla «Disuade a los motores de búsqueda de indexar este sitio» bloquea todo el sitio de inmediato?
No. Es una petición, no un bloqueo: el sitio sigue accesible, y las páginas ya indexadas van saliendo de los resultados poco a poco, al ritmo de los pasos de Googlebot que descubren la etiqueta noindex. Precisamente esa lentitud hace que una casilla olvidada sea tan difícil de detectar sin leer los estados.
¿Basta un plugin SEO para que Google indexe mi sitio WordPress?
No. Yoast, Rank Math y sus equivalentes le facilitan el trabajo a Google (sitemap, etiquetas limpias, canónicas) y te dan control por familia sobre el noindex. Pero la decisión de indexar sigue siendo de Google, y un plugin mal configurado puede igualmente sacar del índice páginas útiles. El informe «Indexación de páginas» sigue siendo el único lugar donde se lee el resultado.
¿Por qué mis páginas WordPress se quedan en «Explorada, actualmente no indexada»?
Google las ha leído y no les ha encontrado interés propio para una búsqueda. En archivos, etiquetas y paginación es el comportamiento esperado. En entradas o páginas trabajadas, este estado invita a revisar la calidad, la redundancia interna y el enlazado. Las prioridades se aclaran al ver qué familias concentran el estado.
¿Cómo comprobar lo que Google ha indexado realmente de mi sitio WordPress?
Para una URL: la herramienta de inspección de Search Console, que devuelve el estado oficial, la canónica seleccionada y el último rastreo. Para el conjunto del sitio: inspeccionar en masa la lista de tus URLs (sitemap, exportación o selección por patrón desde la GSC) y leer el reparto de estados por familia. Esa vista de conjunto es la que destapa los ajustes cuyo efecto real ya no coincide con la intención.