Il noindex è una regola che chiede ai motori di non mostrare una pagina nei risultati. Non ferma la scansione: Googlebot continua a passare, legge la direttiva, e poi non pubblica. Si scrive in due modi, un meta tag nell’<head> oppure l’intestazione HTTP X-Robots-Tag, e l’effetto è lo stesso.
Non è un interruttore, è una direttiva condizionata. Funziona a tre condizioni: il crawler deve poterla leggere, quindi la pagina non dev’essere bloccata dal file robots.txt; deve stare nell’HTML che il server consegna, non aggiunta dopo via JavaScript; e Google deve ripassare. Se ne salta una, la pagina resta dov’è.
Dove si scrive, come si mette su un PDF o su un’immagine, quali noindex ce li ha messi WordPress da solo, come si verifica che sulla pagina ci sia davvero e quanto ci mette Google a togliere l’URL dai risultati: sono le domande a cui rispondo qui.
Cos’è il noindex
Il noindex è una regola che si scrive in due soli modi, un meta tag nell’<head> o un’intestazione HTTP, e impedisce l’indicizzazione della pagina ai motori che la supportano.
La definizione di Google: «noindex è una serie di regole con un <meta> tag o un’intestazione della risposta HTTP, utilizzata per impedire l’indicizzazione dei contenuti da parte dei motori di ricerca che supportano la regola noindex, come Google». Nella stessa pagina si legge che i due metodi hanno effetto identico: scegli in base a cosa stai marcando, non a quanto vuoi che il segnale sia forte.
Vale per i motori che la supportano, quindi resta una richiesta: Google la rispetta, Bing pure, lo scraper scritto da qualcuno in un pomeriggio fa quello che gli pare. E deve essere leggibile: è il punto che si paga più caro.
Il meta tag robots non è roba di ieri. Nel ripasso di Google sui robots, firmato John Mueller il 14 marzo 2025: «la community coinvolta nello sviluppo degli standard web ha creato i meta tag robots nel 1996, solo pochi mesi dopo la proposta dei meta tag per HTML (e anche prima della fondazione di Google)».
Le tre condizioni perché il noindex funzioni
Il noindex funziona se la pagina è scansionabile, se la direttiva sta nell’HTML iniziale, e solo dopo che Google è ripassato. Tre condizioni, tutte necessarie.
La pagina deve essere raggiungibile dal crawler. Google lo scrive senza margini: «affinché la regola noindex sia efficace, la pagina o la risorsa non deve essere bloccata da un file robots.txt e deve essere altrimenti accessibile al crawler». Un noindex dietro un Disallow è un biglietto lasciato in una stanza di cui hai murato la porta: calligrafia impeccabile, non lo legge nessuno.
La direttiva deve stare nell’HTML che il server consegna. La trappola sta in una riga della documentazione sul JavaScript e la SEO: «quando Google rileva il tag noindex, potrebbe saltare il rendering e l’esecuzione di JavaScript, il che significa che l’utilizzo di JavaScript per modificare o rimuovere il meta tag robots da noindex potrebbe non funzionare come previsto». Il consiglio è secco: «se vuoi che la pagina venga indicizzata, non includere un tag noindex nel codice della pagina originale». Su una SPA o con un plugin SEO lato client il rischio è concreto: se il template parte con un noindex e conta su uno script per toglierlo, hai una pagina che può non indicizzarsi mai, e il bug resta invisibile finché non apri il sorgente.
Serve una nuova scansione. Il noindex non agisce a ritroso: la pagina esce quando Google ci ritorna sopra, «a seconda dell’importanza della pagina su internet, Googlebot potrebbe impiegare mesi per visitarla di nuovo». Quel «a seconda dell’importanza» fa parte dell’affermazione: chi lo taglia via promette un tempo che Google non ha mai promesso.
La sintassi del meta tag noindex
Questa è la riga, e va nell’<head>.
<head>
<meta charset="utf-8">
<meta name="robots" content="noindex">
<title>Pagina che non deve stare in SERP</title>
</head>Virgolette dritte, mai quelle curve. È il modo più stupido di rompere uno snippet copiato da un blog: l’editor trasforma " in ”, il parser legge una cosa che non gli torna, e tu apri il sorgente, vedi il tuo tag al suo posto e giuri che il problema è di Google. Nel sorgente c’è il disegno del tag, non il tag.
Con name="robots" parli a tutti i crawler che leggono il meta tag; per parlare solo a Google sostituisci il valore, <meta name="googlebot" content="noindex">, e il resto continua a indicizzare. Né name né content distinguono maiuscole e minuscole.
Le direttive supportate sono più di quelle che si vedono in giro, e stanno nell’elenco delle regole robots:
| Direttiva | Cosa chiede |
|---|---|
all | Nessun limite: è il comportamento predefinito |
noindex | Non mostrare la pagina nei risultati |
nofollow | Non seguire i link presenti nella pagina |
none | «Equivalente a noindex, nofollow» |
nosnippet | Niente snippet di testo né anteprima video nei risultati; la miniatura statica di un’immagine può restare visibile |
max-snippet:[number] | Al massimo N caratteri di snippet testuale |
max-image-preview:[setting] | Dimensione massima dell’anteprima immagine: none, standard o large |
max-video-preview:[number] | Al massimo N secondi di anteprima video |
notranslate | Non proporre la traduzione della pagina nei risultati |
noimageindex | Non indicizzare le immagini della pagina |
unavailable_after:[date/time] | Non mostrare la pagina nei risultati dopo la data indicata |
indexifembedded | Consente l’indicizzazione del contenuto incorporato in un’altra pagina tramite iframe o tag simili, nonostante il noindex; ha effetto solo se accompagnata da noindex |
data-nosnippet | Attributo HTML, non direttiva del meta tag: esclude dallo snippet una porzione di testo dentro span, div o section |
Sulla data di unavailable_after non c’è un formato unico: «la data e l’ora devono essere specificate in un formato ampiamente adottato inclusi, a titolo esemplificativo, RFC 822, RFC 850 e ISO 8601». L’esempio della documentazione è <meta name="robots" content="unavailable_after: 2020-09-21">.
Due nomi che continuano a circolare stanno invece nell’elenco sotto, il «riferimento alle regole storiche e ad altre regole inutilizzate». noarchive «non viene più utilizzata dalla Ricerca Google per controllare se un link Copia cache viene mostrato nei risultati di ricerca, poiché questa funzionalità non esiste più»; nocache «non viene utilizzata dalla Ricerca Google». Tienile a mente: su Bing, come vedrai in fondo, comandano parecchio.
Le direttive si combinano nello stesso content, separate da virgola: content="noindex, nofollow". E se due si contraddicono, la regola è deterministica: «in caso di regole robots in conflitto, viene applicata quella più restrittiva. Ad esempio, se una pagina ha sia la regola max-snippet:50 che nosnippet, verrà applicata la regola nosnippet».
noindex e nofollow: due direttive, due problemi diversi
Sono due direttive diverse per due problemi diversi: noindex tocca l’indice, nofollow i link della pagina. Metterle insieme è legittimo, ma non rafforza il noindex di un grammo.
La distinzione che genera metà della confusione: il nofollow dentro il meta robots vale per tutti i link della pagina, l’attributo rel="nofollow" sul singolo <a> vale per quel link e basta. E none è noindex, nofollow scritto in cinque caratteri.
La domanda vera è un’altra: noindex, follow o noindex, nofollow? La differenza pratica sta nella scoperta di URL. Con il primo la pagina esce dall’indice e i suoi link restano una strada per arrivare altrove; con il secondo chiudi anche quella, e se quelle URL non sono linkate altrove Google può non trovarle più.
Gira da anni la tesi che a lungo andare i due comportamenti coincidano. Non sta nella documentazione di Google: viene da una dichiarazione di John Mueller in un hangout del dicembre 2017. Le parole esatte sono «so in noindex and follow is essentially kind of the same as a noindex, nofollow», e subito dopo, frase a sé, «there’s no really big difference there in the long run». Quel «kind of» pesa, ed è la prima cosa che sparisce quando la citazione viene rilanciata. Sui tempi, Mueller rispose che dipende.
X-Robots-Tag: il noindex per PDF, immagini e file
Un PDF non ha un <head>, quindi la direttiva viaggia nell’intestazione della risposta HTTP. Stesso effetto del meta tag, su qualsiasi risorsa il server pubblichi.
Nel ripasso del marzo 2025: «l’intestazione supporta gli stessi valori del meta tag robots e può essere aggiunta a qualsiasi contenuto pubblicato online. Oltre all’HTML, Google la supporta per contenuti come PDF, file di documenti e persino immagini».
L’header è X-Robots-Tag: noindex. Su Apache, per tutti i PDF del sito, nel .htaccess o nel virtual host:
<Files ~ "\.pdf$">
Header set X-Robots-Tag "noindex, nofollow"
</Files>Su nginx, dentro il blocco server:
location ~* \.pdf$ {
add_header X-Robots-Tag "noindex, nofollow";
}L’header sa parlare anche a un crawler alla volta, con la sintassi nome-bot: regole:
X-Robots-Tag: googlebot: nofollow
X-Robots-Tag: otherbot: noindex, nofollowE sa scadere da solo, comodo su una landing di campagna:
X-Robots-Tag: unavailable_after: 2026-12-31Sulle intestazioni multiple: «è possibile combinare più intestazioni X-Robots-Tag all’interno della risposta HTTP. In alternativa, puoi specificare un elenco di regole separate da virgole». Due righe o una riga con la virgola, pari sono.
Poi si verifica, altrimenti è solo sperata:
curl -sI https://esempio.it/listino.pdf | grep -i x-robots-tagSe non esce niente l’header non c’è, e su un PDF non esiste un secondo posto dove guardare.
noindex o robots.txt? Non insieme
Non si usano insieme: il Disallow impedisce a Google di leggere il noindex, e l’URL può restare in indice senza descrizione, alimentato dai link degli altri.
Sulla stessa pagina delle regole robots: «se una pagina viene esclusa dalla scansione tramite il file robots.txt, le informazioni relative alle regole di indicizzazione e pubblicazione non vengono rilevate e, pertanto, vengono ignorate».
La sequenza corretta è controintuitiva:
- Togli il blocco dal robots.txt, così il crawler può entrare.
- Lascia entrare Google finché legge il noindex e la pagina sparisce dai risultati. Il momento lo verifichi in Search Console, non a sensazione.
- Rimetti il Disallow solo se ti serve risparmiare scansione, sapendo che da lì in poi la URL può rientrare in indice senza descrizione.
Il passaggio 3 quasi mai serve: una pagina in noindex scansionata due volte al mese non ti sta bruciando niente.
La riga Noindex: dentro il robots.txt, invece, non è mai stata una direttiva supportata ed è dismessa dal 1º settembre 2019. Delle cinque guide italiane che ho aperto su questo termine, lo dice solo SEOZoom. Se trovi quella riga in un file, è codice morto.
Quando serve il noindex e quando no
Serve quando la pagina è utile agli utenti e inutile in SERP, e quasi mai come rimedio a un problema che ha già una soluzione più precisa. Casi in cui ha senso:
- risultati della ricerca interna, URL a valanga che non rispondono a nessuna query esterna;
- thank-you page e conferme, che non vuoi far trovare a chi non ha compilato il modulo;
- carrello e checkout, per lo stesso motivo;
- landing di campagne a pagamento sovrapponibili a pagine organiche già esistenti;
- archivi sottili, tipo un tag con due articoli dentro.
Casi in cui c’è di meglio:
- contenuti duplicati:
rel="canonical", che consolida i segnali invece di buttarli; - contenuti eliminati sul serio: uno status 410, più esplicito di un 404;
- staging: autenticazione HTTP, l’unica cosa che protegge davvero;
- pagine legali, contatti, chi siamo: lasciale indicizzate, sono segnali di affidabilità.
| Strumento | Cosa ferma | Cosa non ferma | Quando usarlo |
|---|---|---|---|
noindex | La pubblicazione in SERP | La scansione, l’accesso diretto | La pagina serve agli utenti ma non ai motori |
Disallow | La richiesta dell’URL | L’indicizzazione dell’URL senza descrizione | Risparmiare scansione su aree che non devono essere lette |
rel="canonical" | Nessuno: è un suggerimento | Scansione e accesso | Duplicati e varianti da consolidare |
| 404 / 410 | La pubblicazione, dopo la nuova scansione | Nulla di immediato | Il contenuto non esiste più |
| Password / HTTP auth | Tutto, motori e persone | Niente | Il contenuto non deve essere visto da nessuno |
| Strumento Rimozioni | La pubblicazione, entro un giorno | Il ritorno alla scadenza | Urgenze, in attesa della soluzione definitiva |
C’è poi una gerarchia dichiarata nella guida alle rimozioni, e conviene non invertirla: per una rimozione permanente il primo metodo è rimuovere o aggiornare i contenuti, «il modo più sicuro», poi la password, poi il noindex. Sul file di esclusione Google è esplicita: «non utilizzare robots.txt come metodo per bloccare la pagina». Se un contenuto è davvero da togliere, la mossa giusta resta toglierlo.
noindex su WordPress: metà dei tag non li hai messi tu
Su WordPress il noindex può arrivare da tre posti, e solo uno dei tre è un plugin. Il core ne mette già per conto suo, e la spunta nelle impostazioni non fa quello che leggi in giro.
Quello che segue sta nel sorgente del core, versione 7.0, in wp-includes/robots-template.php, default-filters.php e functions.php. Con un avvertimento: qualsiasi plugin agganciato ai filtri wp_robots o robots_txt può cambiare l’output, quindi la verifica finale resta sul sorgente della pagina pubblicata.
Le pagine che WordPress mette in noindex da solo
Tre tipi di pagina hanno già il noindex senza che tu installi niente. In default-filters.php sono attivi di serie wp_robots_noindex_search per i risultati della ricerca interna e wp_robots_noindex_embeds per gli embed, mentre wp_robots_no_robots è agganciato a login_head, quindi anche il login è coperto. C’è pure wp_robots_max_image_preview_large, ed è il motivo per cui nel tuo <head> trovi max-image-preview:large senza averlo mai chiesto a nessuno.
Questo smonta un consiglio che gira parecchio: informaticaprod scrive che le pagine dei risultati della ricerca interna «vanno tassativamente escluse con il tag noindex», come se toccasse a te. Su WordPress l’ha già fatto il core: apri il sorgente di /?s=prova e guarda l’<head>.
Cosa fa davvero «Scoraggia i motori di ricerca»
La spunta in Impostazioni, Lettura agisce sul meta tag e non sul robots.txt: nel core attuale non aggiunge nessun Disallow: / al file.
Il meccanismo: la spunta imposta blog_public a 0, e da lì wp_robots_noindex() chiama la funzione descritta nel reference di wp_robots_no_robots, che scrive noindex e, visto che il sito non è pubblico, aggiunge anche nofollow. Nell’head esce <meta name='robots' content='noindex, nofollow' />.
Il robots.txt virtuale invece non cambia: do_robots() emette sempre lo stesso file (User-agent: *, Disallow: /wp-admin/, Allow: /wp-admin/admin-ajax.php) e passa il valore della spunta soltanto come argomento del filtro robots_txt. Chi scrive che quella casella «agisce sul robots.txt» sta descrivendo una versione di WordPress diversa da quella che hai installato.
Quando dopo un go-live ti resta un noindex appiccicato addosso, l’ordine di ispezione è: la spunta in Impostazioni, Lettura; il plugin SEO, sul contenuto o sull’intero tipo; gli header del server o della CDN, dove nessuno guarda mai e dove i noindex di staging sopravvivono per mesi come cimeli.
Come si verifica se una pagina ha il noindex
Si guarda in due posti, il sorgente e gli header della risposta, e i due possono dire cose diverse. Il terzo posto, il DOM, serve a capire di chi è la colpa.
Sorgente, header, DOM
Il sorgente si legge con view-source: davanti all’URL, cercando <meta name="robots". Mostra l’HTML che arriva dal server, prima che il browser ci metta le mani: è la vista che serve.
L’header si legge con lo stesso curl -sI ... | grep -i x-robots-tag visto sui PDF, ed è l’unico modo di vederlo su un PDF o un’immagine. Se nella risposta c’è x-robots-tag: noindex, la direttiva sta nel server: nel pannello del plugin SEO non la troverai mai.
Il DOM è la pagina dopo l’esecuzione del JavaScript, e lo leggi nel pannello Elements dei DevTools. Serve a una domanda sola: sorgente e DOM concordano?
La prima volta ho perso mezza giornata a fissare un <meta name="robots"> pulitissimo in Elements, convinto che Search Console avesse le allucinazioni. Era pulito perché uno script lo aveva ripulito, mentre nel sorgente il tag stava ancora lì.
Se il tag c’è nel sorgente e non nel DOM lo sta rimuovendo uno script, ed è il caso che Google descrive come inaffidabile; se compare solo nel DOM, uno script lo sta aggiungendo. In tutti e due i casi il problema è il JavaScript, non il tag.
Controllo URL: versione indicizzata e test dal vivo
In Search Console i due pulsanti raccontano due momenti diversi: la versione indicizzata è l’ultima scansione, il test dal vivo è la pagina di adesso.
Da qui l’equivoco quotidiano: togli il noindex, apri Controllo URL, leggi ancora «esclusa» e ti convinci che non funzioni. Quella schermata descrive il passato. Se nel test dal vivo il noindex non c’è più hai finito la tua parte, e da lì si chiede la nuova scansione.
«URL contrassegnato con “noindex”» in Search Console
Nel rapporto Indicizzazione delle pagine la voce si chiama «URL contrassegnato con “noindex”», e vuol dire che Google è arrivato sulla pagina, ha letto la direttiva e l’ha rispettata: il meccanismo ha funzionato.
La descrizione ufficiale, nell’aiuto del rapporto Indicizzazione delle pagine: «quando Google ha provato a indicizzare la pagina ha trovato un’istruzione “noindex”, pertanto l’indicizzazione non è stata eseguita». In inglese la voce è «URL marked ‘noindex’».
E adesso la parte strana. La stringa che quasi tutti cercano è un’altra, e circola anche nelle istruzioni: supporthost invita a cliccare nel rapporto proprio sulla voce «Esclusa in base al tag “noindex”». Quella stringa non compare nell’elenco ufficiale dei quindici motivi di mancata indicizzazione. Chi la cerca nell’interfaccia non la trova, e non sta guardando nel posto sbagliato: è la voce ad avere un altro nome.
La lettura operativa è una sola: quella voce diventa un problema solo se dentro ci trovi URL che dovrebbero stare in indice. Per ognuna, cerca il colpevole nell’ordine di prima: spunta, plugin, header del server.
Quanto ci mette Google a deindicizzare
Dipende dall’importanza della pagina, e un numero non c’è: la documentazione parla di mesi, con la condizione già citata qui sopra. Le forbici in ore che circolano non hanno una fonte ufficiale dietro.
Per accelerare, la richiesta di nuova scansione da Controllo URL mette la URL in coda: non in cima, senza tempi garantiti, ma su una pagina singola è la cosa giusta da fare.
Lo strumento Rimozioni serve quando il problema è il tempo. La guida alle rimozioni dice di usarlo «per le rimozioni rapide», in modo che una pagina «venga eliminata dai risultati di ricerca di Google entro un giorno». Ha un limite che sulle cinque guide italiane aperte per questo pezzo non compare: «le richieste effettuate nello strumento per le rimozioni hanno una durata di circa 6 mesi». È un cerotto con la scadenza stampata sopra: se a quel punto il noindex non è stato letto, o il contenuto non è stato tolto, la pagina torna.
Nota operativa che si dimentica sempre: un URL in noindex non va tenuto in sitemap XML. La guida di Google alle sitemap è netta, «includi gli URL nella Sitemap che vuoi visualizzare nei risultati di ricerca di Google», e una URL in noindex chiede l’opposto. La struttura del file sta nel pezzo sulla sitemap XML.
Il noindex e le funzionalità AI: Google e Bing non fanno la stessa cosa
Su Google il noindex agisce sulle funzionalità AI per via indiretta; su Bing la documentazione lo lega esplicitamente anche all’addestramento dei modelli. Due impianti diversi, da tenere separati.
La catena di Google sta nella pagina sulle funzionalità AI nella Ricerca: «per essere idonea a essere mostrata come link di supporto in AI Overview o AI Mode, una pagina deve essere indicizzata e idonea a comparire nella Ricerca Google con uno snippet e soddisfare i requisiti tecnici della Ricerca», e «non sono previsti requisiti tecnici aggiuntivi». Una pagina in noindex non è indicizzata, quindi non è idonea come link di supporto. E un nosnippet basta a escluderla da quelle superfici senza toglierla dall’indice, che è spesso quello che volevi davvero.
Il documento sull’ottimizzazione per l’AI, aggiornato al 4 agosto 2026, ripete la stessa catena per le funzionalità di AI generativa nella Ricerca: la pagina deve essere indicizzata, idonea a essere mostrata «con uno snippet» e conforme ai requisiti tecnici. Le due pagine concordano, e chiudono con lo stesso caveat: soddisfare requisiti, best practice e norme non significa che Google scansionerà, indicizzerà o pubblicherà il contenuto.
Google-Extended è un’altra cosa: riguarda addestramento e grounding in altri prodotti, non la Ricerca. Chi scrive che «il noindex blocca i crawler AI» sta impastando due controlli che Google tiene distinti.
Su Bing il quadro cambia. Nella pagina di Bing sui meta robots, a noindex è associato anche «do not use the content for training Microsoft’s generative AI foundation models»; a noarchive, «do not link in Chat and Copilot» più lo stesso divieto sull’addestramento; a nocache, «display only URL/Snippet/Title in Chat or Copilot. Use only URLs, Titles and Snippets for training Microsoft’s generative AI foundation models». L’ultima va letta intera: la seconda metà concede quello che la prima sembrava chiudere. E noarchive, che Google tiene nell’elenco delle regole storiche, su Bing governa Chat e Copilot.
Sulla stessa pagina Bing ripete la condizione di crawlabilità («we need to be able to crawl the page to see this tag, so do not block access to the page»), dice che ogni tag vale anche come X-Robots-Tag e che si può sostituire name="robots" con name="bingbot" per parlare solo a lui. L’elenco lì si ferma a max-video-preview: nofollow, none, notranslate, noimageindex, unavailable_after e indexifembedded non sono elencati in quella pagina, che è un’informazione diversa dal dire che Bing non li supporti.
Dove si vede l’effetto, lato Google: il 3 giugno 2026 sono arrivati i report sul rendimento dell’AI generativa in Search Console, con impressioni, pagine, paesi, dispositivi («disponibile per i risultati della Ricerca») e date. Vengono distribuiti «per un sottoinsieme di siti web»: se nel tuo account non ci sono non è un problema tuo, e i dati restano conteggiati nel rapporto complessivo. Come si misura la visibilità da queste parti sta nel pezzo sulla SEO per l’AI.
Cinque righe da portarsi via
Si legge solo se il crawler entra. Bloccare in robots.txt una pagina in noindex annulla la direttiva e lascia la URL in indice senza descrizione.
Sta nell’HTML iniziale o non conta. Google può saltare il rendering proprio quando trova un noindex: metterlo o toglierlo via JavaScript non è affidabile.
Sparisce solo dopo una nuova scansione. Nessuna stima in ore: «potrebbe impiegare mesi», e la condizione sull’importanza della pagina fa parte della frase.
Se una URL è in noindex, fuori dalla sitemap. Chiedere l’indicizzazione e negarla nello stesso momento serve solo a confondere te stesso fra sei mesi.
Se hai fretta, Rimozioni compra circa sei mesi. Il tempo di applicare la soluzione definitiva, che sta più in alto nella gerarchia di Google.
Se hai un caso in cui il noindex si comporta in modo strano, un tag che ricompare dopo il deploy o una pagina che resta in SERP mesi dopo, scrivimene: sto raccogliendo quelli in cui la direttiva c’è e l’effetto no, e finora si sono spiegati tutti con una delle tre condizioni qui sopra. Il resto della catena sta nel pezzo sull’indicizzazione.
Domande frequenti
Il noindex blocca la scansione?+
No. Blocca l’indicizzazione. Googlebot continua a richiedere la pagina, e deve poterlo fare: se non la scansiona, non legge nemmeno il noindex. Per limitare la scansione serve il robots.txt, che però dall’indice non toglie niente.
Posso usare noindex e Disallow insieme?+
No. Il Disallow impedisce a Google di leggere la direttiva, e l’URL può restare in indice senza descrizione. Prima togli il blocco, lasci entrare il crawler finché la pagina esce dai risultati, e solo dopo, se serve, rimetti il Disallow.
Quanto ci mette Google a togliere una pagina in noindex?+
Dipende dall’importanza della pagina: Googlebot «potrebbe impiegare mesi per visitarla di nuovo». Si accelera con la richiesta di nuova scansione da Controllo URL, oppure con lo strumento Rimozioni, che elimina l’URL dai risultati entro un giorno e dura circa sei mesi.
Come metto il noindex su un PDF?+
Con l’header HTTP, perché un PDF non ha un <head>. Su Apache un blocco <Files ~ "\.pdf$"> con Header set X-Robots-Tag "noindex, nofollow", su nginx un location ~* \.pdf$ con add_header. Verifica con curl -sI sull’URL del file.
Una pagina in noindex resta in sitemap?+
No. La sitemap elenca gli URL che vuoi vedere nei risultati di ricerca, e un noindex chiede il contrario: tenerli insieme significa chiedere due cose opposte, e quella URL finisce nel rapporto Indicizzazione delle pagine sotto «URL contrassegnato con “noindex”». Toglila quando metti la direttiva, non sei mesi dopo.
noindex e canonical possono convivere?+
Tecnicamente sì, ma sono due richieste opposte: il canonical dice «indicizza quest’altra al posto mio», il noindex dice «non indicizzare niente». Se il problema è un duplicato usa solo il canonical, se la pagina non deve stare in SERP usa solo il noindex.
Che differenza c’è fra noindex,follow e noindex,nofollow?+
Il primo lascia i link della pagina buoni per scoprire altre URL, il secondo no. La tesi che alla lunga diventino la stessa cosa non sta nella documentazione Google: è una dichiarazione di John Mueller del dicembre 2017, con un «kind of» dentro, e sui tempi rispose «dipende».
Il noindex mi toglie dalle AI Overviews?+
Su Google sì, ma per conseguenza: una pagina deve essere indicizzata e idonea allo snippet per comparire come link di supporto in AI Overview o AI Mode. Se vuoi restare in indice e uscire da quelle superfici, la direttiva giusta è nosnippet. Su Bing il noindex vale esplicitamente anche come opt-out dall’addestramento dei modelli.
Perché in Search Console non trovo la voce «Esclusa in base al tag noindex»?+
Perché nell’elenco ufficiale dei quindici motivi di mancata indicizzazione quella stringa non c’è. La voce corrispondente si chiama «URL contrassegnato con “noindex”», e in inglese «URL marked ‘noindex’». Le guide che citano l’altra formulazione ti mandano a cercare un’etichetta che l’interfaccia non usa.
