- Crawl Budget Management For Large Sites | Google Search Central | Documentation | Google for Developers
- Learn what crawl budget is and how you can optimize Google's crawling of large and frequently updated websites.
Texto traducido por IA.
Resumen de la publicación por la IA de durumis
- Para utilizar de manera eficiente el presupuesto de rastreo de Google Search, hemos mejorado la velocidad de transferencia de páginas web e implementado un servicio de redirección basado en Cloud Run.
- Hemos migrado archivos estáticos como robots.txt, favicon.ico y la lógica de redirección a Cloud Run, mejorando la velocidad de respuesta de 200 ms a 20 ms en comparación con GKE Autopilot.
- Hemos implementado Cloud Run en varias regiones de todo el mundo para proporcionar el servicio desde el servidor más cercano a la ubicación del usuario, lo que mejora la velocidad y reduce los costes.
Todos los servicios que se basan en contenido desean tener una gran visibilidad en la búsqueda de Google.
Sin embargo, para lograr la visibilidad en la búsqueda de Google, es necesario que el rastreador (crawler) visite el sitio web con frecuencia para rastrear los datos más recientes y que estos se reflejen correctamente.
En este caso, para que el rastreador visite el sitio web con más frecuencia, se utiliza el concepto de "presupuesto de rastreo" que, si es más alto, permite que el rastreador visite el sitio con mayor frecuencia. Para ello, el sitio web debe tener un cierto volumen de tráfico.
¿Cómo podemos optimizar la utilización de este "presupuesto de rastreo" limitado para que el rastreador visite nuestro sitio con más frecuencia con el mismo presupuesto?
La clave está en la velocidad de transferencia de las páginas web del sitio. Por ejemplo, un sitio con un tiempo de descarga de página de 20 ms será rastreado con más frecuencia que un sitio con un tiempo de descarga de 200 ms.
En durumis, dado que nuestro objetivo principal es ofrecer un "servicio global", brindamos un servicio de tráfico básico en 8 regiones de todo el mundo.
Regiones del servidor GCP
Actualmente, nuestro servicio utiliza las regiones de 40 regiones de Googleconcretamente, las regiones de Seúl, Singapur y Mumbai en Asia, Bélgica en Europa, Los Ángeles y Carolina del Sur en Estados Unidos. Esto permite que la conexión sea rápida independientemente de dónde se acceda desde cualquier parte del mundo.
Sin embargo, por las razones mencionadas anteriormente, hemos decidido realizar una optimización adicional para lograr una velocidad aún mayor.
Actualmente, nuestro servicio se encuentra en un proceso de cambio de la estructura de URL, pasando de un método de URL inicial a un nuevo método de subdominio. Como consecuencia, existe un cierto número de redirecciones (Redirect) y Google está realizando un gran número de rastreos en esta parte del sitio web. Es importante que Google reconozca rápidamente las nuevas URL en sustitución de las antiguas.
Por lo tanto, para aprovechar al máximo el presupuesto de rastreo asignado, es necesario mantener la máxima velocidad posible en el tráfico de redireccionamiento.
Inicialmente, GKE se encontraba distribuido en las 8 regiones mencionadas, y cada instancia de GKE utilizaba GKE Autopilot de Google para realizar las redirecciones utilizando datos que no estaban vinculados a la base de datos.
Por ello, hemos decidido trasladar parte de la lógica que se encontraba en GKE y en otras instancias de Cloud Run a una nueva instancia de Cloud Run. La lista de elementos que se van a trasladar es la siguiente:
- robots.txt: Aunque es un archivo estático, se sirve en varios subdominios con un contenido generado dinámicamente por una lógica específica.
- favicon.ico: Archivo estático puro.
- durumis.com/[lang]/@userId/postID: Redireccionamiento a la nueva URL -> userId.durumis.com/[lang]/postID
Cuando se servía a través del framework relativamente pesado de GKE Autopilot, el tiempo de respuesta era de aproximadamente 200 ms.
El nuevo método utiliza Cloud Run y, dado que la lógica es muy simple, no se utiliza ningún framework. Se ha utilizado el código básico con node:http sin bibliotecas adicionales.
const http = require("http"); const fs = require("fs"); const path = require("path"); let cachedFavicon = null; function loadFavicon() { const faviconPath = path.join(__dirname, "favicon.ico"); try { cachedFavicon = fs.readFileSync(faviconPath); console.log("Favicon loaded into memory"); } catch (err) { console.error("Error loading favicon:", err); } } --- 생략 --- const server = http.createServer((req, res) => { if (req.url === "/favicon.ico") { res.writeHead(200, { "Content-Type": "image/x-icon", "Cache-Control": "public,max-age=2419200" } res.end(cachedFavicon); }); server.listen(port, () => { console.log(Server running at http://localhost:${port}/); });
(Si se introduce el código tal cual, no funcionará. Solo es para comprender el concepto general.)
En el caso de favicon.ico, que es un archivo de imagen, se ha optado por cargarlo desde un archivo y mantenerlo en memoria para su posterior envío.
Se utiliza un script de shell con gcloud para desplegar simultáneamente en varias regiones.
¡Tachán!
El resultado del despliegue es el siguiente:
Pantalla de Cloud Run
Se ha realizado el despliegue en "todas las regiones" de Estados Unidos y, además, en 2 regiones de Europa, 2 de Asia, 1 de África y 2 de Sudamérica. En realidad, esta es una de las ventajas de Serverless: aunque se realice este tipo de despliegue, el coste no aumenta (de hecho, si se sirve el tráfico desde una ubicación más cercana, el coste puede incluso reducirse).
Ahora bien, ¿cuánto ha aumentado la velocidad con estas mejoras?
La velocidad de respuesta del servidor anterior era la siguiente:
GKE Autopilot
La velocidad mejorada es la siguiente:
Archivo estático utilizando Cloud Run
Es posible que se pregunte si Cloud Run, al ser Serverless, no tendrá un tiempo de inicio en frío (cold start). Sin embargo, en un escenario donde se realizan rastreos continuos a intervalos regulares, esto no suele ser un problema. Esta es una de las características de Serverless de GCP: permanece en estado de espera (Standby) o inactivo (Idle) esperando a ser utilizado (y no supone un aumento de coste).
En la próxima publicación, explicaré cómo gestionar archivos de imagen y otros archivos, que no son archivos estáticos o redirecciones 301 como los que se han descrito en esta publicación.