Un cliente me llamó un martes por la mañana la primavera pasada -- puro pánico en su voz. Administraba un sitio de listados inmobiliarios, unos 42,000 páginas, y Google Search Console acababa de decirle que solo 5,800 estaban indexadas. Había perdido aproximadamente el 86% de sus páginas indexables, aparentemente de la noche a la mañana. Sin actualización de algoritmo. Sin acción manual. Sin implementaciones recientes que recordara. Solo... desaparecieron.
Conclusión clave: Cuando un sitio WordPress de 40,000 páginas tiene solo 6,000 indexadas, la causa casi siempre es la arquitectura: URLs facetadas, plantillas delgadas y desperdicio de rastreo, no una penalización de Google.When a 40,000-page WordPress site has 6,000 pages indexed, the cause is almost always architecture: faceted URLs, thin templates, and crawl waste, not a Google penalty.
He visto este escenario exacto más veces de las que puedo contar, en más de 12,000 construcciones de WordPress de Seahawk. Y lo que enloquesce es que la pérdida de indexación en sitios grandes rara vez tiene una sola causa. Generalmente son tres o cuatro pequeños fallos que se componen silenciosamente hasta que algo colapsa.WordPress builds. And the maddening thing is that indexation loss on large sites rarely has one cause. It's usually three or four small failures that compound quietly until something collapses.
Así es exactamente cómo lo diagnostico.
---
Comienza con Google Search Console -- Pero No Te Detengas Allí
Lo primero que siempre hago es abrir el informe de Páginas en Google Search Console. No el antiguo informe de Cobertura -- Google actualizó esto en 2023, y la nueva vista de Páginas desglosa indexadas vs. no indexadas con códigos de razón apropiados. Toma una captura de pantalla el primer día. Necesitas una línea de base.Pages report in Google Search Console. Not the old Coverage report -- Google updated this in 2023, and the new Pages view breaks down indexed vs. non-indexed with proper reason codes. Take a screenshot on day one. You need a baseline.
Los códigos de razón importan enormemente. "Rastreada -- actualmente no indexada" es un problema completamente diferente a "Excluida por etiqueta 'noindex'". Uno es un problema de señal de calidad; el otro es un desastre de configuración. He visto desarrolladores tratar ambos idénticamente y perder semanas persiguiendo lo equivocado.
Las razones que veo con más frecuencia en sitios grandes
- Rastreada -- actualmente no indexada: Google visitó la página pero decidió que no valía la pena indexarla. Normalmente contenido delgado, casi duplicados, o páginas que no generan backlinks o enlaces internos.: Google visited the page but decided it wasn't worth indexing. Usually thin content, near-duplicates, or pages that don't earn backlinks or internal links.
- Descubierta -- actualmente no indexada: Google encontró la URL (probablemente en tu sitemap) pero aún no se ha molestado en rastrearla. Este es un problema de presupuesto de rastreo, no un problema de contenido.: Google found the URL (likely in your sitemap) but hasn't bothered to crawl it yet. This is a crawl budget problem, not a content problem.
- Excluida por etiqueta 'noindex': Alguien -- posiblemente tú, posiblemente un plugin -- añadió una directiva noindex. Más sobre esto abajo.: Someone -- possibly you, possibly a plugin -- added a noindex directive. More on this below.
- Duplicada, Google eligió un canonical diferente: Tus etiquetas canonical apuntan a algo inesperado, o Google las está anulando.: Your canonical tags are pointing somewhere unexpected, or Google is overriding them.
- Página con redirección: Una página que debería ser indexable está redirigiendo a algún lugar, correcta o incorrectamente.: A page that should be indexable is redirecting somewhere, either correctly or incorrectly.
No solo mires los totales. Descarga la lista completa para cada código de razón como CSV. En un sitio de 40,000 páginas, necesitas poder ordenar y filtrar.
---
El Presupuesto de Rastreo Es Real y Destruirá Sitios Grandes
En 2019, Seahawk estaba trabajando con un cliente de comercio electrónico grande -- unos 28,000 páginas de productos -- y no podíamos averiguar por qué Google solo estaba rastreando alrededor de 3,000 páginas por día. El sitio era rápido. El sitemap estaba limpio. Todo se veía bien en la superficie.
Resultó que el sitio estaba generando miles de URLs de navegación facetada -- ?colour=red&size=large&sort=price -- que eran rastreables, no estaban canonicalizadas correctamente, y consumían el presupuesto de rastreo de Googlebot antes de que llegara a las páginas de producto reales.?colour=red&size=large&sort=price -- that were crawlable, not canonicalised properly, and eating through Googlebot's crawl allowance before it ever reached the real product pages.
El presupuesto de rastreo es esencialmente la cantidad de URLs que Googlebot está dispuesto a rastrear en tu sitio dentro de un período de tiempo determinado. La documentación de Google sobre presupuesto de rastreo realmente vale la pena leer -- son honestos sobre cómo funciona. En resumen: si lo desperdicias en URLs basura, las páginas importantes no se rastreamn.Google's own documentation on crawl budget is genuinely worth reading -- they're honest about how it works. The short version: if you're wasting it on garbage URLs, the important pages don't get crawled.
Cómo Auditar Realmente el Presupuesto de Rastreo
- Obtén los registros de tu servidor. No las estadísticas de rastreo de Google -- registros reales del servidor. Herramientas como Screaming Frog Log File Analyser te permiten filtrar únicamente por accesos de Googlebot.Screaming Frog Log File Analyser let you filter purely for Googlebot hits.
- Observa qué porcentaje de las visitas de Googlebot caen en URLs que realmente te importan. Si está por debajo del 60%, tienes un problema de presupuesto.
- Encuentra los patrones de URL que están consumiendo la mayoría de rastreos. Ordena por frecuencia. Los principales culpables son casi siempre: navegación facetada, paginación en archivos paginados, parámetros de ID de sesión, y páginas de archivo de categoría/etiqueta vacías.
- Arregla la fuente, no solo el síntoma. Desallows en robots.txt para parámetros que nunca deberían rastrearse. Etiquetas canónicas para todo lo demás.
robots.txtfor parameters that should never be crawled. Canonical tags for everything else.
En ese proyecto de e-commerce, bloqueamos las URLs facetadas mediante robots.txt y agregamos rel="canonical" a todas las vistas filtradas. En seis semanas, las páginas indexadas pasaron de 8,000 a 24,000. Mismo contenido. Solo Googlebot finalmente llegando a él.robots.txt and added rel="canonical" to all filtered views. Within six weeks, indexed pages went from 8,000 to 24,000. Same content. Just Googlebot finally reaching it.
---
El desastre noindex (Sucede más de lo que crees)
Necesito hablar de esto porque yo mismo lo he causado. No fue mi mejor momento. Durante una migración de staging a producción para un sitio de noticias allá en 2021, olvidamos desmarcar "Desalentar a los motores de búsqueda de indexar este sitio" en WordPress Configuración → Lectura. El sitio salió a producción con noindex en todo el sitio. Pasaron once días antes de que el cliente notara que el tráfico orgánico se había desplomado.
WordPress esconde esa casilla en un lugar que nadie espera. Y ciertos plugins de SEO -- Yoast, Rank Math, incluso AIOSEO -- tienen sus propios interruptores de noindex en el nivel de tipo de contenido, en el nivel de taxonomía, y en el nivel de página individual. Cualquiera de ellos puede poner silenciosamente noindex en grandes secciones de tu sitio.
Cómo verificar noindex a escala
Ejecuta Screaming Frog en el sitio completo y filtra por páginas que retornan una directiva noindex. Exporta la lista. Luego haz una referencia cruzada contra tus grupos de URL importantes -- páginas de producto, páginas de servicio, posts del blog, lo que sea que importe al negocio.noindex directive. Export the list. Then cross-reference against your important URL groups -- product pages, service pages, blog posts, whatever matters to the business.
También verifica tu robots.txt en tudominio.com/robots.txt. Busca reglas Disallow: demasiado amplias. He visto reglas como Disallow: /wp-content/ que bloquean CSS y JS que Google necesita para renderizar páginas correctamente -- lo que puede causar fallos de renderizado que parecen problemas de indexación pero en realidad son Googlebot viendo una página rota.robots.txt at yourdomain.com/robots.txt. Look for overly broad Disallow: rules. I've seen rules like Disallow: /wp-content/ blocking CSS and JS that Google needs to render pages properly -- which can cause rendering failures that look like indexation problems but are actually Googlebot seeing a broken page.
---
Etiquetas Canonical que se están disparando silenciosamente
Los canonicals son el asesino de indexación más sigiloso en sitios WordPress grandes. Porque se ven correctos en aislamiento y solo revelan su daño a escala.
Aquí hay un patrón que veo constantemente: un sitio con WooCommerce tiene productos accesibles a través de múltiples rutas de URL -- /product/red-shoes/, /product-category/footwear/red-shoes/, y a veces /shop/red-shoes/. Cada una tiene una etiqueta canónica, pero si esas canónicas apuntan a URLs ligeramente diferentes (HTTP vs HTTPS, barra diagonal final vs sin barra diagonal, www vs sin www), Google las trata como señales que apuntan a páginas diferentes y se niega a consolidarlas./product/red-shoes/, /product-category/footwear/red-shoes/, and sometimes /shop/red-shoes/. Each one has a canonical tag, but if those canonicals point to slightly different URLs (HTTP vs HTTPS, trailing slash vs no trailing slash, www vs non-www), Google treats them as signals pointing to different pages and refuses to consolidate.
La solución es aburrida pero necesaria:
- Audita cada estructura de URL que tu instalación de WordPress genera. Usa el rastreo de sitio de Screaming Frog → filtra por "Canonical" → exporta.
- Busca desajustes en protocolos, barras diagonales finales y variaciones de subdominio.
- Asegúrate de que tu canónica siempre coincida exactamente con tu URL preferida, carácter por carácter.
Rank Math y Yoast generan etiquetas canónicas automáticamente, pero ninguno de los dos plugins sabe sobre tus redirecciones de .htaccess o la normalización de URLs de tu CDN. Tienes que verificar la canónica renderizada, no solo lo que el plugin cree que está generando. Descarga la página con una herramienta como httpstatus.io e inspecciona los encabezados de respuesta y el HTML reales..htaccess redirects or your CDN's URL normalisation. You have to verify the rendered canonical, not just what the plugin thinks it's outputting. Fetch the page with a tool like httpstatus.io and inspect the actual response headers and HTML.
---
Los Sitemaps XML Suelen Estar Mal en Sitios Grandes
La mayoría de los plugins de SEO para WordPress generan mapas del sitio automáticamente. La mayoría de ellos también incluyen URLs que no deseas en tu mapa del sitio -- páginas paginadas (/page/2/, /page/3/), archivos de autor, páginas de etiqueta con dos posts, páginas de adjuntos./page/2/, /page/3/), author archives, tag pages with two posts on them, attachment pages.
Un sitemap debe ser una lista corta de tus mejores páginas más canónicas. No un volcado de cada URL que WordPress haya generado alguna vez.
Reglas de Higiene de Sitemap que Realmente Sigo
- Excluye páginas de archivo paginadas. Siempre.
- Excluye páginas de archivo de autor a menos que sea un sitio multiautor donde las páginas de autor tengan valor de contenido genuino.
- Excluye archivos de etiquetas a menos que las etiquetas estén editorialmentegestionadas y tengan contenido significativo.
- Establece un umbral de cantidad de posts -- generalmente excluyo cualquier página de archivo con menos de cinco posts.
- Divide sitemaps grandes en índices de sitemap. Mantén archivos de sitemap individuales por debajo de 10MB y por debajo de 50,000 URLs. Google ha documentado límites aquí.documented limits here.
En el sitio de listados de propiedades del inicio de este post, el mapa del sitio tenía 41,000 URLs incluyendo cada archivo de etiqueta, cada página paginada, y -- esto todavía me duele decirlo -- la página de login de WordPress. Límpialo primero. Siempre.
---
Los Enlaces Internos Son un Tema de Indexación
Las personas no piensan en los enlaces internos como una herramienta de indexación. Deberían.
Si una página no tiene enlaces internos que apunten hacia ella, es posible que Googlebot nunca la encuentre en primer lugar, incluso si está en tu sitemap. Los sitemaps le dicen a Google que una URL existe. Los enlaces internos le dicen a Google que una URL importa. Esas son señales diferentes.matters. Those are different signals.
En sitios grandes de contenido, las páginas huérfanas son frecuentes. Un artículo de blog publicado hace tres años, enlazado desde el archivo de posts pero nunca enlazado desde ningún otro post, verá su frecuencia de rastreo caer a casi nada con el tiempo.
Uso el reporte "Orphan Pages" de Screaming Frog (bajo Site Structure) para identificar páginas en el sitemap que tienen cero enlaces internos apuntando hacia ellas. Luego reviso el contenido para encontrar lugares lógicos donde agregar enlaces. No enlaces forzados, sino enlaces realmente relevantes. Lleva tiempo pero el impacto en la indexación es real.
---
Una Lista de Verificación de Diagnóstico Sistemático
Si le estuviera pasando esto a un desarrollador junior en Seahawk, así es el orden en el que le haría trabajar:
- Abre Google Search Console → reporte Pages → descarga todas las URLs no indexadas con códigos de razón.
- Revisa robots.txt para disallows amplios accidentales.
robots.txtfor accidental broad disallows. - Verifica que la casilla "Discourage search engines" de WordPress esté desactivada.
- Ejecuta Screaming Frog y filtra por directivas noindex a nivel de página.
- Revisa las etiquetas canónicas en el output renderizado, no en la configuración del plugin.
- Extrae los registros del servidor y revisa la distribución de rastreo de Googlebot entre tipos de URL.
- Audita el sitemap XML en busca de URLs innecesarias (paginación, archivos vacíos, variantes no canónicas).
- Ejecuta el reporte de Páginas Huérfanas e identifica páginas sin enlaces internos.
- Busca navegación facetada o URLs basadas en parámetros que generen rutas duplicadas rastreables.
- Verifica la velocidad de la página. Las páginas que se agotan consistentemente reciben menor prioridad de Googlebot.
No intentes arreglarlo todo de una vez. Soluciona una categoría de problemas, espera tres o cuatro semanas a que Google vuelva a rastrear, mide, y luego pasa al siguiente. Si cambias todo simultáneamente nunca sabrás qué fue lo que realmente funcionó.
---
FAQ
¿Por qué se indexan páginas una semana y luego desaparecen la siguiente?
El índice de Google no es estático. Constantemente reevalúa páginas basándose en señales de calidad, frescura y eficiencia de rastreo. Una página que fue indexada hace seis meses puede ser eliminada si no ha ganado ningún enlace, no está siendo enlazada internamente, o si la evaluación de calidad de Google sobre tu dominio ha cambiado. Esto es especialmente común después de una migración de sitio o una revisión de contenido significativa. Google rastreará nuevamente, reevaluará, y a veces decide que páginas indexadas previamente ya no cumplen con los estándares.
¿Afecta la velocidad del sitio a la indexación?
Sí, más directamente de lo que la mayoría de las personas se dan cuenta. Si las páginas responden lentamente, consistentemente por más de 2-3 segundos para la respuesta inicial del servidor, Googlebot les dará menor prioridad de rastreo. A escala, esto significa que las páginas lentas simplemente no son rastreadas con la frecuencia suficiente para mantenerse indexadas. Arregla tu Time to First Byte (TTFB) antes de preocuparte por cualquier otra cosa relacionada con velocidad. Un plugin de caché económico como WP Rocket hace una diferencia medible. Core Web Vitals importan para los rankings, pero TTFB importa para el rastreo.Core Web Vitals matter for rankings, but TTFB matters for crawling.
¿Pueden demasiadas páginas en un sitemap perjudicar la indexación?
No directamente, pero un sitemap hinchado con URLs de baja calidad diluye la señal que le envías a Google sobre qué importa. Si tu sitemap contiene 40,000 URLs y 30,000 de ellas son páginas de archivo delgadas, Google aprende a tratar tu sitemap como ruido. Mantén los sitemaps compactos y de alta calidad. Piénsalo como una curaduría editorial, no como un inventario de URLs.
¿Debería usar la herramienta de Inspección de URL de Google para solicitar indexación manualmente?
Para páginas individuales importantes, sí, absolutamente. Pero no intentes solicitar manualmente la indexación de miles de URLs. No escala y Google ha dicho que no da un trato especial a las URLs solicitadas manualmente a largo plazo. Arregla los problemas subyacentes de rastreo y calidad y deja que el rastreo natural de Google haga el trabajo. Usa la inspección manual para verificar que páginas específicas puedan ser indexadas, no para forzar la indexación de todo.can be indexed, not to force index everything.
---
La verdad honesta es que el diagnóstico de indexación no es un trabajo glamoroso. Son hojas de cálculo, archivos de logs, y mucha espera. Pero en un sitio grande, incluso recuperar el 20% de las páginas indexadas perdidas puede significar un salto significativo en el tráfico orgánico. Y en una propiedad de listados de 40,000 páginas, eso es dinero real. Consigue lo básico bien antes de perseguir cualquier cosa exótica. Casi nunca es exótico.