Mapa del sitio de WordPress no se indexa: causas comunes y soluciones

Qué significa realmente “el sitemap no se indexa”

La gente dice “mi sitemap no se indexa” cuando quiere decir una de cuatro cosas:

• Google no puede obtener el sitemap (red, DNS, TLS, autenticación, robots, WAF, 4xx/5xx, bucles de redirección).
• Google lo obtiene pero no puede parsearlo (content-type incorrecto, HTML en lugar de XML, XML corrupto, problemas con gzip, archivos enormes, fechas inválidas, URLs inválidas).
• Google lo parsea pero ignora las URLs (bloqueadas por robots, noindex, discordancia de canonical, soft 404, duplicados, baja calidad, señales de spam).
• Google indexa algunas URLs pero no otras (presupuesto de rastreo, URLs facetadas, enlazado interno pobre, contenido escaso, proliferación de parámetros).

Un sitemap no garantiza indexación. Es una pista. Una buena pista ayuda al descubrimiento y la priorización; una pista mala es ruido que se relega. Tu trabajo es hacerla obtenible, parseable y confiable.

Una realidad operativa: Search Console “Enviado” o incluso “Éxito” no es una prueba de aprobado/rehazado. Es el estado de un paso en una tubería de múltiples pasos. Trátalo como un HTTP 200 desde un reverse proxy: agradable, pero no prueba de que la aplicación funcione.

Hechos y contexto histórico (por qué esto es más difícil de lo que parece)

• Los sitemaps son relativamente nuevos. El protocolo XML Sitemaps se introdujo en 2005; antes de eso, el descubrimiento era mayormente enlaces y suerte.
• Los buscadores tratan los sitemaps como pistas, no como órdenes. Ese lastmod que pones es consultivo; si parece poco fiable, se le resta valor.
• Google ha soportado archivos índice de sitemap durante años porque un solo sitemap tiene límite (normalmente 50.000 URLs y ~50MB sin comprimir). Los sitios grandes deben dividirse.
• WordPress no incluyó un sitemap nativo hasta WordPress 5.5 (2020). Antes de eso, los plugins dominaban —y algunos aún confligen con el comportamiento del core.
• Robots.txt es anterior a los sitemaps por más de una década. Viene de mediados de los 90 y sigue arruinando SEO moderno cuando alguien copia un bloqueo “temporal” a producción.
• Las etiquetas canónicas cambiaron las reglas. Si la URL del sitemap difiere de tu canonical, Google suele confiar en el canonical e ignorar la entrada del sitemap.
• Los CDN se volvieron infraestructura por defecto. Geniales para latencia. También geniales para cachear lo incorrecto para siempre si los dejas.
• Los errores en migraciones a HTTPS son persistentes. Mezclar http/https en sitemaps sigue siendo uno de los fallos más comunes que “a los humanos les parece bien”.
• WAFs y mitigación de bots son ahora comunes. Muchas políticas de “seguridad” desafían a Googlebot con JS/CAPTCHA —luego te preguntas por qué el descubrimiento colapsa.

Guía de diagnóstico rápido (primero/segundo/tercero)

Primero: confirma qué intenta obtener Google

1. En Search Console, verifica la URL exacta del sitemap que enviaste (http vs https, www vs apex, barra final, ruta).
2. Revisa el estado de obtención del sitemap y “Última lectura”. Si “No se pudo obtener”, deja de teorizar y empieza a hacer HTTP.
3. Elige una URL del sitemap que debería indexarse. Inspecciónala en Search Console (Inspección de URL) y anota: “Crawled as”, “¿Indexación permitida?”, “Canonical declarado por el usuario”, “Canonical seleccionado por Google”.

Segundo: reproduce desde fuera con curl

1. Obtén el sitemap con curl y sigue redirecciones. Verifica código de estado, content-type y el inicio del body.
2. Verifica que sea XML (o XML gzipped), no HTML, no una página de login, no una página de error cacheada.
3. Valida que la cadena de redirecciones sea corta y estable (1–2 saltos como máximo).

Tercero: traza la falla dentro de tu stack

1. Revisa logs del servidor para intentos de obtención por Googlebot y respuestas (códigos de estado, bytes, user agent, ubicación del edge si estás detrás de un CDN).
2. Revisa robots.txt, meta robots y cabeceras HTTP (X-Robots-Tag).
3. Revisa conflictos de plugins (sitemap del core vs Yoast/Rank Math) y capas de caché que devuelven variantes erróneas.

Si haces estas tres fases en ese orden, normalmente encontrarás el cuello de botella en menos de 20 minutos. Si te saltas a “reinstalar plugin SEO”, solo estarás reiniciando la impresora.

Modos de fallo que bloquean la indexación del sitemap

1) La URL del sitemap está “bien” en tu cabeza, mal en la realidad

WordPress puede exponer múltiples endpoints de sitemap según el core y los plugins:

• Core: /wp-sitemap.xml (y índices relacionados).
• Yoast: /sitemap_index.xml
• Rank Math: /sitemap_index.xml (misma ruta, generador distinto)

Problema común: envías /wp-sitemap.xml pero un plugin desactiva el core y sirve otra cosa, o tu reverse proxy reescribe la ruta y devuelve una página de error HTML con 200. Google no “lo averigua”. Simplemente falla o ignora.

2) Robots.txt bloquea el sitemap o las URLs dentro de él

Bloquear la obtención del sitemap es obvio. Bloquear las URLs listadas en el sitemap es más sutil: el sitemap puede obtenerse y parsearse, pero ninguna de sus URLs es elegible para rastreo.

3) Noindex, X-Robots-Tag o una cabecera de seguridad cierran la puerta

Los sitios WordPress suelen acumular noindex en tres lugares:

• Meta tag en HTML (<meta name="robots" content="noindex">), a menudo activado por “Disuadir a los motores de búsqueda” o un toggle de un plugin SEO.
• Cabecera HTTP (X-Robots-Tag: noindex), normalmente establecida por reglas de nginx/Apache o un plugin de seguridad.
• Directivas de robots en robots.txt que desautorizan el rastreo.

4) Discordancia de canonical y variantes duplicadas de URL

Si tu sitemap lista http://example.com/page pero la página tiene canonical a https://www.example.com/page/, Google a menudo tratará la entrada del sitemap como una pista de baja calidad. Multiplica eso por miles y el sitemap se vuelve ruido de fondo.

5) El sitemap devuelve HTML (o JSON) en lugar de XML

Ocurre por caché, desafíos del WAF, “modo mantenimiento” o páginas forzadas de login. Tu navegador puede renderizar algo que parece plausible; Googlebot ve una variante distinta. Si tu CDN hace variación por dispositivo o por bot, enhorabuena: construiste un split-brain.

6) 200 OK con payload de error (fallos suaves)

Operativamente, el peor bug es 200 OK con un body que dice “Error”. Algunos plugins y themes lo hacen. Algunos reverse proxies lo hacen cuando el upstream está caído y se sirve una página en caché obsoleta. Google parseará basura y seguirá adelante.

7) Cadenas de redirección, bucles y normalizaciones “útiles”

Tres redirecciones no son una estrategia. Las cadenas largas desperdician presupuesto de rastreo y a veces rompen la obtención. Los bucles de redirección son obvios y aún así pasan porque alguien “arregló” www→apex y apex→www en capas distintas.

8) Errores de servidor y limitación de tasa

Googlebot es educado, pero retrocede cuando le devuelves 429s o 5xx inconsistentes. Si la obtención del sitemap devuelve 503 en picos, Search Console mostrará fallos intermitentes. Eso se traduce en descubrimiento retrasado, y “descubrimiento retrasado” se convierte en “no se indexa” en lenguaje ejecutivo.

9) Sitemaps grandes y generación lenta

Generar sitemaps dinámicos puede ser costoso en WordPress. Si generar /sitemap_index.xml dispara consultas pesadas y caduca detrás del proxy, verás salida parcial, XML truncado o 504s. Dividir sitemaps ayuda, pero almacenar en caché y pre-generar ayuda más.

10) Mala higiene de lastmod (erosión de confianza)

Si cada URL muestra la misma marca de tiempo lastmod, cada día, eternamente, Google aprenderá que no tiene sentido. Si tu sitemap siempre afirma “todo cambió”, Google lo tratará como el chico que gritaba deploy.

Idea parafraseada de Werner Vogels: Todo falla todo el tiempo; construye sistemas que toleren fallos y se recuperen rápido. Se aplica también a la plomería del SEO: diseña para corrección, observabilidad y degradación elegante.

Broma corta #1: Un sitemap que “se indexa a sí mismo” es como un buscapersonas que confirma sus propias alertas—reconfortante, pero inútil.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estas tareas asumen que tienes acceso a una máquina con shell que pueda alcanzar tu sitio (un bastión, un runner de CI o incluso tu servidor web). Sustituye example.com por tu dominio. El punto no es el comando exacto; es la decisión que tomes a partir de la salida.

Task 1: Fetch the sitemap and verify status, redirects, and content-type

cr0x@server:~$ curl -sSIL -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://example.com/sitemap_index.xml
HTTP/2 301
location: https://www.example.com/sitemap_index.xml

HTTP/2 200
content-type: application/xml; charset=UTF-8
cache-control: max-age=300

Qué significa: Una redirección al host canónico, luego 200 con content-type XML. Eso es sano.

Decisión: Si ves 403/503/429, arregla edge/WAF/límites de tasa primero. Si content-type es text/html, busca la capa que devuelve HTML.

Task 2: Confirm the body is actually XML (not a login page)

cr0x@server:~$ curl -sS -A "Googlebot" https://www.example.com/sitemap_index.xml | head -n 5


  
    https://www.example.com/post-sitemap.xml

Qué significa: Comienza con la declaración XML y un nodo sitemapindex. Bien.

Decisión: Si ves HTML (<!doctype html>) o una página “Por favor active cookies”, tu WAF/CDN está sirviendo la variante equivocada a bots.

Task 3: Validate sitemap XML well-formedness quickly

cr0x@server:~$ curl -sS https://www.example.com/post-sitemap.xml | xmllint --noout -
cr0x@server:~$ echo $?
0

Qué significa: Código de salida 0 indica que el XML está bien formado.

Decisión: Si es distinto de cero, el XML está roto. Arregla la generación (plugin/theme), la truncación (timeouts) o la compresión (gzip doble) antes de cualquier otra cosa.

Task 4: Check for accidental noindex via HTTP headers

cr0x@server:~$ curl -sSI https://www.example.com/ | egrep -i "x-robots-tag|location|content-type"
content-type: text/html; charset=UTF-8
x-robots-tag: noindex, nofollow

Qué significa: Todo tu sitio está siendo noindexado a nivel de cabecera.

Decisión: Elimina o delimita esa cabecera. Si proviene de nginx/Apache, ajusta la configuración. Si viene de un plugin de seguridad, desactiva esa función o haz whitelist.

Task 5: Check robots.txt fetch and contents (including sitemap directive)

cr0x@server:~$ curl -sS https://www.example.com/robots.txt
User-agent: *
Disallow: /wp-admin/
Disallow: /
Sitemap: https://www.example.com/sitemap_index.xml

Qué significa: Disallow: / bloquea todo. La directiva sitemap no la sobreescribe.

Decisión: Elimina el disallow global (a menos que realmente quieras ocultar el sitio). Si es staging, no copies el robots.txt de staging a producción.

Task 6: Check the sitemap URLs for mixed host/protocol and redirects

cr0x@server:~$ curl -sS https://www.example.com/post-sitemap.xml | grep -Eo "[^<]+" | head
http://example.com/hello-world/
http://example.com/about/
http://example.com/contact/

Qué significa: El sitemap emite http y dominio apex, no tu canónico https://www.

Decisión: Corrige los ajustes de Site URL/Home URL de WordPress, la configuración de plugins y cualquier filtro hardcodeado. Luego vuelve a enviar el sitemap. No confíes en redirecciones como “arreglo”.

Task 7: Sample a URL from the sitemap and verify canonical and robots meta

cr0x@server:~$ curl -sS https://www.example.com/hello-world/ | egrep -i "

Qué significa: El canonical coincide con la URL y es indexable.

Decisión: Si el canonical apunta a otro sitio o la meta robots muestra noindex, corrige la plantilla/reglas del plugin SEO. Si es intencional (archivos de etiquetas, búsqueda interna), elimina esas URLs del sitemap.

Task 8: Detect if the sitemap is being gzipped or double-compressed

cr0x@server:~$ curl -sSI -H "Accept-Encoding: gzip" https://www.example.com/post-sitemap.xml | egrep -i "content-encoding|content-type"
content-type: application/xml; charset=UTF-8
content-encoding: gzip

Qué significa: Gzip está activo; eso está bien.

Decisión: Si ves contenido gzipped pero el body no es realmente gzip (o es gzip dentro de gzip), corrige la compresión de servidor/CDN. Googlebot es paciente, no psíquico.

Task 9: Confirm the sitemap is not blocked by basic auth or IP allowlists

cr0x@server:~$ curl -sSIL https://www.example.com/sitemap_index.xml | head
HTTP/2 401
www-authenticate: Basic realm="Restricted"

Qué significa: El sitemap está detrás de autenticación. Google no puede obtenerlo.

Decisión: Quita la autenticación de rutas públicas o protege solo áreas de administración. Si es un entorno staging, no envíes su sitemap.

Task 10: Check nginx access logs for Googlebot sitemap fetches and status codes

cr0x@server:~$ sudo grep -E "Googlebot|sitemap" /var/log/nginx/access.log | tail -n 5
203.0.113.10 - - [27/Dec/2025:10:21:12 +0000] "GET /sitemap_index.xml HTTP/2.0" 200 1249 "-" "Googlebot/2.1"
203.0.113.10 - - [27/Dec/2025:10:21:13 +0000] "GET /post-sitemap.xml HTTP/2.0" 503 182 "-" "Googlebot/2.1"

Qué significa: El índice fue obtenido, pero un sitemap hijo falla intermitentemente con 503.

Decisión: Arregla la estabilidad del origen para sitemaps hijos (timeouts, saturación de PHP-FPM, base de datos). Google tratará hosts de sitemap inestables como poco fiables.

Task 11: Look for PHP-FPM saturation that causes intermittent 504/503

cr0x@server:~$ sudo tail -n 8 /var/log/php8.2-fpm.log
[27-Dec-2025 10:21:13] WARNING: [pool www] server reached pm.max_children setting (20), consider raising it
[27-Dec-2025 10:21:13] WARNING: [pool www] child 1942 said into stderr: "script_filename = /var/www/html/index.php"

Qué significa: Tu pool de PHP está al máximo. La generación del sitemap puede colapsarlo durante rastreos.

Decisión: Añade caché para endpoints de sitemap, aumenta capacidad con cuidado, o reduce consultas DB caras. No subas pm.max_children sin cálculo de memoria.

Task 12: Verify WordPress “Discourage search engines” setting via wp-cli

cr0x@server:~$ cd /var/www/html
cr0x@server:~$ wp option get blog_public
0

Qué significa: WordPress está configurado para disuadir a motores de búsqueda (a menudo pone noindex vía plugins/themes o afecta la salida de robots).

Decisión: Ponlo a 1 en producción y confirma las cabeceras/meta/robots reales.

cr0x@server:~$ wp option update blog_public 1
Success: Updated 'blog_public' option.

Task 13: Confirm which sitemap generator is active (plugin conflicts)

cr0x@server:~$ wp plugin list --status=active
+--------------------+--------+-----------+---------+
| name               | status | update    | version |
+--------------------+--------+-----------+---------+
| wordpress-seo      | active | none      | 22.5    |
| rank-math          | active | available | 1.0.225 |
| wp-super-cache     | active | none      | 1.12.3  |
+--------------------+--------+-----------+---------+

Qué significa: Dos plugins SEO activos. Así se obtienen canonicals enfrentados, sitemaps en conflicto y culpas cruzadas.

Decisión: Elige un plugin SEO. Desactiva el otro. Luego confirma el endpoint del sitemap y el comportamiento de los canonicals otra vez.

Task 14: Verify that the sitemap isn’t cached incorrectly by your CDN

cr0x@server:~$ curl -sSI https://www.example.com/sitemap_index.xml | egrep -i "cf-cache-status|age|via|x-cache"
cf-cache-status: HIT
age: 86400

Qué significa: El CDN sirve un sitemap en caché de un día. Puede estar bien—salvo que haya cacheado una página de error o contenido obsoleto tras una migración.

Decisión: Purga las URLs del sitemap, establece un TTL sensato y considera excepciones “Cache Everything”. Los sitemaps pueden cachearse, pero no deben estar permanentemente equivocados.

Task 15: Check database performance impact if sitemaps are dynamic

cr0x@server:~$ mysql -NBe "SHOW FULL PROCESSLIST" | head
12345	root	localhost	wp	Query	2	Sending data	SELECT ID, post_title FROM wp_posts WHERE post_status='publish' ORDER BY post_modified DESC LIMIT 50000

Qué significa: La generación del sitemap puede estar haciendo consultas pesadas. En bases compartidas, compite con cargas de página.

Decisión: Cachea la salida del sitemap, pre-genera o ajusta consultas/índices. Si el endpoint del sitemap es “lento”, Googlebot lo aprenderá y volverá con menos frecuencia.

Tres micro-historias corporativas desde el terreno

Micro-historia 1: El incidente causado por una suposición equivocada

Migraron un sitio de marketing WordPress detrás de un CDN y un flamante WAF. El equipo supuso: “Si la homepage funciona en un navegador, Google puede rastrearla.” Esa suposición pertenece a un museo junto a Netscape.

Search Console empezó a mostrar errores de obtención del sitemap. La responsable de SEO escaló, el equipo de plataforma se encogió de hombros y todos se señalaron entre sí. La URL del sitemap devolvía 200 y parecía correcta—en un navegador normal. Al obtenerla con un user agent de bot, el WAF servía una página de desafío JavaScript. Seguía siendo 200. Seguía “bien” para cualquiera que no la parseara como XML.

La solución fue vergonzosamente simple: una regla del WAF para permitir a crawlers verificados obtener endpoints de sitemap y rutas clave sin desafíos. El trabajo real fue construir la disciplina: tests curl en CI, una comprobación sintética de “bot fetch” y una política que diga “los controles de seguridad deben ser observables”.

Después del cambio, la indexación se recuperó lentamente en días. Ese retraso causó más drama que la propia interrupción. Pero así funciona: el rastreo es eventualmente consistente y la tubería tiene backoff. Si tu organización no tolera gratificación retrasada, no rompas el descubrimiento.

Micro-historia 2: La optimización que salió mal

Otra compañía intentó acelerar todo cacheando a tope en el edge. Regla del CDN: cachear HTML 24 horas, ignorar query strings y “optimizar” contenido. El sitio se sentía rápido. Los dashboards se pusieron verdes. Todos celebraron y se fueron a casa temprano.

Luego lanzaron una nueva línea de producto y actualizaron cientos de páginas. Internamente, las páginas estaban actualizadas. Externamente, Googlebot veía contenido viejo. El sitemap se actualizó en origen, pero el CDN seguía sirviendo un índice de sitemap en caché con valores lastmod obsoletos—y a veces una respuesta 503 cacheada que el origen había devuelto durante un deploy.

Search Console reportó rarezas: “El sitemap se puede leer, pero tiene errores,” y las URLs quedaron “Descubiertas – actualmente no indexadas” más tiempo de lo normal. El equipo intentó “forzar indexación” re-enviando, lo que no sirvió porque la obtención seguía golpeando el objeto edge obsoleto.

La solución: definir comportamiento de caché explícito para endpoints de sitemap (TTL corto, sin transformaciones, clave de caché incluye host y purga en deploy). También dejaron de actualizar automáticamente lastmod para páginas sin cambios porque habían entrenado a Google a ignorarlo. El sitio perdió un poco en “perfect score” en Lighthouse. La indexación se volvió mucho más predecible. Hay que elegir batallas.

Micro-historia 3: La práctica aburrida pero correcta que salvó el día

En una gran empresa, WordPress era solo una de muchas plataformas. Tenían una política sosa: cada hostname público debe tener un “manual de rastreabilidad” estándar y una comprobación automática semanal que valida robots, sitemap y unas pocas páginas canónicas. Sin excepciones. Sin heroísmos.

Un viernes, un cambio de DNS pensado para staging se filtró a producción: el dominio apex empezó a redirigir a un host de mantenimiento para un subconjunto de usuarios. Los navegadores a veces funcionaban gracias a HSTS en caché y rutas felices. Googlebot, sin embargo, siguió redirecciones como si le pagaran por salto y acabó en una página 404 con estado 200 (porque claro que sí).

La comprobación automática lo detectó en minutos. No porque fuera ingeniosa—porque era rutinaria: curl fetch, validar XML, verificar canonical, alertar si no es content-type XML. El on-call tuvo un diff claro de lo que cambió y revirtió el DNS antes de que la tubería de rastreo hiciera backoff completo.

No pasó nada dramático. Y ese es el punto. El mejor incidente SEO es el que no llega a reunión.

Broma corta #2: Lo único más optimista que un sitemap es el plan de proyecto que dice “indexación: 2 días.”

Errores comunes: síntoma → causa raíz → solución

“No se pudo obtener” en Search Console

• Síntoma: Search Console muestra “No se pudo obtener” o “Fallo de obtención”.
• Causa raíz: 401/403 por WAF, autenticación, bloqueos geográficos o listas de permitidos por IP; 5xx por inestabilidad del origen; problemas DNS/TLS.
• Solución: Reproduce con curl usando UA de Googlebot; revisa logs de acceso; haz whitelist del tráfico de bots para endpoints de sitemap; estabiliza el origen y quita autenticación de rutas públicas.

“El sitemap es HTML” o “Formato inválido”

• Síntoma: Search Console se queja del formato o reporta errores de parseo.
• Causa raíz: CDN/WAF devuelve un desafío HTML, página de login o mantenimiento; timeout de PHP trunca el XML.
• Solución: Asegura content-type: application/xml; evita transformaciones para rutas de sitemap; añade caché para la generación; aumenta timeouts upstream solo si además arreglas la lentitud.

“Éxito” pero las URLs no se indexan

• Síntoma: Estado del sitemap “Éxito”, pero cobertura muestra “Descubierto – actualmente no indexado” o “Rastreado – actualmente no indexado”.
• Causa raíz: URLs bloqueadas por robots/noindex; discordancia de canonicals; contenido fino/duplicado; enlazado interno débil; demasiadas URLs de bajo valor.
• Solución: Elige URLs representativas e inspéctalas; elimina noindex y corrige canonicals; poda sitemaps para incluir solo URLs con valor de indexación; mejora enlazado interno hacia páginas valiosas.

Sólo funcionan algunos sitemaps (archivo índice ok, sitemaps hijos fallan)

• Síntoma: El índice de sitemap se obtiene, pero un sitemap hijo falla intermitentemente o devuelve 5xx.
• Causa raíz: Generación dinámica pesada; PHP-FPM saturado; DB lenta; caché inconsistente; limitación de tasa.
• Solución: Cachea la salida de sitemaps hijos; pre-genera; divide por tipo de post/fecha; ajusta PHP-FPM y la BD; añade monitorización en endpoints de sitemap.

La indexación colapsó tras migración HTTPS o de dominio

• Síntoma: URLs desaparecen; Search Console muestra problemas de duplicado y canonical alternativo.
• Causa raíz: Mezcla de http/https y variantes www/apex en el sitemap; canonicals antiguos; bucles de redirección; normalización de host inconsistente entre CDN y origen.
• Solución: Define un host/protocolo canónico; actualiza ajustes de WordPress; regenera sitemaps; mantiene redirecciones simples y coherentes en una sola capa; audita etiquetas canonical.

Masivo “Excluido por etiqueta ‘noindex’”

• Síntoma: La cobertura muestra muchas URLs excluidas por noindex.
• Causa raíz: Toggle “Disuadir a motores de búsqueda” activado; plantillas de plugin SEO aplican noindex a posts; cabecera HTTP X-Robots-Tag configurada de forma amplia.
• Solución: Confirma con curl; arregla en la capa más específica responsable; luego elimina noindex del sitemap (no listes lo que te niegas a indexar).

“La URL enviada parece un Soft 404”

• Síntoma: Google trata páginas como soft 404 aunque devuelvan 200.
• Causa raíz: Contenido escaso, plantillas “sin resultados”, contenido bloqueado a bots o páginas de error que devuelven 200.
• Solución: Devuelve 404/410 adecuados para contenido inexistente; evita cloaking; mejora contenido real y enlazado interno; elimina URLs basura de sitemaps.

Listas de verificación / plan paso a paso

Paso a paso: hacer el sitemap obtenible y confiable

1. Elige un generador de sitemap. Core o un plugin. Desactiva el resto. Los conflictos no son “redundancia”.
2. Fija tu host/protocolo canónico. Decide https y www o apex. Aplícalo con una única regla de redirección en el edge u origen (no ambos peleando).
3. Valida el comportamiento del endpoint del sitemap. 200, content-type XML, caché sensato, sin transformaciones, sin auth, sin desafíos.
4. Valida sitemaps hijos. Muestrea aleatoriamente 5 sitemaps hijos y 10 URLs. Si no muestreas, confías en la parte más optimista de tu stack.
5. Elimina URLs de poco valor de los sitemaps. Nada de archivos de etiquetas salvo que realmente aporten valor. No búsquedas internas. No páginas paginadas basura. No variantes con parámetros.
6. Corrige discrepancias de robots/noindex/canonical. No listes URLs que desautorizas, noindexas o canonicalizas a otro lado. Solo estás perdiendo el tiempo de todos.
7. Haz que la generación de sitemap sea barata. Cachea la salida. Si es dinámica y cara, pre-genera o usa object cache. El tráfico de Googlebot no debería ser tu prueba de carga.
8. Reenvía el sitemap tras cambios reales. No como ritual. Reenvía cuando cambias el endpoint, host, protocolo o eliminas bloqueos.
9. Monitorea como una API. Chequeos sintéticos que validen content-type y parseabilidad XML son mejores que esperar a que Search Console se enfade.

Lista operativa: antes de culpar a Google

• ¿Puedes obtener el sitemap desde un cliente no navegador?
• ¿Devuelve XML y valida?
• ¿Hay respuestas 4xx/5xx/429 en logs para rutas de sitemap?
• ¿Robots.txt es permisivo para el contenido que quieres indexar?
• ¿URLs muestreadas devuelven señales indexables (sin noindex, canonical coincide)?
• ¿Tu CDN está cacheando o transformando respuestas de sitemap?
• ¿Desplegaste, migraste, cambiaste DNS o activaste un modo WAF recientemente?

Higiene mínima “conocida buena” para sitemaps

• Usa URLs absolutas en <loc>, solo el host canónico.
• Divide sitemaps cuando sean grandes; usa un índice de sitemap.
• Marca lastmod solo cuando el contenido cambie realmente.
• No incluyas URLs que estén noindex, redirigidas o bloqueadas por robots.
• Sirve con content-type correcto y caché estable.

Preguntas frecuentes (FAQ)

¿Por qué Search Console dice “Éxito” pero mis páginas aún no están indexadas?

Porque “Éxito” significa que Google obtuvo y parseó el sitemap. La indexación depende de las URLs mismas: robots/noindex, elección de canonical, calidad percibida, duplicados y programación de rastreo.

¿Qué sitemap debo enviar para WordPress: wp-sitemap.xml o sitemap_index.xml?

Envía el que tu sitio realmente sirva como índice de sitemap autorizado. Si usas un plugin SEO que proporciona /sitemap_index.xml, envía ese. Si dependes del core, envía /wp-sitemap.xml. No envíes ambos a menos que disfrutes señales duplicadas.

¿Puede un CDN romper la indexación del sitemap?

Absolutamente. Los CDN pueden cachear sitemaps obsoletos, transformar contenido o servir desafíos a bots. Haz los endpoints de sitemap predecibles: TTL corto, sin reescrituras HTML, sin desafíos a bots y purga en deploy/migración.

¿Necesito una directiva Sitemap en robots.txt?

Ayuda pero no es obligatoria si ya lo envías en Search Console. Vale la pena porque otros crawlers la usan y actúa como señal al depurar.

¿Debo incluir archivos de categoría/etiqueta en mi sitemap?

Sólo si esas páginas son landing pages valiosas con contenido único. Si son delgadas, duplicadas o generadas automáticamente, ponles noindex y elimínalas del sitemap.

¿Con qué frecuencia debería actualizarse mi sitemap?

Cuando cambie contenido significativo. Evita actualizar lastmod para cada URL en cada petición; entrenarás a los buscadores a ignorar tus timestamps. Cachea el sitemap y regénralo en eventos de publicación/actualización.

¿La opción “Disuadir a los motores de búsqueda” de WordPress bloquea la indexación completamente?

PUEDE hacerlo, dependiendo del theme/plugins y cómo lo implementen. Trátalo como una alerta roja en producción. Verifica señales reales con curl: meta robots y cualquier cabecera X-Robots-Tag.

¿Cuál es la forma más rápida de saber si Googlebot está siendo bloqueado?

Revisa tus logs de acceso buscando peticiones con UA de Googlebot a rutas de sitemap y páginas clave, y verifica códigos de estado y bytes. Combínalo con curl usando un UA de Googlebot desde fuera de tu red.

¿Importan las redirecciones en un sitemap?

Sí. Unas pocas redirecciones no te matarán, pero los sitemaps deberían listar URLs finales canónicas. Si todo redirige, desperdicias presupuesto de rastreo y señalas mala higiene.

Mi sitemap tiene más de 50.000 URLs. ¿Es un problema?

Es un problema si está en un solo archivo. Divídelo y usa un índice de sitemap. Más importante: asegúrate de que esas URLs merezcan indexación. Los sitemaps grandes a menudo esconden un problema de calidad, no técnico.

Conclusión: siguientes pasos que realmente importan

Si quieres que tu sitemap de WordPress impulse la indexación, deja de tratarlo como un artefacto mágico de SEO y empieza a tratarlo como un endpoint de API con consumidores estrictos.

1. Ejecuta la guía de diagnóstico rápido: confirma la URL exacta, haz curl como Googlebot y luego verifica logs y directivas.
2. Arregla la obtenibilidad primero: 200 OK, XML correcto, sin auth, sin desafíos WAF, sin circo de redirecciones.
3. Arregla señales de confianza después: consistencia de canonical, alineación robots/noindex y solo incluye URLs que realmente quieras indexar.
4. Hazlo operativo: monitoriza endpoints de sitemap, cachea inteligentemente y prueba la rastreabilidad tras cada migración o cambio en CDN/seguridad.

Haz eso y “no se indexa” dejará de ser un misterio ansioso y se convertirá en un incidente directo con causa raíz y ticket de cambio. Como debería ser siempre.