Enviás el sitemap y Search Console lo procesa. Sin embargo, el archivo contiene páginas redirigidas, variantes que apuntan a otra canónica y direcciones que ya no existen. El envío funcionó; lo que necesita revisión es la selección de URLs.
Un sitemap ayuda a comunicar qué direcciones querés que el buscador descubra y considere. Su presencia no garantiza rastreo ni indexación. Esta auditoría permite contrastar el archivo con la respuesta real del sitio y con la política de publicación, para corregir el generador y mantener el resultado después del próximo cambio.
Definí el conjunto que debería aparecer
Antes de revisar un XML, escribí qué tipos de contenido querés ofrecer en resultados: servicios, categorías, fichas, artículos o documentos útiles. Anotá también las exclusiones deliberadas, como áreas privadas, confirmaciones o variantes sin valor independiente. Esas decisiones se revisan por necesidad del usuario, no por la comodidad del plugin.
La referencia habitual para un sitemap de páginas son URLs públicas que querés indexar, que responden correctamente y representan la versión preferida del contenido. Si aparece una URL con noindex, una redirección o una canónica hacia otra página, investigá la contradicción antes de agregar excepciones.
No confundas el mapa con el inventario completo de todo lo que el servidor puede responder. Tampoco lo uses para resolver por sí solo la exclusión de contenido: quitar una URL del sitemap no la retira del índice. Para esa decisión, revisá rastreo, noindex y retirada de páginas.
Localizá el índice y todos sus archivos hijos
Recuperá la dirección enviada en Search Console y la declaración que exista en robots.txt. En WordPress puede haber un índice generado por el núcleo o por un plugin SEO. Los nombres varían; no des por hecho que el archivo correcto siempre termina en sitemap.xml.
Abrí el recurso sin sesión iniciada y registrá estado HTTP, contenido y archivos enlazados. Un índice contiene referencias a otros sitemaps; necesitás revisar esos hijos para conocer las páginas incluidas. Guardá una copia de trabajo antes de modificar configuraciones.
Si encontrás varios generadores, determiná cuál está activo y qué archivos utiliza el sitio. Dos archivos accesibles no son automáticamente un problema, pero conjuntos contradictorios o generadores que siguen publicando rutas antiguas complican el mantenimiento. La corrección debe tener una fuente de verdad identificada.
Exportá las URLs y cruzalas con una comprobación HTTP
Extraé cada loc y su lastmod, si existe. Conservá el archivo de origen para localizar después el generador responsable. Eliminá duplicados en una columna de análisis sin borrar todavía la evidencia original.
Con una herramienta de rastreo en modo lista, solicitá esas URLs y exportá estado inicial, redirecciones, URL final, canónica e instrucciones de indexación. Revisá que la herramienta haya podido acceder: un bloqueo del servidor contra el rastreador de auditoría no demuestra que Google reciba la misma respuesta.
Para páginas relevantes o patrones dudosos, contrastá el contenido y los datos de Search Console. Un rastreo técnico señala candidatos a revisión; no conoce por sí solo si una página de error con 200 reemplazó a una categoría comercial.
Podés organizar la hoja con estas columnas: URL enviada, sitemap de origen, estado, destino final, canónica, indexabilidad, tipo de contenido, decisión y causa. La columna de causa evita que el equipo elimine direcciones del archivo sin reparar la configuración que las vuelve a generar.
Usá cada hallazgo para decidir una corrección
Estos ejemplos pertenecen a un sitio ficticio. Las rutas ilustran problemas distintos; no son instrucciones para excluir indiscriminadamente todos los parámetros o todas las páginas de un tipo.
Deslizá la tabla para ver todas las columnas.
| Hallazgo | Comprobación | Corrección posible |
|---|---|---|
/servicio-anterior/ devuelve 301. | Confirmar que el destino sea el reemplazo aprobado y responda correctamente. | Publicar la URL final en el sitemap y actualizar las referencias propias. |
/producto-retirado/ devuelve 404. | Verificar si la retirada fue deliberada o si el producto sigue vigente. | Corregir la página si fue una falla; excluirla del generador si se retiró. |
/gracias/ tiene noindex. | Confirmar que la exclusión sea la política esperada. | Mantener noindex si corresponde y quitar esa URL del conjunto enviado. |
| Una variante declara otra canónica. | Comprobar contenido, enlaces y versión que debe conservarse. | Alinear el generador con la URL preferida, después de resolver contradicciones. |
| Una página devuelve 200, pero muestra un error. | Revisar el cuerpo, la plantilla y la respuesta del servidor. | Reparar el contenido o representar correctamente su retirada. |
Si una página importante apunta a otra canónica sin que esa fuera la intención, no la elimines del sitemap como primera reacción. Investigá el conflicto con la guía de selección de canónicas. El objetivo es que la página, sus señales y el archivo expresen la misma decisión.
Compará también las URLs que faltan
Auditar solo lo enviado permite detectar sobrantes, pero deja fuera las páginas que el generador olvidó. Cruzá el sitemap con el CMS y un rastreo de enlaces internos. Agregá páginas importantes que conozcas por otros registros, como campañas o inventarios de producto.
Si falta una categoría nueva, comprobá estado de publicación, acceso, canónica y exclusiones del plugin. Si está huérfana, agregala a la arquitectura pertinente además de revisar su inclusión. Un sitemap no reemplaza la navegación ni los enlaces contextuales que ayudan a entender una página.
En sitios grandes, agrupá la revisión por plantillas y sitemaps hijos para localizar patrones. Muestrear ayuda a investigar, pero no equivale a haber comprobado todas las URLs. Si vas a informar cobertura completa, necesitás un cruce que contemple el conjunto total y registre los errores de acceso.
Lastmod debe describir un cambio real
La fecha de última modificación debería corresponder a una actualización significativa de la página. Regenerar el sitemap cada madrugada no significa que todos los artículos hayan cambiado. Tampoco cambiar el año del pie de página justifica actualizar de manera masiva esa señal.
Contrastá una muestra con el historial del contenido. Revisá especialmente fechas idénticas en miles de URLs, valores futuros y páginas antiguas que aparentan actualizarse cada día. Si el sistema no puede ofrecer una fecha fiable para cierto contenido, es preferible omitir el campo opcional antes que inventarlo.
En un índice, el lastmod del sitemap hijo se refiere al archivo correspondiente. Dentro del sitemap de páginas, se refiere a cada URL. Mantener esa distinción evita trasladar automáticamente la hora de generación a todo el contenido.
Revisá formato, tamaño y direcciones
Usá URLs absolutas, con protocolo y host elegidos. Verificá codificación UTF-8, XML válido y escape de caracteres. Una dirección con varios parámetros necesita representar correctamente el separador dentro del XML; una página que lo muestra bonito en el navegador todavía puede contener un archivo inválido.
Cada sitemap está limitado a 50.000 URLs o 50 MB sin comprimir. Si se supera cualquiera de esos límites, dividí el conjunto en archivos y, si conviene, organizalos mediante un índice. Separar por tipo de contenido también puede facilitar el análisis, siempre que el generador mantenga consistencia.
Google no utiliza los valores priority y changefreq. Ajustarlos para que todas las páginas parezcan prioritarias no sustituye la selección correcta ni una fecha fiable.
Un ejemplo mínimo, con una fecha ficticia que solo sería válida si refleja una actualización real de esa página:
<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
<url>
<loc>https://negocio.example/servicios/consultoria/</loc>
<lastmod>2026-10-28</lastmod>
</url>
</urlset>La dirección HTTP del atributo xmlns identifica el esquema del XML; no indica que tus páginas deban utilizar HTTP. Las URLs del contenido deben conservar su protocolo correcto.
Corregí el generador y volvé a comprobar el resultado
Aplicá los cambios en la fuente: reglas del plugin, estado del contenido o código que construye el sitemap. Editar una copia exportada no modifica el archivo que el servidor seguirá entregando. Si una exclusión debe afectar una sola sección, comprobá también ejemplos que deben permanecer incluidos.
Después regenerá o invalidá la copia correspondiente y abrí el archivo público. Revisá caché del plugin, servidor o CDN si el resultado sigue igual. El diagnóstico de caché en WordPress permite separar un cambio no aplicado de una respuesta antigua.
Enviá la dirección vigente mediante Search Console y comprobá su lectura y procesamiento. También podés declararla en robots.txt. No dependas de los antiguos endpoints de ping de Google para notificar cambios. Volver a enviar repetidamente el mismo archivo no corrige las URLs que contiene.
Cerrá con evidencias y una regla de mantenimiento
Registrá cuántas URLs revisaste, qué patrones corregiste y cuáles quedaron pendientes por una decisión de contenido. Conservá una muestra de respuestas antes y después. Separá “archivo leído” de “páginas indexadas”: son resultados diferentes, y la indexación requiere otras comprobaciones.
Programá una revisión cuando cambien plantillas, plugins SEO, reglas de catálogo o dominio. En una migración, el mapa nuevo y las redirecciones deben contar la misma historia. Un sitemap mantenible es el resultado de una política clara y un generador que la cumple después de cada publicación.