Codice HTML e DOM sono due concetti che ogni SEO tecnico deve saper distinguere con precisione. Il codice sorgente HTML è la risposta statica del server; il DOM è la struttura ad albero che il browser costruisce, modifica ed espone a JavaScript. Quando le due rappresentazioni divergono — e nei siti moderni divergono quasi sempre — cambia radicalmente il modo in cui Google indicizza i contenuti e il modo in cui un audit tecnico deve essere condotto.
Questa guida analizza nel dettaglio la relazione tra HTML source e DOM, il funzionamento del rendering pipeline del browser, il comportamento di Googlebot con il Web Rendering Service (WRS), i pattern di rendering moderni (SSR, CSR, SSG, ISR) e le implicazioni per Shadow DOM e Virtual DOM. Nella parte finale, trovi una metodologia di audit operativa per confrontare HTML e DOM su siti JavaScript-heavy.
HTML source vs DOM: definizione operativa
Per evitare ambiguità, fissiamo le definizioni operative che useremo in tutta la guida.
Codice HTML: la risposta del server
Il codice HTML (o HTML source, o view-source) è il documento testuale restituito dal web server in risposta a una richiesta HTTP. È ciò che vedi premendo Ctrl+U in Chrome o Firefox, oppure ciò che ricevi con un curl -s URL da terminale. È una stringa statica: non cambia dopo la ricezione, non viene manipolata dal browser, non risente dell’esecuzione di JavaScript.
In termini SEO, l’HTML source è ciò che Googlebot riceve nella prima fase di crawling, prima di qualsiasi rendering. Se il contenuto critico per l’indicizzazione si trova qui, il processo è lineare. Se non si trova qui, servono passaggi aggiuntivi.
DOM: la rappresentazione live del browser
Il DOM (Document Object Model) è un’interfaccia di programmazione definita dal W3C che rappresenta il documento HTML come un albero di nodi — oggetti con proprietà, metodi e gestori di eventi. Il browser costruisce il DOM a partire dall’HTML source, ma il risultato finale può differire significativamente dal sorgente per diverse ragioni:
- Correzione automatica: il parser HTML5 corregge markup malformato. Un documento senza
<head>o<body>viene ricostruito con la struttura corretta nel DOM. - Manipolazione JavaScript: gli script eseguiti dal browser aggiungono, rimuovono o modificano nodi nel DOM. Questo è il caso più rilevante per la SEO.
- Estensioni del browser: plug-in e extension iniettano elementi nel DOM (ad blocker, gestori di password, tool di analisi). Questi elementi non fanno parte del documento originale e non sono rilevanti per il rendering di Googlebot.
Il DOM è ciò che vedi nel pannello Elements degli Chrome DevTools quando usi “Ispeziona Elemento”. Non è il codice sorgente: è la rappresentazione live del documento dopo il parsing e l’esecuzione di tutti gli script.
Quando HTML e DOM divergono
La divergenza tra HTML source e DOM è minima nei siti generati interamente server-side (WordPress classico, siti statici). Diventa invece sostanziale quando:
- Il contenuto principale (testi, link, immagini) viene iniettato da JavaScript dopo il caricamento della pagina (tipico di SPA e applicazioni CSR).
- I meta tag (
title,meta description,canonical,hreflang) vengono impostati o modificati lato client. - Sistemi di lazy loading sostituiscono attributi
srcdelle immagini o differiscono il caricamento di intere sezioni della pagina. - Framework JavaScript gestiscono il routing client-side, dove l’URL cambia senza una nuova richiesta HTTP al server.
Per un SEO tecnico, la domanda operativa è sempre: il contenuto che deve essere indicizzato è presente nell’HTML source o solo nel DOM? La risposta determina il livello di rischio e la strategia di audit.
Come il browser costruisce il DOM
Il percorso che trasforma un documento HTML in una pagina visualizzata sullo schermo è noto come Critical Rendering Path. Comprendere questo processo è essenziale per diagnosticare problemi di rendering, performance e indicizzazione.
Parsing HTML e costruzione dell’albero DOM
Quando il browser riceve l’HTML source dal server, avvia il processo di parsing secondo le specifiche HTML5 (WHATWG HTML Living Standard, sezione 13.2). Il parsing procede in quattro fasi:
- Conversione byte → caratteri: il browser decodifica il flusso di byte secondo l’encoding dichiarato (UTF-8 nella maggior parte dei casi).
- Tokenizzazione: il tokenizer identifica tag di apertura, tag di chiusura, attributi e contenuto testuale, producendo una sequenza di token.
- Costruzione nodi: ogni token viene convertito in un nodo dell’albero DOM (Element, Text, Comment, Document).
- Costruzione albero: i nodi vengono inseriti nella gerarchia padre-figlio secondo le regole di nesting HTML5. Tag non chiusi o nesting errato vengono corretti automaticamente dal parser.
Il risultato è un albero DOM che riflette la struttura logica del documento. Questo albero è già potenzialmente diverso dall’HTML source, perché il parser ha applicato correzioni e normalizzazioni.
CSSOM e render tree
In parallelo alla costruzione del DOM, il browser costruisce il CSSOM (CSS Object Model): un albero che rappresenta tutte le regole CSS applicabili al documento. Il CSSOM viene costruito analizzando i fogli di stile esterni (<link>), i blocchi <style> interni e gli stili inline.
DOM e CSSOM vengono poi combinati nel render tree (albero di rendering), che contiene solo i nodi visibili con le rispettive proprietà di stile computate. Gli elementi con display: none esistono nel DOM ma non nel render tree. Gli pseudo-elementi (::before, ::after) esistono nel render tree ma non nel DOM.
Il render tree viene poi utilizzato per calcolare il layout (posizione e dimensioni di ogni elemento) e infine per il paint (il disegno effettivo dei pixel sullo schermo).
Il ruolo di JavaScript nella manipolazione del DOM
JavaScript è il fattore che crea la divergenza più significativa tra HTML source e DOM. Il motore JavaScript del browser (V8 in Chrome/Chromium, SpiderMonkey in Firefox, JavaScriptCore in Safari) può accedere al DOM tramite le API standard (document.querySelector, document.createElement, innerHTML, ecc.) e modificare qualsiasi aspetto della struttura, del contenuto e dello stile.
Quando il parser HTML incontra un tag <script> senza attributi async o defer, la costruzione del DOM si blocca fino al completamento del download e dell’esecuzione dello script. Questo è il motivo per cui JavaScript è definito un render-blocking resource: blocca sia la costruzione del DOM che il rendering della pagina.
Gli attributi async e defer cambiano questo comportamento:
async— il download avviene in parallelo al parsing, ma l’esecuzione blocca il parser nel momento in cui lo script è pronto. L’ordine di esecuzione non è garantito.defer— il download avviene in parallelo e l’esecuzione viene posticipata al termine del parsing del documento, prima dell’eventoDOMContentLoaded. L’ordine è garantito.
Dopo l’evento DOMContentLoaded, qualsiasi script che manipola il DOM produce aggiornamenti che sono visibili solo nel DOM, mai nell’HTML source. È esattamente qui che si crea la divergenza che un SEO tecnico deve saper identificare e gestire.
Googlebot e il rendering: come Google vede il DOM
La gestione del rendering da parte di Google è il punto critico in cui la distinzione tra HTML e DOM diventa una questione SEO concreta. Dal 2019, Google ha aggiornato il proprio sistema di rendering, ma il processo non è ancora istantaneo né privo di limiti.
Web Rendering Service (WRS) e Chromium evergreen
Il Web Rendering Service (WRS) è il componente dell’infrastruttura di Google Search che esegue JavaScript e produce il DOM renderizzato delle pagine web. Dal maggio 2019, il WRS utilizza una versione evergreen di Chromium (allineata alle ultime versioni stabili), sostituendo il precedente sistema basato su Chrome 41 che aveva gravi limitazioni nell’interpretazione di JavaScript moderno.
Questo significa che, nella maggior parte dei casi, il WRS è in grado di eseguire framework moderni (React, Vue, Angular, Svelte) e produrre un DOM renderizzato coerente con quello che vede un utente. Tuttavia, “in grado” non significa “garantito”: esistono vincoli importanti.
Due fasi di indicizzazione: crawl e render
L’indicizzazione di Google opera in due fasi distinte, documentate da Martin Splitt (Google Developer Relations) e dalla documentazione ufficiale di Google Search Central:
- Prima ondata (crawl): Googlebot scarica l’HTML source e lo analizza. I link trovati nell’HTML vengono estratti e aggiunti alla coda di crawling. Il contenuto presente nell’HTML source viene indicizzato immediatamente.
- Seconda ondata (render): la pagina viene inviata al WRS, che esegue JavaScript, costruisce il DOM completo e indicizza il contenuto risultante. Questa fase può avvenire secondi, ore o giorni dopo il crawl iniziale.
Il ritardo tra le due fasi è il problema fondamentale. Se il contenuto critico (testi, link interni, dati strutturati) è disponibile solo nel DOM post-rendering, l’indicizzazione subisce un ritardo variabile e non prevedibile. Per siti con aggiornamenti frequenti (news, e-commerce con inventory dinamico), questo ritardo può avere un impatto concreto sulla visibilità in SERP.
Timeout e limiti del rendering di Googlebot
Il WRS ha limiti operativi che distinguono il rendering di Googlebot da quello di un browser utente:
- Stateless: il WRS non mantiene sessioni, cookie o local storage tra una visita e l’altra. Ogni rendering parte da zero.
- No user interaction: nessun click, scroll, hover o input. Il contenuto caricato tramite interazione utente (infinite scroll, click su “mostra di più”, tab switching) non viene renderizzato.
- Timeout: esiste un limite temporale per l’esecuzione di JavaScript. Script particolarmente pesanti o che dipendono da API esterne lente possono non completarsi prima del timeout.
- Risorse bloccate: se il
robots.txtblocca file CSS o JS necessari per il rendering, il WRS produce un DOM incompleto o errato. - Nessun supporto per Permission API: notifiche push, geolocalizzazione e altre API che richiedono il consenso dell’utente non sono disponibili.
L’implicazione pratica è diretta: il contenuto SEO-critical deve essere nell’HTML source o, al massimo, generato da JavaScript leggero che si esegue rapidamente senza dipendenze esterne. Affidarsi al rendering per il contenuto principale è una scommessa, non una strategia.
Rendering patterns e impatto SEO
La distinzione binaria “server-side vs client-side” è una semplificazione che non rappresenta più lo stato attuale dello sviluppo web. I framework moderni offrono pattern di rendering multipli, spesso combinabili nello stesso progetto. Ogni pattern ha implicazioni diverse sulla relazione tra HTML source e DOM e, di conseguenza, sull’indicizzazione.
SSR, CSR, SSG, ISR e streaming SSR
| Pattern | HTML source | DOM dopo JS | Rischio SEO |
|---|---|---|---|
| SSR (Server-Side Rendering) | Completo: il server genera l’HTML completo ad ogni richiesta | Minime differenze, hydration aggiunge interattivita | Basso |
| CSR (Client-Side Rendering) | Scheletro vuoto con riferimenti a bundle JS | Completamente diverso: tutto il contenuto e generato da JS | Alto |
| SSG (Static Site Generation) | Completo: HTML pre-generato a build time | Minime differenze | Molto basso |
| ISR (Incremental Static Regeneration) | Completo: HTML statico rigenerato su base temporale o on-demand | Minime differenze | Molto basso |
| Streaming SSR | Completo, inviato progressivamente al client | Minime differenze | Basso |
La regola operativa per la SEO e chiara: piu il contenuto e presente nell’HTML source, minore e il rischio di indicizzazione. SSG e ISR offrono il profilo di rischio piu basso perche l’HTML e completo e statico. CSR puro rappresenta il rischio massimo.
Framework moderni: Next.js, Nuxt, Astro, SvelteKit
I framework JavaScript di ultima generazione supportano nativamente pattern di rendering multipli, riducendo significativamente i problemi storici del JavaScript SEO:
- Next.js (React) — supporta SSR, SSG, ISR e App Router con React Server Components. Le pagine possono usare pattern diversi nella stessa applicazione. La funzione
generateStaticParamspre-genera le pagine a build time. - Nuxt (Vue) — supporta SSR, SSG e routing ibrido con la modalita
hybridche permette di specificare il pattern per ogni route. La funzioneuseSeoMeta()gestisce i meta tag sia lato server che client. - Astro — adotta un approccio “zero JavaScript by default”: le pagine sono generate come HTML statico a build time, con l’opzione di aggiungere interattivita tramite “islands” (componenti React, Vue o Svelte hydrated selettivamente).
- SvelteKit (Svelte) — supporta SSR, SSG e rendering ibrido. Il compilatore Svelte produce codice JavaScript minimale, con un overhead di hydration significativamente inferiore rispetto a React o Vue.
In un audit SEO tecnico, la scelta del framework non e sufficiente per determinare il profilo di rischio. Serve verificare quale pattern di rendering e stato effettivamente configurato per le pagine critiche, perche lo stesso framework puo produrre risultati radicalmente diversi.
Hydration e impatto su DOM e Core Web Vitals
L’hydration e il processo con cui un framework JavaScript “attiva” un documento HTML generato lato server, collegando gli event handler e rendendo la pagina interattiva. Durante l’hydration, il framework confronta il DOM renderizzato dal server con quello atteso dal client e, in caso di mismatch, puo ri-renderizzare intere sezioni della pagina.
L’impatto sui Core Web Vitals e misurabile:
- INP (Interaction to Next Paint): un DOM di grandi dimensioni (oltre 1.500 nodi, secondo le raccomandazioni di Lighthouse) rallenta la risposta del browser alle interazioni dell’utente. L’hydration aggiunge tempo all’interattivita iniziale.
- LCP (Largest Contentful Paint): se l’elemento LCP dipende dall’hydration per essere visualizzato, il tempo di rendering aumenta.
- CLS (Cumulative Layout Shift): un hydration mismatch che causa ri-rendering puo produrre layout shift visibili.
Le tecniche moderne per mitigare questi problemi includono il partial hydration (hydrate solo i componenti interattivi), il progressive hydration (hydrate i componenti in ordine di priorita) e le islands architecture di Astro, dove la maggior parte della pagina resta HTML statico senza hydration.
Shadow DOM e Virtual DOM
Oltre al DOM “standard”, esistono due varianti che un SEO tecnico incontra sempre piu frequentemente: lo Shadow DOM e il Virtual DOM. Entrambi influenzano il modo in cui il contenuto e accessibile ai crawler, ma con meccanismi molto diversi.
Shadow DOM: web components e isolamento
Lo Shadow DOM e una specifica W3C che permette di creare sotto-alberi DOM incapsulati, con scope CSS isolato e non accessibile tramite i normali selettori document.querySelector. E il meccanismo alla base dei Web Components (custom elements).
Dal punto di vista SEO, il comportamento di Googlebot con lo Shadow DOM e documentato: il WRS supporta sia l’open Shadow DOM sia il closed Shadow DOM. Il contenuto all’interno di uno Shadow Root viene renderizzato e indicizzato. Tuttavia, nella pratica emergono problemi:
- I link all’interno di Shadow DOM potrebbero non essere scoperti nella prima ondata di crawl (HTML source), ma solo dopo il rendering.
- I dati strutturati (JSON-LD) inseriti all’interno di un Shadow Root potrebbero non essere estratti correttamente.
- Tool di crawling come Screaming Frog in modalita “text only” (senza rendering JavaScript) non vedono il contenuto dentro Shadow DOM.
Nota: se il contenuto SEO-critical si trova all’interno di Web Components con Shadow DOM, e preferibile usare il pattern Declarative Shadow DOM (attributo shadowrootmode sul tag <template>), che rende il contenuto disponibile nell’HTML source senza richiedere JavaScript per la costruzione del sotto-albero.
Virtual DOM: React e reconciliation
Il Virtual DOM e un concetto architetturale introdotto da React (e adottato con varianti da Vue e altri framework). Non e una specifica W3C ne un’API del browser: e una rappresentazione JavaScript in-memory del DOM, usata dal framework per calcolare le differenze (diffing) tra lo stato precedente e quello corrente, applicando poi solo le modifiche necessarie al DOM reale (reconciliation).
Il Virtual DOM non ha impatto diretto sull’indicizzazione: Googlebot vede il DOM reale dopo la reconciliation, non il Virtual DOM. L’impatto e indiretto e riguarda le performance:
- Un’applicazione React con molti re-render produce un overhead JavaScript che puo rallentare il rendering iniziale, impattando LCP e INP.
- Framework come Svelte e SolidJS hanno eliminato il Virtual DOM a favore di aggiornamenti DOM chirurgici compilati a build time, con overhead di runtime significativamente inferiore.
Implicazioni per crawling e indicizzazione
La regola operativa resta la stessa indipendentemente dalla tecnologia:
- Verificare se il contenuto critico e nell’HTML source (accessibile senza JavaScript).
- Se non lo e, verificare che il rendering JavaScript produca un DOM completo entro i tempi di timeout del WRS.
- Per Shadow DOM, verificare che i link e i dati strutturati siano accessibili al crawler.
- Per applicazioni con Virtual DOM pesante, monitorare i Core Web Vitals come indicatore di rendering performance.
Audit tecnico: confrontare HTML source e DOM
Confrontare HTML source e DOM renderizzato e una delle operazioni fondamentali di un audit SEO tecnico su siti che utilizzano JavaScript. Di seguito la metodologia che applico e gli strumenti coinvolti.
Strumenti: DevTools, Screaming Frog, Puppeteer
Chrome DevTools — il confronto manuale piu rapido. Apri la pagina, premi Ctrl+U per vedere l’HTML source, poi F12 → pannello Elements per vedere il DOM. Per una differenza visiva immediata, Chrome DevTools permette di copiare l’outer HTML del nodo <html> dal pannello Elements e confrontarlo con il view-source usando un tool di diff.
Screaming Frog — il crawler offre due modalita di rendering: “Text Only” (analizza solo l’HTML source) e “JavaScript Rendering” (usa un browser Chromium headless per costruire il DOM). Eseguire due scansioni in parallelo, una per modalita, e confrontare i risultati (titoli, heading, word count, link interni) e il metodo piu efficiente per identificare discrepanze su larga scala.
Puppeteer / Playwright — per un confronto programmatico e ripetibile, uno script Node.js puo scaricare l’HTML source (richiesta HTTP diretta) e il DOM renderizzato (browser headless) della stessa pagina, producendo un diff automatico.
Esempio di script Puppeteer per il confronto:
const puppeteer = require('puppeteer');
const https = require('https');
async function compareHtmlDom(url) {
// 1. HTML source: richiesta HTTP diretta
const htmlSource = await new Promise((resolve, reject) => {
https.get(url, (res) => {
let data = '';
res.on('data', chunk => data += chunk);
res.on('end', () => resolve(data));
}).on('error', reject);
});
// 2. DOM renderizzato: browser headless
const browser = await puppeteer.launch({ headless: 'new' });
const page = await browser.newPage();
await page.goto(url, { waitUntil: 'networkidle0' });
const domRendered = await page.content();
await browser.close();
// 3. Confronto: estrai testo visibile da entrambi
const { JSDOM } = require('jsdom');
const textFromHtml = new JSDOM(htmlSource).window.document.body.textContent.trim();
const textFromDom = new JSDOM(domRendered).window.document.body.textContent.trim();
console.log('HTML source length:', htmlSource.length);
console.log('DOM rendered length:', domRendered.length);
console.log('Text match:', textFromHtml === textFromDom);
if (textFromHtml !== textFromDom) {
console.log('Content differs - investigate further');
}
}
compareHtmlDom('https://example.com/page');Lo script e un punto di partenza. In un audit reale, lo estendo per confrontare anche i link interni (<a href>), i meta tag, i dati strutturati e gli heading, producendo un report CSV per ogni URL analizzato.
Metodologia di confronto HTML vs DOM renderizzato
Il processo che seguo per un audit sistematico:
- Identificare le pagine target: pagine con traffico in calo, pagine non indicizzate, pagine con contenuto JavaScript-dependent. I dati di Google Search Console e il report “Pagine” sono il punto di partenza.
- Scansione dual-mode con Screaming Frog: una scansione “Text Only” e una “JavaScript Rendering” sulle stesse URL. Esportare entrambi i dataset ed eseguire un confronto colonna per colonna su: title, meta description, H1, H2, word count, link interni trovati.
- Analisi differenze critiche: qualsiasi contenuto presente nel DOM ma assente nell’HTML source e un potenziale problema. Prioritizzare: meta tag (
canonical,hreflangmanipolati via JS sono ad altissimo rischio), link interni non scoperti, contenuto principale assente. - Verifica rendering Googlebot: usare lo strumento “Controllo URL” in Google Search Console per vedere lo screenshot e l’HTML renderizzato da Googlebot. Confrontare con il DOM locale.
- Test con risorse bloccate: verificare che il
robots.txtnon blocchi file CSS o JS necessari per il rendering. Lo strumento “Controllo URL” di GSC segnala le risorse bloccate.
Checklist per siti JavaScript-heavy
Una checklist operativa per la valutazione di siti che dipendono pesantemente da JavaScript per il rendering dei contenuti:
- Il
<title>e presente nell’HTML source o viene impostato via JS? - Il tag
canonicale nell’HTML source? - I tag
hreflangsono nell’HTML source? - Il contenuto testuale principale (H1, paragrafi) e nell’HTML source?
- I link interni di navigazione sono nell’HTML source?
- I dati strutturati (JSON-LD) sono nell’HTML source?
- Le immagini critiche hanno attributo
srcnell’HTML source (non lazy-loaded con placeholder)? - Il
robots.txtpermette l’accesso a tutti i file JS e CSS necessari? - Il rendering JavaScript si completa entro 5 secondi su una connessione standard?
- Il DOM renderizzato ha meno di 1.500 nodi (raccomandazione Lighthouse)?
- Lo strumento “Controllo URL” di GSC mostra lo screenshot corretto della pagina?
Se la risposta a una di queste domande e “no” o “non so”, quell’area richiede un’indagine approfondita prima di considerare chiuso l’audit.
Problemi frequenti e soluzioni
Dai progetti su cui ho lavorato, questi sono i problemi ricorrenti legati alla divergenza tra HTML e DOM, con le soluzioni che ho implementato.
Contenuto critico generato solo via JS
Problema: il contenuto principale della pagina (testi, heading, descrizioni prodotto) non e nell’HTML source. Il server invia uno scheletro HTML con un <div id="root"></div> vuoto e un bundle JavaScript da diversi MB.
Rischio: indicizzazione ritardata o incompleta. Se il WRS fallisce il rendering per timeout o errore JavaScript, la pagina viene indicizzata con il contenuto dell’HTML source — cioe sostanzialmente vuota.
Soluzione: implementare SSR o SSG per le pagine che devono essere indicizzate. Con Next.js, basta usare getServerSideProps o generateStaticParams. Con Nuxt, la configurazione di default e gia SSR. Per applicazioni legacy in Angular o React CSR puro, valutare l’implementazione di un layer di pre-rendering con strumenti come Prerender.io o rendertron.
Meta tag iniettati lato client
Problema: tag canonical, hreflang, meta robots o title vengono impostati o modificati da JavaScript dopo il caricamento della pagina. Nell’HTML source il tag e assente o ha un valore di default sbagliato.
Rischio: nella prima ondata di indicizzazione, Googlebot legge il valore dall’HTML source. Se il canonical nell’HTML punta a un URL diverso da quello corretto (impostato poi via JS), si creano problemi di cannibalizzazione o de-indicizzazione.
Soluzione: i meta tag SEO-critical devono essere generati server-side, senza eccezioni. In Next.js usare il componente Head o la Metadata API dell’App Router. In Nuxt usare useSeoMeta() o useHead(). Verificare sempre con curl -s URL | grep canonical che il tag sia nell’HTML source.
Lazy loading e contenuto below-the-fold non renderizzato
Problema: sistemi di lazy loading aggressivo che nascondono contenuto below-the-fold fino allo scroll dell’utente. Il contenuto testuale, i link o le immagini non vengono inseriti nel DOM fino all’interazione, che il WRS non esegue.
Rischio: il contenuto below-the-fold non viene indicizzato. I link interni in quelle sezioni non vengono scoperti. Le immagini senza src nell’HTML source non vengono indicizzate in Google Images.
Soluzione: usare il lazy loading nativo del browser (loading="lazy" sulle immagini) che e supportato dal WRS e non richiede JavaScript. Per il contenuto testuale, evitare il lazy loading: il testo deve essere nel DOM al momento del rendering iniziale. Se si usa intersection observer per caricare sezioni di contenuto, assicurarsi che il contenuto sia comunque presente nel DOM (nascosto con CSS se necessario), non aggiunto dinamicamente.
La comprensione della relazione tra HTML source e DOM e una competenza tecnica che distingue un audit superficiale da un’analisi approfondita. In un ecosistema web dove JavaScript e onnipresente, saper identificare cosa vede il server, cosa vede il browser e cosa vede Googlebot e la base per qualsiasi decisione SEO informata su architettura, crawl budget e strategia di indicizzazione.
Articoli correlati
Autore
Mi chiamo Giovanni Sacheli e dal 2009 aiuto le aziende a farsi trovare online. Sono specializzato in SEO tecnica e PPC, competenze che applico quotidianamente nella mia agenzia, Searcus Swiss Sagl. Mi piace sviluppare strumenti a supporto del mio lavoro, ho creato SEOdata.app e cluster.army e co-scritto il libro SEO Audit Avanzato. Curo maniacalmente questo blog per colleghi e appassionati, dove mi "appunto" quello che imparo. Sono un NERD anni '80, motociclista e orgoglioso papà di due bambini.
Link:
Giovanni Sacheli
SEO Audit Avanzato
Searcus Swiss Sagl
SEOdata.app
cluster.army