Perché i permessi file WordPress si rompono così spesso

Gestisco server in produzione da anni. I motivi sono sempre gli stessi. Una migrazione tra hosting diversi, con un client FTP configurato male, lascia cartelle a 777 e file eseguibili da chiunque. Un ripristino da backup che non preserva i permessi originali è un altro classico. L’archivio si scompatta con i permessi di default dell’utente che lo estrae, non con quelli che il sito aveva prima. Capita anche con un intervento manuale frettoloso via SFTP: si cambia un file di notte e si dimentica di rimettere i permessi giusti.

C’è poi un caso che mi sta particolarmente a cuore: la bonifica dopo un incidente di sicurezza. Quando ho scritto di come ho protetto i server durante l’emergenza PHP2Shell, uno dei passaggi era verificare i permessi file WordPress rimasti dopo la pulizia. Nessun file doveva restare scrivibile oltre il necessario. Lo stesso vale quando faccio la rotazione delle credenziali dopo una violazione ISPConfig. Ripristinare permessi corretti è uno dei controlli che faccio sempre, non un’opzione.

Cosa fa davvero lo script

Lo script è volutamente piccolo. Imposta le cartelle a 755, i file a 644, e protegge wp-config.php a 600 se lo trova. Vediamo perché proprio questi numeri.

#!/bin/bash

echo "Ripristino permessi nella cartella attuale..."

# Imposta tutte le cartelle a 755
find . -type d -exec chmod 755 {} +

# Imposta tutti i file a 644
find . -type f -exec chmod 644 {} +

# Proteggi wp-config.php se presente
if [ -f "wp-config.php" ]; then
  chmod 600 wp-config.php
  echo "=> wp-config.php protetto con permessi 600"
fi

echo "Fatto! Permessi aggiornati."

Lo script è fornito così com’è, a scopo informativo. L’uso è sotto la tua esclusiva responsabilità. Non mi assumo alcuna responsabilità per perdita di dati, interruzioni di servizio, o qualsiasi errore generato da un utilizzo scorretto o da un contesto diverso da quello in cui lo eseguo io stesso. Fai sempre un backup indipendente prima di eseguirlo in produzione.

Le cartelle vanno a 755, cioè rwxr-xr-x. Il proprietario può leggere, scrivere ed entrare nella cartella. Il gruppo e tutti gli altri possono solo leggerla ed entrarci. Quell’ultima “x”, sulle cartelle, non significa “eseguire” come per un programma. Su una directory vuol dire poter attraversarla. Il server web deve poter attraversare ogni cartella per arrivare al file richiesto. Ma non deve poterci scrivere dentro, se non ne è il proprietario.

I file invece vanno a 644, cioè rw-r--r--. Lettura per tutti, scrittura solo per il proprietario, nessun bit di esecuzione per nessuno. Un file .php non deve mai essere eseguibile come un binario. Viene interpretato da PHP-FPM o dal modulo del server, non lanciato direttamente dalla shell. Un file eseguibile a livello di filesystem è un segnale che qualcosa non va, non un vantaggio. Sono questi due numeri, 755 e 644, il cuore di come imposto i permessi file WordPress su ogni server che gestisco.

Il caso speciale è wp-config.php, protetto a 600, cioè rw-------. Solo il proprietario può leggerlo e scriverlo, nemmeno il gruppo. Quel file contiene le credenziali del database in chiaro, oltre alle chiavi di sicurezza di WordPress. Non c’è motivo che altri utenti del sistema, inclusi altri siti sullo stesso server condiviso, possano anche solo leggerlo.

Il dettaglio tecnico di find con il +

Chi guarda da vicino il comando find . -type d -exec chmod 755 {} + noterà quel + finale al posto del più comune \;. Non è un dettaglio stilistico. Con \;, find lancia un processo chmod separato per ogni file o cartella trovata. Su un sito con poche decine di file va bene. Ma su un hosting con centinaia di migliaia di file, tra core, plugin, temi e uploads, è diverso. Significa avviare centinaia di migliaia di processi uno dopo l’altro. Con +, invece, find raggruppa quanti più argomenti possibile. Li passa a poche chiamate di chmod, esattamente come farebbe xargs. La differenza di velocità, su un sito grande, si misura in minuti e non in secondi. Chi vuole la descrizione ufficiale può leggere la pagina man di find su man7.org, alla voce -exec command {} +.

Come lo lancio, anche da remoto

La versione che preferisco è scaricare lo script, dargli un’occhiata, e solo dopo eseguirlo. La consiglio anche a chi legge:

cd /percorso/del/sito
curl -sO https://cisilino.com/mscripts/fix_permessi.sh
cat fix_permessi.sh   # guardo cosa contiene prima di lanciarlo
chmod +x fix_permessi.sh
./fix_permessi.sh

Quando sono in fretta, su un server che conosco, uso la versione compatta. Scarico ed eseguo in sequenza, senza passaggi intermedi:

cd /percorso/del/sito && curl -sO https://cisilino.com/mscripts/fix_permessi.sh && chmod +x fix_permessi.sh && ./fix_permessi.sh

Ecco l’equivalente con wget. Utile sui server dove curl non è installato di default:

cd /percorso/del/sito && wget -q https://cisilino.com/mscripts/fix_permessi.sh && chmod +x fix_permessi.sh && ./fix_permessi.sh

Quello che non faccio mai, nemmeno di fretta, è la pipe diretta tipo curl https://... | bash. Tecnicamente funziona. Per questo script specifico il rischio è basso, perché lo conosco e lo controllo io stesso. Ma è un’abitudine che vale la pena non prendere. Eseguire alla cieca un codice scaricato al volo, senza un attimo per leggerlo, prima o poi si paga. Magari non con questo script, ma con un altro trovato in giro e meno affidabile. Un cat prima del chmod +x costa due secondi.

Dove lo script si ferma

Lo script opera su “.” in modo ricorsivo. Va lanciato dalla root del sito, non da una cartella superiore o da una sottocartella qualsiasi. Se lo lancio dalla cartella sbagliata, sistema i permessi solo di quella, oppure tocca file che non c’entrano nulla.

Non gestisce i casi particolari in cui alcune cartelle devono restare scrivibili dal gruppo del server web. Capita con wp-content/uploads su certe configurazioni, o con la cache di alcuni plugin che scrivono file a runtime. In quei casi, dopo lo script, va rimesso a mano il permesso specifico che serve. Altrimenti il plugin smette di funzionare.

Non c’è nessuna modalità dry-run, né un backup integrato dei permessi precedenti. A differenza di script più strutturati, come quello per la rotazione delle password del database, qui non c’è rete di sicurezza. Va eseguito sapendo già cosa ci si aspetta di ottenere. E va lanciato con l’utente giusto: quello proprietario dei file, non root. Altrimenti i file finiscono di proprietà di root. A seconda di come è configurato PHP-FPM, il server web potrebbe non riuscire più a leggerli.

Con questi limiti chiari in testa, è uno script che tengo a portata di mano su ogni server. Quando i permessi file WordPress vanno in confusione, in un comando torno a una base pulita. Poi sistemo a mano le eccezioni che servono davvero.

The post Permessi file WordPress rotti? Lo script che li ripristina first appeared on Matteo Cisilino.

Questo articolo si rivolge a due lettori: chi ha appena registrato un .si e cerca dove ospitarlo. E chi vende hosting e vuole trasformare questa ondata di attenzione in clienti e visibilità organica.

Perché il boom dei domini interessa a chi vende hosting

Registrare un dominio è solo il primo passo. Un nome senza server, DNS configurati e certificato SSL non genera traffico né vendite. Ogni ondata di registrazioni crea quindi una domanda a valle di servizi tecnici. Il .si ne ha generata una nuova in pochissimo tempo.

I profili che compaiono dopo un boom di questo tipo sono tre, ciascuno con bisogni diversi:

Il primo profilo è il più numeroso oggi, ma è anche il più volatile: secondo Netcraft circa il 52% dei .si registrati su Dynadot tra il 19 e il 22 settembre è stato messo in vendita subito dopo (CircleID), e molti nomi potrebbero non essere rinnovati. Il secondo è meno numeroso e più redditizio, perché usa davvero il sito.

Per chi opera in Italia c’è un’opportunità da verificare. Le ricerche in italiano legate a “hosting dominio .si” potrebbero avere ancora pochi contenuti di qualità a rispondere. Un controllo della SERP prima di pubblicare dirà quanto la nicchia è aperta.

Strategia SEO per un provider di hosting

L’obiettivo è trasformare l’attenzione sul .si in traffico qualificato verso le pagine commerciali. Servono pochi contenuti ben collegati, pubblicati subito, invece di molti articoli generici.

1. Mappa le keyword per intento

I volumi vanno verificati con Search Console o Keyword Planner prima di investire. I numeri dipendono dal momento e dal paese.

2. Pubblica in ordine di valore commerciale

1. Landing page “Hosting per dominio .si” con prezzi, SSL incluso, DNS gestiti, email e un’unica call to action chiara.
2. Guida “Come registrare un dominio .si” con requisiti, costi e passaggi, che rimanda alla landing.
3. Post di analisi sul boom, per attirare link e condivisioni dal settore.
4. Confronto “hosting per startup AI” con criteri misurabili (velocità, uptime, supporto).
5. FAQ ottimizzate per snippet in evidenza (vedi sezione dedicata).

3. Ottimizza on-page e tecnica

• Title e meta description con la keyword all’inizio.
• Struttura H1-H2-H3 che rispecchia le domande degli utenti, una keyword secondaria per sezione.
• Dati strutturati FAQ e Article, per aumentare le possibilità di snippet.
• Link interni tra i due post, la guida e la landing, con anchor descrittive (“hosting per dominio .si”), non “clicca qui”.
• Velocità e Core Web Vitals: per un provider di hosting il sito è la prova del prodotto. Una pagina lenta contraddice il messaggio.
• Fonti citate e data di aggiornamento visibili, perché il tema cambia ogni settimana.

4. Sfrutta il tempismo

Il picco di interesse è legato a un evento recente. Pubblicare entro pochi giorni, aggiornare i numeri ogni settimana e ripubblicare con data aggiornata aiuta a restare in SERP finché la ricerca resta alta. Se il fenomeno si sgonfia, le pagine di guida e la landing continuano comunque a servire chi registra un .si per motivi ordinari.

5. Comunica con prudenza

Il valore dei .si dipende dall’adozione reale della sigla SI. Netcraft segnala rischi di cybersquatting e frodi legati all’ondata di registrazioni (Netcraft). Per un provider la comunicazione più sicura vende un servizio tecnico concreto, non un guadagno sui domini, e prevede una policy sugli abusi.

Domande frequenti sull’hosting per dominio .si

Serve un hosting speciale per un dominio .si? No. Un dominio .si si collega a qualsiasi hosting configurando i DNS. Contano velocità, affidabilità, SSL incluso e assistenza, come per qualsiasi altro dominio.

Chi può registrare un dominio .si? Secondo le fonti consultate, chiunque può registrarlo. Verifica sempre requisiti e costi aggiornati sul sito del registro .si, dove trovi le regole ufficiali, o del registrar scelto.

Che cosa serve per mettere online un dominio .si? Un hosting o un server, i DNS puntati correttamente, un certificato SSL e, se serve, una casella email sul dominio.

Conviene investire in domini .si? È un’operazione speculativa. Una parte consistente dei nomi viene messa in vendita subito dopo la registrazione e il valore dipende dall’adozione reale della sigla SI. Valuta solo budget che puoi permetterti di perdere.

Perché i domini .si sono tornati di moda a settembre 2026? Perché “SI” coincide con la sigla di super intelligence, adottata dal governo USA al posto di “AI”. Nel post sul boom dei domini .si trovi i dati e il contesto.

Conclusione: dal dominio al sito online

Il valore per un provider di hosting non sta nella speculazione sui domini, ma nel servizio che serve dopo. Servono DNS affidabili, SSL, prestazioni, email e assistenza per chi vuole davvero mettere online un sito.

Il piano è semplice: pubblica la landing per il .si, affianca la guida alla registrazione, aggiorna i dati ogni settimana. Comunica un servizio tecnico, non un’opportunità di guadagno. Se il fenomeno si sgonfia, restano contenuti utili e una pagina che converte.

Ti serve un hosting per dominio .si? Scopri l’hosting con SSL incluso, DNS gestiti ed email professionale, attivo in pochi minuti.

Fonti

Dati verificati il 13 ottobre 2026.

• .si Registrations Surge After US Shift to ‘Super Intelligence’, CircleID, 1 ottobre 2026.
• Slovenian .SI Domain Registrations Outpace .AI, Netcraft, 24 settembre 2026.

The post Hosting per dominio .si: guida e strategia SEO per i provider first appeared on Matteo Cisilino.