Un dominio, sei verità diverse: cosa vedono DNS, TLS, browser, Googlebot, crawler social e scanner di sicurezza

https://example.com/artykul

e ottieni sei risposte diverse:

• il DNS afferma che il dominio punta a due indirizzi IP,
• il livello TLS vede un certificato che non copre www,
• il tuo browser mostra una pagina corretta e personalizzata,
• Googlebot indicizza un titolo più vecchio,
• LinkedIn mostra ancora l'immagine precedente,
• lo scanner di sicurezza assegna una valutazione bassa a causa di intestazioni mancanti.

Nessuna di queste osservazioni deve necessariamente essere falsa.

Ogni sistema osserva una porzione diversa dello stack, utilizza una cache diversa, invia un diverso insieme di intestazioni, può connettersi da una posizione diversa e non sempre esegue JavaScript nello stesso modo. La «verità di un sito web» non è un unico documento. È un insieme di stati visibili a client diversi.

Conclusione più importante: un dominio può funzionare correttamente nel browser del proprietario e, allo stesso tempo, avere un DNS errato per una parte dei resolver, un certificato non valido su un nodo CDN, contenuti non indicizzabili per Googlebot, un'anteprima social datata e una protezione debole delle risposte HTTP.

L'articolo non presuppone che ogni differenza sia un errore. La personalizzazione, le varianti linguistiche, la cache e l'infrastruttura distribuita sono normali. Il problema inizia quando la differenza è involontaria, invisibile nel monitoraggio oppure impedisce a un determinato client di raggiungere la versione corretta.

La documentazione e il comportamento dei sistemi descritti sono stati verificati il 23 luglio 2026.

Sei prospettive in un'unica tabella

Osservatore	Cosa verifica realmente	Cosa di solito non conosce	Cosa può cambiare il risultato
DNS	nome host, record, delega, cache, DNSSEC	contenuto HTML, percorso URL, titolo della pagina	resolver, TTL, regione, IPv4/IPv6
TLS	endpoint, SNI, certificato, SAN, chain, protocollo	contenuto della pagina e relativo SEO	indirizzo IP, nodo CDN, configurazione del virtual host
Browser	DNS, TLS, HTTP, HTML, CSS, JavaScript, cookies, cache, DOM	l'intenzione dell'autore e lo stato degli altri client	utente, viewport, locale, storage, service worker
Googlebot	accessibilità, robots, HTTP, HTML, risorse, rendering, canonical, noindex	contenuti che richiedono login o interazione	mobile-first, crawl cache, render queue, blocchi delle risorse
Crawler dei social	URL, redirect, metadata, immagine di anteprima, cache della piattaforma	l'esperienza completa dell'applicazione	piattaforma, cache, Open Graph, disponibilità dell'immagine
Scanner di sicurezza	la superficie pubblica e i test nel proprio ambito	l'intera logica di business, il codice e i ruoli degli utenti	tipo di scanner, autorizzazione, percorso, configurazione del test

«Lo stesso dominio» non significa sempre lo stesso test

Prima di confrontare i risultati, stabilisci con precisione la risorsa da analizzare:

http://example.com
https://example.com
https://www.example.com
https://example.com/
https://example.com/artykul
https://example.com/artykul?utm_source=test

Queste non sono richieste tecnicamente identiche. Possono:

• passare attraverso redirect diversi,
• utilizzare host diversi,
• raggiungere un virtual host diverso,
• avere regole di cache diverse,
• indicare canonical diversi,
• restituire intestazioni diverse,
• generare card social separate.

L'audit dovrebbe sempre registrare l'URL completo, l'orario, la posizione del test, lo user-agent, lo stato finale e la catena di redirect.

Verità numero 1: il DNS vede il nome, non la pagina

Il DNS traduce il nome host nei dati necessari per individuare il servizio. In una tipica query per:

https://example.com/artykul?id=42

al DNS interessa il nome:

example.com

Non analizza il percorso /artykul, i parametri ?id=42, il titolo HTML né il tag canonical. Il DNS è un sistema gerarchico di nomi e record di risorse.

Cosa può vedere la diagnostica DNS?

Tra le altre cose:

example.com.      IN A      192.0.2.10
example.com.      IN AAAA   2001:db8::10
www.example.com.  IN CNAME  edge.example.net.
example.com.      IN CAA    0 issue "letsencrypt.org"

Può inoltre verificare:

• i server NS,
• il record SOA,
• la posta MX,
• i dati TXT,
• i record HTTPS e SVCB,
• le firme DNSSEC.

Perché due persone possono ricevere risposte diverse?

La causa più semplice è la cache. Un resolver può conservare la risposta fino alla scadenza del TTL. Anche le risposte negative, come NXDOMAIN, possono essere memorizzate nella cache.

Le differenze possono derivare anche da:

• resolver diversi,
• versioni di cache differenti,
• infrastruttura geografica o load balancing DNS,
• risposte separate per IPv4 e IPv6,
• migrazioni tra operatori,
• server autoritativi non coerenti,
• una catena DNSSEC danneggiata.

Il DNSSEC autentica l'origine e l'integrità dei dati DNS, ma non cifra la query stessa. Un record DS errato può far sì che un resolver che esegue la validazione restituisca SERVFAIL, mentre un resolver senza validazione mostra comunque l'indirizzo.

Cosa il DNS non conferma?

Una risposta DNS corretta non dimostra che:

• il server sia attivo,
• la porta 443 sia aperta,
• il certificato sia valido,
• l'applicazione restituisca il codice 200,
• la pagina sia indicizzabile,
• le intestazioni di sicurezza siano implementate.

Il DNS indica dove il client deve tentare di connettersi. Non dice cosa troverà dopo la connessione.

Verità numero 2: il TLS vede l'identità dell'endpoint, non il contenuto dell'articolo

Dopo aver individuato l'indirizzo, il client stabilisce una connessione con il server e negozia il TLS. In un ambiente che gestisce più domini su un unico indirizzo, l'estensione SNI consente al client di indicare il nome del server per cui desidera ottenere la connessione.

Il livello TLS può rivelare, tra l'altro:

• le versioni di protocollo supportate,
• l'algoritmo negoziato,
• il certificato del server,
• i nomi SAN,
• l'autorità di certificazione,
• la data di scadenza,
• i certificati intermedi,
• il risultato della negoziazione ALPN, ad esempio HTTP/2.

TLS 1.3 è definito nella RFC 8446 e protegge il trasporto dei dati tra client e server.

Il certificato corrisponde al nome, non al contenuto

Il client verifica se il nome host corrisponde all'identità registrata nel certificato, in particolare nel subjectAltName.

Un certificato per:

example.com

non deve necessariamente coprire:

www.example.com
api.example.com

Un wildcard:

*.example.com

non copre automaticamente il dominio principale example.com né il dominio multilivello www.eu.example.com.

Perché un utente vede un certificato valido e un altro no?

Scenari possibili:

• A e AAAA puntano a server diversi,
• un nodo CDN non ha ricevuto il nuovo certificato,
• la configurazione SNI ha un default virtual host errato,
• il traffico proveniente da una determinata regione raggiunge un'infrastruttura diversa,
• l'origin ha un certificato diverso da quello dell'edge pubblico,
• una parte dei server invia una chain incompleta.

Dal punto di vista dell'utente è ancora «lo stesso dominio», ma dal punto di vista della rete non è lo stesso endpoint.

Cosa il TLS non sa?

Un TLS corretto non dimostra che:

• la pagina sia sicura a livello applicativo,
• il JavaScript non contenga XSS,
• l'utente abbia i permessi corretti,
• il canonical sia corretto,
• Google indicizzi il contenuto,
• la card Open Graph abbia un'immagine adeguata.

Il lucchetto verde indica una connessione protetta verso un nome accettato dal client. Non è un certificato di qualità dell'intera applicazione.

Verità numero 3: il browser vede il risultato del funzionamento dell'intero ambiente

Il browser svolge molto più lavoro del semplice download dell'HTML. Una navigazione tipica comprende DNS, connessione di trasporto, TLS, richiesta HTTP, parsing dell'HTML, download di CSS e JavaScript, costruzione di DOM e CSSOM, layout e rendering dei pixel.

Ciò che l'utente vede sullo schermo può essere diverso dal codice sorgente della risposta.

Source HTML, DOM e schermo sono tre cose diverse

HTML dal server

<div id="app"></div>
<script src="/app.js"></script>

DOM dopo l'esecuzione del JavaScript

<div id="app">
  <h1>Raport dla zalogowanego użytkownika</h1>
</div>

L'immagine sullo schermo

L'aspetto finale è influenzato inoltre da CSS, font, dimensione del viewport, disponibilità delle immagini, impostazioni di sistema e interazioni dell'utente.

Cosa personalizza la «verità del browser»?

• cookie e sessione,
• localStorage e sessionStorage,
• lingua del browser,
• fuso orario,
• larghezza dello schermo,
• prefers-color-scheme,
• prefers-reduced-motion,
• permessi,
• esperimento A/B,
• risposte API,
• stato di login.

Il browser dispone inoltre di una cache HTTP privata. Una risposta memorizzata come fresh può essere utilizzata senza un nuovo download, a seconda delle direttive di cache.

Un service worker può intercettare le richieste e restituire dati dalla propria cache o da una strategia offline personalizzata. Questo spiega le situazioni in cui un semplice refresh mostra ancora la vecchia versione, mentre la modalità privata presenta quella nuova.

Perché «da me funziona» è un test debole?

Il proprietario del sito può avere:

• una sessione di amministratore attiva,
• dati nella cache,
• un vecchio service worker,
• accesso a un'API non disponibile pubblicamente,
• una lingua e una regione diverse,
• estensioni che modificano la pagina,
• un banner o un onboarding già saltati.

Un test tramite browser dovrebbe includere un profilo pulito, la modalità privata, un dispositivo mobile, IPv4, IPv6 e un utente non autenticato.

Verità numero 4: Googlebot vede una pagina destinata al crawling, al rendering e all'indicizzazione

Google descrive la gestione delle pagine JavaScript come tre fasi principali:

1. crawling,
2. rendering,
3. indexing.

Googlebot scarica l'URL, analizza la risposta e può inoltrare la pagina al Web Rendering Service. Google utilizza per il rendering la versione aggiornata di Chrome, ma il risultato non deve necessariamente prodursi nello stesso momento del primo download.

Googlebot non è un utente comune

Google dispone di Googlebot Smartphone e Desktop e, per la maggior parte dei siti, indicizza principalmente la versione mobile. La maggior parte delle richieste proviene quindi dal crawler mobile.

Googlebot:

• non accede al tuo account,
• non possiede i tuoi cookie,
• non vede dati privati,
• non si comporta come un utente che esegue tutti gli scenari,
• può scaricare le risorse separatamente,
• è soggetto a robots.txt e ai controlli di indicizzazione.

Google indica esplicitamente che non caricherà il contenuto principale che richiede un'interazione, come un clic, l'inserimento di dati o lo spostamento di un elemento.

Robots.txt non è la stessa cosa di noindex

robots.txt controlla quali URL il crawler può scaricare. Google sottolinea che non si tratta di un meccanismo che garantisce la rimozione di un URL dai risultati.

Affinché noindex funzioni, il crawler deve poter scaricare la pagina e vedere il tag o l'intestazione. Se l'URL è al contempo bloccato in robots.txt, Google potrebbe non vedere noindex.

<meta name="robots" content="noindex">

oppure:

X-Robots-Tag: noindex

Il canonical è un suggerimento, non un comando assoluto

<link rel="canonical" href="https://example.com/artykul">

Google può scegliere una versione canonical diversa da quella indicata dal proprietario, poiché la canonicalizzazione tiene conto di molti segnali. Google definisce l'indicazione del canonical come un suggerimento, non una regola.

Cosa può vedere l'utente ma non Googlebot?

• contenuto visibile solo dopo aver cliccato «Mostra altro»,
• dati disponibili solo dopo il login,
• un elemento che dipende da un'API non disponibile,
• contenuto caricato da uno script bloccato,
• una versione desktop più ricca di quella mobile,
• un componente che funziona solo con i dati salvati nel browser.

Cosa può vedere Googlebot ma non un utente comune?

Ad esempio, il server può restituire una variante diversa per il suo user-agent. Un semplice adattamento tecnico non costituisce automaticamente una violazione, ma mostrare intenzionalmente al motore di ricerca contenuti sostanzialmente diversi da quelli mostrati agli utenti può essere considerato cloaking.

La pratica più sicura consiste nel rendere disponibile lo stesso contenuto rilevante nella risposta iniziale o in un rendering che non richieda l'interazione dell'utente.

Verità numero 5: il crawler dei social costruisce una card, non l'esperienza completa della pagina

Quando un URL viene incollato su Facebook, LinkedIn, Slack o un'altra piattaforma, il sistema può scaricare la pagina e costruire un'anteprima. Non bisogna presumere che ogni piattaforma esegua l'applicazione JavaScript esattamente come il browser completo dell'utente.

Il modo più portabile di descrivere una pagina sono i metadata inseriti nell'<head> dell'HTML iniziale.

Open Graph di base

La specifica Open Graph definisce quattro proprietà obbligatorie:

<meta property="og:title" content="Tytuł artykułu">
<meta property="og:type" content="article">
<meta property="og:image" content="https://example.com/og/article.jpg">
<meta property="og:url" content="https://example.com/artykul">

In pratica conviene aggiungere:

<meta property="og:description" content="Opis artykułu">
<meta property="og:image:width" content="1200">
<meta property="og:image:height" content="630">
<meta property="og:image:alt" content="Opis grafiki">

Meta/Facebook

Meta consiglia di utilizzare i tag Open Graph affinché il crawler possa recuperare il titolo, la descrizione e l'immagine di anteprima. La documentazione di Meta descrive anche il recupero e la memorizzazione nella cache dei metadata al momento della condivisione di un URL.

Ciò significa che la modifica di un'immagine sul server non cambia necessariamente in modo immediato una card esistente. La piattaforma può ancora conservare uno snapshot più vecchio.

LinkedIn

LinkedIn indica che le anteprime utilizzano, tra l'altro, Open Graph o oEmbed. Un'immagine datata può provenire dalla cache, e il Post Inspector consente di aggiornare i dati per le nuove condivisioni.

I post esistenti possono mantenere l'anteprima precedente anche dopo l'aggiornamento dell'URL.

Slack

Slack documenta il classico unfurling come un processo in cui, dopo aver rilevato un link, il sistema esegue il crawling della pagina e crea un'anteprima. Le app Slack possono inoltre fornire unfurl propri e programmabili.

Si tratta di una distinzione importante: una card in Slack può essere il risultato standard del crawling oppure un oggetto personalizzato restituito da un'integrazione.

Perché le piattaforme mostrano immagini diverse?

• una piattaforma ha una cache datata,
• un'altra non riesce a scaricare l'immagine,
• l'URL dell'immagine effettua un redirect,
• l'immagine ha un MIME o un codice di stato non disponibile,
• più og:image hanno un ordine diverso,
• la pagina ha tag separati per le diverse versioni linguistiche,
• il bot riceve una variante diversa tramite CDN o firewall,
• i metadata vengono aggiunti solo dal JavaScript.

La soluzione più sicura è inserire i tag social di base direttamente nell'HTML dal server e indicare indirizzi HTTPS assoluti.

Verità numero 6: lo scanner di sicurezza vede solo l'ambito che è in grado di analizzare

«Scanner di sicurezza» può indicare strumenti molto diversi:

• un analizzatore di intestazioni HTTP,
• uno scanner della configurazione TLS,
• un DAST che esegue richieste e test di vulnerabilità,
• un crawler dell'applicazione,
• un SAST che analizza il codice,
• uno scanner delle dipendenze,
• uno strumento per il test dell'infrastruttura.

In questo articolo parliamo principalmente di uno scanner esterno che analizza una pagina accessibile pubblicamente.

Cosa vede lo scanner delle intestazioni?

MDN HTTP Observatory valuta principalmente le intestazioni HTTP e alcune configurazioni di sicurezza.

Può verificare, tra l'altro:

• CSP,
• HSTS,
• la protezione dal framing,
• X-Content-Type-Options,
• i cookie,
• il redirect verso HTTPS,
• alcune policy cross-origin.

Ciò non significa che abbia letto il codice del backend, i ruoli degli utenti, la configurazione del database o tutti gli endpoint API.

Il voto in lettere non è un verdetto sull'intera sicurezza

La documentazione di Observatory precisa che lo scoring serve a indicare i meccanismi di sicurezza non utilizzati, e la necessità di una specifica intestazione può dipendere dal tipo di sito.

Una pagina può ottenere un punteggio elevato per le intestazioni e avere comunque:

• IDOR,
• un'autorizzazione errata,
• SQL Injection,
• un pannello di amministrazione vulnerabile,
• chiavi esposte,
• una logica di business che consente abusi.

È possibile anche la situazione inversa: un semplice endpoint JSON riceverà una valutazione più bassa per l'assenza di intestazioni tipiche di un documento HTML, anche se alcune di esse non hanno per esso lo stesso significato.

Il DAST ha un ambito diverso, ma anch'esso dei limiti

OWASP descrive i web application vulnerability scanner come strumenti che testano esternamente le applicazioni alla ricerca di vulnerabilità e configurazioni errate.

ZAP avverte che la scansione automatica ha dei limiti. Senza un'autenticazione configurata non individuerà le pagine protette da login, e lo spider automatico non eseguirà tutti i processi utente realistici.

Il risultato dipende da:

• l'account e il ruolo utilizzati nel test,
• gli URL disponibili,
• i moduli e i dati di test,
• l'ambito dei domini,
• lo user-agent,
• i limiti del WAF,
• il tempo di scansione,
• il fatto che lo scanner esegua o meno JavaScript.

Lo scanner dice: «in questo ambito ho trovato o non ho trovato determinati segnali». Non dice: «ho dimostrato l'assenza di tutte le vulnerabilità».

Un solo URL, sei report corretti

L'esempio seguente è ipotetico, ma tecnicamente realistico.

Indirizzo analizzato:

https://example.com/raport

DNS

A:    192.0.2.10
AAAA: 2001:db8::20
TTL:  300

Conclusione: il dominio ha due possibili endpoint.

TLS su IPv4

SAN: example.com, www.example.com
TLS: 1.3
Chain: poprawny

TLS su IPv6

SAN: old.example.net
TLS: 1.2
Chain: poprawny, ale zła nazwa

Conclusione: una parte dei client non aprirà la pagina.

Il browser del proprietario

• utilizza IPv4,
• ha una sessione attiva,
• il service worker restituisce la versione dalla cache,
• mostra il report aggiornato.

Conclusione dell'utente: «tutto funziona».

Googlebot Smartphone

• arriva tramite IPv6,
• non riesce a completare il TLS,
• non scarica la pagina.

Conclusione SEO: il nuovo contenuto non viene sottoposto a crawling.

LinkedIn

• ha un'anteprima salvata una settimana prima,
• mostra il precedente og:image.

Conclusione di marketing: la card non è aggiornata.

Scanner delle intestazioni

• testa IPv4,
• scarica il documento senza login,
• rileva l'assenza di CSP e HSTS.

Conclusione di sicurezza: il trasporto funziona, ma l'hardening delle risposte è incompleto.

Tutti i report descrivono una porzione diversa del sistema.

Matrice dei sintomi

Sintomo	Prospettiva più probabile	Primo test
La pagina funziona solo per una parte degli utenti	DNS, IPv6 o TLS	dig A/AAAA, test di entrambi gli indirizzi
Certificato di un altro dominio	TLS/SNI	openssl s_client -servername
Dopo il deploy si vede ancora la vecchia pagina	cache del browser o service worker	profilo pulito, DevTools Application
Google mostra un vecchio titolo	crawl/index cache o canonical diverso	URL Inspection, verifica del rendered HTML
La pagina non è nell'indice	robots, noindex, errori di crawling	robots.txt, Search Console
Facebook o LinkedIn mostra una vecchia immagine	cache del crawler dei social	debugger o Post Inspector
Lo scanner segnala l'assenza di HSTS, mentre il browser usa HTTPS	intestazioni della risposta	curl -I per l'URL finale
Il risultato dello scanner è buono, ma la funzione ha un problema di accesso	logica applicativa fuori dall'ambito dello scanner	test di autorizzazione e ruoli
Il contenuto mobile è più povero in Google	mobile-first e contenuto differente	confronto del rendering mobile
noindex non funziona	URL bloccato in robots.txt	consentire il crawling ed eseguire nuovamente il test

Metodologia di un audit completo

1. Registra la catena completa degli URL

curl -IL https://example.com/artykul

Presta attenzione a:

• gli stati,
• il cambio di host,
• il passaggio HTTP→HTTPS,
• l'URL finale,
• il numero di redirect.

2. Verifica il DNS da più resolver

dig example.com A
dig example.com AAAA
dig example.com NS
dig example.com CAA
dig example.com A +dnssec

Confronta le risposte con il resolver dell'operatore, un resolver pubblico e un server autoritativo.

3. Verifica ogni endpoint TLS

openssl s_client \
  -connect 192.0.2.10:443 \
  -servername example.com \
  -showcerts

Ripeti per IPv6 e per gli altri indirizzi restituiti dal DNS.

4. Verifica la risposta HTTP senza stato utente

curl -sS -D headers.txt https://example.com/artykul -o page.html

Verifica:

• il codice di stato,
• Content-Type,
• la cache,
• CSP,
• HSTS,
• X-Robots-Tag,
• il contenuto di <head>.

5. Confronta il source HTML e il DOM

Nel browser verifica:

• View Source,
• il pannello Elements,
• Network,
• Application,
• il service worker attivo,
• cache storage,
• i cookie.

6. Verifica Googlebot

Usa lo strumento URL Inspection in Google Search Console e confronta:

• l'HTML scaricato,
• l'HTML renderizzato,
• screenshot,
• le risorse che non è stato possibile caricare,
• il canonical indicato e quello scelto da Google,
• la possibilità di indicizzazione.

Non identificare Googlebot solo in base allo user-agent. Google consiglia la verifica tramite reverse DNS o gli intervalli IP ufficiali.

7. Verifica la card social

Analizza:

<title>
<meta name="description">
<meta property="og:title">
<meta property="og:description">
<meta property="og:image">
<meta property="og:url">

Successivamente usa gli strumenti di aggiornamento della specifica piattaforma.

8. Esegui più classi di test di sicurezza

• l'analisi delle intestazioni,
• il test TLS,
• il DAST su un ambiente dedicato,
• i test di autenticazione e autorizzazione,
• l'analisi delle dipendenze,
• la revisione del codice e della configurazione.

Una singola valutazione non sostituisce le altre.

<head> esemplare accessibile a client diversi

<!doctype html>
<html lang="pl">
<head>
  <meta charset="utf-8">
  <meta name="viewport" content="width=device-width, initial-scale=1">

  <title>Jedna domena, sześć różnych prawd</title>
  <meta
    name="description"
    content="Jak DNS, TLS, przeglądarka, Googlebot, social crawler i skaner bezpieczeństwa widzą tę samą domenę."
  >

  <link
    rel="canonical"
    href="https://example.com/jedna-domena-szesc-prawd"
  >

  <meta name="robots" content="index,follow">

  <meta
    property="og:title"
    content="Jedna domena, sześć różnych prawd"
  >
  <meta property="og:type" content="article">
  <meta
    property="og:url"
    content="https://example.com/jedna-domena-szesc-prawd"
  >
  <meta
    property="og:image"
    content="https://example.com/images/six-truths-1200x630.jpg"
  >
  <meta property="og:image:width" content="1200">
  <meta property="og:image:height" content="630">
  <meta
    property="og:image:alt"
    content="Schemat sześciu warstw obserwujących jedną domenę"
  >
</head>

I metadata più importanti sono nella risposta HTML, e non solo dopo l'avvio dell'applicazione.

Checklist pratica delle «sei verità»

DNS

• A e AAAA puntano a endpoint attivi.
• Tutti i server autoritativi restituiscono dati coerenti.
• Il TTL è comprensibile e monitorato.
• Il DNSSEC supera la validazione.
• www e apex hanno il comportamento previsto.
• Il test è stato eseguito da più resolver e posizioni.

TLS

• Ogni indirizzo IP restituisce il certificato corretto.
• Il SAN copre ogni hostname utilizzato.
• La chain è completa.
• IPv4 e IPv6 hanno la stessa qualità di configurazione.
• L'SNI seleziona il virtual host corretto.
• CDN e origin hanno un TLS corretto.

Browser

• La pagina funziona in un profilo pulito.
• È stata verificata la versione non autenticata.
• Il source HTML contiene il contenuto chiave e i metadata.
• Il DOM dopo il rendering è conforme alle aspettative.
• Il service worker e la cache non mascherano il deploy.
• La versione mobile contiene il contenuto completo.
• Gli errori dell'API vengono gestiti.

Googlebot

• robots.txt consente di scaricare la pagina e le risorse.
• noindex è conforme all'intenzione.
• Il canonical è coerente con i redirect e la sitemap.
• Il contenuto principale non richiede un clic.
• Il rendering mobile contiene lo stesso contenuto rilevante.
• URL Inspection mostra un HTML e uno screenshot corretti.
• Le risorse CSS e JS sono disponibili.

Crawler dei social

• L'Open Graph di base è presente nell'HTML iniziale.
• og:url indica l'URL stabile corretto.
• og:image è un indirizzo HTTPS assoluto.
• L'immagine restituisce 200 e un MIME corretto.
• Le dimensioni dell'immagine sono dichiarate.
• Ogni versione linguistica ha i metadata corretti.
• La cache della piattaforma è stata aggiornata dopo la modifica.

Sicurezza

• Sono state testate le intestazioni della risposta finale.
• Il test include più della sola homepage.
• Sono stati verificati gli endpoint dopo il login.
• I ruoli degli utenti sono stati testati separatamente.
• I risultati automatici sono stati verificati da una persona.
• Il DAST è stato integrato con SAST e analisi delle dipendenze.
• Una valutazione bassa o alta è stata interpretata nel contesto.

Strumenti POLPROG utili per un audit di questo tipo

• Ispettore DNS e SSL mostra i record del dominio e i dati del certificato.
• Open Graph Preview verifica i metadata e la card di condivisione.
• Ispettore delle intestazioni di sicurezza analizza l'hardening delle risposte HTTP.
• Stato di salute del sito combina i segnali di SEO, prestazioni, accessibilità e sicurezza.
• FlowTrace visualizza il percorso dall'evento nel browser attraverso DNS, TLS, CDN, backend e rendering.

I miti più comuni

«Se il sito funziona da me, funziona ovunque»

No. Il tuo resolver, protocollo IP, cache, cookie e nodo CDN possono essere diversi.

«Google vede esattamente la stessa cosa di Chrome»

Google renderizza le pagine tramite Chrome, ma Googlebot ha uno stato diverso, uno user-agent mobile-first, fasi di crawling e rendering separate e non esegue i contenuti che richiedono interazione.

«Robots.txt rimuove la pagina da Google»

No. Robots.txt limita il crawling. Per il controllo dell'indicizzazione si usa noindex, che deve essere visibile al crawler.

«Il canonical costringe Google a usare l'URL scelto»

No. È un segnale importante, ma Google può scegliere un canonical diverso.

«Ho cambiato og:image, quindi la card è già nuova»

Non sempre. La piattaforma può utilizzare la versione salvata e richiedere un nuovo download dell'URL.

«A+ nello scanner significa che l'applicazione è sicura»

No. Significa un punteggio elevato in uno specifico insieme di test. Non dimostra un'autorizzazione corretta, la logica di business né la sicurezza del codice.

Verdetto

Un dominio non ha un unico «volto» tecnico.

• Il DNS vede il nome e i record.
• Il TLS vede l'endpoint e l'identità del certificato.
• Il browser vede l'esperienza renderizzata di un utente specifico.
• Googlebot vede una risorsa disponibile per il crawling, il rendering e l'indicizzazione.
• il crawler dei social vede i metadata necessari per costruire una card.
• lo scanner di sicurezza vede solo la superficie coperta dai suoi test.

Un audit maturo quindi non chiede solo: «Il sito funziona?»

Chiede:

Dla kogo?
Z jakiej lokalizacji?
Po IPv4 czy IPv6?
Z jakim stanem cache?
Z jakim user-agentem?
Przed czy po wykonaniu JavaScriptu?
Z logowaniem czy bez?
W jakim zakresie testu?

Solo le risposte a queste domande creano un'immagine coerente del sistema.