Come lanciare un blog gratis nel 2018

Nel 2018 “gratis” non voleva dire “senza problemi”: voleva dire accettare vincoli chiari su spazio, traffico, pubblicità, controllo del dominio e accesso ai file. Se l’obiettivo era aprire un blog tecnico o personale con poca manutenzione, la scelta giusta non era cercare il servizio più ricco, ma quello che riduceva il numero di punti fragili: pubblicazione, DNS, backup e recupero credenziali.

La differenza vera non stava tra “avere un blog” e “non averlo”, ma tra un setup che sopravviveva ai primi mesi e uno che si rompeva al primo cambio di tema, al primo limite di banda o al primo problema di login. In pratica, il blog gratis andava progettato come un servizio piccolo ma serio: dominio, piattaforma, contenuti, copie di sicurezza e un minimo di osservabilità.

La decisione che conta: piattaforma ospitata o hosting tuo

Per un blog gratis nel 2018 le strade realistiche erano due. La prima era una piattaforma ospitata tipo WordPress.com, Blogger, Medium o simili: meno libertà, meno manutenzione, più velocità di messa online. La seconda era un hosting free o quasi-free con WordPress installato da te: più controllo, ma anche più rischio di limiti nascosti, backup assenti e performance imprevedibili.

Se l’obiettivo era pubblicare contenuti e basta, la piattaforma ospitata vinceva quasi sempre. Se invece servivano plugin, codice personalizzato o gestione fine del DNS, allora un hosting con accesso al pannello e almeno un database MySQL diventava inevitabile. La regola pratica era semplice: più vuoi controllare, più devi accettare responsabilità operative.

Un criterio utile era questo: se non eri disposto a gestire almeno DNS, SSL, backup e aggiornamenti, non scegliere un setup “semi-libero” solo perché sembrava più professionale. Meglio un servizio chiuso ma stabile che un server gratuito lasciato a metà.

Stack minimo sensato per partire senza spendere

Il punto non era installare il CMS più famoso, ma costruire il percorso più corto tra scrittura e pubblicazione. Nel 2018, per un blog gratuito, lo stack minimo funzionante poteva essere:

• dominio gratuito o sottodominio della piattaforma;
• CMS ospitato o WordPress su hosting free con PHP e MySQL;
• tema leggero, senza builder pesanti;
• backup esterno dei contenuti;
• SSL attivo, anche automatico;
• un canale alternativo di accesso amministrativo in caso di blocco account.

Se si usava WordPress, la combinazione minima corretta era PHP aggiornato per l’epoca, database MySQL/MariaDB, e un tema che non richiedesse librerie strane o decine di plugin per funzionare. In un hosting free, il problema non era quasi mai “WordPress non parte”, ma “parte oggi e domani il provider limita CPU, I/O o processi simultanei”.

Per questo il tema doveva essere leggero, il numero di plugin ridotto e i contenuti serviti con immagini compresse. Un blog gratis non regge bene la filosofia “installo tutto, poi vedo”.

Come scegliere il provider senza farsi fregare dai limiti nascosti

La scheda commerciale contava poco. Quello che contava era leggere le restrizioni operative: banda mensile, spazio disco, limiti su PHP, SMTP bloccato, accesso FTP, cron job, pubblicità forzata, inattività automatica. Nel 2018 molti servizi free erano sostenibili solo finché il sito restava piccolo e poco visitato. Appena arrivava un picco, comparivano code, timeout o sospensioni.

Un test rapido prima di impegnarsi era verificare tre cose: esiste un export completo? si può cambiare tema senza pagare? il dominio può essere collegato via DNS esterno? Se la risposta a una sola di queste era “no”, il rischio di lock-in saliva parecchio.

Per un blog tecnico la priorità era avere il controllo sui contenuti e sul nome del sito. I contenuti si esportano, la reputazione del dominio molto meno. Se il provider consentiva solo un sottodominio del tipo nomepiano.provider.tld, andava bene per un test o per un diario personale, ma era una base debole per qualcosa che doveva durare.

Dominio, DNS e certificato: il punto dove i blog gratuiti si rompono più spesso

Molti blog gratuiti fallivano non per il CMS, ma per la parte di bordo: dominio mal configurato, record DNS errati, certificato scaduto o redirect fatti male. Nel 2018 HTTPS non era più un optional realistico. Anche sui blog piccoli, il certificato serviva sia per credibilità sia per evitare warning nel browser.

Se usavi un dominio tuo, i record minimi erano quelli classici: A o AAAA verso l’host, eventualmente CNAME per www, e un TTL non troppo basso se non avevi bisogno di migrazioni frequenti. Un controllo essenziale era:

dig +short example.com A
curl -I https://example.com

Se il DNS rispondeva ma il sito no, il problema era a valle: origin, web server, PHP o database. Se il certificato dava errore, andava verificato il nome SAN, la catena e il redirect HTTP→HTTPS. Un blog gratis non poteva permettersi un flusso di accesso confuso: il visitatore non aspetta, chiude.

In caso di piattaforma ospitata, il rischio era opposto: tutto funzionava finché restavi dentro le regole del provider. Appena si voleva un dominio personalizzato, il setup diventava un esercizio di DNS e policy del servizio. Qui la disciplina contava più della fantasia.

Backup: la parte noiosa che salva il blog quando cambia il provider

Un blog gratis senza backup reale è un blog in affitto senza chiavi. Nel 2018 la forma minima di backup era doppia: export dei contenuti e copia dei media. Per WordPress, l’export XML bastava per i post, ma non per immagini, tema e configurazioni più sottili.

Se avevi accesso ai file, il backup utile comprendeva almeno `wp-content/uploads`, i temi personalizzati e, se possibile, un dump del database. Un esempio di base, lato server, era:

mysqldump -u bloguser -p blogdb > blogdb.sql
zip -r blog-backup.zip wp-content/ blogdb.sql

Se invece eri su piattaforma chiusa, il backup diventava un processo di export periodico. L’errore tipico era fidarsi dell’export una volta sola, poi rimandare. Dopo tre mesi di articoli e immagini, il ripristino completo diventava molto più laborioso. Il backup non si misura quando lo fai, ma quando provi a rientrare dopo un problema.

La cadenza minima ragionevole era settimanale per un blog attivo, mensile per un blog quasi statico. E la copia non doveva stare solo nello stesso account del provider: se cade l’account, cade anche la copia.

WordPress gratis nel 2018: quando ha senso e quando no

WordPress restava la scelta più flessibile, ma non sempre la più furba su hosting gratuito. Ha senso quando servono portabilità, editor noto e possibilità di migrare in futuro. Non ha senso se il provider impone limiti stretti su PHP, cron, upload e database, perché il margine operativo si assottiglia subito.

Su installazioni minime, il tema e i plugin facevano la differenza più del CMS in sé. Un blog semplice poteva vivere bene con pochi plugin: cache leggera, SEO basilare, backup o export, antispam. Ogni plugin in più aumentava il rischio di incompatibilità e consumo risorse.

Una checklist pratica prima di pubblicare era questa:

• homepage caricata in meno di 3 secondi su connessione normale;
• login admin protetto da password forte e, se disponibile, 2FA;
• immagini ridimensionate prima dell’upload;
• nessun plugin duplicato che faccia la stessa cosa;
• versione PHP supportata dal provider;
• backup testato con restore in ambiente separato.

Se uno di questi punti mancava, il blog poteva comunque partire, ma era già tecnicamente fragile. E la fragilità, nei servizi gratuiti, si paga sempre con più tempo che con più soldi.

Pubblicare senza diventare amministratore a tempo pieno

Il trucco per non trasformare un blog gratis in un lavoro era ridurre le attività ricorrenti. Niente personalizzazioni inutili, niente esperimenti continui sul tema, niente plugin installati “per provare”. Ogni modifica andava fatta con un criterio: migliora davvero il flusso di scrittura o il recupero dei contenuti?

Una buona pratica era tenere un file locale con le impostazioni essenziali del sito: nome del provider, URL admin, credenziali recuperabili tramite password manager, record DNS, data dell’ultimo backup e lista plugin. Non per nostalgia del foglio Excel, ma perché quando un blog si blocca dopo sei mesi, la memoria umana è il primo componente a fallire.

Se il provider offriva statistiche base, bastavano. Se non le offriva, si poteva usare un contatore esterno minimale, ma senza riempire il sito di script. Un blog gratis deve rimanere leggero. Il traffico iniziale va bene, il sovraccarico autoindotto no.

Una configurazione pratica che stava in piedi davvero

Una configurazione realistica nel 2018 poteva essere questa: dominio personale, DNS su un registrar affidabile, hosting gratuito con PHP e MySQL, WordPress installato con tema leggero, SSL automatico, backup settimanale esportato fuori dal provider. Era una struttura semplice, ma aveva un vantaggio importante: ogni pezzo poteva essere sostituito senza rifare tutto da zero.

Se il provider diventava lento, si poteva migrare il CMS. Se il CMS diventava un peso, si poteva passare a una piattaforma statica. Se il dominio restava tuo, il danno era limitato. Il vero asset del blog non era il pannello di controllo: erano dominio, contenuti e archivio.

In pratica, il blog gratis riusciva quando si trattava come un servizio essenziale, non come un giocattolo. Bastavano poche scelte fatte bene all’inizio per evitare settimane di correzioni dopo.

Quando conviene smettere di usarlo gratis

Ci sono segnali chiari che il blog ha superato il perimetro del “gratis”: accessi in crescita, necessità di plugin più seri, importanza del posizionamento, bisogno di redirect puliti, richieste di email associate al dominio. A quel punto il costo vero non è il canone del server, ma il tempo perso a compensare limiti strutturali.

Il passaggio a un hosting economico o a un VPS piccolo ha senso quando il blog inizia a produrre valore o richiede affidabilità. Fino ad allora, il setup gratuito resta valido se è sobrio, esportabile e sotto controllo. La soglia da guardare non è il numero assoluto di visite, ma la quantità di manutenzione necessaria per tenerlo in piedi.

Un blog gratis nel 2018 poteva funzionare bene. Ma solo se lo si costruiva con mentalità da amministratore, non da utente distratto: pochi componenti, backup veri, DNS pulito, SSL attivo, contenuti esportabili. Il resto era rumore.