SEO on-page: cosa ottimizzare in una pagina, con esempi

La SEO on-page è tutto ciò che si ottimizza dentro la pagina e nel suo codice per far capire a Google di cosa parla e per convincere chi la vede in SERP a cliccarla: title, meta description, heading, URL, contenuto, link interni, immagini e dati strutturati. È la parte della SEO che uno sviluppatore controlla al cento per cento, perché vive nel template, nel CMS o nel framework.

Questa guida va elemento per elemento: cosa conta davvero, dove si mette mano (HTML, WordPress con Yoast, framework come Next.js) e quali errori si vedono più spesso. In fondo c’è una checklist da usare prima di pubblicare.

Indice

• Cos’è la SEO on-page e come si distingue dalla off-page
• Title tag
• Meta description
• Heading e struttura della pagina
• URL e slug
• Contenuto e intento di ricerca
• Link interni
• Immagini e testo alternativo
• Dati strutturati
• Checklist prima di pubblicare

---

Cos’è la SEO on-page e come si distingue dalla off-page

Ottimizzare una pagina significa renderla la risposta più chiara possibile a una ricerca precisa, sia per chi legge sia per i sistemi che la scansionano e la indicizzano. In pratica si lavora su due fronti: i segnali che Google legge nel codice (title, heading, link, markup) e quello che l’utente vede prima di entrare (il risultato in SERP) e dopo (il contenuto).

La distinzione con la SEO off-page è semplice: on-page è ciò che sta sul tuo sito e che puoi modificare con un deploy; off-page è ciò che succede fuori, soprattutto i link da altri siti (backlink), le menzioni del brand e, per le attività locali, le recensioni. Un backlink, tecnicamente, è solo un <a href> su un dominio che non controlli. Le due parti non sono alternative: una pagina con molti link ma confusa nei contenuti fatica, e una pagina perfetta che nessuno cita fatica su query competitive. Poi c’è la SEO tecnica (scansione, indicizzazione, velocità), che spesso si sovrappone all’on-page; se il problema è che le pagine non entrano nell’indice, parti da questa guida sui post non indicizzati.

Title tag

Il <title> nel <head> è la fonte principale del titolo cliccabile in SERP e il testo della scheda del browser. Google però non lo usa sempre così com’è: per generare il title link può attingere anche all’<h1>, a og:title, al testo dei link che puntano alla pagina. Lo riscrive quando il title è vuoto, identico su molte pagine, pieno di keyword ripetute o non corrisponde al contenuto. Il modo più affidabile per farlo rispettare è scriverne uno che descriva davvero la pagina.

Regole che contano

• Unico per pagina. I title generati da template (“Articolo | Sito”, “Prodotto | Sito”) sono il caso classico che Google riscrive.
• Il concetto principale verso l’inizio. Non per un “peso” magico, ma perché è la parte che resta visibile se il titolo viene troncato e quella che l’utente legge per prima.
• Lunghezza: conta la larghezza, non i caratteri. Google non fissa un limite; taglia il titolo in base allo spazio disponibile sul dispositivo. Una “M” occupa più pixel di una “i”, quindi i 50-60 caratteri sono solo un’indicazione di massima. L’anteprima dello snippet di Yoast misura la larghezza in pixel ed è più affidabile del conteggio.
• Brand alla fine, breve. Un separatore e il nome del sito bastano.
• Niente anno se il contenuto non è legato a una data. “(2024)” nel title di una guida evergreen invecchia la pagina dal primo gennaio successivo e ti obbliga a ritoccarla ogni anno. Ha senso solo per contenuti davvero datati: un report annuale, le novità di una release, una classifica dell’anno.

Esempi: prima e dopo

Articolo tecnico. Troppo generico il primo, il secondo dice argomento e cosa si trova nella pagina:

<!-- da evitare -->
<title>Guida SEO</title>

<!-- meglio -->
<title>SEO on-page: title, heading e link interni spiegati | NomeSito</title>

Pagina prodotto. Il nome della categoria da solo non distingue la pagina da altre mille; marca, modello e un dettaglio utile all’acquisto sì:

<!-- da evitare -->
<title>Scarpa da corsa</title>

<!-- meglio -->
<title>Nike Pegasus 40 uomo, scarpa da corsa su strada | NomeShop</title>

Servizio locale. Chi cerca un servizio sul territorio cerca quasi sempre anche la città:

<!-- da evitare -->
<title>Servizio idraulico</title>

<!-- meglio -->
<title>Idraulico a Milano, pronto intervento 24 ore | NomeDitta</title>

Dove si imposta

In WordPress il tema deve dichiarare add_theme_support( 'title-tag' ) e lasciare che sia il core (o Yoast) a stampare il tag; un <title> scritto a mano in header.php crea duplicati. In Yoast il modello di default si definisce per tipo di contenuto con le variabili %%title%% %%sep%% %%sitename%% e si sovrascrive nel singolo post. In Next.js (App Router) si usa l’API dei metadati:

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const { slug } = await params; // in Next.js 15+ params è una Promise
  const post = await getPost(slug);
  return {
    title: `${post.title} | NomeSito`,
    description: post.excerpt,
  };
}

Meta description

La meta description non è un fattore di ranking: serve a far scegliere il tuo risultato. Va detto subito anche il secondo limite: Google costruisce lo snippet soprattutto dal testo della pagina, scegliendo il passaggio più vicino alla query, e usa la description solo quando la ritiene una sintesi migliore. La stessa pagina può quindi mostrare snippet diversi per ricerche diverse. Scriverla resta utile, perché per la query principale è spesso quella che compare.

<head>
  <meta name="description" content="Cosa ottimizzare in una pagina: title, meta description, heading, URL, link interni e dati strutturati, con esempi in HTML e WordPress.">
</head>

Come scriverla

• Riassumi la pagina, non pubblicizzarla. Dì cosa trova chi clicca: argomento, formato (guida, esempi, codice), eventuali dettagli concreti come prezzo, versione o autore.
• Usa le parole della ricerca in modo naturale. Google evidenzia in grassetto i termini che corrispondono alla query; un elenco di keyword invece è un motivo per scartare la description.
• Una per pagina. Description identiche su tutto il sito non danno informazioni e vengono ignorate. Su siti grandi generati da database è accettabile costruirle con un template, purché il risultato sia leggibile e diverso da pagina a pagina.
• Le informazioni importanti all’inizio. Non c’è un limite ufficiale di lunghezza: lo snippet viene tagliato in base alla larghezza del dispositivo, più stretta su mobile. Intorno ai 120-155 caratteri il messaggio arriva quasi sempre intero.

Un confronto rapido. Debole: “In questo articolo si parla di meta description.” Non dice nulla che il title non dica già. Meglio: “Come scrivere una meta description: cosa mettere, quanto deve essere lunga e perché Google a volte la sostituisce con il testo della pagina.” Promette tre risposte precise, senza “raddoppia il tuo CTR” o punti esclamativi.

Se una parte della pagina non deve mai finire nello snippet (un disclaimer, un banner), si può marcare con l’attributo data-nosnippet; per limitare la lunghezza dello snippet esiste la direttiva max-snippet nel meta robots.

Heading e struttura della pagina

Gli heading descrivono la gerarchia del contenuto: un <h1> con l’argomento della pagina, <h2> per le sezioni, <h3> per i sotto-punti. Google dichiara che non penalizza heading fuori ordine e che non esiste un numero ideale; la gerarchia corretta serve soprattutto a chi usa uno screen reader, che naviga la pagina saltando da un titolo all’altro, e a chi legge di corsa.

• Un solo <h1> visibile, coerente con il title (non deve essere identico).
• Non saltare livelli per motivi grafici: se un <h4> serve solo perché “è più piccolo”, la dimensione va gestita in CSS.
• Controlla il template: molti temi usano heading per il logo, i widget della sidebar o il footer, e la pagina finisce con tre <h1> o con decine di <h2> che non c’entrano con il contenuto.

La struttura degli heading fa parte di un discorso più ampio sul markup: <main>, <article>, <nav> e compagnia sono trattati nella guida all’HTML semantico.

URL e slug

Un URL leggibile aiuta l’utente a capire dove sta andando e Google può mostrarne le parti come breadcrumb nel risultato. Lo slug ideale è corto, in minuscolo, con trattini e senza parole vuote:

• Bene: /seo-on-page/, /blog/react-hook-form/
• Male: /index.php?p=123, /2025/12/03/ecco-tutto-quello-che-devi-sapere-su-come-funziona-la-seo/

Il punto più importante per uno sviluppatore è un altro: cambiare un URL ha un costo. Ogni modifica a slug o struttura dei permalink richiede un redirect 301 dal vecchio indirizzo al nuovo, senza catene, e l’aggiornamento dei link interni. Lo stesso Google consiglia di non riorganizzare un sito solo per avere URL più belli. In WordPress la struttura si decide una volta in Impostazioni → Permalink (/%postname%/ è la scelta più semplice) e si evita di includere la data se i contenuti sono evergreen.

Contenuto e intento di ricerca

Tutto il resto serve a poco se la pagina non risponde alla domanda per cui viene trovata. Prima di scrivere, guarda cosa mostra Google per la query: se i primi risultati sono tutorial con codice, un articolo teorico difficilmente si posizionerà; se sono definizioni brevi, una guida da cinquemila parole probabilmente è fuori bersaglio.

• Rispondi subito. Le prime righe devono contenere la risposta; il resto la approfondisce.
• Una pagina, un argomento. Più pagine sottili sulla stessa query si fanno concorrenza; meglio una sola completa.
• Mostra esperienza reale. Codice che hai eseguito, errori incontrati, versioni testate: è ciò che Google descrive con l’acronimo E-E-A-T, approfondito in questa guida alla SEO su Google.
• Il testo deve essere nell’HTML. Contenuti caricati solo lato client dopo un’interazione, o nascosti dentro tab che non vengono renderizzati, rischiano di non essere visti. Con i framework JavaScript conviene il rendering lato server o la generazione statica per le pagine che devono posizionarsi.

Link interni

I link interni sono il modo in cui Google scopre le pagine e capisce quali sono collegate tra loro; per l’utente sono il percorso naturale verso l’approfondimento. Tre regole pratiche:

• Anchor text descrittivo. “Guida all’HTML semantico” dice cosa c’è dall’altra parte; “clicca qui” no.
• Link veri. Un elemento <a> con un href che punta a un URL reale. Un <span onclick> o un href vuoto non vengono seguiti.
• Nessuna pagina orfana. Ogni contenuto importante deve essere raggiungibile da almeno un’altra pagina, non solo dalla sitemap. Dopo una fusione o un cambio di slug, aggiorna i link che puntano al vecchio indirizzo invece di affidarti al redirect.

Per i link verso siti esterni di cui non ti fidi, o per quelli inseriti dagli utenti nei commenti, si usano gli attributi rel="nofollow" o rel="ugc".

Immagini e testo alternativo

Le immagini pesano su due fronti: comprensione (testo alternativo, nome file, testo intorno) e prestazioni (peso e stabilità del layout).

<img src="/img/seo-on-page-checklist.webp"
     alt="Checklist degli elementi on-page: title, description, heading, URL e link"
     width="800" height="450"
     loading="lazy">

• alt breve e descrittivo, che spieghi cosa mostra l’immagine nel contesto della pagina. Non è il posto per un elenco di keyword: lo legge ad alta voce lo screen reader. Per le immagini puramente decorative si usa alt="".
• Nome file leggibile (seo-on-page-checklist.webp, non IMG_1234.jpg).
• width e height sempre indicati, per riservare lo spazio ed evitare spostamenti del layout (CLS).
• loading=”lazy” solo sotto la piega: sull’immagine principale in alto rallenta il caricamento percepito (LCP). Formati moderni come WebP o AVIF riducono il peso.

Gli aspetti di performance di HTML e CSS legati ai Core Web Vitals sono trattati nell’articolo su HTML, CSS e performance.

Dati strutturati

I dati strutturati descrivono la pagina in un formato standard (schema.org) e rendono la pagina idonea ad alcuni risultati arricchiti: breadcrumb, recensioni, prodotti, eventi. Google raccomanda il formato JSON-LD, che sta in un tag <script> separato dal markup visibile:

<script type="application/ld+json">
{
  "@context": "https://schema.org",
  "@type": "Article",
  "headline": "SEO on-page: cosa ottimizzare in una pagina",
  "author": { "@type": "Person", "name": "Fabio Gulotta" },
  "datePublished": "2025-12-03",
  "dateModified": "2026-10-15"
}
</script>

Due avvertenze. I dati strutturati non fanno salire di posizione una pagina e non garantiscono il risultato arricchito; devono descrivere contenuti realmente visibili nella pagina. E se usi Yoast, il plugin genera già un grafo con Article, WebPage e BreadcrumbList: aggiungere a mano un secondo blocco Article crea duplicati. Prima di pubblicare, verifica con il Rich Results Test di Google.

Checklist prima di pubblicare

1. Il title è unico, descrive la pagina, ha il concetto principale all’inizio e non contiene l’anno se il contenuto è evergreen. Nell’anteprima di Yoast non viene troncato.
2. La meta description riassume la pagina in una o due frasi, è unica e non è un elenco di keyword.
3. C’è un solo <h1>, e gli <h2>/<h3> seguono le sezioni del contenuto. Controllato anche il markup del tema, non solo l’editor.
4. Lo slug è corto e leggibile. Se è cambiato, c’è il redirect 301 dal vecchio URL e i link interni sono aggiornati.
5. Le prime righe rispondono alla domanda; il contenuto è nell’HTML servito, non solo caricato via JavaScript.
6. La pagina riceve almeno un link interno da un contenuto correlato e ne contiene verso pagine utili, con anchor descrittivi.
7. Ogni immagine ha alt, width e height; quella principale non è in lazy loading.
8. I dati strutturati passano il Rich Results Test e non sono duplicati.
9. Dopo qualche settimana, in Search Console controlla le query per cui la pagina compare: se sono diverse da quelle previste, è il title (o il contenuto) da rivedere.

Per un controllo più esteso sul markup, dal lang del documento ai canonical, c’è la checklist SEO per l’HTML.

Fonti

• Google Search Central: influenzare i title link nei risultati di ricerca
• Google Search Central: controllare gli snippet e scrivere meta description
• Google Search Central: SEO Starter Guide
• Google Search Central: introduzione ai dati strutturati