El sitemap XML desaparecido · Serpion 013

La cadena de restaurantes tenía presencia física en siete ciudades. Nada masivo, pero tampoco pequeño. Cada local con su ficha, sus horarios, su carta y su zona de cobertura a domicilio. Un proyecto donde el SEO local era la palanca real de captación, y donde cada página de ubicación necesitaba estar visible, rastreable y accesible para Google sin fricciones. El tráfico orgánico llevaba semanas sin caídas dramáticas, pero tampoco crecía. Se había quedado plano de una forma que no encajaba con el ritmo habitual del sitio.

Esto no me cuadraba. El sitio funcionaba. Las páginas cargaban. El contenido estaba ahí. Pero había algo en esa ausencia de señal del sitemap XML, en ese silencio técnico, que me decía que la historia tenía más capas de las que se veían a primera vista.

El rastro del sitemap que dejó de responder

Lo primero que hice fue ir directo a la ruta estándar. En sitios con este tipo de CMS, la ubicación del sitemap XML suele ser predecible: /sitemap.xml o alguna variación declarada en el robots.txt. Accedí a la ruta esperada y el resultado fue inmediato y rotundo: un error 404. No había archivo, no había redirección, no había respuesta alternativa. Simplemente no existía nada en esa dirección.

Lo que me llamó la atención no fue una caída de impresiones ni un aumento de errores de cobertura. Fue una señal más silenciosa: el sitemap registrado en la herramienta llevaba tiempo sin actualizarse, y la última comprobación automática había devuelto un estado que no invitaba a ignorarlo. No era un aviso menor. Era una señal de que algo en la comunicación entre el sitio y el rastreador se había interrumpido antes de que nadie lo notara.

Abrí Google Search Console y confirmé lo que ya intuía. El sitemap registrado llevaba semanas en estado de error. La herramienta lo había intentado recuperar en varias ocasiones y en todas ellas había recibido el mismo resultado: URL no encontrada. Google no estaba ignorando el archivo; lo buscaba activamente y no lo encontraba.

Aquí era donde la situación se ponía interesante. El sitio tenía más de sesenta URLs entre fichas de restaurante, páginas de zona y la portada. Si el rastreador perdía el hilo del mapa de navegación declarado, no dejaba de rastrear automáticamente, pero sí empezaba a depender solo de los enlaces internos para descubrir y revisar páginas. Y eso, en un sitio con estructura modular y actualizaciones frecuentes de horarios y carta, significaba que algunas páginas podían quedarse sin visitas del bot durante semanas.

Antes de concluir nada, revisé los logs del servidor filtrando las visitas de Googlebot durante las últimas cuatro semanas. El patrón que vi no era de abandono total: el bot seguía entrando, pero con una frecuencia y cobertura claramente inferiores a lo habitual. Las páginas principales de cada ciudad recibían visitas, sí, pero algunas fichas de local más recientes apenas aparecían en el registro. Google estaba entrando, pero se estaba entreteniendo en las zonas que ya conocía y dejando de explorar las que más necesitaban señal fresca.

En ese momento apareció la primera hipótesis que me hizo perder tiempo. En los logs había un patrón de respuestas inconsistentes: la mayoría de URLs devolvían 200 sin problema, pero había un puñado de peticiones de Googlebot que recibían respuestas con latencias anómalas. Mi primera lectura fue que podía haber una configuración de caché del servidor que estaba sirviendo respuestas inestables a determinados agentes, incluido el rastreador. Un comportamiento así habría explicado tanto la caída de cobertura como la falta de actualización del sitemap en Search Console.

Revisé la configuración de cabeceras HTTP para las URLs afectadas, comprobé si los encabezados de caché variaban según el agente y analicé si las latencias coincidían con un patrón de caché fría o caducada. El resultado fue claro: las respuestas eran consistentes. Las latencias altas correspondían a dos URLs con imágenes pesadas sin optimizar, no a un problema de caching. El servidor estaba funcionando bien. Esa pista no iba a ningún sitio.

El problema no era que Google no pudiera entrar al sitio. Era que cuando buscaba el mapa que le habían prometido, encontraba un muro en blanco.

¿Por qué el sitemap ausente afectaba más a las páginas nuevas que a las antiguas?

Esta distinción importaba. Las páginas que llevaban más tiempo conocidas por Google seguían apareciendo en los resultados sin grandes variaciones, porque el bot ya las tenía registradas y las revisitaba por inercia desde los enlaces internos. Pero las fichas de los dos locales más recientes, abiertos hace menos de tres meses, apenas tenían impresiones. Sin un sitemap activo que facilitara su redescubrimiento periódico, dependían exclusivamente de que el bot las encontrara navegando por los enlaces internos del sitio. Y en un proyecto donde el enlazado a fichas nuevas tardaba en propagarse, eso las ponía en desventaja clara: Google las había visto alguna vez.

Esto lo confirmé cruzando los datos de cobertura en Search Console con las fechas de publicación de cada ficha. Las páginas publicadas antes del fallo no mostraban pérdidas significativas. Las publicadas después tenían estados de "Descubierta: actualmente sin indexar" o simplemente no aparecían en el informe de cobertura. La correlación era clara, aunque no podía cerrarse como prueba absoluta: había otros factores posibles, pero el patrón apuntaba en una dirección concreta.

Usé Screaming Frog para hacer un rastreo completo del sitio y verificar qué URLs eran accesibles, cuáles devolvían estados distintos de 200 y si había algún patrón de respuesta vinculado a la ruta del sitemap XML. El rastreo confirmó lo que ya sabía: el resto del sitio estaba técnicamente sano. El único punto de fallo era la ruta declarada del sitemap, que devolvía un 404 limpio, sin respuesta alternativa.

La pieza que nadie recordaba haber quitado

Con toda esa información encima de la mesa, el diagnóstico se cerró solo. El sitemap no había desaparecido por un error de configuración manual, ni por un cambio de URL intencionado, ni por un problema de servidor. Había dejado de generarse. Y había dejado de generarse porque el módulo del CMS responsable de producirlo no trabajaba con un archivo físico almacenado en el servidor: lo construía de forma dinámica. Cada vez que alguien, o algo, accedía a la ruta /sitemap.xml, el módulo consultaba la base de datos, componía el XML al vuelo y lo devolvía como respuesta. No había ningún archivo que eliminar porque nunca había existido uno en disco.

Al actualizarse a una versión incompatible con la configuración existente, el módulo perdió sus ajustes internos. La ruta seguía declarada en el sistema, pero el proceso encargado de responderla había dejado de funcionar. El resultado era previsible: cualquier petición a esa URL, viniera de un usuario, de Search Console o de Googlebot, recibía un error 404. No porque el archivo se hubiera borrado, sino porque ya no había nada detrás que lo sirviera.

Eso explicaba el timing. El fallo no había sido inmediato ni dramático. Durante los primeros días tras la actualización, Google todavía no había vuelto a solicitar una versión nueva del sitemap. Cuando el bot intentó recuperarlo de nuevo, el módulo respondió con un 404. Y desde entonces, cada intento de Search Console por recuperar el archivo había obtenido la misma respuesta.

GET /sitemap.xml HTTP/1.1
Host: restaurante-cadena.es
User-Agent: Googlebot/2.1

HTTP/1.1 404 Not Found
Content-Type: text/html; charset=UTF-8
Date: [fecha de acceso]

Aquí el detalle técnico que más me interesó: el módulo seguía activo en el panel de administración. No había ningún aviso de error visible, ninguna alerta en el sistema. Funcionaba para todo lo demás que se le había asignado. Solo había perdido la configuración específica de la ruta del sitemap, y esa pérdida era completamente silenciosa. Nadie había recibido una notificación. Nadie había visto un error en el backoffice.

Una señal rota no siempre grita. A veces solo deja de empujar, y nadie lo nota hasta que el daño lleva semanas acumulándose.

El impacto real no era catastrófico en términos de tráfico global, pero sí era significativo para el negocio concreto: las dos fichas de locales nuevos no tenían visibilidad orgánica relevante, y ese era exactamente el tipo de página que más necesitaba señal rápida y continua para posicionarse en búsquedas locales competidas. Cada semana sin que Google pudiera redescubrirlas con facilidad era una semana perdida en un mercado donde las búsquedas de "restaurante + ciudad" tienen picos muy concentrados.

Reconstruir desde lo que quedaba en pie

Una vez identificado el problema, tocaba decidir cómo resolverlo. Y aquí la decisión no era tan obvia como parecía.

Entre dejar que el sistema lo regenerara o construirlo a mano desde el principio

La opción más rápida era reconfigurar el módulo del CMS para que retomara la generación dinámica del sitemap. Técnicamente era viable: bastaba con revisar los ajustes, restaurar la configuración perdida y verificar que la ruta volvía a responder correctamente. El problema era que esa opción dependía de que todo quedara bien guardado, algo que ya había fallado una vez sin dejar rastro visible. Fiarme de que esta vez funcionaría sin validación externa me parecía arriesgado.

La otra vía era generar el sitemap XML de forma manual, con control total sobre su estructura y contenido, y registrarlo directamente en Search Console. Más trabajo inmediato, pero sin dependencias ocultas. Podía revisar exactamente qué URLs incluía y verificar que la ruta era accesible antes de enviar nada a Google.

Elegí la segunda opción. No porque la primera fuera incorrecta, sino porque en ese momento necesitaba certeza, no probabilidad. El riesgo de ejecutar mal la reconfiguración automática era quedarme con un módulo aparentemente activo que volviera a fallar en silencio. Si eso ocurría, tardaría otras semanas en detectarlo.

Generé el archivo XML manualmente incluyendo todas las URLs activas del sitio. Cada entrada llevaba su lastmod con la fecha real de última modificación, que era lo único que merecía incluir aquí: una referencia temporal verificable que le diera a Google información útil sobre cuándo había cambiado cada página.

<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
  <url>
    <loc>https://restaurante-cadena.es/restaurantes/madrid-centro/</loc>
    <lastmod>2024-10-15</lastmod>
  </url>
  <url>
    <loc>https://restaurante-cadena.es/restaurantes/barcelona-gracia/</loc>
    <lastmod>2024-10-15</lastmod>
  </url>
  <url>
    <loc>https://restaurante-cadena.es/zona/madrid/</loc>
    <lastmod>2024-09-30</lastmod>
  </url>
</urlset>

Una vez publicado y verificado que respondía con un estado 200 limpio, lo registré en Google Search Console. La herramienta lo procesó en menos de veinticuatro horas y confirmó que había podido leer el archivo sin errores de formato. Las URLs declaradas quedaron registradas como descubiertas; si estaban indexadas o no era algo que se vería después, con tiempo y con las señales que el sitio fuera acumulando.

Que un archivo exista en el servidor no significa que Google lo encuentre. Que Google lo encuentre no significa que lo procese. Y que lo procese no significa que el sitio haya hecho su parte bien. Cada paso de esa cadena puede romperse de forma independiente.

La validación real llegó dos semanas después: las fichas de los locales nuevos empezaron a aparecer en el informe de cobertura con estado indexado, y sus impresiones en búsquedas locales comenzaron a crecer desde cero. No fue una recuperación explosiva, pero sí fue constante y clara. El rastreador había retomado el hilo.