Un sitemap XML no se limita a una lista de URL generada automáticamente por un CMS. En un sitio parisino cuyo contenido evoluciona al ritmo de eventos locales, actualizaciones de servicios o noticias del barrio, la calidad del archivo condiciona directamente la velocidad a la que los motores de búsqueda descubren nuevas páginas e ignoran las antiguas.
Fiabilidad de lastmod: la única señal que cuenta en un sitemap
Observamos con demasiada frecuencia sitemaps cuya etiqueta lastmod muestra la fecha de generación del archivo en cada URL, sin relación con la realidad editorial. Google ha aclarado su posición: utiliza esta fecha únicamente cuando es constantemente y verificablemente exacta, es decir, que refleja una modificación significativa del contenido principal, de los datos estructurados o de los enlaces.
Modificar el año de copyright en el pie de página no constituye una actualización significativa. En un sitio parisino cuyos horarios, tarifas o páginas de eventos cambian regularmente, lastmod debe provenir del historial editorial real, no de la fecha de reconstrucción del archivo.
Un CMS como WordPress, combinado con un plugin SEO correctamente configurado, puede fechar cada URL a partir de la última copia de seguridad efectiva del artículo. En cambio, un script casero que regenera el sitemap cada noche aplicando la fecha del día a todas las entradas envía una señal confusa. Los robots terminan ignorando completamente las fechas, lo que anula el interés del archivo para el recrawl dirigido.
Al analizar el sitemap del sitio Paris Astuce, se observa una estructura que refleja este principio: las URL están organizadas por tipo de contenido, con fechas coherentes en relación con las publicaciones efectivas.

Diferencias entre sitemap, CMS y Search Console en un sitio web parisino
La comparación entre las URL del sitemap, las páginas realmente publicadas por el CMS y las indexadas en Google Search Console constituye una auditoría que la mayoría de las guías para el público en general ignoran. Sin embargo, estas diferencias revelan problemas concretos.
Páginas presentes en el sitemap pero ausentes del índice
Un sitemap es una señal de descubrimiento, no una solicitud imperativa de rastreo. Una URL listada en el archivo puede permanecer excluida si lleva una directiva noindex, si su contenido se considera demasiado débil o si ningún enlace interno apunta hacia ella. En un sitio parisino con decenas de páginas de servicios locales, recomendamos cruzar regularmente el informe “Páginas” de Search Console con el contenido del sitemap para detectar estas exclusiones.
Páginas indexadas pero ausentes del sitemap
El caso inverso es igualmente frecuente. Páginas de prueba, borradores publicados por error o URL con parámetros de seguimiento pueden ser rastreadas a través del enlace interno sin nunca figurar en el sitemap. Un sitemap limpio solo contiene las URL canónicas a indexar. Cualquier URL que no desee ver aparecer en los resultados de búsqueda no tiene nada que hacer en este archivo.
A continuación, se presentan los controles a realizar periódicamente:
- Extraer la lista completa de URL del sitemap y compararla con la exportación de las páginas publicadas del CMS (estado “publicado” únicamente, excluyendo borradores y páginas privadas)
- Verificar en Search Console que cada URL del sitemap esté indexada o excluida intencionadamente por una directiva explícita (noindex, canónica hacia otra página)
- Identificar las URL huérfanas indexadas por Google pero ausentes del sitemap, que a menudo señalan páginas obsoletas o rutas técnicas no limpiadas
Organización de los sitemaps para un sitio parisino multi-secciones
Un sitio web parisino que cubre varias temáticas (distritos, salidas, buenas ofertas, noticias) se beneficia de segmentar su sitemap en lugar de agrupar todo en un único archivo. El mecanismo de sitemap index permite referenciar varios archivos hijos, cada uno dedicado a un tipo de contenido.
Esta segmentación no es solo estética. Permite observar en Search Console la tasa de indexación por categoría. Si las páginas “eventos” muestran una tasa de indexación notablemente inferior a las páginas “guías de barrio”, el problema probablemente radica en la frescura o profundidad del contenido de eventos, no en la configuración técnica.

Nombrar y estructurar los archivos hijos
Recomendamos un nombramiento explícito: sitemap-posts.xml, sitemap-pages.xml, sitemap-categories.xml. Esta convención facilita la lectura de los informes de Search Console y acelera el diagnóstico en caso de caída de indexación en un segmento específico.
Cada archivo hijo debe contener solo URL que devuelvan un código HTTP 200. Las redirecciones 301, los errores 404 y las páginas en soft 404 contaminan el archivo y desperdician el presupuesto de rastreo. En un sitio cuyo contenido está relacionado con la actualidad parisina, las páginas caducadas (eventos pasados, lugares cerrados) deben ser retiradas del sitemap tan pronto como ya no sean relevantes.
Interacción entre robots.txt y sitemap XML
El archivo robots.txt puede declarar la ubicación del sitemap a través de la directiva Sitemap, lo que sigue siendo el método más simple para que los robots lo encuentren sin envío manual. Sin embargo, una incoherencia entre los dos archivos crea un conflicto silencioso.
Si robots.txt bloquea un directorio entero a través de Disallow y el sitemap contiene URL de ese directorio, los motores reciben una señal contradictoria. El sitemap nunca supera una regla Disallow en robots.txt. La URL será descubierta pero no rastreada, lo que genera errores en Search Console sin beneficio SEO.
En un sitio WordPress parisino, este problema ocurre con frecuencia con los directorios de imágenes, las páginas de autor o las archivas de etiquetas que algunos plugins SEO incluyen por defecto en el sitemap mientras los bloquean en robots.txt. Una auditoría cruzada de los dos archivos evita estas contradicciones.
El sitemap de un sitio web parisino no es un archivo que se genere una vez y luego se olvide. Es una herramienta de diagnóstico continuo cuyo valor depende completamente de la rigurosidad con la que refleje el estado real del sitio, URL por URL, fecha por fecha.



