SEO per sviluppatori: cosa conta davvero nel codice

TL;DR: La SEO per sviluppatori è la parte “strutturale” della SEO che vive nel codice: risposte HTTP, HTML iniziale, link, metadata, direttive di crawl, URL, dati strutturati e performance. L’obiettivo è eliminare ogni possibile motivo meccanico per cui un crawler potrebbe non riuscire ad accedere, eseguire il rendering, indicizzare o comprendere una pagina. Tutto questo non sostituisce contenuti utili o autorevolezza.

La parte della SEO che appartiene al repository

Chiamo questo il 20% della SEO che è in capo agli sviluppatori (una regola di priorità, non una statistica di settore). La scelta delle keyword, la qualità editoriale, i backlink e la domanda legata al brand avvengono per lo più fuori dal repository. Nessun componente React può produrli.

Gli sviluppatori, invece, controllano ciò che riceve il crawler: codice di stato, HTML iniziale, link, titolo, canonical, direttive di indicizzazione, schema e comportamento a runtime. Se sono sbagliati, contenuti utili possono restare inesplorati o essere interpretati come duplicati. Se sono corretti, però, il contenuto deve comunque meritare visibilità. Hai rimosso il “veto” tecnico, ma non hai garantito un ranking.

Il modello utile sono quattro “cancelli”: crawlable, renderable, indexable, understandable. Un URL deve passarci attraverso, grosso modo in quest’ordine. La nostra guida su cosa significa crawling nella SEO tratta in modo più dettagliato il primo cancello.

Diffido delle promesse secondo cui un framework, un tipo di schema o un punteggio di audit perfetto produrranno un aumento di ranking prevedibile. La nostra migrazione di gennaio 2026 da seojuice.io a seojuice.com ha confermato la lezione meno “entusiasmante”: redirect accurati, canonicals coerenti, link interni aggiornati e risposte osservabili in produzione contano più delle teorie sulla migrazione. Abbiamo trattato la mappa vecchi-URL → nuovi-URL come qualcosa da testare, non come un foglio di calcolo da archiviare dopo il go-live.

Inizia dalla risposta HTTP

Un componente rifinito che restituisce lo stato sbagliato è comunque la pagina sbagliata. Controlla la risposta prima di aprire DevTools.

Secondo la documentazione di Google Search Central sui codici di stato HTTP, un 301 è un “strong signal” (segnale forte) sul fatto che la destinazione del redirect debba essere processata. Un 302 è un “weak signal” (segnale debole). Usa 301 per un trasferimento permanente e 302 solo quando lo spostamento è davvero temporaneo.

Una rotta mancante deve restituire un vero 404 dal server o dall’edge. Fare il rendering di un componente “not found” gentile mantenendo però 200 crea un soft 404: lo strato di trasporto dichiara che esiste contenuto valido, mentre il body dice il contrario. La pagina di errore può apparire eccellente e restare comunque tecnicamente falsa.

Un 410 dichiara esplicitamente che il contenuto è sparito, ma c’è poca ragione pratica nel fissarsi su 404 vs 410 per una rimozione ordinaria. Google tratta entrambi come contenuto assente. Un 404 corretto è sufficiente.

Conta anche l’affidabilità. Google afferma che le risposte 5xx e 429 fanno rallentare temporaneamente i suoi crawler, mentre il contenuto restituito con uno stato 5xx viene ignorato. Un errore applicativo intermittente non è quindi solo un problema di disponibilità: può ridurre il crawl proprio quando servono download di nuove o pagine aggiornate.

Metti queste verifiche nei test di integrazione:

• Una rotta pubblica valida restituisce 200.
• Un URL spostato in modo permanente restituisce 301 verso la sostituzione rilevante più vicina.
• Un redirect temporaneo usa 302 intenzionalmente, non perché quello era l’impostazione predefinita del framework.
• Una rotta sconosciuta restituisce 404 prima dell’hydration.
• Un’eccezione dell’app non “cade” in una risposta branded 200.
• Un redirect raggiunge la destinazione finale senza catene o loop.

Una risposta 200 non garantisce l’indicizzazione. Sposta soltanto il documento nel prossimo step di elaborazione di Google. Questa distinzione è centrale in come funziona l’indicizzazione di Google.

Includi HTML significativo nella prima risposta

Questa è la più grande rischiosità SEO specifica per gli sviluppatori. Un’app JavaScript può sembrare completa nel browser, mentre nella risposta iniziale contiene poco più di un root vuoto ed eventuali riferimenti ai bundle.

Google Search Central spiega che le pagine che restituiscono 200 vengono messe in coda per il rendering. Una pagina può restare in quella coda per secondi o più prima che un Chromium headless esegua il suo JavaScript. Google usa poi l’HTML renderizzato per l’indicizzazione.

Googlebot può eseguire JavaScript moderno. La domanda architetturale non è solo “Google può eseguirlo?”. È “Perché obbligare un crawler a scaricare, eseguire, chiamare un’API e aggiornare il DOM prima di poter scoprire l’intestazione principale?”. Ogni dipendenza extra crea un punto di fallimento in più.

“Il server-side rendering è una scelta popolare per fornire un’esperienza ‘dalla resa completa’ che i crawler possono interpretare.”

Questa raccomandazione arriva dagli ingegneri di Google Chrome Addy Osmani e Jason Miller in Rendering on the Web. Loro sottolineano anche che il crescente peso del JavaScript lato client può incidere sull’INP: in pratica collega l’architettura di rendering alla reattività percepita dagli utenti, invece di trattare SSR come semplice “teatro per crawler”.

Il mio default: generazione statica per contenuti che cambiano raramente, server-side rendering per pagine che dipendono dalla richiesta, e hydration o componenti client selettivi per l’interazione. La guida di Google su dynamic rendering è altrettanto diretta: il dynamic rendering era una soluzione di workaround, non un rimedio di lungo periodo; Google raccomanda invece server-side rendering, rendering statico o hydration.

Il rendering puramente client-side non è automaticamente letale. Google potrebbe processarlo con successo. Ma “Google può renderizzare questo, prima o poi” è una garanzia ingegneristica più debole di “il contenuto è arrivato nella risposta” (più precisamente: è una speranza supportata da un altro pipeline di esecuzione). Molti crawler non-Google e strumenti di anteprima inoltre non eseguono JavaScript in modo coerente.

Fallimenti in SPA che vale la pena testare

• HTML iniziale vuoto: Recupera la rotta senza eseguire JavaScript. L’intestazione principale, la copia utile e i link importanti devono essere già presenti.
• Link “finti”: La navigazione dovrebbe usare anchor con attributi href. Un div con un click handler è un obiettivo di interazione, non un percorso di crawl affidabile.
• Routing con hash: Evita rotte come /#/pricing. Usa percorsi stabili e fai in modo che ogni rotta sia risolvibile lato server.
• Metadata condivisa: Fornisci a ogni rotta indicizzabile un titolo descrittivo, un canonical e metadata rilevanti, preferibilmente nella risposta server.
• Errori solo client: Le rotte mancanti hanno bisogno di un 404 HTTP, non di una risposta 200 trasformata dopo l’hydration.
• Contenuto bloccato dall’interazione: Non richiedere un click o uno scrolling arbitrario per esporre copy essenziale. Liste infinite richiedono una paginazione crawlable con URL reali.

Da ciò che vediamo in tutti i siti su SEOJuice, le contraddizioni “banali” tornano più spesso di bug esotici di rendering: un noindex in produzione, un canonical che punta all’host sbagliato, oppure link che si vedono ma non sono anchor. Di solito il framework funziona. Il punto in cui le assunzioni collidono è la risposta finale assemblata da framework, CMS, proxy ed edge configuration.

La nostra guida SEO per JavaScript approfondisce la pipeline crawl-render-index, mentre SEO per Next.js, React e Nuxt mappa gli stessi test alle decisioni a livello di framework.

Tratta i controlli di crawl come meccanismi separati

Robots.txt, noindex, canonicals e sitemap sono spesso raggruppati sotto “impostazioni di indicizzazione”. Fanno lavori diversi e metterli insieme in modo incauto può rendere impossibile per Google osservare l’istruzione desiderata.

Robots.txt controlla l’accesso del crawler

La documentazione ufficiale di Google su robots.txt dice che il file comunica ai crawler quali URL possono accedere ed è usato principalmente per evitare di sovraccaricare un sito con richieste. Il limite cruciale è esplicito: “non è un meccanismo per tenere una pagina web fuori da Google”. Un URL non consentito può comunque essere indicizzato se altre pagine vi linkano.

Usa robots.txt per gestire il crawling, non per riservatezza o rimozione affidabile dalla ricerca.

Noindex controlla l’inclusione nell’indice

Per tenere fuori da Google una pagina accessibile, invia una direttiva meta robots noindex o un header X-Robots-Tag. Lascia l’URL crawlable abbastanza a lungo perché Google possa vedere quell’istruzione.

Qui c’è la trappola: se robots.txt blocca l’URL, il crawler non può scaricare la pagina e non può osservare la sua direttiva noindex. La documentazione di Google sul noindex dice esplicitamente che la risorsa non deve essere bloccata da robots.txt affinché la regola sia efficace.

Il canonical identifica un duplicato preferito

Il canonical è un segnale forte, non una direttiva assoluta. Un default pratico è un canonical self-referencing su ogni pagina indicizzabile. Puntalo altrove solo quando l’URL corrente è davvero un duplicato o una forma alternativa della destinazione.

Tutti i segnali devono essere coerenti. Reindirizzare A verso B dichiarando però A come canonical è una contraddizione. Lo è anche inserire nel sitemap un URL con parametri mentre lo canonicalizzi verso una versione “pulita”. Google può selezionare un canonical diverso se la tua implementazione invia messaggi misti.

Durante la migrazione di dominio, il test utile non era “Il componente canonical contiene il nuovo dominio?”. Era: “Per ogni vecchio URL pubblico, che status, destinazione, canonical, link interni e voce nel sitemap riceve davvero un crawler?”. Questa matrice ha evidenziato classi di errori che una revisione del template non avrebbe potuto scoprire.

Una sitemap aiuta la scoperta

Google descrive una sitemap come un modo per identificare pagine e file che consideri importanti. Non garantisce crawling o indicizzazione e un sito ben linkato può essere scoperto anche senza.

Include URL canonici indicizzabili che restituiscono 200. Escludi redirect, errori, pagine noindex e varianti duplicate con parametri. Una sitemap deve descrivere il sito pubblico “pulito”, non replicare ogni record che il tuo database ha prodotto.

HTML semantico: infrastruttura per i crawler

MDN definisce la semantica come “il significato di un pezzo di codice”. Un elemento di heading assegna un ruolo di heading. Un grande span stilizzato può sembrare identico, ma non esprime quel ruolo. La stessa distinzione vale per un anchor usato per la navigazione e per un button usato per un’azione.

Le impostazioni predefinite del mio template sono volutamente noiose:

• Un solo h1 chiaro a livello pagina come regola di casa, non un presunto trucco per il ranking.
• Una outline logica di h1, h2 e h3 guidata dalla struttura del contenuto, non dalla dimensione del font.
• Anchor con attributi href per le destinazioni.
• Button per le azioni.
• Landmark utili: header, nav, main, article e footer.
• Un titolo unico e descrittivo e una meta description per ogni rotta indicizzabile.

La guida di MDN sull’HTML semantico collega queste scelte ad accessibilità, SEO e manutenibilità. Questa sovrapposizione è utile: il markup che comunica chiaramente lo scopo tende a funzionare meglio per i crawler, per le tecnologie assistive e per lo sviluppatore che lo debuggga sei mesi dopo.

Mantieni coerenti URL e segnali leggibili dalle macchine

Preferisci percorsi leggibili, in minuscolo e con trattini, e tienili stabili. Evita di esporre session ID, stato interno e parametri di tracking non necessari come varianti crawlable di URL. Se un URL cambia in modo permanente, fai redirect dal vecchio percorso e aggiorna i link interni verso la destinazione finale.

I dati strutturati forniscono una classificazione esplicita leggibile dalle macchine. Google definisce i dati strutturati come un formato standard per descrivere una pagina e raccomanda JSON-LD quando la configurazione lo consente.

Tipi come Article, BreadcrumbList, Product, Organization e WebSite possono essere utili quando descrivono accuratamente il contenuto visibile. Genera le proprietà richieste dalla stessa sorgente della pagina, poi valida l’output distribuito. I dati strutturati possono creare eleggibilità per risultati rich; non garantiscono però che Google li mostri.

Template internazionali richiedono coerenza analoga. Ogni versione hreflang deve riferirsi a se stessa e alle alternative, e i riferimenti devono essere bidirezionali. Usa lingue valide e codici regione opzionali, più x-default per una pagina di fallback. Una volta ho dato per scontato che i crawler avrebbero riconciliato più incoerenze di quante ne riconcilino (potrebbero anche farlo, ma è un pessimo contratto su cui costruire).

Performance: misura le metriche attuali

Le Core Web Vitals sono segnali di “page experience”, non un interruttore che spinge su in ranking una pagina più velocemente. Contenuti rapidi e sottili non diventano automaticamente più utili. La performance resta di responsabilità degli sviluppatori, è misurabile e ha valore per gli utenti.

web.dev definisce queste soglie al 75° percentile di caricamenti reali delle pagine, segmentate tra mobile e desktop. Una singola esecuzione rapida di Lighthouse non è rappresentativa (un run locale pulito può rendere quasi qualsiasi applicazione troppo bene). Usa dati di campo per individuare le rotte e le classi di device in cui gli utenti reali ricevono l’esperienza lenta.

Aggiorna anche le dashboard vecchie. INP ha sostituito FID come Core Web Vital il 12 marzo 2024. Se un report performance continua a trattare FID come metrica attuale di reattività, la guida SEO è datata.

Cosa va nelle verifiche CI e di rilascio

1. Richiedi rotte rappresentative e valida le risposte attese 200, 301 e 404.
2. Ispeziona l’HTML iniziale per titolo, canonical, direttiva robots, h1, copia principale e link interni.
3. Verifica che le pagine indicizzabili non siano bloccate da robots.txt.
4. Verifica che le pagine noindex restino crawlable, così i crawler possono osservare la direttiva.
5. Controlla che gli URL della sitemap restituiscano 200 e si identifichino come canonical.
6. Testa i redirect da host e percorsi vecchi fino a un’unica destinazione finale.
7. Convalida i JSON-LD generati rispetto al tipo di pagina visibile e alle proprietà richieste.
8. Monitora la performance su mobile nei dati di campo per LCP, INP e CLS.
9. Crawl della versione pubblicata dopo routing, CMS, proxy o cambi di dominio.

Esegui queste verifiche sulla distribuzione pubblica, non solo sul template sorgente. Middleware, regole CDN, plugin, variabili d’ambiente e cache obsolete possono modificare la risposta (e sì, è per questo che verifico ancora la produzione dopo un rilascio “solo metadata”).

Su SEOJuice, io e Lida automatizziamo lo strato on-page ripetitivo: link interni, meta titoli e descrizioni, markup schema e testo alternativo delle immagini. Questa automazione non può “salvare” HTML iniziale vuoto, codici di stato errati o un noindex in produzione. Se l’igiene pagina-per-pagina sta consumando tempo ingegneristico, SEOJuice ha un piano gratuito senza carta di credito, mentre il tuo team mantiene il controllo delle decisioni architetturali che solo lui può prendere.

Domande frequenti

Quali parti della SEO controllano davvero gli sviluppatori?

Gli sviluppatori controllano gli status HTTP, il rendering, l’HTML semantico, i link, le direttive di crawl, i canonicals, le sitemap, le metadata, i dati strutturati, le Core Web Vitals, hreflang e il comportamento degli URL. Non controllano direttamente qualità editoriale, backlink o autorevolezza del brand. Il loro lavoro è rendere i contenuti utili crawlable, renderable, indexable e understandable.

Il JavaScript è cattivo per la SEO?

No. Googlebot usa un Chromium sempre aggiornato e può eseguire JavaScript, ma il rendering viene accodato e introduce dipendenze aggiuntive. SSR, SSG o hydration mettono contenuti e link importanti nella risposta iniziale, riducendo la superficie di fallimento e migliorando l’accesso per i crawler che non eseguono JavaScript.

Robots.txt impedisce che una pagina venga indicizzata?

No. Robots.txt controlla l’accesso dei crawler, non l’inclusione nell’indice. Un URL bloccato può comunque comparire su Google se altre pagine vi linkano. Usa noindex per richiedere la rimozione e lascia l’URL crawlable così Google può vedere la direttiva. Il nostro generatore robots.txt gratuito può fornire una struttura sicura di partenza.

Qual è la differenza tra redirect 301 e 302 per la SEO?

Google descrive un 301 come un segnale forte sul fatto che la destinazione del redirect debba essere processata, mentre un 302 è un segnale debole. Usa 301 per gli spostamenti permanenti e 302 solo per redirect davvero temporanei.

Quali soglie delle Core Web Vitals dovrebbero puntare gli sviluppatori?

Target LCP di 2,5 secondi o meno, INP di 200 millisecondi o meno e CLS di 0,1 o meno. Queste soglie “buone” vengono valutate al 75° percentile dei caricamenti nel campo, su mobile e desktop. INP ha sostituito FID il 12 marzo 2024.

Perché la mia single-page application non compare su Google?

Controlla prima la risposta iniziale. Cause comuni: contenuti che esistono solo dopo l’esecuzione di JavaScript, navigazione senza veri link href, rotte con hash, metadata ripetute, direttive noindex accidentalmente attive e rotte mancanti che restituiscono 200. Correggi risposta e contratto di routing prima di cercare una spiegazione più “esotica”.