Core Web Vitals ancora negativi dopo le correzioni: cosa controllare in Search Console

Ricostruire cosa è stato corretto e quando

Prepara un registro essenziale: problema iniziale, pagine coinvolte, intervento svolto, data di pubblicazione e verifiche effettuate. Scrivere soltanto “ottimizzazione completata” non permette di capire se sia stata modificata la homepage, un modello condiviso o l’intero sito. Conserva anche il rapporto precedente, con dispositivo e periodo visibili.

Chiedi al fornitore di distinguere le modifiche effettivamente online dalle prove eseguite su una copia di lavoro. Una versione rimasta in staging non cambia l’esperienza dei visitatori. Controlla inoltre che le risorse aggiornate siano servite correttamente: la guida alle modifiche del sito che non si vedono aiuta a riconoscere questo caso.

Un esempio ipotetico: sono state compresse le foto della pagina principale, mentre il rapporto segnala le schede del catalogo. Il lavoro può essere utile, ma la verifica deve tornare alle pagine interessate dall’avviso.

Confrontare il dato storico con le prove attuali

I valori sul campo rappresentano esperienze raccolte nel tempo; un test lanciato oggi descrive invece una prova nelle condizioni impostate. Nei Core Web Vitals i valori di gruppo si riferiscono agli ultimi 28 giorni e al settantacinquesimo percentile. Nei giorni successivi all’intervento possono quindi convivere visite precedenti e successive alla correzione.

Prepara due colonne di lavoro: evidenze attuali e andamento nel periodo. Nella prima conserva prove ripetibili sulle pagine corrette; nella seconda annota la data finale del rapporto consultato. Non confrontare una schermata mobile con una desktop, oppure una prova su una singola pagina con il valore dell’intero sito.

La metodologia CrUX descrive requisiti e popolazione del campione. Quel dato non coincide con tutte le visite registrate da Analytics. Per la diagnosi iniziale resta utile la guida su come trovare le cause di un sito lento; qui l’obiettivo è stabilire se il confronto dopo l’intervento sia coerente.

Verificare il modello di pagina, non soltanto un indirizzo

Search Console raggruppa pagine con un’esperienza simile e presenta URL di esempio. Il risultato di un indirizzo in PageSpeed può differire dal gruppo. Scegli quindi un campione che includa più condizioni: scheda breve e lunga, immagini differenti, presenza di video, varianti di contenuto e componenti aggiuntivi.

Puoi organizzare il collaudo con una tabella semplice, condivisa con chi esegue l’intervento.

Non scegliere soltanto il caso più leggero per dimostrare il risultato. Se il difetto appartiene a un componente riutilizzato, elenca dove compare e quali eccezioni richiedono una verifica separata.

Controllare che il problema iniziale sia davvero risolto

Ripeti l’azione che mostrava il difetto e verifica anche le funzioni vicine. Un’immagine principale più leggera non dimostra che il calendario risponda bene; un menu rapido non assicura che il contenuto resti stabile durante il caricamento. La scheda di collaudo deve nominare il problema osservato e l’evidenza della sua correzione.

Per approfondire le singole cause consulta le guide su LCP e contenuto principale, INP e risposta dei comandi oppure CLS e spostamenti del layout. Evita di cambiare continuamente componenti diversi senza conservare le misure precedenti.

Quando il traffico lo consente, affianca un monitoraggio delle esperienze reali. I dati devono permettere di riconoscere versione e tipo di pagina, senza raccogliere i valori personali inseriti nei moduli. Anche il codice di misurazione va mantenuto leggero per non introdurre il problema che dovrebbe osservare.

Avviare la convalida dopo aver controllato il gruppo

Nel rapporto Core Web Vitals, l’avvio del monitoraggio apre una finestra di 28 giorni sui dati CrUX. Non forza nuove scansioni né indicizzazione. Fallimenti ancora presenti possono impedire la conferma della correzione. Usa quindi questa funzione dopo aver verificato gli esempi e l’estensione dell’intervento.

Assegna un referente che segua il controllo e registri data di avvio, problema selezionato e stato osservato. Non è utile far ripartire il monitoraggio ogni mattina perché il grafico non cambia subito: renderebbe meno chiaro il calendario delle verifiche. Se emergono altri difetti, annotali separatamente prima di decidere come intervenire.

La consegna al cliente dovrebbe comprendere anche ciò che resta aperto. “Modifica pubblicata e verificata sul campione; monitoraggio in corso” è una descrizione più precisa di una dichiarazione generale di completamento basata soltanto su un test riuscito.

Decidere cosa fare se l’avviso rimane o i dati mancano

Se il monitoraggio segnala ancora un problema, apri i dettagli e riparti dall’esempio concreto. Controlla se usa realmente il componente aggiornato, se contiene una risorsa diversa o se ha ricevuto modifiche successive. Il confronto con il registro degli interventi aiuta a distinguere un difetto mai risolto da una regressione.

Quando manca un campione sufficiente, l’assenza del dato non dimostra che la pagina sia buona o cattiva. Mantieni prove tecniche rappresentative e osservazioni sugli utenti disponibili, documentando il limite. Non conviene generare visite artificiali per tentare di ottenere una classificazione.

Se i valori oscillano vicino a una soglia, confronta anche le condizioni delle visite e le integrazioni esterne. Il calendario commerciale può portare un pubblico diverso da quello abituale. Un nuovo widget o una galleria aggiunta dopo il collaudo meritano una verifica prima di attribuire tutto al ritardo del rapporto.

Concludere il lavoro con evidenze e controlli mantenibili

Raccogli una breve relazione finale: problema iniziale, causa verificata, modifica, pagine provate, risultati e questioni residue. Conserva i collegamenti ai rapporti e le condizioni dei test, in modo che un altro tecnico possa ripetere il controllo. Le sole schermate con un numero verde raccontano poco del percorso verificato.

Concorda quando ripetere il campione: cambio del tema, nuova integrazione, caricamento di molte foto o revisione di una funzione importante. Chi aggiorna i contenuti dovrebbe sapere quali limiti rispettare e come segnalare un rallentamento.

Le prestazioni restano collegate all’uso del sito. Verifica che il miglioramento accompagni lettura, ricerca e contatto, senza eliminare informazioni necessarie. Una buona classificazione dei Core Web Vitals non equivale a una promessa di posizionamento: la qualità del lavoro si dimostra anche nella continuità dei percorsi dei clienti.

Domande frequenti

Devo aspettare 28 giorni prima di fare qualsiasi controllo?

No. Puoi verificare subito che la modifica sia online e che il difetto iniziale sia risolto nelle prove concordate. Il rapporto storico e la convalida richiedono invece di osservare il periodo dei dati e l’evoluzione del campione.

Avviare la convalida fa visitare subito le pagine a Google?

No. Nel rapporto Core Web Vitals avvia il monitoraggio dei dati CrUX; non richiede una nuova scansione o una nuova indicizzazione delle pagine.

Se una pagina non compare nel rapporto significa che funziona bene?

Non necessariamente. Può mancare un campione sufficiente o la pagina può non rientrare negli esempi mostrati. La valutazione va completata con prove pertinenti al suo contenuto e alle sue funzioni.