In breve: prendere in carico un sito WordPress significa ricostruire accessi, dipendenze e stato reale prima di modificarlo. Il passaggio è riuscito quando il nuovo referente sa come funziona il progetto, dispone di un backup ripristinabile e può distinguere problemi preesistenti, rischi e priorità future.

Il cambio di fornitore può avvenire perché l’attività è cresciuta, perché manca assistenza o perché il sito presenta errori. La fretta di “sistemare subito tutto” è comprensibile, ma intervenire senza inventario può cancellare personalizzazioni, interrompere email o rendere difficile capire l’origine di un problema.

1. Definire proprietà, autorizzazione e perimetro

Prima di accedere bisogna chiarire chi è titolare del dominio, dei contenuti e degli account, chi autorizza le modifiche e quali ambienti rientrano nel lavoro. Gli accessi dovrebbero essere nominativi: condividere un unico amministratore tra più persone impedisce di attribuire le attività e rende più difficile revocare un permesso.

Il primo perimetro può essere soltanto diagnostico. Una verifica in sola lettura consente di raccogliere informazioni senza aggiornare plugin, cambiare configurazioni o pubblicare contenuti.

2. Raccogliere gli accessi necessari

WordPress amministratore è soltanto uno degli accessi possibili. In base al progetto possono servire pannello hosting, SFTP o SSH, database, DNS, registrar del dominio, posta, SMTP, CDN, backup esterni, Search Console, analytics, gateway di pagamento, servizi di spedizione e API collegate.

Non tutte le credenziali devono essere consegnate allo stesso ruolo. Si applica il privilegio minimo e si registra dove risiede la fonte autorevole. Le password non vanno copiate in documenti editoriali o report di progetto.

3. Creare l’inventario tecnico

L’inventario identifica versione WordPress e PHP, tema attivo e child theme, plugin attivi e inattivi, must-use plugin, cron, utenti privilegiati, licenze, codice personalizzato, endpoint e servizi esterni. Devono emergere modifiche dirette al core o ai plugin, perché potrebbero essere sovrascritte al primo aggiornamento.

Per ogni componente è utile annotare funzione, origine, stato di manutenzione e criticità. Un plugin inattivo ma necessario per un rollback non equivale a un residuo; un plugin abbandonato che gestisce il checkout è invece una priorità.

4. Conservare una baseline prima degli interventi

La baseline comprende URL e funzioni principali, schermate amministrative pertinenti, stato aggiornamenti, errori visibili, risposta server, form, email, ricerca, login e flussi commerciali. Per un e-commerce include almeno catalogo, carrello, checkout, pagamenti, spedizioni, email e amministrazione degli ordini.

Registrare lo stato iniziale protegge entrambe le parti: evita di attribuire al passaggio problemi già presenti e consente di confrontare il sito dopo ogni modifica.

5. Creare e verificare il backup

Il backup deve comprendere file e database coerenti nel tempo. Vanno identificati posizione, cifratura, conservazione, accessi e procedura di ripristino. Quando possibile si prova il restore in un ambiente separato, verificando almeno homepage, amministrazione e funzioni critiche.

La documentazione WordPress ricorda che file e database sono componenti distinti e raccomanda di eseguire il backup prima degli aggiornamenti o degli spostamenti.

Guida ufficiale WordPress ai backup →

6. Valutare aggiornamenti e compatibilità

Una lunga lista di aggiornamenti arretrati non va applicata necessariamente in blocco. Si considera la distanza tra versioni, la compatibilità con PHP, il supporto del tema, le personalizzazioni e la disponibilità di release intermedie. L’ordine degli interventi deve permettere di individuare la causa se qualcosa cambia.

Per un sito critico si replica il progetto in staging, si applicano gli aggiornamenti e si eseguono controlli mirati. Produzione viene modificata soltanto quando esiste un piano di rilascio e rollback proporzionato.

7. Controllare sicurezza e account

La presa in carico è il momento adatto per rimuovere accessi non più necessari, verificare amministratori, aggiornare credenziali condivise, controllare HTTPS, permessi e configurazione del login. Vanno cercati utenti inattesi, file anomali e comportamenti non spiegati, senza confondere un controllo di base con un’indagine forense completa.

Se ci sono segnali di compromissione, il perimetro cambia: prima si contiene l’incidente e si preservano le evidenze, poi si pianifica il ripristino da una copia attendibile.

8. Verificare form, email e conversioni

Molti siti perdono opportunità senza mostrare un errore evidente. Il form può salvare il dato ma non inviare l’email; il messaggio può finire nello spam; una CTA può aprire la pagina sbagliata. Si verificano quindi invio, consegna, conferma, consenso, attribuzione e percorso successivo, usando dati di prova solo quando autorizzati.

9. Tutelare SEO e URL

Prima di migrare o cambiare struttura si esportano URL, title, canonical, stato HTTP, sitemap, redirect e pagine con visibilità. Search Console aiuta a riconoscere query e destinazioni che non devono essere cancellate senza una decisione.

Il passaggio di assistenza non richiede automaticamente una richiesta di indicizzazione o una nuova sitemap. Queste azioni si valutano soltanto quando cambiano realmente pagine o segnali tecnici.

10. Costruire un piano dei primi interventi

Alla fine dell’audit le attività vengono ordinate per impatto e rischio: incidenti e sicurezza, continuità dei backup, aggiornamenti bloccanti, funzioni commerciali, performance e backlog evolutivo. Ogni voce dovrebbe avere una motivazione, una dipendenza e un criterio di completamento.

Non tutto deve essere corretto nella prima settimana. La priorità è rendere il progetto conoscibile e recuperabile, poi ridurre progressivamente il debito tecnico.

Quando rifare il sito è davvero la scelta migliore

L’età non basta per decidere un rifacimento. Ha senso ricostruire quando tema e componenti non sono più mantenibili, gli aggiornamenti richiedono continue eccezioni, l’architettura non sostiene gli obiettivi o il costo di recupero supera quello di una migrazione controllata.

In altri casi una buona presa in carico, insieme a un piano di assistenza WordPress, permette di conservare contenuti, URL e funzioni valide intervenendo soltanto dove serve.

Richiedi la presa in carico del sito →

Domande frequenti sulla presa in carico

Quali accessi servono per prendere in gestione un sito WordPress?

In base al perimetro possono servire WordPress amministratore, hosting o pannello server, SFTP o SSH, database, DNS, dominio, posta, servizi transazionali, Search Console e strumenti analytics. Gli accessi devono essere nominativi e protetti.

Si può iniziare senza conoscere chi ha sviluppato il sito?

Sì, ma aumenta l’importanza dell’inventario. Bisogna identificare tema, plugin, codice personalizzato, licenze, cron, servizi esterni, versioni e flussi critici prima di intervenire.

Conviene aggiornare subito tutti i componenti arretrati?

Non sempre. Prima si crea un backup completo e si valuta la distanza tra versioni, la compatibilità di tema, plugin e PHP e l’esistenza di modifiche dirette. Gli aggiornamenti complessi vanno ordinati e provati fuori produzione.

La presa in carico comprende anche SEO e form di contatto?

Dovrebbe almeno registrarne lo stato. Canonical, indicizzazione, redirect, sitemap, form, email e conversioni sono funzioni che possono rompersi durante migrazioni o aggiornamenti e devono entrare nella baseline pertinente.

Quando è preferibile rifare il sito invece di mantenerlo?

Il rifacimento ha senso se la struttura impedisce aggiornamenti sicuri, il tema o i plugin sono abbandonati, il debito tecnico supera il valore recuperabile oppure obiettivi e contenuti richiedono un’architettura diversa. La decisione va motivata da un audit, non dall’età del sito.

Fonte tecnica

WordPress Advanced Administration Handbook