Un rebrand è una migrazione di dati, non una sostituzione grafica
EclipsMC nasce dopo un progetto con identità e struttura differenti. Alcuni componenti sono stati riutilizzati, altri sostituiti e altri ancora mantenuti come base tecnica. Questo rende la migrazione efficiente, ma crea un rischio: lasciare riferimenti che nessuno vede durante il normale utilizzo e che emergono soltanto in fallback, file di configurazione o pagine non più collegate.
La regola che abbiamo adottato è trattare il vecchio nome come un indicatore di debito di migrazione. Una ricerca globale deve restituire zero occorrenze nei file destinati alla produzione, salvo eventuali contenuti storici in cui il riferimento sia intenzionale e contestualizzato.
Il fallback può sopravvivere più a lungo della pagina principale
Uno dei residui individuati era dentro un file di dati live/fallback: il sito poteva mostrare correttamente EclipsMC durante il normale funzionamento, ma conservare ancora host e nome del progetto precedente nel percorso usato quando la sorgente live non era disponibile. È il tipo di errore che non compare durante un test “felice”.
La correzione è stata accompagnata da una ricerca su codice, dati e configurazioni. Questo controllo è più importante del singolo file: il valore del caso sta nell’aver aggiunto la scansione dei riferimenti al processo di release.
/pages/guides e /pages/guides.php non devono competere
Una stessa pagina raggiungibile con due URL può essere gestita dai motori di ricerca, ma lasciare la scelta completamente implicita crea lavoro inutile e segnali più deboli. La soluzione EclipsMC usa una forma canonica senza estensione per le pagine pubbliche.
Le richieste esplicite alla vecchia variante .php vengono reindirizzate in modo permanente alla URL pulita. La pagina canonica dichiara sé stessa con rel="canonical", la sitemap contiene solo la forma pulita e i link interni puntano alla stessa forma. In questo modo redirect, canonical, sitemap e navigazione raccontano tutti la stessa preferenza.
Non tutto ciò che è utile a un utente deve essere una landing page SEO
Forum, login, profili, roadmap, Command Center e pagine di gestione hanno un ruolo importante nel prodotto, ma non sono necessariamente contenuti editoriali da posizionare. Abbiamo quindi distinto le pagine da indicizzare dalle superfici operative, usando noindex per queste ultime e disattivando per impostazione predefinita il caricamento del codice pubblicitario.
Questa scelta non “nasconde” parti del sito: le rende ancora accessibili agli utenti e attraversabili dai link, ma chiarisce che la parte editoriale da presentare ai motori di ricerca è composta da guide, casi di studio, informazioni sul progetto e contenuti sostanziali.
La sitemap deve essere una selezione, non l’inventario del disco
In una sitemap includiamo le URL canoniche che vogliamo far scoprire e indicizzare. Non serve elencare login, API, redirect, file tecnici o pagine marcate noindex. Una sitemap editoriale più pulita riduce contraddizioni e aiuta anche noi a capire quali pagine stiamo trattando come contenuto principale.
Le date lastmod vengono aggiornate quando il contenuto cambia realmente. Cambiare la data ogni giorno senza modifiche sostanziali non rende una pagina più utile e rende meno affidabile il segnale.
La migrazione si chiude con richieste HTTP, non con una ricerca nel codice
- Richiedere URL pulita e verificare risposta 200.
- Richiedere variante
.phpe verificare un solo 301 verso la canonica. - Controllare canonical assoluta nel sorgente HTML.
- Confrontare sitemap, link interni e redirect.
- Ricercare riferimenti al vecchio dominio in file e dati.
- Usare Search Console per osservare la canonical scelta dopo il nuovo crawl.
La coerenza SEO nasce dalla coerenza del prodotto
Canonical, redirect e sitemap non servono a “convincere Google” di qualcosa che il sito contraddice altrove. Servono a descrivere con precisione una struttura reale. Quando branding, URL, dati e navigazione sono allineati, anche il lavoro SEO diventa più semplice perché non deve compensare incoerenze interne.