Performance e sicurezza

Imunify360 è una piattaforma di sicurezza progettata per proteggere i server hosting e i siti web da malware, file infetti, accessi automatizzati, attacchi alle applicazioni e altre attività sospette.

Non si tratta semplicemente di un antivirus installato su WordPress. La protezione opera a livello server e può quindi controllare siti realizzati con WordPress, Joomla, PrestaShop, Drupal, applicazioni PHP personalizzate e pagine HTML statiche.

In sintesi: Imunify360 combina scansione antimalware, protezione in tempo reale, firewall applicativo e sistemi di prevenzione. Le funzionalità disponibili nel pannello cPanel possono variare in base al piano hosting, alla licenza e ai permessi configurati sul server.

Che cos’è Imunify360

Imunify360 è una soluzione di sicurezza multilivello per server Linux utilizzati nel web hosting. Integra diversi componenti che collaborano per individuare e bloccare attività potenzialmente dannose prima che possano compromettere un sito o propagarsi all’interno dello spazio web.

Tra le principali funzioni possono essere presenti:

  • scanner antimalware per file e applicazioni web;
  • controllo in tempo reale dei file caricati o modificati;
  • Web Application Firewall per filtrare richieste HTTP e HTTPS sospette;
  • firewall di rete e sistemi di rilevamento delle intrusioni;
  • protezione contro tentativi di accesso automatizzati e attacchi brute force;
  • Proactive Defense per analizzare il comportamento degli script PHP;
  • gestione degli indirizzi IP sospetti;
  • cronologia delle rilevazioni e delle operazioni effettuate.

Le funzioni effettivamente visibili al cliente dipendono dalla configurazione scelta dal provider. Alcune attività vengono eseguite automaticamente dal sistema, mentre altre possono richiedere un intervento tecnico o un’autorizzazione specifica.

Come protegge un sito web

Un sito può essere compromesso anche quando il CMS principale è aggiornato. Le vulnerabilità possono infatti trovarsi in plugin, temi, moduli, estensioni, credenziali deboli, vecchi account amministrativi o file caricati da fonti non affidabili.

Imunify360 interviene su più livelli.

Protezione delle richieste web

Il firewall applicativo analizza le richieste dirette al sito e può bloccare quelle che corrispondono a tentativi di exploit, scansioni automatizzate o comportamenti considerati pericolosi.

Le richieste sospette possono essere bloccate oppure sottoposte a una verifica CAPTCHA, in modo da distinguere un visitatore reale da un bot automatico.

Controllo del comportamento degli script PHP

La funzione Proactive Defense analizza il comportamento degli script durante l’esecuzione. Questo permette di intercettare sequenze pericolose anche quando il codice malevolo è offuscato, inserito all’interno di un file legittimo o non ancora riconosciuto da una firma tradizionale.

Scansione dei file

Il Malware Scanner controlla i file presenti nell’account hosting e può rilevare web shell, backdoor, codice PHP iniettato, pagine di phishing, redirect nascosti, script per l’invio di spam e altri contenuti sospetti.

Una rilevazione non indica necessariamente che l’intero sito debba essere eliminato. Prima di cancellare un file è importante verificare il percorso, la data di modifica, la funzione del file e la disponibilità di una copia originale o di un backup.

Come accedere a Imunify360 da cPanel

Quando il servizio è disponibile sul piano hosting, l’interfaccia può essere aperta da cPanel selezionando l’icona Imunify360 o ImunifyAV nella sezione dedicata alla sicurezza.

L’interfaccia utente può contenere le sezioni:

  • Files o Malicious: mostra i file nei quali è stata individuata una possibile minaccia;
  • History: conserva la cronologia delle rilevazioni e delle azioni eseguite;
  • Ignore List: contiene eventuali file o directory esclusi dai controlli, quando questa funzione è abilitata.

Il pulsante per avviare manualmente una scansione può non essere presente. La sua disponibilità dipende dai permessi assegnati all’account e dalla configurazione del server.

Come leggere l’elenco dei file infetti

La tabella dei file rilevati contiene normalmente alcune informazioni fondamentali:

  • Detected: data e ora della rilevazione;
  • File: percorso completo del file interessato;
  • Reason: firma o categoria associata alla rilevazione;
  • Status: stato attuale del file e dell’eventuale operazione di pulizia.

Gli stati più comuni sono:

  • Infected: il file contiene ancora il codice rilevato come dannoso;
  • Cleaned: il contenuto malevolo è stato rimosso;
  • Content removed: durante la pulizia è stato necessario rimuovere il contenuto del file;
  • Cleanup queued: la pulizia è stata inserita in coda ed è in attesa di esecuzione.

La sezione History è utile per ricostruire ciò che è accaduto: mostra quando un file è stato individuato, pulito, eliminato, ripristinato o aggiunto all’elenco delle esclusioni.

Pulire, eliminare o ripristinare un file

In base alla configurazione e alla licenza possono essere disponibili diverse azioni.

Cleanup

La funzione di pulizia tenta di rimuovere soltanto il codice dannoso, preservando la parte legittima del file. Dopo l’operazione è comunque necessario verificare il funzionamento del sito e confrontare il file con una copia originale.

Delete

L’eliminazione rimuove completamente il file dal server. Deve essere utilizzata con cautela, perché un file compromesso può essere anche un componente necessario al funzionamento del CMS, del tema o di un plugin.

Quando possibile è preferibile sostituire il file con una copia originale proveniente dal pacchetto ufficiale del software.

Restore original

Se è disponibile una copia precedente, l’interfaccia può consentire il ripristino del file originale. Anche in questo caso occorre verificare che la copia ripristinata sia sicura e che la vulnerabilità che ha causato l’infezione sia stata corretta.

Ignore List

L’aggiunta alla Ignore List esclude il file dai controlli successivi. Questa funzione non deve essere usata semplicemente per far sparire un avviso.

Un file dovrebbe essere escluso soltanto dopo aver verificato con certezza che si tratta di un falso positivo. Escludere un file realmente infetto potrebbe permettere al malware di continuare a operare senza essere nuovamente segnalato.

Cosa fare quando viene rilevato malware

La pulizia dei file è soltanto una parte dell’intervento. Se non viene individuato il punto di ingresso, il malware può ricomparire anche dopo una scansione conclusa correttamente.

Dopo una compromissione è consigliabile:

  1. conservare un backup prima di eliminare o modificare i file;
  2. aggiornare il CMS, i plugin, i temi e le estensioni;
  3. rimuovere componenti inutilizzati o provenienti da fonti non ufficiali;
  4. modificare la password di cPanel, FTP, database, email e account amministrativi;
  5. controllare gli utenti amministratori presenti nel CMS;
  6. verificare attività pianificate, file caricati e modifiche recenti;
  7. controllare eventuali redirect, pagine di phishing o account email compromessi;
  8. proteggere moduli di contatto e login con CAPTCHA;
  9. verificare i log per ricostruire l’origine dell’attacco;
  10. monitorare il sito dopo la bonifica per individuare nuove modifiche sospette.

Per una procedura più approfondita puoi consultare la guida su come rimuovere malware da WordPress in sicurezza.

Imunify360 sostituisce un plugin di sicurezza WordPress?

Imunify360 e un plugin WordPress operano su livelli differenti.

Un plugin può controllare impostazioni e attività interne a WordPress, ma viene eseguito dallo stesso sito che dovrebbe proteggere. Se WordPress non funziona, il plugin è disattivato oppure l’infezione interessa file esterni al CMS, il suo controllo può essere limitato.

Imunify360 opera invece sull’infrastruttura hosting e può analizzare file e richieste prima che WordPress venga eseguito. Questo consente di proteggere anche siti non realizzati con WordPress.

Le due soluzioni possono essere complementari, ma nessuna sostituisce aggiornamenti regolari, password sicure, backup e una corretta manutenzione del sito.

Su quali piani Xlogic è disponibile

La disponibilità di Imunify360 dipende dal servizio scelto.

Le caratteristiche commerciali possono cambiare nel tempo. Prima dell’acquisto è quindi opportuno verificare sempre la scheda aggiornata del singolo piano.

Altri approfondimenti su Imunify e malware

Domande frequenti su Imunify360

Imunify360 elimina automaticamente tutti i malware?

No. La possibilità di pulire automaticamente un file dipende dal tipo di infezione, dalla licenza e dalla configurazione del server. Alcuni file devono essere verificati, sostituiti o ripristinati manualmente.

Una scansione senza rilevazioni garantisce che il sito sia sicuro?

No. Una scansione è un controllo importante, ma potrebbero essere presenti vulnerabilità applicative, password compromesse, utenti amministrativi non autorizzati o codice dannoso non ancora riconosciuto.

Posso eliminare immediatamente tutti i file segnalati?

Non è consigliabile. Prima di eliminare un file bisogna controllare il percorso, creare un backup e verificare se il file appartiene al CMS, al tema o a un plugin necessario.

Perché il malware ricompare dopo la pulizia?

Le cause più frequenti sono una vulnerabilità non corretta, credenziali compromesse, una backdoor rimasta nello spazio web, un database infetto o un componente obsoleto.

Imunify360 rallenta il sito?

Le funzioni operano principalmente a livello server. L’impatto effettivo dipende dalla configurazione e dalle operazioni in corso, ma la piattaforma è progettata per integrare i controlli di sicurezza nell’ambiente hosting.

Posso avviare personalmente una scansione?

Solo se il piano, la licenza e i permessi dell’account lo consentono. In alcune configurazioni le scansioni vengono gestite automaticamente e il pulsante di avvio manuale non viene mostrato all’utente.

Imunify360 protegge soltanto WordPress?

No. Il controllo avviene a livello hosting e può interessare anche Joomla, PrestaShop, Drupal, applicazioni PHP personalizzate e siti HTML.

Proteggere il sito prima di una compromissione

La sicurezza più efficace nasce dalla combinazione di più misure: infrastruttura protetta, aggiornamenti regolari, password uniche, backup, controllo degli accessi e monitoraggio dei file.

Imunify360 aggiunge un importante livello di difesa sul server e permette di individuare rapidamente molti comportamenti sospetti. Per verificare se il servizio è incluso nel tuo piano, consulta le caratteristiche dell’hosting oppure contatta l’assistenza Xlogic.

Fonte tecnica: documentazione ufficiale Imunify360.

ERR_SSL_PROTOCOL_ERROR appare quando il browser non riesce a completare correttamente la connessione HTTPS con il sito. Il problema si verifica durante la negoziazione SSL/TLS oppure quando il server restituisce sulla porta 443 una risposta incompatibile con il protocollo atteso.

Risposta rapida: controlla data e ora del dispositivo, aggiorna il browser, prova un’altra rete e disattiva temporaneamente VPN, proxy o scansione HTTPS dell’antivirus. Se gestisci il sito, verifica certificato, dominio coperto, data di scadenza, catena completa, chiave privata, porta 443, configurazione SNI, web server, AutoSSL cPanel e modalità SSL/TLS di Cloudflare.

Il messaggio non indica necessariamente che il certificato sia scaduto. Può dipendere anche da una configurazione errata del server, da protocolli incompatibili, da un proxy che intercetta il traffico oppure da un problema tra Cloudflare e il server di origine.

Indice

Che cosa significa ERR_SSL_PROTOCOL_ERROR

HTTPS protegge la comunicazione tra browser e server attraverso TLS, successore del vecchio protocollo SSL. Prima di inviare la pagina, client e server devono completare un handshake: concordano il protocollo, verificano il certificato, selezionano gli algoritmi crittografici e stabiliscono le chiavi della sessione.

ERR_SSL_PROTOCOL_ERROR indica che questo processo non è terminato correttamente. Cloudflare descrive l’errore come un fallimento dell’handshake SSL/TLS che può dipendere da certificati, incompatibilità di protocollo o interferenze di rete.

Le cause più comuni sono:

  • data e ora del dispositivo non corrette;
  • browser o sistema operativo obsoleto;
  • VPN, proxy, filtro aziendale o antivirus che intercettano HTTPS;
  • porta 443 non configurata per TLS;
  • certificato scaduto, non ancora valido o non corrispondente al dominio;
  • catena di certificazione incompleta;
  • chiave privata non corrispondente al certificato;
  • certificato installato sul virtual host sbagliato;
  • SNI configurato in modo errato;
  • web server che espone protocolli o cifrari incompatibili;
  • record DNS A o AAAA diretti verso un server differente;
  • modalità SSL/TLS Cloudflare non coerente con il certificato di origine;
  • firewall o dispositivo intermedio che interrompe l’handshake;
  • rinnovo AutoSSL non completato o dominio escluso dalla copertura.

Differenze rispetto agli altri errori SSL

ErroreSignificato principaleControllo prioritario
ERR_SSL_PROTOCOL_ERRORL’handshake TLS non viene completato o la risposta sulla porta HTTPS non è valida.Protocollo, certificato, catena, porta 443, proxy e server.
NET::ERR_CERT_DATE_INVALIDIl certificato risulta scaduto, non ancora valido oppure il dispositivo ha data e ora errate.Validità del certificato e orologio del dispositivo.
NET::ERR_CERT_COMMON_NAME_INVALIDIl certificato non copre il nome host richiesto.SAN del certificato, dominio e virtual host.
ERR_SSL_VERSION_OR_CIPHER_MISMATCHClient e server non trovano una versione TLS o un cifrario compatibile.Versioni TLS, cifrari e copertura del certificato CDN.
Cloudflare 525Fallisce l’handshake TLS tra Cloudflare e il server di origine.Certificato e configurazione HTTPS dell’origine.
Cloudflare 526Cloudflare non riesce a verificare il certificato dell’origine.Validità, hostname e catena del certificato in modalità Full (strict).

Se il dominio non viene risolto, il problema è differente: consulta la guida a DNS_PROBE_FINISHED_NXDOMAIN e l’approfondimento sui record DNS.

Come capire se il problema è locale o dipende dal sito

Prima di intervenire sul server, esegui alcuni test semplici:

  1. Apri altri siti HTTPS: se falliscono tutti, controlla dispositivo, rete, antivirus, proxy o data e ora.
  2. Prova un altro browser: se il sito funziona, il problema può riguardare cache, estensioni o configurazione del browser.
  3. Usa un altro dispositivo sulla stessa rete: se fallisce anche quello, verifica router, DNS o filtri di rete.
  4. Prova la rete mobile: se il sito funziona, il problema potrebbe dipendere dal Wi-Fi, dal provider o da un proxy locale.
  5. Controlla il sito da una rete esterna: se fallisce ovunque, passa ai controlli su certificato e server.
  6. Confronta dominio principale e www: uno dei due nomi potrebbe non essere coperto o puntare a un server differente.
RisultatoCausa probabile
L’errore compare su molti sitiOrologio, browser, sistema, antivirus, VPN, proxy o rete locale.
L’errore compare soltanto su un sitoCertificato, DNS, web server, CDN o virtual host del dominio.
Funziona da rete mobile ma non dal Wi-FiProxy, DNS, filtro di rete, router o ispezione HTTPS.
Funziona senza CloudflareModalità SSL/TLS, certificato edge/origin o firewall dell’origine.
Funziona su IPv4 ma non su IPv6Record AAAA o configurazione HTTPS del server IPv6.

Soluzioni per chi visita il sito

1. Controlla data, ora e fuso orario

Il certificato contiene un intervallo di validità. Un dispositivo con data o ora errate può considerarlo scaduto o non ancora valido. Attiva la sincronizzazione automatica e verifica anche il fuso orario.

2. Aggiorna browser e sistema operativo

Un browser o un sistema molto vecchio può non supportare correttamente versioni TLS moderne, catene aggiornate o autorità di certificazione recenti. Installa gli aggiornamenti disponibili e riavvia il dispositivo.

3. Prova la navigazione in incognito

La modalità privata aiuta a escludere estensioni, cookie e dati temporanei. Se il sito funziona, riattiva le estensioni una alla volta per individuare quella che interferisce con HTTPS.

4. Cancella cache e cookie del dominio

Elimina inizialmente soltanto i dati del sito interessato. Questa operazione non corregge un certificato errato, ma può risolvere sessioni o redirect memorizzati in modo incoerente.

5. Disattiva temporaneamente VPN e proxy

VPN e proxy possono terminare e ricreare la connessione TLS. Disconnettili per una prova breve. Nelle reti aziendali non modificare configurazioni gestite senza l’autorizzazione dell’amministratore.

6. Verifica la scansione HTTPS dell’antivirus

Alcuni prodotti di sicurezza installano un certificato locale e analizzano il traffico cifrato. Una configurazione corrotta o non aggiornata può interrompere l’handshake. Disattiva la funzione soltanto per un test controllato, quindi riattivala immediatamente.

7. Riavvia router e dispositivo

Il riavvio chiude connessioni bloccate e può correggere problemi temporanei del router. Scollega il modem per circa trenta secondi, riaccendilo e attendi che la connessione sia stabile.

8. Prova un’altra rete

Usa temporaneamente la rete mobile. Se il sito torna raggiungibile, controlla DNS, proxy, firewall o filtri della rete originaria.

9. Non ignorare avvisi di sicurezza

Non inserire password, dati personali o informazioni di pagamento su un sito che presenta errori TLS. Evita soluzioni che disabilitano permanentemente i controlli del browser.

Controlli per il proprietario del sito

10. Verifica DNS A e AAAA

dig +short A esempio.it
dig +short AAAA esempio.it
dig +short A www.esempio.it
dig +short AAAA www.esempio.it

Controlla che tutti gli indirizzi puntino al server corretto. Un record AAAA dimenticato può inviare gli utenti IPv6 verso una macchina con certificato o virtual host non configurati.

11. Controlla la porta 443

nc -vz esempio.it 443
ss -lntp | grep ':443'

Il primo comando verifica la raggiungibilità dall’esterno; il secondo controlla se il server ascolta localmente. La porta aperta non garantisce però che il servizio risponda realmente con TLS.

12. Verifica dominio, scadenza e SAN del certificato

Il certificato deve essere valido e includere tutti gli hostname utilizzati, per esempio esempio.it e www.esempio.it. Il Common Name da solo non è sufficiente: i browser verificano i Subject Alternative Name.

13. Controlla la catena completa

Il server deve presentare il certificato del dominio insieme agli intermedi necessari. LiteSpeed documenta l’utilizzo di fullchain.pem e della configurazione della catena. Una catena incompleta può funzionare su alcuni dispositivi e fallire su altri.

14. Verifica che chiave privata e certificato corrispondano

Un certificato associato alla chiave sbagliata impedisce al server di completare correttamente TLS. Il controllo deve essere eseguito in modo sicuro sul server, senza copiare o condividere la chiave privata.

Per certificati RSA:

openssl x509 -noout -modulus -in certificato.pem | openssl sha256
openssl rsa  -noout -modulus -in chiave-privata.pem | openssl sha256

I due valori devono coincidere. Per chiavi di tipo differente utilizza i comandi OpenSSL appropriati. Non inviare mai il contenuto della chiave privata a servizi esterni.

15. Controlla SNI e virtual host

Su server che ospitano più domini, SNI permette di presentare il certificato corretto per ogni hostname. Se il virtual host HTTPS è assente o associato al certificato sbagliato, il browser può ricevere un certificato di un altro sito.

16. Controlla protocolli TLS e cifrari

Evita protocolli obsoleti. Allo stesso tempo, una configurazione eccessivamente restrittiva può escludere client ancora supportati. Verifica che il web server utilizzi versioni e cifrari coerenti con la tua compatibilità richiesta.

17. Esamina i log del web server

/usr/local/lsws/logs/error.log
/var/log/apache2/error.log
/var/log/httpd/error_log
/var/log/nginx/error.log

Cerca errori relativi a certificato, chiave, listener HTTPS, handshake, SNI e permessi dei file. Confronta sempre l’orario del test con il log.

Diagnosi con OpenSSL e curl

OpenSSL descrive s_client come un client generico SSL/TLS utile per diagnosticare i server. Il comando principale è:

openssl s_client -connect esempio.it:443 -servername esempio.it -showcerts

Controlla:

  • certificato presentato;
  • hostname e Subject Alternative Name;
  • catena inviata;
  • protocollo e cifrario negoziati;
  • eventuali errori di verifica;
  • presenza di una risposta TLS invece di semplice HTTP.

Per ottenere le date del certificato:

echo | openssl s_client \
  -connect esempio.it:443 \
  -servername esempio.it 2>/dev/null |
openssl x509 -noout -subject -issuer -dates

Per verificare la risposta con curl:

curl -Iv https://esempio.it/

curl -Iv mostra risoluzione DNS, connessione, negoziazione TLS e intestazioni. Non pubblicare output che contenga cookie, token o dati di autenticazione.

Per confrontare IPv4 e IPv6:

curl -4Iv https://esempio.it/
curl -6Iv https://esempio.it/

AutoSSL e cPanel

In cPanel, la sezione SSL/TLS Status consente di controllare quali domini sono protetti, quali certificati stanno per scadere e quali hostname non risultano coperti.

Controlla:

  • che il dominio e il sottodominio www siano inclusi;
  • che il dominio punti realmente al server;
  • che non sia stato escluso da AutoSSL;
  • che la verifica DCV sia riuscita;
  • che eventuali record CAA consentano l’autorità di certificazione usata;
  • che il certificato rinnovato sia installato sul virtual host corretto.

Da WHM puoi eseguire una verifica AutoSSL per tutti gli utenti:

/usr/local/cpanel/bin/autossl_check --all

Prima di rilanciare ripetutamente AutoSSL, consulta i log: il rinnovo può fallire per DNS errati, redirect della verifica, record CAA, limiti dell’autorità o hostname non raggiungibili.

LiteSpeed, Apache e Nginx

LiteSpeed

Verifica il listener HTTPS, il virtual host, il percorso del certificato, la chiave privata e l’opzione relativa al certificato concatenato. I file devono essere leggibili dal processo LiteSpeed. Dopo una modifica valida, utilizza un riavvio graceful anziché interrompere bruscamente il servizio.

Apache

Controlla il virtual host sulla porta 443, i percorsi del certificato e della chiave e la configurazione SNI. Prima di ricaricare il servizio, verifica la sintassi:

apachectl configtest

Nginx

Controlla i parametri listen 443 ssl, server_name, ssl_certificate e ssl_certificate_key. Verifica la sintassi prima del reload:

nginx -t

Non riavviare un server di produzione senza aver prima controllato configurazione, log e disponibilità di un rollback.

Cloudflare: errori 525 e 526

Cloudflare gestisce due connessioni TLS separate:

  1. dal visitatore al nodo Cloudflare;
  2. da Cloudflare al server di origine.

Errore 525: SSL handshake failed

Cloudflare indica che il 525 compare quando fallisce l’handshake tra Cloudflare e l’origine. Controlla:

  • porta 443 raggiungibile;
  • certificato installato sull’origine;
  • SNI e virtual host;
  • protocolli e cifrari supportati;
  • firewall che potrebbe bloccare gli IP Cloudflare;
  • stabilità e carico del server.

Errore 526: invalid SSL certificate

Il 526 indica che Cloudflare non riesce a verificare il certificato del server di origine. È particolarmente rilevante con la modalità Full (strict). Verifica scadenza, hostname, catena completa e autorità attendibile.

Modalità SSL/TLS

Per un sito pubblico è preferibile mantenere una connessione cifrata e verificata fino all’origine. Non utilizzare la modalità Flexible come scorciatoia per mascherare un certificato server non valido: può generare redirect e lasciare non cifrato il tratto tra Cloudflare e origine.

Dopo ogni modifica, controlla sia il certificato edge sia quello dell’origine. Se disattivi temporaneamente il proxy per una diagnosi, considera l’esposizione dell’IP reale e ripristina la configurazione prevista al termine del test.

ERR_SSL_PROTOCOL_ERROR su WordPress

WordPress è compatibile con HTTPS quando il certificato è installato e disponibile sul web server. L’errore di protocollo avviene normalmente prima che WordPress elabori la richiesta; tuttavia, configurazioni dell’applicazione possono aggravare il problema con redirect incoerenti.

Controlla:

  • che Indirizzo WordPress e Indirizzo sito utilizzino il dominio corretto;
  • che non esistano redirect duplicati tra plugin, .htaccess, web server e Cloudflare;
  • che il sito non alterni continuamente HTTP e HTTPS;
  • che il dominio principale e www siano entrambi coperti dal certificato;
  • che la cache non conservi vecchi redirect;
  • che proxy e CDN passino correttamente l’informazione sul protocollo HTTPS.

Il contenuto misto, da solo, di solito non produce ERR_SSL_PROTOCOL_ERROR: la pagina può aprirsi ma mostrare avvisi o risorse bloccate. Prima bisogna quindi risolvere handshake e certificato, poi correggere URL HTTP residui.

Per un’infrastruttura ottimizzata puoi consultare l’Hosting WordPress Xlogic, con LiteSpeed Enterprise, LSCache, CloudLinux, storage NVMe, Redis, backup JetBackup e protezione Imunify360.

Checklist finale

  • Data, ora e fuso orario del dispositivo sono corretti?
  • Browser e sistema operativo sono aggiornati?
  • VPN, proxy e scansione HTTPS sono stati esclusi?
  • Il problema si verifica da reti e dispositivi differenti?
  • I record A e AAAA puntano al server corretto?
  • La porta 443 è raggiungibile?
  • Il server risponde realmente con TLS sulla porta 443?
  • Il certificato è valido e non scaduto?
  • Il certificato copre dominio e www?
  • La catena completa viene inviata?
  • Certificato e chiave privata corrispondono?
  • SNI e virtual host sono configurati correttamente?
  • Protocolli e cifrari sono compatibili?
  • AutoSSL mostra errori DCV o hostname esclusi?
  • I log del web server riportano errori SSL/TLS?
  • La modalità Cloudflare è coerente con il certificato di origine?
  • Cloudflare mostra un errore 525 o 526?
  • WordPress o il server creano redirect HTTP/HTTPS duplicati?

Quando contattare il provider hosting

Contatta il provider quando non puoi gestire certificato, listener HTTPS, AutoSSL, firewall o configurazione del web server. Fornisci:

  • dominio e hostname esatto che genera l’errore;
  • data e ora del test;
  • browser, sistema operativo e rete utilizzata;
  • eventuale codice Cloudflare 525 o 526;
  • output di curl -Iv e openssl s_client privato di dati sensibili;
  • modifiche recenti a DNS, certificato, CDN o server.

Non inviare mai chiavi private, password, token, cookie o file di configurazione contenenti credenziali.

Domande frequenti su ERR_SSL_PROTOCOL_ERROR

Che cosa significa ERR_SSL_PROTOCOL_ERROR?

Significa che il browser non è riuscito a completare correttamente la connessione TLS con il sito oppure ha ricevuto una risposta non valida sulla porta HTTPS.

Il problema dipende sempre dal certificato?

No. Può dipendere anche da browser, data e ora, VPN, proxy, antivirus, porta 443, SNI, protocolli, cifrari, DNS o Cloudflare.

Come verifico se il certificato è scaduto?

Puoi controllarlo dal browser, da cPanel SSL/TLS Status oppure con OpenSSL visualizzando i campi notBefore e notAfter.

Perché il sito funziona su un dispositivo ma non su un altro?

I dispositivi possono avere sistemi, autorità attendibili, versioni TLS, proxy o antivirus differenti. Anche una catena incompleta può essere ricostruita da alcuni client ma non da altri.

Un record AAAA può causare l’errore?

Sì. Se IPv6 punta a un server non configurato correttamente per HTTPS, alcuni utenti possono ricevere l’errore mentre IPv4 continua a funzionare.

Che differenza c’è tra Cloudflare 525 e 526?

Il 525 indica il fallimento dell’handshake tra Cloudflare e origine; il 526 indica che Cloudflare non riesce a verificare il certificato dell’origine.

Posso usare Cloudflare Flexible per risolvere?

Non è una correzione del certificato dell’origine. Può causare redirect e non cifra il tratto tra Cloudflare e server. È preferibile configurare un certificato valido e usare Full (strict).

Il contenuto misto causa ERR_SSL_PROTOCOL_ERROR?

Normalmente no. Il contenuto misto viene gestito dopo l’apertura della connessione HTTPS. Può causare risorse bloccate o avvisi, ma non sostituisce una diagnosi dell’handshake.

Devo rigenerare subito il certificato?

Prima controlla DNS, hostname coperti, scadenza, catena, chiave e virtual host. Rigenerare senza individuare la causa può produrre lo stesso errore o raggiungere limiti dell’autorità.

OpenSSL s_client modifica il server?

No. Il comando apre una connessione diagnostica e mostra i dettagli TLS. Non modifica certificati o configurazioni.

Conclusione

ERR_SSL_PROTOCOL_ERROR richiede un’analisi ordinata: prima si escludono dispositivo e rete, poi si controllano DNS e porta 443, infine certificato, catena, chiave, SNI, protocolli, web server e CDN.

La soluzione corretta non consiste nel disabilitare i controlli di sicurezza, ma nel ripristinare una configurazione HTTPS valida e verificabile. Per siti professionali consulta l’Hosting Condiviso Xlogic, l’Hosting WordPress Xlogic oppure il servizio per cambiare hosting.

Fonti ufficiali e approfondimenti

Un Internal Server Error, spesso mostrato come errore HTTP 500, indica che il server non è riuscito a completare la richiesta. Il messaggio è generico: non identifica da solo la causa e non significa necessariamente che il server sia guasto. Su Apache e cPanel il problema può dipendere da un file .htaccess non valido, da permessi o proprietà errati, da un errore PHP, da un plugin WordPress, dalla versione di PHP oppure dal superamento di un limite di risorse.

La soluzione più sicura non è modificare file a tentativi, ma leggere prima il log degli errori, individuare l’evento relativo all’ora e all’URL interessati e intervenire solo sull’elemento indicato. Prima di ogni modifica è inoltre opportuno creare un backup dei file e del database.

Che cos’è un Internal Server Error 500

Il codice HTTP 500 Internal Server Error viene restituito quando il server incontra una condizione imprevista che gli impedisce di generare correttamente la pagina. Il browser vede soltanto il codice generico, mentre il dettaglio tecnico viene normalmente scritto nei log del server o dell’applicazione.

L’errore può interessare tutto il sito oppure una singola pagina. Se compare dopo un aggiornamento, una modifica al file .htaccess, il cambio della versione PHP o l’installazione di un plugin, l’ultima operazione eseguita è il primo elemento da verificare. Se invece appare senza modifiche evidenti, occorre controllare log, risorse e integrità dei file.

Prima verifica: leggere il log degli errori in cPanel

In cPanel apri Metriche → Errori. La pagina mostra gli eventi recenti registrati per il dominio e può indicare il file, la riga o la direttiva che ha causato il problema. In alcuni account è disponibile anche un file error_log nella cartella del sito, ad esempio dentro public_html o nella directory dell’applicazione.

Riproduci l’errore una sola volta, annota l’ora esatta e aggiorna il log. Cerca una riga con lo stesso orario e con il percorso della pagina coinvolta. Messaggi come PHP Fatal error, Allowed memory size exhausted, Invalid command, Permission denied o End of script output before headers portano a diagnosi differenti.

Non pubblicare integralmente i log: possono contenere percorsi del server, indirizzi IP o altri dati tecnici. Quando chiedi assistenza, invia soltanto le righe pertinenti insieme all’ora dell’errore e all’URL interessato.

Cause più comuni dell’errore 500 su Apache e cPanel

1. File .htaccess errato o non compatibile

Una direttiva scritta male, non consentita dalla configurazione del server oppure rimasta da una vecchia versione di PHP può produrre immediatamente un Internal Server Error. Anche regole di riscrittura che si richiamano tra loro possono creare un ciclo e impedire il caricamento della pagina.

Dal File Manager di cPanel attiva la visualizzazione dei file nascosti, crea una copia di sicurezza di .htaccess e rinominalo temporaneamente, per esempio in .htaccess-old. Se il sito torna raggiungibile, la causa è contenuta nel file. Non lasciare però il sito senza regole: ricrea un file pulito e reinserisci le direttive una alla volta.

Le vecchie righe come AddType application/x-httpd-php5 .php non devono essere copiate in configurazioni moderne. La versione PHP va selezionata dagli strumenti previsti dal proprio hosting, come MultiPHP Manager o Select PHP Version, senza riutilizzare handler obsoleti.

Su WordPress puoi rigenerare le regole standard aprendo Impostazioni → Permalink e salvando nuovamente la struttura, dopo aver verificato che l’area amministrativa sia accessibile. Conserva eventuali regole personalizzate e ripristinale soltanto dopo averle controllate.

2. Permessi o proprietà di file e cartelle

In una configurazione hosting tipica, le cartelle utilizzano permessi 755 e i file 644. Gli script che devono essere realmente eseguibili possono richiedere impostazioni differenti, ma non è corretto assegnare indiscriminatamente 755 a tutti i file. I permessi 777 sono generalmente inutili e rischiosi.

ElementoPermesso tipicoNota
Cartelle755Il proprietario può scrivere; gli altri possono leggere e attraversare.
File644Il proprietario può scrivere; gli altri possono leggere.
Script CGI eseguibili755Solo quando l’esecuzione è effettivamente richiesta.

Controlla i valori dal File Manager o tramite FTP. Se sembrano corretti ma il log continua a mostrare Permission denied, il problema potrebbe essere il proprietario del file e non il numero dei permessi. In questo caso evita correzioni ricorsive alla cieca e chiedi al provider di verificare ownership e gruppo.

3. Errore PHP o limite di memoria

Un errore fatale PHP interrompe l’esecuzione e può essere visualizzato come errore 500. Il log indica normalmente il file e la riga coinvolti. Le cause frequenti includono funzioni mancanti, codice non compatibile con la versione PHP attiva, estensioni assenti e memoria insufficiente.

Se trovi Allowed memory size exhausted, verifica il consumo dell’applicazione prima di aumentare il limite. Un plugin difettoso o una query anomala possono esaurire anche un valore elevato. Quando il piano lo consente, i limiti PHP possono essere modificati in cPanel da Select PHP Version → Options oppure da MultiPHP INI Editor. Consulta anche la guida su Allowed memory size exhausted in PHP.

Dopo un cambio di versione PHP controlla che tutte le estensioni necessarie siano abilitate e che CMS, tema e plugin siano compatibili. Non passare a una versione PHP obsoleta come soluzione permanente: usa il downgrade soltanto come test temporaneo e pianifica l’aggiornamento del componente incompatibile.

4. Plugin o tema WordPress incompatibile

Se l’errore è comparso subito dopo l’attivazione o l’aggiornamento di un plugin, disattivalo dall’area amministrativa. Se WordPress non è accessibile, rinomina via File Manager la cartella del singolo plugin dentro wp-content/plugins. Per una diagnosi generale puoi rinominare temporaneamente la cartella plugins, verificare il sito e poi ripristinare il nome originale.

Con WP-CLI, quando disponibile, puoi controllare lo stato dei plugin e disattivare quello sospetto:

wp plugin list
wp plugin deactivate nome-plugin

Per escludere il tema, attiva temporaneamente un tema WordPress predefinito soltanto dopo aver effettuato un backup e verificato che sia installato. Non sostituire intere cartelle wp-admin o wp-includes senza aver prima identificato la causa e controllato la versione esatta del core.

5. Limiti di risorse o processi interrotti

CPU, memoria, processi simultanei e timeout possono essere superati durante importazioni, backup, scansioni, operazioni WooCommerce o picchi di traffico. In cPanel verifica le statistiche disponibili e confronta l’orario del limite con quello dell’errore. Aumentare un valore può aiutare solo se il carico è legittimo e temporaneo; in presenza di un processo anomalo è necessario correggere la causa.

6. File danneggiati o caricamenti incompleti

Un aggiornamento interrotto può lasciare file mancanti o parziali. Confronta i file con una copia integra della stessa versione dell’applicazione e controlla lo spazio disponibile. Per WordPress, WP-CLI permette di verificare i checksum del core senza modificare i contenuti:

wp core verify-checksums

Se la verifica segnala differenze, crea un backup e reinstalla soltanto i file del core della medesima versione. Le cartelle wp-content e i file di configurazione non devono essere sovrascritti indiscriminatamente.

Come attivare il debug di WordPress senza mostrare errori ai visitatori

Quando il log del server non basta, WordPress può registrare gli errori nel file wp-content/debug.log. Inserisci temporaneamente nel file wp-config.php, prima della riga finale di stop, queste costanti:

define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false );
@ini_set( 'display_errors', 0 );

In questo modo gli errori vengono registrati senza essere mostrati pubblicamente. Riproduci il problema, scarica le sole righe utili e poi disattiva il debug. Il file di log può contenere informazioni sensibili e non deve essere lasciato accessibile o crescere senza controllo. La procedura completa è descritta anche nella documentazione ufficiale WordPress.

Procedura rapida per risolvere un errore 500

  1. Annota URL, ora esatta e operazione che ha preceduto l’errore.
  2. Crea un backup di file e database.
  3. Consulta cPanel → Metriche → Errori e gli eventuali file error_log.
  4. Se il log indica .htaccess, provalo con un nome temporaneo e ricrea regole pulite.
  5. Controlla permessi, proprietà e spazio disponibile.
  6. Verifica versione, estensioni e limiti PHP.
  7. Su WordPress disattiva il componente indicato e, se necessario, attiva il debug nel log.
  8. Svuota la cache dell’applicazione e del server, quindi riprova in una finestra anonima.
  9. Riattiva un componente alla volta e controlla nuovamente i log.

Cosa comunicare all’assistenza hosting

Se l’Internal Server Error continua, apri una richiesta indicando il dominio, l’URL esatto, l’orario con fuso orario, le operazioni già eseguite e poche righe pertinenti del log. Specifica se il problema riguarda tutte le pagine, soltanto l’amministrazione o un singolo percorso. Queste informazioni permettono di distinguere rapidamente un errore dell’applicazione da un limite o da una configurazione lato server.

Evita di inviare password, chiavi API, cookie, backup completi o log non filtrati. Il supporto può verificare configurazione, proprietà dei file e registri non accessibili dall’account; lo sviluppatore del sito può invece intervenire sul codice indicato dal messaggio PHP.

Domande frequenti sull’Internal Server Error

L’errore 500 significa che il server è offline?

No. Il server può essere perfettamente raggiungibile e non riuscire a completare soltanto una specifica richiesta. Il log degli errori è necessario per conoscere la causa reale.

Posso impostare file e cartelle a 777?

È sconsigliato. In genere le cartelle usano 755 e i file 644. Se questi valori non funzionano, occorre verificare proprietà e configurazione invece di concedere permessi indiscriminati.

Rinominare .htaccess è sufficiente?

È un test diagnostico, non sempre la soluzione definitiva. Se il sito riparte, crea un file valido e reinserisci con cautela le sole regole necessarie.

L’aumento della memoria PHP risolve sempre?

No. Può risolvere un limite adeguato male, ma non corregge un plugin difettoso, un ciclo o una query inefficiente. Prima identifica dal log quale processo consuma memoria.

Quando devo contattare il provider?

Quando non puoi accedere ai log necessari, quando ownership e configurazione del server richiedono privilegi amministrativi oppure quando l’errore persiste dopo aver escluso file .htaccess, applicazione e limiti visibili dall’account.

La sicurezza di un sito web richiede più livelli: aggiornamenti, backup verificati, password uniche, autenticazione a due fattori, HTTPS, permessi minimi, monitoraggio e risposta agli incidenti. Nessuna singola estensione elimina tutti i rischi.

Nota di aggiornamento: Le misure devono essere adattate a CMS, hosting e dati trattati. Verifica periodicamente utenti, componenti inutilizzati, log e possibilità reale di ripristino.

Informazioni aggiornate e controlli essenziali

La sicurezza di un sito web è importante quanto il suo aspetto e la sua funzionalità, soprattutto se si archiviano dati personali, come i dati della carta di credito, indirizzi email, etc. Se siete stati vittima di un hacker, allora probabilmente vi rendete conto di quanto dannoso e frustrante possa essere la violazione del proprio sito.

Esempio di sito bucato dagli Hacker

Sito web compromesso da un attacco informatico

Ci sono alcuni accorgimenti che consentono di rendere il vostro sito web meno vulnerabile agli attacchi hacker e non richiedono grosse conoscenze tecniche.

Questi 10 consigli vi aiuteranno a rendere il vostro sito più sicuro ed è un ottimo punto di partenza per la maggior parte degli utenti.

 

Mantieni gli Script aggiornati

Le applicazioni open source come Magento, WordPress, phpBB, OpenCart ed altri CMS sono molto utili, ma bisogna ricordarsi di mantenerli sempre aggiornati. Le vecchie versioni di queste applicazioni possono rendere il vostro sito vulnerabile agli attacchi degli hacker, quindi è importante eseguire l’aggiornamento alla versione più recente di qualsiasi script che usi per il tuo sito web.

Se hai installato uno script utilizzando Softaculous, riceverai una e-mail ogni volta che viene rilasciata una nuova versione. Prima di aggiornare un CMS alla versione più recente, esegui sempre un backup del sito nel caso in cui la versione più recente dia problemi.

 

Aggiorna Plugin ed Estensioni

Se utilizzi Magento, WordPress, Joomla o altro, hai dei plugin o delle estensioni installate sul tuo sito, assicurati di tenerli sempre aggiornati, le vecchie versioni di plugin o estensioni sono vulnerabili dagli hacker.

Nel caso di WordPress, gli Hacker utilizzano quasi sempre un codice maligno che risiede all’interno dei Temi per bucarvi il sito, questo non succede se scaricate i Temi dalla directory ufficiale di WordPress dove i temi sono controllati e sicuri. Leggi anche: WordPress come assicurarsi che il proprio tema sia sicuro

 

Elimina le installazioni non utilizzate

Se hai installato WordPress 2 anni fa e non hai ancora trovato il tempo per scrivere un post, allora è il momento di cancellare questa installazione, perchè è vulnerabile agli attacchi degli hacker.

Disinstalla e reinstalla l’ultima versione di WordPress.

 

Utilizza Password difficili da indovinare

Secondo un rapporto di Imperva , una delle principali società di sicurezza dati, le password più comunemente utilizzate sono cifre consecutive, come 1234567, chiavi adiacenti come QWERTY, parole in gergo e nomi propri. Se la password utilizzata per l’area di amministrazione del tuo sito web rientra in una delle categorie elencate, allora dovresti cambiarla immediatamente.

E’ meglio utilizzare delle password generate in modo casuale con combinazioni di numeri, lettere e caratteri speciali. Per creare una password generata in modo casuale è possibile utilizzare il generatore casuale di password random.org.

 

Non condividere le tue Password con nessuno

Se vuoi evitare che il tuo sito web o posta elettronica sia bucato dagli hacker, non condividere le tue password con nessuno. Con la maggior parte delle applicazioni open source è possibile creare facilmente nomi utenti e password per utenti diversi, quindi non c’è bisogno di condividere le informazioni con nessuno.

 

Cambia le Password regolarmente

Per contribuire a mantenere sicuro il tuo sito web, cambia le password ogni 3 mesi circa. Se hai avuto un problema di sicurezza, allora cambiale subito.

 

Non utilizzare il tuo nome Utente predefinito

Quando si installa un’applicazione open source come WordPress o Magento, verrà creato un account admin di default con il nome utente admin.

Cambia il nome utente per l’account subito.

 

Non pubblicizzare lo Script che stai usando

Un modo per scoraggiare gli hacker è quello di rendere difficile a loro capire quale applicazione open source stai utilizzando sul tuo sito. Quando si installa uno script, la favicon di default sarà il logo dell’applicazione. Se non si cambia la favicon, allora gli hacker si renderanno conto immediatamente  dello script che state utilizzando.

Inoltre, verifica che i temi non includano link che richiamino il CMS usato, tipo ‘Powered by WordPress’ e rimuovi il meta name=”generator”, ciò potrebbe rendere il vostro sito un bersaglio per gli hacker.

 

Elimina gli Account Ftp inutilizzati

Se disponi di più account FTP per il tuo sito, assicurati di eliminare gli account FTP che non stai utilizzando.

Gli account inutilizzati possono essere facilmente eliminati tramite cPanel in ‘Account FTP’.

 

Cosa fare se il tuo sito è stato compromesso dagli Hacker?

Se il tuo sito è stato bucato dagli Hacker, contatta il Provider dell’Hosting subito. Il tuo fornitore di hosting dovrebbe essere in grado di dirti l’entità del danno causato dall’hacker, oltre a fornire raccomandazioni sui passi che devi fare per rendere il sito fruibile e sicuro.

In alcuni casi, i siti hackerati potranno essere ripristinati da un backup e poi in seguito dovranno essere adottate delle contromisure per proteggere il sito. Anche se la maggior parte dei Provider effettuano il Backup di tutti siti residenti in un server è importante e consigliato per gli utenti creare il proprio backup il più spesso possibile.

 

Alla Prossima.

 

Approfondimenti correlati

Fonte ufficiale: OWASP Top 10.

Domande frequenti

Qual è il controllo più importante?

Non esiste un solo controllo. Aggiornamenti, accessi protetti e backup ripristinabili riducono rischi diversi e devono essere gestiti insieme.

Un certificato SSL rende il sito sicuro?

HTTPS protegge la comunicazione, ma non corregge vulnerabilità, password deboli, malware o configurazioni errate.

Quanto spesso testare i backup?

Con una frequenza coerente con il valore dei dati. Un backup non verificato non garantisce che il ripristino funzioni.

Il file robots.txt comunica ai crawler quali percorsi possono o non possono visitare. Non protegge contenuti riservati e non garantisce la rimozione dall’indice: per questo servono autenticazione, noindex o gestione degli URL secondo il caso.

Nota di aggiornamento: Una regola errata può bloccare risorse o sezioni importanti. Prima della pubblicazione verifica sintassi, maiuscole, percorsi e comportamento con gli strumenti del motore di ricerca.

Informazioni aggiornate e controlli essenziali

Il file robots.txt è un semplice file di testo che contiene delle regole usate dagli Spider (Crawler) per applicare restrizioni sulle pagine di un sito web. I Web Crawler sono dei software programmati che effettuano ricerche sul Web e indicizzazioni per i motori di ricerca, quando analizzano un sito web controllano l’esistenza del file Robots.txt e se vi trovano delle regole o restrizioni le applicano.

Il file robots.txt viene inserito nella directory principale di un sito web ed è puramente consultivo, non tutti gli Spider applicano le regole inserite in esso.

 

Perché è un file robots.txt è importante?

Per evitare lo spreco di risorse del server, molti, se non la maggior parte dei siti web, hanno degli script che girano sul loro sito web che non hanno nessuna utilità pratica per un motore di ricerca, quando i robot dei motori  indicizzano il sito è possibile tramite il file robots.txt impedire agli spider l’indicizzazione di tali script, riducendo il carico sul server e eliminando le esecuzioni non necessarie.

 

Ridurre la larghezza di banda

Se guardate le statistiche del vostro sito web, troverete molte richieste per il Robots.txt da parte degli spider dei motori di ricerca. I motori di ricerca tentano di recuperare il robots.txt prima di indicizzare il sito web, per vedere se ha istruzioni per loro.

Se non si dispone di un file robots.txt, il server restituisce una pagina di errore 404 per il motore, questo causa l’utilizzo di molta banda a causa delle sue ripetute richieste per recuperare il file 404.

Qualche motore di ricerca indicizza anche i file grafici tipo .Gif, .Jpg e .Png, se si desidera bloccarli per risparmiare banda, lo si può fare usando il file robots.txt.

 

Come impostare un file robots.txt

Scrivere un file robots.txt è estremamente semplice. E’ solo un file di testo ASCII che si colloca alla radice del vostro dominio. Ad esempio, se il dominio è www.esempio.com, bisognerà inserire il file in www.esempio.com/robots.txt.

Per coloro che non sanno cosa sia un file di testo ASCII, è solo un file di testo che si crea con un editor di testo. Se utilizzate Windows, è già presente un editor di testo sul vostro sistema, chiamato Blocco note.

Il file Robots.txt elenca fondamentalmente i nomi degli Spider su una linea, seguito da un elenco di directory o file da non indicizzare.

Ogni riga del file contiene un record. Ogni record ha la seguente sintassi :

<campo> : <valore>

I campi disponibili sono :

User-Agent il valore di questo campo contiene il nome del robot che si deve attenere alle restrizioni. Con il carattere * la regola viene applicata a qualsiasi robot.

Disallow il valore di questo campo contiene le pagine del sito che devono essere escluse dai robot durante l’indicizzazione. Si può indicare un URL specifico o una serie di URL appartenenti ad un pattern. Per ogni User-Agent è possibile specificare una o più restrizioni tramite Disallow.

Il file robots.txt è case sensitive quindi se blocchiamo la pagina /PAGINA_DA_BLOCCARE sarà differente da bloccare la pagina /pagina_da_bloccare.

 

Esempio (1) file robots.txt

Per permettere l’accesso a tutto il sito web, non indicare nulla nella direttiva Disallow. Alcuni crawler supportano anche la direttiva Allow

User-agent: *
Disallow:

Per bloccare un intero sito, utilizza una barra.

User-agent: *
Disallow: /

Per bloccare una directory e il relativo contenuto, fai seguire il nome della directory da una barra.

User-agent: *
Disallow: /private_directory/

Per bloccare una pagina, indica tale pagina.

User-agent: *
Disallow: /private_file.html

Per segnalare il file Sitemap del sito.

Sitemap: http://www.esempio.com/sitemap.xml

 

Esempio (2) file robots.txt

User-agent: *
Disallow: /cgi-bin/

Le due righe sopra, inserite in un file robots.txt, informano tutti i robot che non sono autorizzati ad accedere nella directory e nelle sottodirectory di cgi-bin.

 

E’ possibile, bloccare i robot che indicizzano le immagini, tipo Google Image Search, inserendo le righe seguenti:

User-agent: Googlebot-Image
Disallow: /

Ciò significa che il robot di Google Image Search, non dovrebbe tentare di accedere a qualsiasi file nella directory radice / e in tutte le sue sottodirectory.

 

È possibile avere più linee Disallow per ogni user agent (cioè, per ogni spider). Ecco un esempio di file robots.txt più lungo:

User-agent: *
Disallow: /images/
Disallow: /cgi-bin/
User-agent: Googlebot-Image
Disallow: /

 

E’ possibile escludere l’indicizzazione di un determinato file. Per esempio, se non volete fare indicizzare l’immagine test.jpg, dovrete aggiungere le seguenti righe:

User-agent: Googlebot-Image
Disallow: /images/test.jpg

 

Senza restrizioni

Se si desidera che tutte le directory vengano indicizzate da tutti i motori di ricerca, basta un semplice file robots con le seguenti righe:

User-agent: *
Disallow:

 

Alla prossima.

 

 

Approfondimenti correlati

Fonte ufficiale: Google Search Central: robots.txt.

Domande frequenti

Robots.txt rimuove una pagina da Google?

Non in modo affidabile. Blocca la scansione, ma un URL può essere conosciuto tramite collegamenti. Per la deindicizzazione occorrono strumenti appropriati.

Si possono inserire dati riservati nel robots.txt?

No. Il file è pubblico e non è un sistema di sicurezza. Le aree private devono essere protette con autenticazione e permessi.

Dove si trova il file?

Normalmente nella radice del protocollo e host, ad esempio https://example.com/robots.txt. Le regole valgono soltanto per quello specifico host.

Per migliorare la velocità del sito oggi si utilizzano PageSpeed Insights, Lighthouse e dati reali dei Core Web Vitals. L’analisi deve distinguere prestazioni di laboratorio e utenti reali, quindi intervenire su immagini, cache, JavaScript, CSS, font e tempi del server.

Nota di aggiornamento: Firebug e la vecchia estensione PageSpeed descritti nell’articolo non sono più il flusso di lavoro corrente. Il contenuto storico resta utile per capire l’evoluzione, ma i test vanno eseguiti con gli strumenti moderni.

Informazioni aggiornate e controlli essenziali

Avere un sito veloce o almeno un sito che non è più lento rispetto alla media, può aiutare a ottenere o mantenere un buon posizionamento nei motori di ricerca e di conseguenza può portare più traffico al vostro sito web. La velocità di un sito viene determinata dal tempo di caricamento di tutti gli elementi di una pagina web, il suo testo, le immagini, i video, etc.

Già nel 2010, Google ha aggiunto in Strumenti per Webmaster un tool:  Prestazioni del sito, in cui la velocità del sito viene elaborata e stabilita tramite 200 fattori,  ciò significa che la velocità del sito è molto considerata quando si lavora sull’ottimizzazione dei motori di ricerca (SEO).

Come ottimizzare il proprio sito?

Compressione del sito: usando la compressione gzip, si può ridurre di molto il tempo necessario per inviare i contenuti del vostro sito ai visitatori. La compressione agisce sugli elementi di testo del sito,  Html, JavaScript e Css e accelera il tempo necessario per caricare la pagina. La compressione non influisce sulle immagini.

Ottimizzare le immagini: non usare immagini di grandi dimensioni, se è possibile impostare sempre la larghezza e l’altezza nel codice Html corrispondenti all’immagine caricata, altrimenti se l’immagine è più grossa rispetto alle dimensioni inserite nel codice Html, ci sarà un ridimensionamento dell’immagine che rallenterà il caricamento della pagina.

Scegliere il formato del file: non utilizzate un file JPG a meno che non si desideri includere una fotografia con una vasta gamma di colori. Per la maggior parte delle immagini, utilizzate un file GIF o PNG, questi tipi di file si caricano più velocemente.

Inserire il codice in ordine ottimale: la collocazione dei fogli di stile (CSS) và inserita nella parte superiore (Header) e il JavaScript in fondo al codice (Footer) per ciascuna delle vostre pagine web, questo può migliorare la velocità percepita del tuo sito per i visitatori.

Acquista un Hosting Professionale: per la maggior parte dei siti web è importante avere un Hosting competente che risponde rapidamente quando hai una domanda o un problema. I fattori che possono determinare la velocità o i rallentamenti del vostro sito sono sempre controllati dalla società di Hosting che ospita il vostro sito web. Se stai cercando un Hosting Professionale, guarda i nostri Piani Hosting.

Usare PageSpeed per ottimizzare il proprio sito.

Page Speed ​​è un progetto open-source iniziato da Google per aiutare gli sviluppatori a ottimizzare le proprie pagine web. Il progetto Page Speed ​​è iniziato come un’estensione per browser,  ora è distribuito come prodotto anche a terzi, come Webpagetest.org , Slow Show e Google Webmaster Tools.

Come installo PageSpeed?

Prima di tutto, bisogna installare Firefox. Si può scaricare tramite questa pagina www.mozilla-europe.org/it/, lo installate.

Browser Firefox utilizzato nella vecchia guida PageSpeed

 

 

 

 

 

 

 

 

 

Ora scarichiamo ed installiamo Firebug, da questa pagina getfirebug.com/downloads/

Download dell’estensione Firebug per Firefox

 

 

 

 

 

 

 

 

 

A questo punto, scarichiamo ed installiamo PageSpeed, da questa pagina code.google.com/intl/it-IT/speed/page-speed/download.html.

Download della vecchia estensione PageSpeed

 

 

 

 

 

 

 

 

 

 

 

Ora apriamo Firefox, clicchiamo su Strumenti -> Firebug -> Avvia firebug, si aprirà una schermata come l’immagine sotto. Per analizzare il sito, clicchiamo su Page Speed -> Analyze Performance.

Analisi del sito con Firebug

 

 

 

 

 

 

 

 

 

La velocità del sito viene determinata da un punteggio (Max 100), nel caso del nostro sito, già ottimizzato, restituisce un punteggio di 97 su 100, quasi il massimo.

Risultato del vecchio test PageSpeed

 

 

 

 

 

 

 

 

 

Vediamo nel dettaglio cosa abbiamo ottimizzato:

Abilita la compressione: abbiamo abilitato la compressione Gzip dal Pannello di Controllo Hosting, in alternativa si può abilitare tramite file .Htaccess, inserendo il seguente codice:

# BEGIN Gzip
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/text text/html text/plain text/xml text/css application/x-javascript application/javascript
</IfModule>
# END Gzip

Sfrutta il caching del browser: per sfruttare il caching del browser abbiamo inserito sempre nel file .htaccess, il seguente codice:

<FilesMatch “\.(asf|asx|wax|wmv|wmx|avi|bmp|class|divx|doc|docx|exe|gif|gz|gzip|ico|jpg|jpeg|jpe|mdb|mid|
midi|mov|qt|mp3|m4a|mp4|m4v|mpeg|mpg|mpe|mpp|odb|odc|odf|odg|odp|ods|odt|ogg|pdf|png|pot|pps|ppt|
pptx|ra|ram|swf|tar|tif|tiff|wav|wma|wri|xla|xls|xlsx|xlt|xlw|zip|ASF|ASX|WAX|WMV|WMX|AVI|BMP|CLASS|
DIVX|DOC|DOCX|EXE|GIF|GZ|GZIP|ICO|JPG|JPEG|JPE|MDB|MID|MIDI|MOV|QT|MP3|M4A|MP4|M4V|MPEG|
MPG|MPE|MPP|ODB|ODC|ODF|ODG|ODP|ODS|ODT|OGG|PDF|PNG|POT|PPS|PPT|PPTX|RA|RAM|SWF|TAR|TIF|
TIFF|WAV|WMA|WRI|XLA|XLS|XLSX|XLT|XLW|ZIP)$”>
Header set Cache-Control “max-age=37739520, public”
</FilesMatch>

Minimizza CSS: abbiamo ridotto le dimensioni dei file CSS, scaricando il file proposto da PageSpeed e sovrascrivendo l’originale.

Minimizza JavaScript: abbiamo ridotto le dimensioni dei file Javascript, scaricando il file proposto da PageSpeed e sovrascrivendo l’originale.

Ottimizza immagini: abbiamo ridotto le dimensioni delle immagini, scaricando il file proposto da PageSpeed e sovrascrivendo l’originale.

Minimizza HTML: abbiamo ridotto le dimensioni dei file Html, scaricando il file proposto da PageSpeed e sovrascrivendo l’originale.

Specifica dimensioni immagine: abbiamo specificato, in alcune immagine le dimensioni nel codice Html.

 

Il risultato è notevole, 97 su 100.

Giudicate voi stessi la velocità del nostro sito Xlogic.org

 

State cercando un Hosting Professionale?

I nostri Piani Hosting sono l’ideale.. Offriamo Hosting a prezzi contenuti e prestazioni elevate.

Contattateci

 

 

 

Approfondimenti correlati

Fonte ufficiale: Google PageSpeed Insights.

Domande frequenti

PageSpeed Insights misura la velocità reale?

Combina dati di laboratorio e, quando disponibili, dati reali raccolti sul campo. I due insiemi rispondono a domande diverse e vanno letti separatamente.

Un punteggio 100 garantisce un sito veloce?

No. Il punteggio è diagnostico e può variare. Contano esperienza reale, stabilità, tempi di risposta e metriche Core Web Vitals.

Da dove iniziare l’ottimizzazione?

Dalle opportunità con impatto maggiore: immagini, risorse bloccanti, cache, JavaScript non necessario, font e risposta del server.