Basi SEO nello sviluppo web: cosa integrare dall'inizio
Buona parte del SEO non è affatto marketing: sono decisioni prese durante lo sviluppo, poco costose in fase di costruzione e care in seguito. La struttura degli URL, la strategia di rendering, il collegamento interno e i metadati modificabili rientrano tutti in questa categoria.
Questa guida copre cosa integrare fin dall'inizio, grosso modo in ordine di quanto sia doloroso aggiungerlo dopo.
Assicurati che il sito possa essere scansionato e indicizzato#
Tutto il resto è irrilevante se i motori non riescono a raggiungere o leggere le tue pagine. È anche qui che si concentrano gli errori del giorno del lancio.
- Il robots.txt di produzione consente la scansione. La copia di preproduzione non deve essere rilasciata con esso.
- Nessun tag noindex sfuggito e riportato dalla preproduzione.
- Ogni pagina ha un URL canonico autoreferenziale, ed esiste un solo nome host canonico.
- Il contenuto è nell'HTML o reso lato server. Se compare solo dopo l'esecuzione del JavaScript, l'indicizzazione diventa più lenta e meno affidabile.
- Una sitemap XML che elenchi solo URL indicizzabili e canonici, non varianti filtrate o paginate.
- Ogni pagina indicizzabile ha almeno un link interno. Le pagine orfane vengono scansionate a malapena.
- Codici di stato coerenti: 200 per le pagine vere, 404 per quelle mancanti, 301 per quelle spostate.
Il fallimento di lancio più comune in questo elenco è il robots.txt di preproduzione che arriva in produzione. Controllalo dall'esterno della tua rete il giorno del lancio.
Una struttura che i motori possano leggere#
Le decisioni strutturali sono quelle dolorose da cambiare dopo, perché cambiarle significa reindirizzamenti e perdita dei segnali accumulati.
| Decisione | Costruiscila così | Costo del cambiarla dopo |
|---|---|---|
| Schema di URL | Breve, minuscolo, con trattini, stabile | Alto: reindirizzamenti e segnali persi |
| Gerarchia dei titoli | Un H1, nessun livello saltato | Basso |
| Collegamento interno | Pilastri che collegano le pagine di dettaglio e viceversa | Medio |
| Paginazione | Link scansionabili, non solo JavaScript | Medio |
| Navigazione a faccette | noindex sulle combinazioni di filtri | Alto: il gonfiore dell'indice si riassorbe lentamente |
| Versioni linguistiche | URL con prefisso più hreflang reciproco | Molto alto |
Metadati che il tuo team possa davvero modificare#
Un errore ricorrente in realizzazione è generare titoli e descrizioni da un template senza modo di sovrascriverli. Sei mesi dopo il marketing deve cambiare il titolo di una pagina e la risposta è un ticket allo sviluppo.
- Tag title modificabile per pagina, con un valore predefinito generato sensato.
- Meta descrizione modificabile, con un contatore di caratteri visibile nel CMS.
- Titolo, descrizione e immagine Open Graph modificabili per i link condivisi.
- Dati strutturati sui template che li supportano: Article, Product, FAQ, Breadcrumb, Organization.
- Un interruttore noindex per pagina, per le pagine che devono esistere ma non posizionarsi.
- Canonico automatico, con sovrascrittura manuale per il caso raro che ne abbia bisogno.
Marca solo ciò che è davvero visibile sulla pagina. Dati strutturati che descrivono contenuti che un visitatore non può vedere sono una violazione delle linee guida, non una scorciatoia.
Velocità e stabilità come requisiti di realizzazione#
L'esperienza di pagina fa parte della realizzazione, non di un progetto di ottimizzazione successivo. Aggiungere velocità a un sito finito di solito significa disfare decisioni anziché aggiungere codice.
| Metrica | Obiettivo | Si ottiene con |
|---|---|---|
| Largest Contentful Paint | Sotto 2,5 s | Dare priorità all'immagine di testata, evitare risorse che bloccano il rendering |
| Cumulative Layout Shift | Sotto 0,1 | width e height sulle immagini, spazio riservato per gli incorporamenti |
| Interaction to Next Paint | Sotto 200 ms | Meno JavaScript e non bloccare il thread principale |
| Peso di pagina | Il più basso che il design consenta | Formati di immagine moderni, nessuna libreria inutilizzata |
| Time to First Byte | Sotto 800 ms | Cache, un CDN e query di database sensate |
Domande frequenti
Il SEO deve stare nel brief di sviluppo?
Le parti tecniche sì: scansionabilità, struttura degli URL, metadati modificabili, dati strutturati, obiettivi di prestazione e la mappa dei reindirizzamenti. La strategia dei contenuti e la costruzione di link sono lavoro a parte con un profilo diverso. Mettere i requisiti tecnici nel brief significa che vengono quotati anziché scoperti dopo il lancio, quando costano diverse volte tanto.
Un framework JavaScript danneggia il SEO?
Può, se le pagine vengono rese solo nel browser. I motori eseguono JavaScript ma in ritardo e non sempre completamente, quindi il rendering solo lato client rende l'indicizzazione più lenta e meno affidabile. Il rendering lato server o la generazione statica elimina il problema. Per un sito editoriale la risposta più semplice è di solito mettere il contenuto nell'HTML.
Quanto tempo dopo il lancio prima di vedere traffico di ricerca?
Per un dominio nuovo, tipicamente settimane per l'indicizzazione e mesi prima di posizioni significative: i siti nuovi non si posizionano in fretta indipendentemente dalla qualità tecnica. Per il rilancio di un sito esistente con reindirizzamenti puliti, conta due-sei settimane di oscillazione prima di riassestarsi intorno al livello precedente.
Mi serve un plugin SEO?
Su un CMS, un plugin è un modo comodo per dare alla redazione il controllo su titoli, descrizioni, canonici e sitemap. Non è una strategia, e il suo output predefinito non sostituisce qualcuno che decida di cosa debba parlare ogni pagina. Su uno sviluppo su misura la stessa funzionalità di solito viene scritta direttamente e risulta più leggera.
seo sviluppo webbasi seoseo tecnicoseo per sviluppatoriscansionabilitàseo on page
