Parti dal verificare che cosa riceve un crawler con curl: se l'HTML è vuoto, nessun meta tag aggiunto lato client servirà a qualcosa. Il prerendering o il rendering lato server è la vera risposta. Solo dopo, gestisci titoli, descrizioni e dati strutturati con unhead, che sostituisce vue-meta.
Un’applicazione Vue costruisce la sua pagina nel browser. L’HTML servito dal server è quasi vuoto, e tutto dipende poi dall’esecuzione del JavaScript. Per Google può funzionare, molto meno per gli altri crawler, a cominciare da quelli degli assistenti conversazionali. Ecco come affrontare il problema nell’ordine giusto.
Il vero problema non sono i meta tag
La prima domanda da farsi non è «come cambio il titolo» ma «che cosa riceve il crawler». Verificalo senza browser:
curl -s https://mon-site.com/ma-page | head -40Se la risposta è un <div id="app"></div> vuoto, nessun meta tag aggiunto lato client cambierà qualcosa per un crawler che non esegue JavaScript. Il rendering deve allora avvenire prima dell’invio. È l’argomento dell’ultima sezione, di gran lunga il più importante.
Gli esempi presuppongono un progetto creato con create-vue e Vite. Le sezioni che seguono partono dai metadati, perché sono utili in ogni caso, anche con il rendering lato server.
I metadati con unhead
Ogni pagina deve avere il proprio titolo e la propria descrizione. unhead si installa come qualsiasi plugin Vue. In una single page application devono cambiare a ogni navigazione.
vue-meta era la risposta ai tempi di Vue 2 e la maggior parte degli articoli online la cita ancora. La sua versione per Vue 3 non è mai stata stabilizzata. La libreria usata oggi, anche da Nuxt, è unhead.
npm install @unhead/vueimport { createApp } from 'vue'
import { createHead } from '@unhead/vue/client'
import App from './App.vue'
const app = createApp(App)
app.use(createHead())
app.mount('#app')In un componente, useHead e useSeoMeta scrivono nel <head>:
<script setup>
import { useHead, useSeoMeta } from '@unhead/vue'
useHead({
title: 'T-Shirt Gekkode',
titleTemplate: '%s — Boutique Gekkode',
link: [{ rel: 'canonical', href: 'https://mon-site.com/t-shirt' }]
})
useSeoMeta({
description: 'Un T-shirt en coton, laine et polyester.',
ogTitle: 'T-Shirt Gekkode',
ogDescription: 'Un T-shirt en coton, laine et polyester.',
ogImage: 'https://mon-site.com/images/t-shirt.png',
ogUrl: 'https://mon-site.com/t-shirt',
twitterCard: 'summary_large_image'
})
</script>I composable arrivano da @unhead/vue, ma createHead arriva da @unhead/vue/client, o da @unhead/vue/server in rendering lato server. Importare tutto dallo stesso percorso dà l’errore createHead is not a function.
useSeoMeta evita di scrivere a mano gli array di tag: ogni chiave corrisponde a un tag noto, e gli errori di battitura saltano fuori con l’autocompletamento.
I valori possono essere reattivi: passa una ref o una computed, e il tag segue il caricamento dei dati.
const produit = ref(null)
useHead({
title: computed(() => produit.value?.nom ?? 'Chargement…')
})Il link canonico
La stessa scheda raggiungibile da più URL, con o senza parametri di tracciamento, diluisce il segnale. Dichiara l’indirizzo di riferimento:
useHead({
link: [{ rel: 'canonical', href: `https://mon-site.com${route.path}` }]
})Costruiscilo a partire dal path della route, mai da window.location.href, che si porterebbe dietro i parametri di campagna.
La sitemap
Un file sitemap.xml elenca gli URL che consideri importanti. Su una single page application non può essere scoperto tramite crawling: va generato.
Generalo dalla stessa sorgente delle tue route, al momento della build, invece che a mano:
import { writeFileSync } from 'node:fs'
import { routes } from '../src/router/routes.js'
const base = 'https://mon-site.com'
const urls = routes
.filter((r) => !r.meta?.noindex && !r.path.includes(':'))
.map((r) => ` <url><loc>${base}${r.path}</loc></url>`)
.join('\n')
writeFileSync(
'public/sitemap.xml',
`<?xml version="1.0" encoding="UTF-8"?>
<urlset xmlns="http://www.sitemaps.org/schemas/sitemap/0.9">
${urls}
</urlset>`
)Le route con parametro sono escluse: i loro URL reali devono venire dai tuoi dati, non dalla definizione delle route. Dichiara poi il file in robots.txt:
User-agent: *
Allow: /
Sitemap: https://mon-site.com/sitemap.xmlI dati strutturati
Un blocco JSON-LD descrive in modo esplicito che cosa contiene la pagina. È quello che alimenta i risultati avanzati, e si legge molto più facilmente di un testo da interpretare.
useHead({
script: [{
type: 'application/ld+json',
innerHTML: JSON.stringify({
'@context': 'https://schema.org',
'@type': 'Product',
name: 'T-Shirt Gekkode',
offers: {
'@type': 'Offer',
price: '25.00',
priceCurrency: 'EUR',
availability: 'https://schema.org/InStock'
}
})
}]
})Verifica il risultato con il test dei risultati avanzati di Google, sull’URL online e non sul codice sorgente.
Le prestazioni
I Core Web Vitals pesano sul posizionamento. Tre leve danno la gran parte del guadagno su un’applicazione Vue.
Dividere il bundle per route. Basta un import dinamico nella definizione delle route: Vite produce un file separato, caricato su richiesta.
const routes = [
{ path: '/', component: () => import('../views/AccueilView.vue') },
{ path: '/produit/:id', component: () => import('../views/ProduitView.vue') }
]Dimensionare le immagini. Un width e un height espliciti evitano lo spostamento del layout che peggiora il CLS. Il formato AVIF o WebP riduce molto il peso.
Misurare prima di ottimizzare. Lancia Lighthouse sul sito compilato, non sul server di sviluppo: i numeri non hanno niente a che vedere tra loro.
npm run build
npm run preview
npx lighthouse http://localhost:4173 --viewIl rendering lato server (SSR), la vera risposta
Tutto quello che precede migliora un’applicazione già indicizzabile. Se il tuo HTML iniziale è vuoto, è qui che si gioca la partita.
Tre opzioni, in ordine di impegno crescente.
Il prerendering genera un file HTML completo per ogni route al momento della build. È la soluzione più semplice, e basta appena il contenuto non dipende dal visitatore: pagine di presentazione, documentazione, blog. Un plugin come vite-plugin-prerender si aggiunge alla configurazione esistente, senza toccare il codice dell’applicazione.
La generazione di sito statico spinge la stessa idea più avanti, con la gestione dei dati e del routing. Nuxt in modalità nuxt generate copre questa esigenza.
Il rendering lato server, o SSR per server-side rendering, costruisce la pagina a ogni richiesta. Serve quando il contenuto dipende dal visitatore o cambia di continuo. Impone un server Node e attenzione al codice che dà per scontata l’esistenza di window o document. Nuxt resta la strada più corta, un SSR montato a mano è un progetto a sé.
Se il contenuto è lo stesso per tutti, fai prerendering: ottieni il risultato migliore con il minimo sforzo. Il rendering lato server si giustifica solo se la pagina dipende davvero da chi la chiede.
Il posizionamento nelle risposte degli assistenti
I crawler degli assistenti conversazionali di solito non eseguono JavaScript. Un’applicazione renderizzata interamente lato client per loro è invisibile, qualunque siano i suoi meta tag.
Quello che conta per loro coincide con le buone pratiche classiche: HTML servito così com’è, una struttura di titoli che segue il discorso, dati strutturati, una risposta chiara in cima alla pagina invece che dopo tre paragrafi di introduzione.
L’ordine delle priorità
- Servire HTML completo, con prerendering o rendering lato server. Senza questo, il resto non serve a niente.
- Un titolo e una descrizione propri di ogni pagina, con unhead.
- Un link canonico sulle pagine raggiungibili da più URL.
- Una sitemap generata e dichiarata in
robots.txt. - I dati strutturati sulle pagine che descrivono un’entità identificabile.
- Le prestazioni, misurate sul sito compilato.
Se stai scoprendo Vue adesso, il tutorial Vue 3 per principianti pone le basi necessarie prima di affrontare il routing e il rendering lato server.
Errori frequenti
@unhead/vue, createHead da @unhead/vue/client. Importare tutto dallo stesso percorso dà « useHead is not a function ».curl.npm run build.
