Salvataggio del SEO tecnico per Expreso (WordPress + CloudPanel + NGINX + S3/CloudFront)

Il problema tipico di un ambiente di grandi dimensioni: volume + legacy

L'Expreso presentava le classiche facciate di un sito con anni di contenuti:

• 404 e altri 4XX da URL vecchi, inventati dai bot o generati da modelli errati.
• Immagini rotte (risorse mancanti) che hanno provocato “Immagini non funzionanti” e “La pagina ha un'immagine non funzionante”.
• Contenuto misto (pagine HTTPS con risorse HTTP).
• Obiettivo duplicato (meta descrizione multipla) per sovrapposizione di componenti.
• Sitemaps intermittenti (occasionalmente 503 per carico/proxy/cache).
• Link esterni con reindirizzamento (http → https / accorciatori).

In un mezzo di comunicazione, questi dettagli si moltiplicano rapidamente: se non c'è un sistema di manutenzione, il sito può continuare a pubblicare senza sosta... ma ogni settimana il “rumore” cresce e le segnalazioni diventano più difficili da controllare.

Strategia: attacco a strati (server → CDN → WordPress)

La logica era semplice: invece di cercare gli errori uno per uno, una sistema di pulizia e prevenzione.

1) NGINX: igiene globale per ridurre il rumore e proteggere le risorse

Il primo livello è stato quello di filtrare ciò che arriva al sito:

• Tipiche richieste di scanner (.env, wp-config.php, admin.php, shell, percorsi falsi).
• Percorsi ripetitivi che gonfiano i registri e gli audit (ad esempio, varianti di mraid.js, pagespeed, ecc.).
• Comportamento “igienico” per il 4XX senza interrompere gli endpoint legittimi.

È stato organizzato in frammenti per evitare di mettere a rischio il vhost e sono state applicate le risposte appropriate:

• 444 / 410 / 204 a seconda dei casi, evitando di passare traffico spazzatura a PHP.
• Eccezioni chiare in cui il sito deve rispondere (ad esempio, .well-known validi o percorsi reali).

Impatto: meno sprechi di carico, meno falsi errori e una base più stabile per il tracciamento.

2) CDN (S3/CloudFront): risolvere in massa le “Immagini rotte”.

Ecco il vero volume.

In un supporto, molte immagini storiche vengono perse o cancellate nel corso del tempo. Non è possibile recuperarle, ma è possibile prevenirle:

• l'utente vede le immagini spezzate,
• I crawler trovano migliaia di 404,
• il sito è eternamente “sporcato” nelle verifiche.

Soluzione pratica applicata in Expreso: segnaposto in S3 + invalidazione in CloudFront.

Flusso:

1. Estrarre dal report (CSV) gli URL delle immagini con 4XX in cdn.expreso.press.
2. Caricare un segnaposto minimo (1px o immagine leggera) con tipo di contenuto corretto.
3. Invalidare CloudFront per cancellare la cache 404.

Principali insegnamenti: l'approccio ingenuo di AWS CLI (testa-oggetto per URL) può diventare molto lento o bloccarsi su elenchi di grandi dimensioni. Per Expreso, siamo passati a un approccio “FAST” con boto3 (SDK) + parallelismo + timeout, con progressi visibili nei log.

Dettaglio importante:

• Alcune relazioni sono dotate di percorsi già con wp-content/uploads/..., quindi il sistema dovrebbe evitare di duplicare chiavi come wp-content/uploads/wp-content/uploads/.....

3) Contenuto misto: tagliare il “HTTP dentro HTTPS”.”

Il contenuto misto non sempre rompe la pagina, ma la abbandona:

• avvisi di sicurezza
• rapporti negativi
• incongruenze tecniche

È stato fatto un lavoro di standardizzazione:

• risorse e incorporamenti in HTTPS
• correzione dei modelli precedenti (http://...) durante l'applicazione di
• regola operativa: nulla di “insicuro” nelle risorse vincolate

4) Link esterni con reindirizzamento (External 3XX)

Negli audit è comune trovare:

• link esterni su http:// che reindirizzano a https://
• accorciatori (bit.ly, tinyl...) che aggiungono salti
• domini che hanno cambiato canonical o che reindirizzano verso percorsi strani

In Expreso il lavoro è stato separato in:

• Auto: stesso host (normalizzazione sicura http→https / www→no-www).
• Recensione: accorciatori, stringhe strane, reindirizzamenti a login/paywall, ecc.

In questo modo è possibile sistemare in lotti ciò che è sicuro e lasciare il resto per una revisione sicura.

Risultato: passare dallo “spegnere gli incendi” all'operare con controllo

Una volta applicati i livelli (server + CDN + normalizzazione), il sito rimane:

• pulitore per i crawler,
• con meno interruzioni visibili,
• e con una chiara routine di manutenzione per evitare che si accumuli di nuovo.

Operazione futura (ciò che mantiene Expreso in salute)

Semplici regole tecniche per i catturatori (senza entrare nel merito dei contenuti)

• Incolla i link sempre in https
• Evitare gli accorciatori: incollare il file URL finale
• Immagini solo da Biblioteca multimediale (senza hotlink)
• Embed/iframes sempre presenti https

Routine settimanale per gli amministratori (20-30 minuti)

• Eseguire l'audit (Ahrefs o simili) e seguire l'ordine:
  1. Immagini rotte
  2. Link a pagine non funzionanti
  3. Contenuto misto
  4. Meta descrizione multipla
  5. Timeout / 5XX
• Eseguire le correzioni batch (script + invalidazione), se del caso.
• Convalidare le sitemap (se c'è intermittenza, viene gestita da prestazioni/proxy/cache, non dal “contenuto”).

Conclusione

In un ambiente come Espresso, La SEO tecnica non si risolve con un aggiustamento una tantum: si risolve con sistema + routine.

Quando il rumore è controllato, la consegna è stabilizzata e le risorse non funzionanti sono corrette su scala, il sito diventa più tracciabile, più affidabile e molto più facile da mantenere di settimana in settimana.