Mantener una web no consiste solo en que cargue y realizar actualizaciones, también consiste en resolver incidencias de todo tipo. Hay piezas que funcionan en segundo plano y que cuando fallan, generan más inquietud de la que parece. El sitemap es sin duda una de ellas.
En uno de mis proyectos, una tienda online desarrollada con WooCommerce, utilizábamos un plugin para generar el sitemap. En general todo funcionaba bien, pero de vez en cuando ocurría algo curioso y es que al acceder al sitemap devolvía un error 404. No siempre, solo en momentos puntuales.
El problema que teníamos entre manos era a priori técnico, pero sobre todo emocional. El cliente se dedica al SEO y lógicamente ver que el sitemap no respondía le generaba mucha inquietud. Me llamaba para saber qué estaba pasando, por qué Google dejaba de rastrear la web o las graves consecuencias que esto tendría para su tienda. Vamos, algo totalmente lógico.
Tras revisar el caso con calma, la causa era simplemente que el servidor tenía caídas puntuales. Nada grave, pero lo suficientemente molesto como para que, justo las veces que el cliente entraba a comprobarlo, se encontrara el error.
Para evitar sustos innecesarios y tener una comprobación objetiva, se me ocurrió crear un pequeño script en PHP que verificara cada noche si el sitemap respondía correctamente y nos avisara solo en caso de fallo. Desde entonces, el problema dejó de ser una fuente de ansiedad y pasó a ser algo controlado.
Por qué merece la pena vigilar el sitemap
El sitemap es uno de esos elementos que casi nadie mira mientras todo va bien. Está ahí, Google lo lee, rastrea la web y seguimos con nuestra vida. El problema es que, cuando deja de responder, no siempre nos enteramos a tiempo.
Un sitemap que devuelve un 404, un 500 o que directamente no responde puede provocar que Google deje de rastrear nuevas URLs o tarde más en hacerlo. No suele ser algo catastrófico de inmediato, pero sí un fallo silencioso que, mantenido en el tiempo, acaba pasando factura al SEO.
Además, es importante tener en cuenta que Google Search Console no avisa siempre al momento. En muchos casos el aviso llega horas o incluso días después, cuando el problema ya ha ocurrido varias veces. Y si la caída es puntual, es bastante fácil que no la veas nunca, salvo que tengas muy mala suerte y entres justo en ese instante (como le pasó a mi cliente).
Por eso tiene sentido vigilar el sitemap de forma activa, aunque sea con algo muy sencillo. No para vivir obsesionado, sino para saber que si falla, te vas a enterar. Y si no falla, no perder ni un segundo pensando en ello.
Qué hace exactamente el script
Antes de entrar en el código, conviene entender qué hace el script a nivel conceptual. La idea no es analizar el contenido del sitemap ni validar su estructura, sino algo mucho más básico y a la vez, más importante en este caso: comprobar que la URL responde correctamente mediante el código de respuesta del servidor.
El funcionamiento es muy simple. El script intenta acceder a la URL del sitemap y se queda únicamente con el código de respuesta HTTP. Si todo va bien y el servidor devuelve un 200, no hace absolutamente nada más.
Cuando la respuesta no es la esperada, cambia el comportamiento. El script detecta el error, prepara un aviso por correo y lo envía indicando qué URL ha fallado, qué código ha devuelto y en qué momento ocurrió.
Un detalle importante es que el script está pensado para funcionar en entornos reales, no ideales. Intenta usar cURL si está disponible, pero incluye una alternativa para servidores más limitados donde no siempre se puede contar con todas las extensiones activas. Esto permite reutilizarlo en distintos proyectos sin tener que adaptarlo cada vez.
En resumen, no hace nada sofisticado y precisamente por eso funciona bien. Se limita a responder a una única pregunta de si el sitemap está accesible en ese momento o no. Si la respuesta es «no», te enteras por email. Si es «sí», el script desaparece en segundo plano, que es justo lo que interesa.
El script en PHP
Este es el script tal cual lo uso en mis proyectos. Está pensado para ejecutarse desde una tarea cron, una vez al día, y no requiere nada especialmente raro a nivel de servidor, como ya adelantaba antes. Precisamente una de las premisas desde el principio fue que pudiera funcionar en entornos compartidos o con configuraciones más restrictivas.
Antes de usarlo, solo hay que ajustar tres valores muy concretos: la URL del sitemap que quieres comprobar y las direcciones de correo a las que debe llegar el aviso en caso de error (puedes añadir varias separadas por comas). No hay más configuración oculta ni dependencias externas.
Aquí puedes ver el código completo y, al final del artículo, te dejo el enlace a mi GitHub por si prefieres descargar el archivo directamente o adaptarlo a tus propios proyectos.
<?php
// --- AJUSTA ESTOS DATOS ---
$URL = "https://tudireccionweb.com/sitemap_index.xml";
$TO = "hola@tudireccionweb.com";
$FROM = "monitorsitemap@tudireccionweb.com";
// ---------------------------
$code = 0;
$err = "";
if (function_exists('curl_init')) {
$ch = curl_init($URL);
curl_setopt_array($ch, [
CURLOPT_NOBODY => true, // solo cabeceras
CURLOPT_FOLLOWLOCATION => true, // seguir 301/302
CURLOPT_MAXREDIRS => 5,
CURLOPT_TIMEOUT => 10,
CURLOPT_RETURNTRANSFER => true,
CURLOPT_HEADER => true,
// Si tienes problemas de CA, descomenta las 2 siguientes (no recomendado en prod):
// CURLOPT_SSL_VERIFYPEER => false,
// CURLOPT_SSL_VERIFYHOST => 0,
]);
curl_exec($ch);
$code = (int)curl_getinfo($ch, CURLINFO_HTTP_CODE);
$err = curl_errno($ch) ? curl_error($ch) : "";
curl_close($ch);
} else {
// Fallback sin cURL: lanza GET ligera y mira código
$ctx = stream_context_create([
'http' => ['method' => 'GET', 'timeout' => 10, 'ignore_errors' => true]
]);
$data = @file_get_contents($URL, false, $ctx);
if (isset($http_response_header[0]) &&
preg_match('~HTTP/\S+\s+(\d{3})~', $http_response_header[0], $m)) {
$code = (int)$m[1];
} else {
$code = 0;
$err = "sin_respuesta";
}
}
if ($code !== 200) {
$subject = "ALERTA: el mapa del sitio responde $code";
$body = "La URL $URL devolvió $code".($err ? " ($err)" : "")
. " a las ".date('Y-m-d H:i:s');
$headers = "From: $FROM\r\n";
@mail($TO, $subject, $body, $headers);
// Marca error para logs si se ejecuta vía CLI o URL
http_response_code(500);
exit(1);
}
// Opcional: salida silenciosa en OK
exit(0);
Cuándo tiene sentido usar algo así
Este tipo de comprobación encaja especialmente bien en webs que ya están en producción y que dependen del tráfico orgánico. Por ejemplo, tiendas online, webs de clientes que requieren mantenimiento continuo o proyectos alojados en servidores que pueden tener caídas puntuales.
También es útil cuando gestionas varias webs y quieres enterarte de los problemas antes de que lo haga el cliente. No sustituye a una monitorización avanzada, pero cubre un punto muy concreto que suele pasarse por alto.
El mantenimiento web rara vez se nota cuando todo funciona correctamente. No hay avisos, no hay llamadas y no hay urgencias. Y paradójicamente, eso suele ser la mejor señal de que las cosas están bien hechas.
Este tipo de scripts pequeños no suelen aparecer en portafolios ni en listados de funcionalidades, pero son los que marcan la diferencia en el día a día. Evitan sustos, reducen la incertidumbre y convierten problemas puntuales en algo controlable.
Como desarrollador web freelance, gran parte del valor está en anticiparse a estos detalles. No siempre se trata de reaccionar cuando algo falla, sino de crear las condiciones para enterarte a tiempo y poder actuar con calma.
Si necesitas ayuda con el mantenimiento o el desarrollo de tu web, estaré encantado de ayudarte. Porque muchas veces, lo más importante no es lo que se ve, sino todo lo que funciona en silencio para que el resto vaya como debe.
Referencias:
- Código de ejemplo – Mi repo en GitHub
Deja una respuesta