Dicembre dedicato alla scansione: CDN e scansione

Martedì 24 dicembre 2024

Le reti CDN (Content Delivery Network) sono particolarmente adatte per ridurre la latenza del vostro sito web e, in generale, per evitare problemi relativi al traffico web. Dopotutto, il loro scopo principale è la pubblicazione rapida dei contenuti anche se il sito riceve molto traffico. La "D" in CDN sta per "delivery" o "distribution", ovvero pubblicazione o distribuzione dei contenuti in tutto il mondo, quindi i tempi di trasferimento dei contenuti agli utenti sono inferiori rispetto a un semplice hosting in un data center. In questo post vedremo come utilizzare le CDN in modo da migliorare la scansione e l'esperienza degli utenti sul vostro sito, nonché alcune particolarità della scansione dei siti basati su CDN.

Riepilogo: che cos'è una CDN?

Le CDN sono sostanzialmente un intermediario tra il server di origine (dove si trova il sito web) e l'utente finale per cui vengono pubblicati (alcuni) file. In passato, l'obiettivo principale delle CDN era la memorizzazione nella cache, il che significa che, una volta che un utente richiedeva un URL dal vostro sito, le CDN memorizzano i contenuti dell'URL in questione nelle loro cache per un po' di tempo in modo che il server non dovesse più pubblicare di nuovo il file per un po'.

Le CDN possono velocizzare notevolmente il sito servendo gli utenti da una località vicina. Ad esempio, se un utente in Australia accede a un sito ospitato in Germania, una CDN pubblicherà i contenuti dalle sue cache in Australia, riducendo il percorso a livello mondiale. Che sia alla velocità della luce o meno, la distanza è comunque piuttosto grande.

Infine, le CDN sono uno strumento eccezionale per proteggere il sito da sovraccarichi e alcune minacce alla sicurezza. Grazie alla quantità di traffico globale gestito, le CDN possono creare modelli di traffico affidabili per rilevare anomalie del traffico e bloccare gli accessi che sembrano eccessivi o dannosi. Ad esempio, il 21 ottobre 2024, i sistemi di Cloudflare hanno rilevato e mitigato autonomamente un attacco DDoS di 4,2 Tbps (molto, molto elevato) durato circa un minuto.

In che modo le CDN possono essere utili per il vostro sito

Potreste avere i server più veloci e l'uplink migliore sul mercato e potreste pensare di non dover accelerare nulla, ma le CDN possono farvi risparmiare denaro a lungo termine, soprattutto se il vostro sito è di grandi dimensioni:

  • Memorizzazione nella cache sulla CDN: se risorse come contenuti multimediali, JavaScript e CSS o persino il codice HTML vengono pubblicate dalle cache di una CDN, i server non devono utilizzare risorse di calcolo e larghezza di banda per pubblicare queste risorse, riducendo così il proprio carico. In genere, ciò significa anche che le pagine si caricano più velocemente nei browser degli utenti, il che è correlato a conversioni migliori.
  • Protezione da attacchi di traffic flood: le CDN sono particolarmente efficaci nell'identificare e bloccare il traffico eccessivo o dannoso, consentendo agli utenti di visitare il vostro sito anche quando bot o malintenzionati con comportamenti illeciti sovraccaricano i vostri server.
    Oltre alla protezione dagli attacchi di tipo flood, gli stessi controlli utilizzati per bloccare il traffico dannoso possono essere utilizzati anche per bloccare il traffico che semplicemente non volete ricevere, ad esempio determinati crawler, client che si adattano a un dato schema o semplicemente troll che continuano a utilizzare lo stesso indirizzo IP. Sebbene sia possibile eseguire questa operazione anche sul server o nel firewall, in genere è molto più facile utilizzare l'interfaccia utente di una CDN.
  • Affidabilità: alcune CDN possono mostrare il vostro sito agli utenti anche se non è funzionante. Ovviamente, questo potrebbe funzionare solo per i contenuti statici, ma potrebbe essere già sufficiente per assicurarvi che gli utenti non si rivolgano altrove.

In breve, le CDN sono vostre alleate e se il vostro sito è di grandi dimensioni o prevedete (o addirittura ricevete già) un volume elevato di traffico, vi consigliamo di trovarne una adatta alle vostre esigenze in base a fattori quali prezzo, prestazioni, affidabilità, sicurezza, assistenza clienti, scalabilità ed espansione futura. Rivolgetevi al vostro provider di hosting o CMS per conoscere le opzioni a vostra disposizione (e per sapere se ne utilizzate già una).

In che modo la scansione influisce sui siti con CDN

Le CDN possono essere utili anche per quanto riguarda la scansione, ma possono causare alcuni problemi (anche se raramente). Continuate a leggere per saperne di più.

Effetto delle CDN sulla frequenza di scansione

La nostra infrastruttura di scansione è progettata per consentire frequenze di scansione più elevate sui siti supportati da una CDN, che viene dedotta dall'indirizzo IP del servizio che pubblica gli URL a cui accedono i nostri crawler. Questo metodo funziona bene, almeno la maggior parte delle volte.

Supponiamo che decidiate di lanciare oggi un sito di foto di stock e che abbiate 1.000.007 foto disponibili. Potete lanciare il sito web con una pagina di destinazione, pagine di categoria e pagine dei dettagli per tutti i vostri contenuti, il che alla fine vi porterebbe ad avere molte pagine. Nella nostra documentazione sul limite di capacità di scansione spieghiamo che, anche se la Ricerca Google vorrebbe eseguire la scansione di tutte queste pagine il più rapidamente possibile, la scansione non deve sovraccaricare i vostri server. Se il server inizia a rispondere lentamente quando deve gestire un numero maggiore di richieste di scansione, Google applica limitazioni per evitare che il server si sovraccarichi. La soglia per queste limitazioni è molto più alta quando la nostra infrastruttura di scansione rileva che il sito è supportato da una CDN e presume che sia possibile inviare più richieste simultanee perché il server molto probabilmente può gestirle, eseguendo così la scansione del negozio web più velocemente.

Tuttavia, al primo accesso a un URL la cache della CDN è "fredda", il che significa che, poiché nessun utente ha ancora richiesto quell'URL, i relativi contenuti non sono ancora stati memorizzati nella cache dalla CDN, pertanto il server di origine dovrà comunque pubblicare quell'URL almeno una volta per "riscaldare" la cache della CDN. Questo processo è molto simile anche al funzionamento della memorizzazione nella cache HTTP.

In breve, anche se il vostro negozio web è supportato da una CDN, il vostro server dovrà pubblicare questi 1.000.007 URL almeno una volta. Solo dopo la pubblicazione iniziale, la CDN può aiutarvi con le sue cache. Si tratta di un carico significativo per il vostro "budget di scansione" e la frequenza di scansione sarà probabilmente elevata per alcuni giorni. Tenetelo presente se prevedete di lanciare molti URL contemporaneamente.

Effetto delle CDN sul rendering

Come spiegato nel nostro primo post del blog di dicembre sulla scansione delle risorse, suddividere le risorse in base al proprio nome host o a un nome host CDN (cdn.example.com) potrebbe consentire al nostro servizio di rendering web (WRS) di eseguire il rendering delle vostre pagine in modo più efficiente. Tuttavia, è necessario fare attenzione: questa pratica potrebbe influire negativamente sulle prestazioni delle pagine a causa dell'overhead di una connessione a un nome host diverso, pertanto dovete tenere attentamente in considerazione l'esperienza sulle pagine con le prestazioni di rendering.

Se supportate l'host principale con una CDN, evitate questo problema: un nome host da sottoporre a query e le risorse di rendering critiche vengono probabilmente pubblicati dalla cache della CDN, quindi il vostro server non deve pubblicarli (e non viene eseguito alcun hit sull'esperienza sulle pagine).

Infine, scegliete la soluzione più adatta alla vostra attività: utilizzate un nome host distinto (cdn.example.com) per le risorse statiche, supportate il nome host principale con una CDN o applicate entrambe le soluzioni. L'infrastruttura di scansione di Google supporta entrambe le opzioni senza problemi.

Quando le CDN sono eccessivamente protettive

A causa della protezione dal traffic flood delle CDN e del modo in cui i crawler eseguono la scansione, a volte i bot che volete sul vostro sito possono finire nella lista bloccata della vostra CDN, in genere nel web application firewall (WAF). In questo modo, i crawler non possono accedere al vostro sito, il che potrebbe impedirne la visualizzazione nei risultati di ricerca. Il blocco può avvenire in vari modi, alcuni più dannosi per la presenza di un sito nei risultati di ricerca di Google rispetto ad altri, e può essere complicato (o impossibile) per voi controllarli poiché si verificano a livello di CDN. In questo post del blog, li abbiamo suddivisi in due gruppi: blocchi rigidi e blocchi flessibili.

Blocchi rigidi

I blocchi rigidi si verificano quando la CDN invia una risposta a una richiesta di scansione che è in qualche modo un errore. Ad esempio:

  • Codici di stato HTTP 503/429: l'invio di questi codici di stato è il modo migliore per segnalare un blocco temporaneo. Vi darà il tempo di reagire ai blocchi involontari della CDN.
  • Timeout di rete: i timeout di rete della CDN causeranno la rimozione degli URL interessati dall'indice della Ricerca Google, poiché questi errori di rete sono considerati definitivi e "irreparabili". Inoltre, possono influire notevolmente sulla frequenza di scansione del vostro sito perché segnalano alla nostra infrastruttura di scansione che il sito è sovraccaricato.
  • Messaggio di errore casuale con un codice di stato HTTP 200: noto anche come errore soft, si tratta di un errore grave. Se il messaggio di errore è equiparato da Google a un errore "irreparabile" (ad esempio un 500 HTTP), Google rimuoverà l'URL dalla Ricerca. Se Google non riesce a rilevare i messaggi di errore come "irreparabili", tutte le pagine con lo stesso messaggio di errore potrebbero essere eliminate come duplicate dall'indice della Ricerca Google. Poiché l'indicizzazione di Google raramente richiede una nuova scansione degli URL duplicati, il recupero potrebbe richiedere più tempo.

Blocchi flessibili

Un problema simile potrebbe verificarsi quando la vostra CDN mostra interstitial del tipo "Sei davvero una persona?".

Crawley confuso per essere chiamato "persona"

I nostri crawler sono infatti convinti di NON essere umani e non fingono di esserlo. Vogliono solo eseguire la scansione. Tuttavia, quando viene visualizzato questo interstitial, è l'unica cosa che vedono, non il vostro fantastico sito. In caso di interstitial per la verifica dei bot, consigliamo vivamente di inviare un messaggio chiaro sotto forma di codice di stato HTTP 503 ai client automatici come i crawler per indicare che i contenuti non sono temporaneamente disponibili. In questo modo, i contenuti non verranno rimossi automaticamente dall'indice di Google.

Debug dei blocchi

In caso di blocchi sia rigidi che flessibili, il modo più semplice per verificare se tutto funziona correttamente è utilizzare lo strumento Controllo URL in Search Console e osservare l'immagine visualizzata: se viene mostrata la vostra pagina, non ci sono problemi; se vedete una pagina vuota, un errore o una pagina con una verifica del bot, vi consigliamo di contattare il fornitore della vostra CDN.

Inoltre, per aiutarvi a risolvere questi blocchi involontari, Google, altri motori di ricerca e altri operatori di crawler pubblicano i nostri indirizzi IP per consentirvi di identificare i nostri crawler e, se lo ritenete opportuno, rimuovere gli IP bloccati dalle regole WAF o addirittura inserirli nella lista consentita. La possibilità di farlo dipende dalla CDN che utilizzate. Per fortuna, la maggior parte delle CDN e dei WAF autonomi dispone di una documentazione eccezionale. Ecco alcune risorse che abbiamo trovato con un po' di ricerca (alla data di pubblicazione di questo post):

Se volete che il vostro sito venga visualizzato nei motori di ricerca, vi consigliamo vivamente di verificare se i crawler che vi interessano possono accedere al sito. Ricordate che gli IP potrebbero finire automaticamente in una lista bloccata, a vostra insaputa, quindi controllare di tanto in tanto le liste bloccate è una buona idea per assicurarvi che il sito compaia nella Ricerca e non solo. Se la lista bloccata è molto lunga (non diversamente da questo post del blog), provate a cercare solo i primi segmenti degli intervalli IP, ad esempio, anziché cercare 192.168.0.101, potete semplicemente cercare 192.168.

Questo è l'ultimo post della nostra serie di post del blog di dicembre sulla scansione. Ci auguriamo che vi siano piaciuti tanto quanto a noi è piaciuto scriverli. Se avete… bla bla bla… lo sapete già.

Scritto da Martin Splitt e Gary Illyes

Vuoi saperne di più sulla scansione? Dai un'occhiata all'intera serie "Dicembre dedicato alla scansione":