Il sito deve reggere la campagna: prepararsi ai picchi di Google Ads

Il giorno in cui parte una campagna, il sito riceve in poche ore più visite di quante ne veda di solito in una settimana. Se non è pronto, rallenta o smette di rispondere proprio quando ogni visitatore ti è costato un clic. Vediamo come preparare il sito a reggere una campagna, cosa facciamo noi e cosa conviene controllare prima di premere «Pubblica».

Il picco del lancio

Le campagne non portano traffico in modo uniforme. Al lancio, nelle ore serali, durante una promozione o dopo un invio di newsletter collegato, le visite arrivano tutte insieme. Un sito che regge benissimo cento visitatori all’ora può andare in difficoltà con mille nello stesso quarto d’ora, soprattutto se ogni pagina va costruita da zero.

Pagine pronte e pagine generate al momento

È la differenza che conta di più.

• Pagine in cache: sono già pronte. Con iWebLab Cache sulla rete iWebLab Edge vengono servite da un punto vicino al visitatore, in pochi millisecondi, senza far lavorare il server. Mille visite alla stessa pagina pesano quasi come una.
• Pagine generate al momento: il server esegue PHP, interroga il database e costruisce la pagina a ogni visita. Sotto picco, è qui che nascono i rallentamenti.

Alcune pagine non possono stare in cache, ed è giusto così: carrello, cassa, area cliente e tutto ciò che è personale. Sono anche le pagine più importanti per incassare. Se le pagine di atterraggio sono in cache, il server ha più risorse libere proprio per carrello e pagamento.

I parametri delle campagne non rompono la cache

Google Ads aggiunge agli indirizzi parametri come gclid, e spesso si usano i parametri utm_ per le statistiche. Con iWebLab Cache sulla rete iWebLab Edge questi parametri di tracciamento vengono riconosciuti: la pagina resta servita dalla cache anche quando l’indirizzo li contiene. Il discorso è diverso per i parametri che cambiano davvero la pagina, come i filtri dei negozi: per questo le campagne vanno mandate su pagine dedicate e non su categorie filtrate.

Errori 5xx: soldi persi

Un errore 500, 502 o 503 durante una campagna significa che la persona ha cliccato, tu hai pagato, e lei ha visto una pagina d’errore. Se gli errori durano, Google può anche segnalare la pagina di destinazione come non funzionante e sospendere gli annunci. Le cause più comuni sotto picco:

• risorse del piano esaurite, perché molte pagine vengono generate al momento;
• un plugin o una ricerca interna che pesa molto sul database;
• pagine di atterraggio non in cache, per esempio perché contengono parametri di filtro.

La lista dei controlli prima del lancio

1. Apri la pagina di destinazione da telefono, con la rete mobile e non con il Wi-Fi dell’ufficio.
2. Verifica che sia in cache: se usi iWebLab Cache, il pannello del plugin mostra lo stato della pagina; nel dubbio chiedi a noi.
3. Controlla il percorso d’acquisto: aggiungi al carrello, arriva alla cassa, prova un pagamento di prova se il tuo sistema lo permette.
4. Togli ciò che non serve dalla pagina: finestre a comparsa, video che partono da soli, script non necessari.
5. Misura con PageSpeed Insights, più di una volta, e sistema i problemi principali.
6. Non avviare la campagna con il sito in manutenzione o con lavori in corso: è più comune di quanto si pensi.

Avvisaci prima delle campagne grandi

Se prevedi un picco importante, una campagna nazionale, un’offerta lampo o un evento televisivo, avvisaci qualche giorno prima con un ticket. Possiamo controllare che le pagine di atterraggio siano in cache, verificare le risorse del piano e dirti se conviene un piano con più risorse per il periodo della campagna. Prevenire costa molto meno che inseguire un sito lento a campagna già partita.

Durante la campagna, Site Monitor tiene d’occhio le risorse dell’account e ti avvisa se si avvicinano al limite.

Dopo la campagna

Finita la campagna, vale la pena guardare i dati anche dal lato del sito: quanti visitatori sono arrivati, quanto tempo hanno impiegato le pagine a caricarsi nei momenti di picco, se ci sono stati errori. SEO Log Intelligence e Site Monitor aiutano a ricostruire cosa è successo. Se il sito ha sofferto, è il momento di decidere con calma cosa migliorare prima della prossima campagna: una pagina più leggera, una cache più completa o un piano con più risorse.

Tenere un piccolo diario delle campagne, con date, budget, pagine usate ed eventuali problemi, rende molto più semplice preparare la successiva e capire cosa ha funzionato davvero.

In sintesi

• Le campagne portano picchi: un sito che va bene ogni giorno può soffrire nelle ore del lancio.
• Le pagine in cache reggono il traffico quasi senza pesare sul server; carrello e cassa restano dinamici.
• I parametri di tracciamento come gclid e utm_ non rompono la cache; i filtri sì.
• Un errore 5xx durante la campagna è un clic pagato e perso: controlla tutto prima del lancio.

Hai una campagna importante in arrivo? Apri un ticket qualche giorno prima: controlliamo insieme che il sito sia pronto.