W3 Total Cache CloudFlare e gli Errori 403 su Google Search Console

| | 0 Comments

Se anche voi usate W3 Total Cache e CloudFlare e anche a voi è arrivata una mail da Google Search Console che dice:

Googlebot ha rilevato un aumento degli errori di autorizzazione di accesso sul sito

allora forse avete il mio stesso problema, un sacco di errori 403 forbidden, che potrebbero presentarsi anche se non avete CloudFlare ma per sicurezza procediamo in ordine. Se non avete CloudFlare saltate al punto 2.

1. CloudFlare 403 error?

Nelle faq di CloudFlare è specificato:

Why am I getting a 403 error?

If you’re seeing a 403 error without CloudFlare branding, this is always returned directly from the web server, not CloudFlare, and is generally related to permission rules on your server.

Ciò vuol dire che il problema è sui permessi e non è sui loro server ma è sul vostro.
Entrate nel vostro pannello di amministrazione di CloudFlare e abilitate il Development Mode, in modo da bypassare il sistema di cache momentaneamente, per vedere tutte le nostre modifiche:

cloudflare development mode

2. W3 Total Cache 403 Forbidden

Fate un test con REDbot.org e dovreste avere un header della risposta simile:

HTTP/1.1 403 Forbidden
Content-Type: text/html
Transfer-Encoding: chunked
Connection: keep-alive
Pragma: public
Cache-Control: max-age=3600, public
X-Powered-By: W3 Total Cache/0.9.4.1
Vary: Accept-Encoding,User-Agent
Last-Modified: Thu, 01 Jan 1970 00:00:00 GMT
Cache-Control: private, must-revalidate
Server: cloudflare-nginx
Content-Encoding: gzip

La prima cosa che dovete fare è controllare l’.htaccess nella root del sito e vedere che non ci siano dei blocchi verso ip o host. Il mio non ne aveva.

2.1 W3 Total Cache: Page Cache method Disc Enhanced

Andando a impostare la Page Cache su Disc Basic, il problema non si verificava più quindi, solo Disc Enhanced da problemi quando è abilitata, ma è anche il metodo più veloce e il più comunemente usato sugli hosting economici. I file serviti da questo metodo risiedono in:

wp-content/cache/page_enhanced/www.vostrosito.com

Ed è proprio qui il problema, infatti se accedete con l’ftp potete vedere una cartella nominata .htaccess:

file htaccess ftp

Questa cartella viene creata se qualcuno prova a visitare questo url www.vostrosito.com/.htaccess e state certi che prima o poi qualche malintenzionato ci proverà. Ora cancellate la cartella e il suo contenuto e vediamo com’è l’header della risposta sempre tramite REDbot.org:

HTTP/1.1 200 OK
Content-Type: text/html; charset=UTF-8
Transfer-Encoding: chunked
Connection: keep-alive
Vary: Accept-Encoding,Cookie
Last-Modified: Fri, 08 Jan 2016 18:07:24 GMT
Cache-Control: max-age=3600, public
X-Powered-By: W3 Total Cache/0.9.4.1
Pragma: public
Server: cloudflare-nginx
Content-Encoding: gzip

Perfetto la risposta ora è uno stato 200 ok.

2.2 Evitare che W3 Total Cache ricrei la cartella .htaccess

Ci sono due metodi per risolvere, entrambi efficaci.

2.2.1 Metodo 1: esclusione .htaccess in W3 Total Cache

Questo primo metodo è sicuramente il più veloce, nelle impostazioni di W3TC andate su Page Cache e in fondo alla sezione Advanced aggiungete su una nuova linea .htaccess alla dicitura Never cache the following pages.

w3 total cache 403: never cache following pages

2.2.1 Metodo 2: creare un file .htaccess nella cartella della cache

Creare il file .htaccess dove c’era l’omonima cartella impedisce che questa venga ricreata. Io per sicurezza ho messo gli ip di CloudFlare all’interno:

# Cloudflare ips
Allow from 199.27.128.0/21
Allow from 173.245.48.0/20
Allow from 103.21.244.0/22
Allow from 103.22.200.0/22
Allow from 103.31.4.0/22
Allow from 141.101.64.0/18
Allow from 108.162.192.0/18
Allow from 190.93.240.0/20
Allow from 188.114.96.0/20
Allow from 197.234.240.0/22
Allow from 198.41.128.0/17
Allow from 162.158.0.0/15
Allow from 104.16.0.0/12
Allow from 172.64.0.0/13
Allow from 2400:cb00::/32
Allow from 2606:4700::/32
Allow from 2803:f800::/32
Allow from 2405:b500::/32
Allow from 2405:8100::/32

3. Visualizza come Google in Search Console

Se vogliamo essere sicuri che la modifica abbia funzionato dovete fare la prova del nove con la Search Console di Google, ovvero il vecchio Strumenti per i Webmaster, sotto Scansione > Visualizza come Google e cliccate su Recupera anche senza inserire particolari url:

visualizza url come google

Se come nell’immagine, dopo il recupero dell’url, lo stato è con la spunta verde allora la modifica ha avuto successo.

Non vi resta che andare in Scansioni > Errori di Scansione e alla scheda Accesso Negato selezionare tutti gli url e cliccare su Segnala come corretti.

Se avete fatto tutto correttamente e Google Search Console da esito positivo presto vedrete dei miglioramenti nei risultati di ricerca, specie se è da tempo che avete questi problemi.

Tags: , , , , , , ,

Category: Internet

About the Author ()

Studio Ingegneria Informatica e Bio. all’ Università Magna Graecia di Catanzaro, sono appassionato di informatica, e mi piace praticare la pesca nelle acque dolci.