- 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.
Dit is een door AI vertaalde tekst.
Samenvatting van de tekst door durumis AI
- Om het Google zoekopdracht crawlbudget efficiënter te benutten, hebben we de webpagina-overdrachtssnelheid verbeterd en een redirect-service gebaseerd op Cloud Run geïntroduceerd.
- We hebben statische bestanden zoals robots.txt, favicon.ico en de redirect-logica naar Cloud Run verplaatst, wat resulteerde in een verbetering van de reactietijd van 200ms naar 20ms in vergelijking met de vorige GKE Autopilot-oplossing.
- Door Cloud Run in verschillende regio's over de hele wereld te distribueren, kunnen we de service leveren vanaf de server die het dichtst bij de gebruiker staat, wat leidt tot een hogere snelheid en kostenbesparingen.
Alle services die zich richten op het hosten van content willen graag goed zichtbaar zijn in de Google-zoekresultaten.
Maar om in de Google-zoekresultaten te worden weergegeven, moeten crawlers regelmatig de website bezoeken om de nieuwste gegevens te crawlen en deze goed te verwerken.
Om crawlers vaker naar de website te laten komen, kan men gebruik maken van het concept "crawlbudget". Met een hoger budget komen crawlers vaker langs, en daarvoor is een bepaald niveau van websiteverkeer nodig.
Hoe kunnen we dit beperkte "crawlbudget" dan efficiënt benutten om crawlers met hetzelfde budget vaker te laten langskomen?
Dat kan door de websitesnelheid van de pagina's te verhogen. Bijvoorbeeld: een website met een pagina-downloadtijd van 20 ms wordt vaker gecrawld dan een website met een downloadtijd van 200 ms.
Durumis streeft in principe naar een "globale service", daarom bieden we basisverkeer vanuit 8 regio's over de hele wereld.
GCP serverregio's
Momenteel maakt onze service gebruik van regio's in 40 Google-regio'sen wel Seoul, Singapore en Mumbai in Azië, België in Europa, Los Angeles en South Carolina in de Verenigde Staten. Ongeacht waar ter wereld u verbinding maakt, kunt u bijna altijd snel verbinding maken.
Maar vanwege de eerder genoemde redenen hebben we besloten om de snelheid nog verder te optimaliseren.
Momenteel doorloopt onze service een proces waarbij de URL-structuur wordt gewijzigd van de oorspronkelijke URL-methode naar een nieuwe subdomeinmethode. Hierdoor zijn er enkele redirects, die veel bezoeken van Google crawlers genereren. We moeten Google snel laten begrijpen dat de oude URL's verwijzen naar de nieuwe URL's.
Om het crawlbudget optimaal te benutten, moeten we dus de snelheid van het redirectverkeer zo hoog mogelijk houden.
Voorheen stonden de GKE's in de eerder genoemde 8 regio's, en elke GKE maakte gebruik van Googles GKE Autopilotom redirects uit te voeren op basis van gegevens die niet gekoppeld zijn aan de database.
Daarom hebben we besloten om een aantal logica's die zich in de GKE bevinden en andere logica's die zich in Cloud Run bevinden naar een nieuwe Cloud Run-omgeving te verplaatsen. De te verplaatsen elementen zijn als volgt:
- robots.txt: Hoewel het een statisch bestand is, wordt het vanuit verschillende subdomeinen met een bepaalde logica geserveerd.
- favicon.ico: Puur statisch bestand.
- durumis.com/[lang]/@userId/postID: Redirect naar nieuwe URL -> userId.durumis.com/[lang]/postID
Bij het serveren via het iets zwaardere framework in GKE Autopilot was de responstijd ongeveer 200 ms.
De nieuwe methode maakt gebruik van Cloud Run en omdat de logica heel eenvoudig is, gebruiken we geen framework, maar node:http zonder libraries en met basiscode.
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}/); });
(Als u de bovenstaande code letterlijk kopieert, werkt deze niet. U moet alleen het concept begrijpen.)
Omdat favicon.ico een afbeeldingsbestand is, hebben we gekozen om het uit een bestand te laden en in het geheugen te bewaren, en vervolgens te verzenden.
We gebruiken een shellscript met gcloud om de implementatie gelijktijdig naar meerdere regio's te pushen.
En voilà...
Het resultaat van de implementatie is als volgt:
Cloud Run scherm
We hebben het geïmplementeerd in "alle regio's" van de Verenigde Staten, en daarnaast in 2 regio's in Europa, 2 regio's in Azië, 1 regio in Afrika en 2 regio's in Zuid-Amerika. Dit is eigenlijk een van de voordelen van Serverless: zelfs als u het op deze manier implementeert, stijgen de kosten niet. (En als u verkeer uit nabijgelegen regio's serveert, kunnen de kosten zelfs dalen.)
Laten we eens kijken hoe snel het nu is geworden.
De oorspronkelijke responstijd van de server was als volgt:
GKE Autopilot
De verbeterde snelheid is als volgt:
Cloud Run voor statische bestanden
U zou kunnen denken dat er een cold start-tijd is bij Cloud Run omdat het Serverless is, maar in een situatie waarin er regelmatig crawls plaatsvinden, is dit geen probleem. Een van de kenmerken van GCP's Serverless is dat het tussen Standby en Idle wisselt en wacht. (En het kost ook niets extra.)
In de volgende post zal ik het hebben over andere bestanden dan kleine statische bestanden of 301-redirects, zoals afbeeldingsbestanden en andere bestandstypen.