Aunque más que crear, la palabra idónea seria gestionar. Sitemap es uno de los elementos más importantes del «SEO onpage» de ahí es importante su creación y mantenimiento periódico. El problema aparece cuando el sitio crece y tenemos un sitemap con decenas de miles o millones de entradas, según la web. Se convierte en algo difícil de «servir dinámicamente». Según el proyecto debemos utilizar con sentido común cache, demonios (tareas programadas o Cron Job) y sobre todo dividir o utilizar un indice…
Utilizar un indice para dividir el sitemap
El protocolo de sitemap.org nos permite contener hasta 50.000 entradas en nuestros archivos .xml con un tamaño máximo de 10Mb. Aunque tenemos la posibilidad de comprimir con .gzip para reducir la transferencia, una vez descomprimido el mismo tampoco puede sobrepasar los 10,485,760 bytes… Para poder gestionar una web con decenas de miles o millones de entradas tenemos la posibilidad de dividir mediante sitemapindex, que tiene que tener esta forma:
|
1 2 3 4 5 6 7 8 9 |
<?xml version="1.0" encoding="UTF-8"?> <sitemapindex xmlns="http://www.sitemaps.org/schemas/sitemap/0.9"> <sitemap> <loc>http://www.example.com/sitemap1.xml</loc> </sitemap> <sitemap> <loc>http://www.example.com/sitemap2.xml</loc> </sitemap> </sitemapindex> |
Cabe destacar que he eliminado la etiqueta «lastmod» (opcional), ya que personalmente hablando ocasionalmente es difícil de proporcionar, sobre todo si sigues sirviendo los sitemaps dinámicamente…
Dividir con sentido común y utilizar el cache
Incluso una misma tabla de algo se puede dividir en diferentes sitemaps. Es decir, las entradas con una fecha más reciente se pueden almacenar en un archivo distinto y con prioridad más alta (el campo priority es opcional). Lo mismo se puede aplicar a los post, noticias, productos… etc. Aquí el limite es la imaginación y sobre todo pensando siempre en el gran Google.
El cache lo suyo seria utilizar con el mismo acercamiento. Lo antiguo y que no cambia demasiado se puede guardar incluso para siempre. Cada aplicación puede utilizar diferente sistemas como Memcached, APC o Redis. Todo es ponerse e investigar… Aun así tampoco es plan almacenar en el cache una consulta de 50.000 resultados, el aumento de rendimiento es significativo pero ridículo, aunque al menos no sobrecargamos la base de datos.
En mi caso, una web de eventos grandes, los eventos pasados tienen la mitad de prioridad que los actuales y lógicamente en un archivo distinto. Ademas el sitemap de los eventos actuales tiene puesto una duración en el cache 10 veces inferior.
No generar dinamicamente y comprimir…
Por ultimo no servir el cache dinámicamente. No generar el archivo sitemap.xml siempre y cuando el Google Bot o el que sea lo requiera. Hay que recordar que internet esta lleno de arañas que rastrean la web para su propio provecho. Ocasionalmente es de sabios esconder el archivo sitemap.xml, lejos de nombres comunes «sitemap.xml«.
El problema de utilizar cache como comente, es que aun guardando consultas bestiales la generación del archivo lleva su tiempo. Para ello disponemos de la opción de utilizar los «Cron Jobs» o como se suelen llamarse demonios. La idea es simple, generar el archivo físico en el servidor llamado «sitemap.xml.gz» cada X tiempo.
No son excesivamente difíciles de implementar, aquí por ejemplo tienes un manual de acercamiento (En ingles). Básicamente lo único que hay que hacer es crear uno que haga aproximadamente esto:
|
1 |
curl -o /var/www/path_to_example_com/sitemap.xml http://www.example.com/generate/sitemap.xml |
Para posteriormente añadir una tarea cada 30 minutos. Para ello puedes crear un shell script, de pocas lineas…
|
1 2 3 4 5 6 |
#ejecutar crontab -e #añadir algo así: #para ejecutar cada 30 minutos */30 * * * * /your/script/path/cron-script |
Como ejemplo en PHP podría ser igual de fácil, podrías ejecutar siempre y cuando añades una entrada a la base de datos un código parecido a esto:
|
1 2 3 4 5 |
//Generamos archivo XML $buffer = file_get_contents('https://example.com/generate/archivo-xml'); //Lo guardamos localmente en un directorio público file_put_contents("{$path}/series.xml", $buffer); |
Ademas recuerda que la carpeta con la que ejecutas el demonio tenga permisos de escritura por parte de usuario, lógicamente puedes añadir la compresión permitida mediante .gzip: «gzip -9 sitemap.xml«.
La solución deseada para mi es tener un indice de sitemap donde ciertos archivos se generan dinámicamente (los importantes y con cambios recientes), mientras que otros sean archivos físicos creados mediante un demonio (los menos importantes, mas numerosos o actualizados hace mucho tiempo). En resumen, un poco de sentido común. Los frameworks modernos te ofrecen herramientas similares, para implementar programación de tareas y eventos dentro de tu código y no estar creando scripts por ahí… uno de los ejemplos es el «shceduler» laravel.
