WordPress User Role Management per Agenzie: Controllo Accessi Clienti, Editor e Freelancer [2026]

Gestire accessi WordPress senza impazzire: il problema reale delle agenzie

Avete 47 siti WordPress da gestire. Ogni cliente vuole l’accesso. Il freelance che scrive i testi ha bisogno dell’editor. Il designer esterno deve caricare mockup. Il SEO consultant vuole configurare Yoast. E il proprietario del sito? Lui vuole “tutto” ma non sa cosa significa “tutto”.

Nella nostra esperienza, il 90% dei problemi di sicurezza WordPress nasce da permessi mal configurati. Non plugin vulnerabili. Non temi scaduti. Permessi. Un amministratore che non dovrebbe esserlo. Un editor con troppi poteri. Un subscriber che in qualche modo può installare plugin. In questa guida spieghiamo come configurare i ruoli WordPress per un’agenzia, creare ruoli personalizzati e tenere tutto sotto controllo con script automatizzati.

TL;DR — Cosa impari in questa guida

• I 6 ruoli nativi di WordPress e quando usarli (e quando no)
• Come creare ruoli personalizzati con capability specifiche per clienti, editor e freelancer
• Script WP-CLI per replicare la configurazione su 50+ siti in batch
• Plugin per gestione ruoli: User Role Editor, Members, Profile Builder a confronto
• Best practice per accesso clienti: il modello “principio del minimo privilegio”
• Automazione del provisioning utenti tramite REST API

I 6 ruoli nativi di WordPress: guida rapida

WordPress definisce 6 ruoli nativi dal core. Ogni ruolo ha un set di capabilities (permessi specifici) che determinano cosa l’utente può fare nel backend. La tabella qui sotto li riassume con il caso d’uso reale per un’agenzia.

La regola d’oro: mai dare Administrator a un cliente. Nella nostra esperienza, il 70% dei clienti con privilegi di amministratore prima o poi rompe qualcosa. Disinstallano un plugin pensando sia inutile. Cambiano il tema. Attivano un plugin di terze parti non testato. Poi chiamano l’agenzia in panico perché “il sito è sparito”.

Il modello di accessi che usiamo in AgencyPilot

Dopo 15 anni e centinaia di siti gestiti, abbiamo standardizzato un modello a 4 livelli che funziona per il 95% dei clienti. Eccolo.

Livello 1 — Cliente Owner (ruolo: Editor personalizzato)

Il cliente paga, quindi vuole controllo. Ma non gli diamo Administrator. Creiamo un ruolo personalizzato chiamato client_owner basato su Editor con alcune capability extra:

• Modifica contenuti (post, pagine, media)
• Modifica menu di navigazione
• Visualizza analitiche (se installato un plugin SEO/analytics)
• Gestione commenti
• NON può installare/disinstallare plugin
• NON può cambiare tema
• NON può gestire altri utenti

Livello 2 — Editor contenuti (ruolo: Editor standard)

Per il team interno del cliente che gestisce blog, news, aggiornamenti pagina. Editor nativo di WordPress basta. Può creare, modificare, pubblicare e programmare contenuti. Non vede impostazioni tecniche.

Livello 3 — Freelance writer (ruolo: Author o Contributor)

Il copywriter esterno, il blogger occasionale, il freelance SEO. Author se è fidato e può pubblicare direttamente. Contributor se deve passare da revisione. Per i freelance che lavorano regolarmente con l’agenzia, creiamo un ruolo freelance_writer che aggiunge la capability di caricare media (che Author ha già) ma limita la gestione categorie.

Livello 4 — Accesso tecnico temporaneo (ruolo: Administrator temporaneo)

Quando un developer esterno deve lavorare sul sito, creiamo un account Administrator con scadenza. Usiamo il plugin Temporary Access o uno script WP-CLI che rimuove l’utente dopo 7 giorni. Niente accessi permanenti per collaboratori esterni.

Come creare ruoli personalizzati in WordPress

WordPress espone la funzione add_role() per creare ruoli personalizzati. Si può fare in tre modi: via codice nel functions.php, via plugin, o via WP-CLI. Per le agenzie che gestiscono molti siti, la via migliore è WP-CLI.

Metodo 1 — Codice nel functions.php (non consigliato per agenzie)

// Aggiungi ruolo client_owner nel functions.php del tema child
function agencypilot_add_client_owner_role() {
    add_role(
        'client_owner',
        'Cliente Owner',
        array(
            'read'                   => true,
            'edit_posts'             => true,
            'edit_pages'             => true,
            'edit_others_posts'      => true,
            'edit_others_pages'      => true,
            'edit_published_posts'   => true,
            'edit_published_pages'   => true,
            'publish_posts'           => true,
            'publish_pages'          => true,
            'delete_posts'            => true,
            'delete_pages'           => true,
            'delete_others_posts'    => true,
            'delete_others_pages'    => true,
            'delete_published_posts' => true,
            'delete_published_pages' => true,
            'upload_files'           => true,
            'manage_categories'       => true,
            'moderate_comments'      => true,
            'manage_links'            => true,
            'unfiltered_html'        => true,
            // Niente: activate_plugins, edit_themes, edit_plugins,
            // update_core, install_plugins, install_themes,
            // delete_themes, delete_plugins, manage_options, list_users,
            // edit_users, create_users, delete_users, promote_users
        )
    );
}
add_action('init', 'agencypilot_add_client_owner_role');

Problema: questo metodo va bene per un sito singolo. Ma se gestisci 50 siti, devi replicare il codice ovunque. E se devi cambiare una capability? Devi andare su ogni sito.

Metodo 2 — WP-CLI (scelta consigliata per agenzie)

WP-CLI ha il comando wp role create che permette di creare ruoli da terminale. Più veloce, più affidabile, e si può scriptare per batch su multipli siti.

# Creare il ruolo client_owner da terminale
wp role create client_owner "Cliente Owner"

# Aggiungere capability al ruolo
wp cap add client_owner \
    read \
    edit_posts \
    edit_pages \
    edit_others_posts \
    edit_others_pages \
    edit_published_posts \
    edit_published_pages \
    publish_posts \
    publish_pages \
    delete_posts \
    delete_pages \
    delete_others_posts \
    delete_others_pages \
    delete_published_posts \
    delete_published_pages \
    upload_files \
    manage_categories \
    moderate_comments \
    manage_links \
    unfiltered_html

# Verificare le capability assegnate
wp cap list client_owner

Per rimuovere una capability: wp cap remove client_owner moderate_comments. Pulito, reversibile, tracciabile.

Metodo 3 — Script batch per 50+ siti

Ecco lo script che usiamo noi per applicare la configurazione a tutti i siti clienti in una volta sola. Salva la lista dei siti in un file sites.txt (un dominio per riga) e lancia:

#!/bin/bash
# agencypilot-setup-roles.sh
# Applica la configurazione ruoli standard AgencyPilot a tutti i siti

SITES_FILE="sites.txt"
WP_PATH="/var/www"  # adjust per il tuo server

while IFS= read -r site; do
    echo "=== Configurando ruoli su $site ==="

    # Path WordPress
    WP_DIR="${WP_PATH}/${site}"

    # Verifica che WP-CLI funzioni
    if ! wp --path="$WP_DIR" core is-installed 2>/dev/null; then
        echo "SKIP: $site non raggiungibile"
        continue
    fi

    # Crea ruolo client_owner se non esiste
    if ! wp --path="$WP_DIR" role exists client_owner 2>/dev/null; then
        wp --path="$WP_DIR" role create client_owner "Cliente Owner"
    fi

    # Resetta capabilities (rimuovi tutto, aggiungi solo quelle giuste)
    wp --path="$WP_DIR" cap reset client_owner
    wp --path="$WP_DIR" cap add client_owner \
        read edit_posts edit_pages edit_others_posts edit_others_pages \
        edit_published_posts edit_published_pages publish_posts publish_pages \
        delete_posts delete_pages delete_others_posts delete_others_pages \
        delete_published_posts delete_published_pages upload_files \
        manage_categories moderate_comments manage_links unfiltered_html

    # Crea ruolo freelance_writer se non esiste
    if ! wp --path="$WP_DIR" role exists freelance_writer 2>/dev/null; then
        wp --path="$WP_DIR" role create freelance_writer "Freelance Writer"
    fi

    wp --path="$WP_DIR" cap reset freelance_writer
    wp --path="$WP_DIR" cap add freelance_writer \
        read edit_posts upload_files edit_published_posts \
        delete_posts delete_published_posts

    echo "DONE: $site"
done < "$SITES_FILE"

echo "=== Configurazione completata ==="

Questo script in 30 secondi configura i ruoli su 50 siti. Se devi cambiare una capability, modifichi lo script, rilanci, fatto. Niente login su ogni singolo sito.

Plugin per gestione ruoli: confronto reale

Se non vuoi usare WP-CLI o il codice, ci sono plugin che semplificano la gestione ruoli. Ne testiamo tre: quelli che funzionano davvero per un'agenzia.

Per le agenzie, User Role Editor è il più diretto. Fa una cosa e la fa bene: gestire ruoli e capabilities. L'export/import ti permette di salvare la configurazione su un sito e caricarla su un altro. Il Pro aggiunge la sync multisite, utile se gestisci reti WordPress.

Members è più completo ma anche più pesante. Se hai bisogno di content permissions (chi può vedere cosa), vale la pena. Se ti serve solo gestire ruoli, è overkill.

Perché non usiamo plugin per i ruoli

Onestamente, per gestire 50+ siti non usiamo plugin. WP-CLI è più veloce, più ripetibile, e non aggiunge codice ai siti clienti. Il principio è: meno plugin, meno problemi. Ogni plugin è una potenziale vulnerabilità, un aggiornamento da fare, un conflitto con un altro plugin.

I plugin li usiamo per il content gating (Members fa questo bene) o per dare ai clienti un'interfaccia per gestire i propri utenti. Ma la configurazione base dei ruoli la facciamo con WP-CLI. Sempre.

Provisioning utenti via REST API

Per automatizzare la creazione di utenti su multipli siti, la REST API di WordPress è la via migliore. L'endpoint /wp-json/wp/v2/users permette di creare, modificare e cancellare utenti via HTTP. Perfetto per integrare il provisioning con i tuoi sistemi CRM o di project management.

// Creare un utente via REST API con PHP
function agencypilot_create_user_via_api($site_url, $username, $email, $role, $password) {
    $credentials = base64_encode('admin:application_password');

    $response = wp_remote_post($site_url . '/wp-json/wp/v2/users', [
        'headers' => [
            'Authorization' => 'Basic ' . $credentials,
            'Content-Type'  => 'application/json',
        ],
        'body' => json_encode([
            'username'  => $username,
            'email'     => $email,
            'password'  => $password,
            'roles'     => [$role],
            'name'      => $email,
        ]),
        'timeout' => 30,
    ]);

    if (is_wp_error($response)) {
        return false;
    }

    $body = json_decode(wp_remote_retrieve_body($response), true);
    return isset($body['id']) ? $body['id'] : false;
}

Per approfondire la REST API di WordPress, abbiamo scritto una guida completa agli endpoint personalizzati che copre autenticazione, JWT e Application Passwords.

Il principio del minimo privilegio applicato a WordPress

Il principio del minimo privilegio (PoLP) dice: dai a ogni utente solo i permessi strettamente necessari per fare il suo lavoro. Niente di più. In WordPress questo significa:

1. Cliente che paga — Editor personalizzato. Può gestire contenuti, non può toccare plugin o temi.
2. Team marketing del cliente — Editor standard. Pubblicazione contenuti, gestione media.
3. Freelance writer — Author o Contributor. Scrive post, non gestisce pagine.
4. SEO consultant esterno — Ruolo personalizzato seo_editor con accesso a Yoast/Rank Math ma niente editing contenuti.
5. Developer esterno — Administrator temporaneo con scadenza 7 giorni.
6. Tu (agenzia) — Administrator. Su tutti i siti. Sempre.

Creare un ruolo SEO Editor

Il caso del SEO consultant è interessante. Ha bisogno di accedere alle impostazioni del plugin SEO (Yoast, Rank Math, SEOPress) ma non deve modificare i contenuti. Creiamo un ruolo specifico:

# Ruolo SEO Editor per consultant esterni
wp role create seo_editor "SEO Editor"
wp cap add seo_editor \
    read \
    edit_posts \
    edit_pages \
    edit_published_posts \
    edit_published_pages \
    manage_categories \
    wpseo_manage_options \
    wpseo_edit_advanced_metadata \
    rank_math_manage_options

Le capability wpseo_manage_options e rank_math_manage_options sono specifiche dei plugin SEO. Le trovi nella documentazione di Yoast e Rank Math rispettivamente. Se usi SEOPress, la capability è seopress_manage_options.

WordPress Multisite: gestione ruoli semplificata

Se gestisci un network Multisite, i ruoli si configurano a livello di singolo sito, non del network. Solo il Super Admin ha accesso al network admin. Questo semplifica le cose: un utente può essere Editor su un sito e Subscriber su un altro.

Per approfondire, la nostra guida a ManageWP vs MainWP vs AgencyPilot copre il confronto tra gestione centralizzata e Multisite per agenzie. Se usi Multisite, la gestione utenti è più semplice perché puoi assegnare ruoli diversi per ogni sito dal pannello network.

# Su Multisite: assegnare un utente a un sito con un ruolo specifico
wp user add-role user@example.com editor --url=client1.example.com

# Rimuovere ruolo da un utente su un sito specifico
wp user remove-role user@example.com editor --url=client1.example.com

# Lista utenti di un sito specifico nel network
wp user list --url=client1.example.com --fields=ID,user_login,roles,display_name

Sicurezza e accessi: cosa controllare ogni mese

La gestione ruoli non è "set and forget". Ogni mese controlla questi punti sui siti clienti. Abbiamo integrato questi check nella nostra guida alla sicurezza WordPress per agenzie, ma qui li riassumiamo per il contesto accessi:

1. Revisione utenti attivi

# Lista utenti con ruolo Administrator
wp user list --role=administrator --fields=ID,user_login,user_email,display_name,last_login

# Su multipli siti
for site in $(cat sites.txt); do
    echo "=== $site ==="
    wp --path="/var/www/${site}" user list --role=administrator \
        --fields=user_login,user_email,registered_date
done

Se vedi un admin che non riconosci, o un freelance che doveva essere rimosso 3 mesi fa, è il momento di pulire.

2. Verifica ruoli personalizzati

# Lista tutti i ruoli personalizzati (esclusi quelli nativi)
wp role list --fields=role,display_name | grep -v -E "administrator|editor|author|contributor|subscriber"

Confronta con la configurazione standard. Se un ruolo ha capabilities extra che non hai autorizzato, qualcuno ha modificato la configurazione (un plugin, un altro developer, il cliente).

3. Controllo sessioni attive

WordPress non ha un sistema nativo per vedere le sessioni attive. Usiamo il plugin Sessions (o WP-CLI con un plugin che supporta la gestione sessioni) per verificare quanti login attivi ci sono per ogni utente.

# Lista sessioni attive (richiede plugin WP Session Manager)
wp user session list --fields=user_login,token,login_time,expiration_time

# Distruggere tutte le sessioni di un utente
wp user session destroy user@example.com --all

Automazione: workflow per onboarding e offboarding utenti

Quando un nuovo cliente firma, o quando un freelance finisce il contratto, devi creare o rimuovere accessi. Farlo a mano su 50 siti è impraticabile. Automatizziamo.

Onboarding nuovo cliente

#!/bin/bash
# onboarding-cliente.sh
# Crea utente client_owner per un nuovo cliente

SITE=$1
CLIENT_EMAIL=$2
CLIENT_NAME=$3
WP_DIR="/var/www/${SITE}"

# Genera password casuale
PASSWORD=$(openssl rand -base64 16)

# Crea utente con ruolo client_owner
wp --path="$WP_DIR" user create "$(echo $CLIENT_EMAIL | cut -d@ -f1)" \
    "$CLIENT_EMAIL" \
    --role=client_owner \
    --display_name="$CLIENT_NAME" \
    --user_pass="$PASSWORD"

# Invia credenziali al cliente (via email o Slack)
echo "Credenziali create per $CLIENT_NAME su $SITE"
echo "Email: $CLIENT_EMAIL"
echo "Password: $PASSWORD"
echo "URL: https://${SITE}/wp-admin/"

# Logga l'operazione
echo "$(date): Creato utente $CLIENT_EMAIL su $SITE" >> /var/log/agency-user-management.log

Offboarding freelance o collaboratore

#!/bin/bash
# offboarding-user.sh
# Rimuove un utente da tutti i siti

EMAIL=$1

while IFS= read -r site; do
    WP_DIR="/var/www/${site}"
    USER_ID=$(wp --path="$WP_DIR" user get "$EMAIL" --field=ID 2>/dev/null)

    if [ -n "$USER_ID" ]; then
        # Riassegna i contenuti a admin e rimuovi utente
        wp --path="$WP_DIR" user delete "$USER_ID" --reassign=1
        echo "Rimosso utente $EMAIL da $site"
    fi
done < "sites.txt"

echo "=== Offboarding completato per $EMAIL ==="

Nota il flag --reassign=1: riassegna tutti i post dell'utente all'amministratore (ID 1). Senza questo flag, WordPress chiede conferma interattiva e blocchi lo script.

Capability API: come funziona davvero

WordPress usa un sistema di capabilities granulari. Ogni azione (editare un post, pubblicare una pagina, moderare un commento) corrisponde a una capability specifica. I ruoli sono solo contenitori di capabilities. Capire questo sistema è essenziale per creare ruoli personalizzati che funzionino davvero.

Le capabilities principali che userai più spesso:

• read — accesso al dashboard (minimo)
• edit_posts / edit_pages — modifica contenuti propri
• edit_others_posts / edit_others_pages — modifica contenuti altrui
• publish_posts / publish_pages — pubblicazione
• upload_files — caricamento media
• manage_options — accesso alle impostazioni
• manage_categories — gestione tassonomie
• moderate_comments — moderazione commenti
• install_plugins / activate_plugins — gestione plugin
• switch_themes / edit_themes — gestione temi
• list_users / edit_users / create_users — gestione utenti

La documentazione ufficiale di WordPress elenca tutte le capabilities native nella guida Roles and Capabilities. Per le capability dei plugin (Yoast, Rank Math, WooCommerce), controlla la documentazione del plugin specifico.

FAQ — Domande frequenti sui ruoli WordPress

Qual è la differenza tra ruolo e capability?

Una capability è un permesso singolo (es. edit_posts). Un ruolo è un gruppo di capabilities. L'utente non ha capabilities direttamente: eredita quelle del suo ruolo. Se cambi le capabilities di un ruolo, tutti gli utenti con quel ruolo vedono il cambiamento immediatamente.

Come cambio il ruolo di un utente esistente?

Dal backend: Users → trova l'utente → cambia il campo "Role" nel profilo. Via WP-CLI: wp user update user@email.com --role=editor. In batch su multipli siti, usa lo script che abbiamo visto sopra con wp user update in un loop.

Posso dare a un cliente accesso a un singolo plugin senza dargli Editor?

Sì. Crea un ruolo personalizzato basato su Subscriber e aggiungi solo la capability del plugin che ti interessa. Per esempio, per dare accesso solo a un form builder: wp cap add client_user wpforms_create_forms. Ogni plugin definisce le proprie capabilities.

Come rimuovo un ruolo personalizzato che non serve più?

Via WP-CLI: wp role delete client_owner. Gli utenti che avevano quel ruolo vengono automaticamente spostati su Subscriber. Verifica dopo l'operazione che non ci siano utenti "orfani" senza ruoli appropriati.

È meglio usare ruoli personalizzati o plugin di gestione accessi?

Dipende dal volume. Sotto 10 siti, un plugin come User Role Editor è più pratico. Sopra 10 siti, WP-CLI con script batch è più efficiente, più ripetibile e non aggiunge codice ai siti clienti. Per agenzie che gestiscono 30+ siti, la via CLI è l'unica sostenibile.

Il ruolo Subscriber può vedere il contenuto privato?

No. Subscriber può solo leggere il backend e gestire il proprio profilo. Per il content gating (contenuti visibili solo a specifici utenti o ruoli), usa un plugin come Members o un snippet di codice con current_user_can().

Schema markup suggerito

Conclusioni

La gestione ruoli WordPress è uno di quei argomenti che nessuno affronta finché non c'è un problema. E quando il problema arriva, di solito è un sito defacciato o un cliente che ha disinstallato un plugin critico. La differenza tra un'agenzia professionale e una improvvisata sta in questo: l'agenzia professionale configura gli accessi prima di consegnare il sito. Quella improvvisata dà admin a tutti e spera per il meglio.

I tre punti da portare a casa:

1. Mai Administrator ai clienti. Crea un ruolo Editor personalizzato. Il cliente può gestire contenuti senza rompere il sito.
2. WP-CLI per tutto. Script batch su 50+ siti in 30 secondi. Niente plugin, niente login manuali.
3. Revisione mensile. Controlla chi ha accesso, verifica ruoli attivi, rimuovi utenti obsoleti. È il check più rapido e più efficace per la sicurezza.

Per approfondire la sicurezza WordPress in generale, leggi la nostra guida alla sicurezza per agenzie. Per la gestione multi-sito, la guida completa alla gestione di siti WordPress copre tutto il workflow operativo.