Parti dai percorsi critici, non da una scansione gigantesca
Scegli cinque-dieci URL e definisci il risultato atteso per ciascuno: una pagina di conferma, una ricevuta, un record CRM o il passaggio a un fornitore. Includi pagine pubbliche e azioni che generano entrate, fiducia, richieste di supporto o obblighi legali. Testa come visitatore in una finestra non autenticata e su un telefono.
Se un terzo gestisce un passaggio critico, mappa il handoff e il contatto di supporto. Puoi testare la transizione dal tuo lato, ma non certificare il fornitore. Classifica i riscontri come bloccante, degrado significativo o miglioramento in modo che il lavoro cosmetico non nasconda un percorso rotto.
Copri le rotte che generano entrate, fiducia, richieste di supporto o obblighi legali.
Ogni riscontro materiale necessita di un responsabile nominato e di una data target.
Controlla l’uso accessibile oltre l’aspetto
Accessibilità significa che le persone possono percepire e usare il sito con metodi di input diversi e tecnologie assistive. Nelle pagine selezionate, usa il Tab per navigare menu, controlli e moduli. Verifica il focus visibile da tastiera, l’operabilità senza mouse dei controlli essenziali e un percorso verso il contenuto principale. Le Easy Checks del W3C identificano il focus da tastiera e un link di salto (skip link) come utili elementi per una prima revisione.
Ispeziona testi alternativi significativi per le immagini, titoli di pagina, intestazioni, contrasto, comportamento dello zoom, alternative media ove necessarie, etichette dei moduli, campi obbligatori e messaggi di errore comprensibili. Invia una prova di invio non sensibile. Questa non è una verifica di conformità: il W3C avverte che le pagine possono superare i controlli rapidi pur contenendo barriere significative. Per lavori ad alto rischio, redesign o problemi noti, usa una valutazione qualificata.
Testa etichette, istruzioni, errori e il percorso reale fino alla conferma.
Il testo alternativo dovrebbe comunicare lo scopo dell’immagine; le intestazioni devono organizzare la pagina.
Verifica la findability senza promettere posizionamenti
La SEO aiuta i motori a comprendere i contenuti e aiuta le persone a decidere se visitare dalla ricerca. Per ogni pagina prioritaria, leggi titolo, principale intestazione, testo d’apertura, URL e link interni come un nuovo visitatore. Devono indicare lo scopo e portare a passaggi utili successivi. Google raccomanda URL descrittivi, contenuti utili e testo dei link descrittivo.
Se usi Google Search Console, ispeziona URL chiave dopo una release materiale. Google afferma che URL Inspection può aiutare a verificare come il suo crawler vede una pagina e se può accedere a risorse importanti. Correggi blocchi accidentali, link interni rotti o percorsi poco chiari, poi concedi tempo per il re-crawling. Google non garantisce indicizzazione o posizionamento.
Apri i link interni senza essere autenticato e registra pagine 404, loop e destinazioni irrilevanti.
Osserva la delivery dove i visitatori la percepiscono
La delivery include risposta del server, immagini, font, script, caching e terze parti. Esegui un controllo delle prestazioni dal browser sulle pagine prioritarie, poi ripeti il compito principale su un vero telefono. Segnala contenuti primari lenti ad apparire, controlli che rispondono tardi, salti di layout, risorse fallite o banner che bloccano un’azione. Core Web Vitals è un framework di web.dev per l’esperienza utente; usa le misurazioni per concentrare l’indagine, non per sostituire il test dei percorsi.
Rivedi nuovi tag, widget, embed, font e modifiche alle immagini con chi ha implementato. Le cache HTTP riutilizzano risposte precedenti. MDN spiega che Cache-Control comunica le regole di caching e che le risposte in cache possono essere fresh o stale. Dopo un rilascio, confronta sessioni browser ordinarie e fresche, poi fai esaminare al responsabile tecnico header e regole CDN. Evita cambi di cache generalizzati senza comprendere gli effetti su privacy e rilascio.
Registra se il contenuto primario appare, la pagina resta stabile e i controlli essenziali rispondono.
MDN osserva che un cookie da solo non rende una risposta privata; chiedi a un responsabile tecnico di rivedere il caching personalizzato.
Conferma la baseline di sicurezza e proteggi i cambiamenti ai pagamenti
Un controllo del proprietario può individuare lacune visibili; non è un penetration test. Apri il sito pubblico via HTTPS e prova HTTP. OWASP raccomanda TLS per tutte le pagine e descrive il redirect del traffico pubblico HTTP verso HTTPS come approccio comune. Scala avvisi su certificati o contenuti misti, domini inattesi e pagine HTTP che servono contenuti invece di reindirizzare in modo sicuro.
Conferma la proprietà corrente di publishing, dominio, DNS, pagamento, accesso ai plugin e backup. Un professionista qualificato o il fornitore dovrebbe rivedere configurazione TLS, patch, autenticazione, configurazione server e log. Per i pagamenti, usa solo metodi di test approvati dal fornitore o un ambiente non di produzione sicuro. Non inserire dati reali di carte o credenziali in un test informale e non affermare che un controllo visivo dimostri la conformità PCI.
Tratta un avviso di certificato, un avviso di contenuto non sicuro o un redirect inatteso come problema che blocca il rilascio finché non è indagato.
Indirizza sospette compromissioni, requisiti di sicurezza e domande di conformità ai pagamenti a revisori qualificati.
Dimostra il ripristino e chiudi il ciclo
Elenca cosa ricostruisce il percorso prioritario: versione dell’applicazione, database, media caricati, posizioni di configurazione, accesso a DNS e dominio, impostazioni delle integrazioni e contatti dei fornitori. La CISA consiglia di identificare i dati critici, proteggere i database del sito e operativi, mettere al sicuro i backup e testare il ripristino. Chiedi quando è stato testato un restore, cosa ha ripristinato, quanto ha impiegato e chi può autorizzarlo. Esegui prove in modo sicuro quando praticabile.
Prima di un rilascio, identifica la versione precedente, il trigger di inversione, l’approvatore e la gestione per DNS, cache, schema del database e cambi terzi. Un backup non è una soluzione istantanea e un rollback potrebbe non invertire dati esterni o eventi di pagamento. Conserva un registro di riscontri, evidenze, responsabile, data e risultato del retest.
Un registro di scope, data, risultato e lacune è più solido di “i backup girano.”
Verifica il percorso originariamente fallito dopo una correzione nell’ambiente rilevante.