Cosa è cambiato nella ricerca nel primo semestre del 2026

Bing ha iniziato a mostrare agli editori dove le loro pagine venivano citate nelle risposte IA. Google ha cambiato Discover, ha ritirato i rich snippet FAQ e ha introdotto report dedicati sulle impression IA. Accanto a questi cambiamenti visibili, limiti del crawler, navigazione nel browser e migrazioni di dominio hanno dato ai team tecnici molto da controllare. Questa rassegna collega le modifiche di gennaio–giugno ai report, alle pagine e alle decisioni di rilascio che toccano.

Dati

La sequenza che ha cambiato le decisioni operative

La sequenza conta perché gli eventi rispondono a domande diverse. Gennaio ha rimosso la documentazione sui dati strutturati Practice problem e ha introdotto la guida sulle fonti preferite. Febbraio ha portato un Discover Core Update regionale in inglese statunitense e la prima anteprima pubblica di AI Performance di Bing. Marzo ha combinato finestre separate di rollout antispam e core con una spiegazione tecnica di come Googlebot elabora le risposte. Aprile ha completato il core rollout e ha aggiunto il dirottamento del pulsante Indietro alla policy antispam. Maggio ha ritirato l'aspetto dei rich snippet FAQ e ha pubblicato la guida sull'IA generativa. Giugno ha aggiunto i report IA di Search Console, la chiarificazione sulle migrazioni, le viste IA estese di Bing e il monitoraggio orario delle query di Yandex.

Questo ordine previene anche gli errori di categoria. Un editore può correggere subito un guasto sulla risposta del crawler, anche se capita durante un core update. Il ritiro di una funzione richiede una decisione su modello e contenuti, mentre il lancio di un report richiede una definizione di misurazione. Metti l'evento accanto alle evidenze delle pagine colpite, non in un'unica colonna indifferenziata di «aggiornamento dell'algoritmo».

Modifica di prodotto

Discover e fonti preferite

Il Discover Core Update di febbraio di Google è partito con un perimetro in inglese statunitense e indicazioni su rilevanza locale, competenza originale tempestiva e meno contenuti sensazionalistici. Questo rende la prima domanda della revisione geografica ed editoriale: il pubblico, la lingua e il formato colpiti erano dentro la superficie documentata? Un movimento di Discover fuori da quel contesto non prova che un modello di pagina generale debba cambiare. Controlla i segnali di localizzazione del contenuto, la competenza sull'argomento, i tempi di pubblicazione e il report Discover effettivo prima di trattare le impression come segnale di posizionamento universale.

Le fonti preferite hanno seguito un percorso diverso. Google ha documentato la funzione a gennaio, l'ha estesa a tutte le lingue della Ricerca ad aprile e ha aggiunto AI Overviews e AI Mode al perimetro documentato a maggio, come registrato nei suoi aggiornamenti della documentazione. Gli editori possono condividere un pulsante o un link che aiuta i lettori a sceglierli come fonte preferita. La scelta la fa il lettore; il markup schema non può farla al suo posto. Dai ai lettori che tornano un'identità editoriale chiara e un modo comodo di selezionarla.

Un controllo pratico di Discover parte dal contenuto stesso: conferma la data visibile, l'argomento, la rilevanza locale e la reportistica o analisi originale. Poi confronta il paese e la lingua colpiti con il perimetro pubblicato della funzione. Se un sito serve più mercati, non usare un aggiornamento in inglese statunitense come spiegazione per ogni localizzazione. Tieni i miglioramenti editoriali legati al pubblico che può davvero incontrare quella superficie.

Modifica di prodotto

Report IA: tenere separate le superfici

A febbraio, Bing AI Performance ha introdotto report orientati alle citazioni. La sua espansione di giugno ha aggiunto Intents, Topics, Citation Share e Compare nel rilascio successivo di Bing. Quei report aiutano un titolare a esaminare come le esperienze IA di Bing citano le pagine; non sostituiscono le sessioni, il posizionamento su Google né una misurazione degli AI Overview. La loro domanda è la visibilità delle citazioni dentro la superficie di report definita da Bing.

L'annuncio di giugno di Google sui report IA in Search Console ha introdotto viste dedicate per le impression nelle funzioni con IA generativa su Ricerca e Discover. Quelle impression restano incluse anche nella reportistica complessiva; le viste dedicate erano inizialmente arrivate a un sottoinsieme di siti. Yandex ha aggiunto i dati orari del Monitoraggio query, un tipo di report diverso per le query di ricerca popolari. Tieni separati questi prodotti per piattaforma, unità e finestra di report. Sommare clic, citazioni e valori orari preliminari oscurerebbe ciò che ogni report misura davvero.

zoom_in

Per una dashboard, definisci la riga prima di esportare i dati. Una riga può significare clic di Google Search Console per un gruppo di URL; un'altra citazioni Bing per un argomento; una terza osservazioni orarie di query Yandex. Dai a ogni riga la sua proprietà o il suo mercato, l'intervallo di date e il fuso orario. Questo toglie la tentazione di disegnare un grafico fluido da misure mai pensate per essere sommate.

Azione

Elaborazione del crawler e il confine dei 2 MB

La spiegazione sul crawler di marzo di Google ha reso operativo un vincolo vecchio ma facile da perdere: Googlebot elabora una quantità limitata di contenuto della risposta, con un confine pratico di due megabyte per la risposta HTML. La lezione non è contare la dimensione del bundle e fermarsi. Ispeziona lo status effettivo, l'URL finale, il corpo della risposta, il tag canonical e i contenuti critici presenti nel risultato renderizzato. Se istruzioni o contenuti essenziali arrivano troppo tardi, la vista del browser su una connessione veloce può nascondere il guasto.

Per una rotta JavaScript pesante, prendi una URL rappresentativa e salva header e byte della risposta grezza. Poi confronta ciò che arriva nell'HTML iniziale con ciò che compare dopo il rendering: contenuto principale, canonical, direttive robots, dati strutturati e link alle prossime pagine significative. Sposta il payload non critico fuori dal percorso critico dove l'evidenza lo supporta, ma non rimuovere contenuti solo per raggiungere un numero di byte. La condizione di accettazione è che il significato necessario della pagina resti raggiungibile e renderizzabile entro i vincoli pratici del crawler.

zoom_in

Il confine dei due megabyte è particolarmente rilevante quando un modello invia grandi dati serializzati, payload di navigazione o markup duplicato prima del contenuto principale. Individua il costo in byte nel documento restituito, non solo nell'output di build JavaScript. Se il canonical o il testo del corpo arrivano lato client dopo una lunga catena di lavoro, rendi esplicita quella dipendenza e testala con gli stessi parametri di rotta che un crawler può richiedere.

Azione

Rollout antispam e dirottamento del pulsante Indietro

L'aggiornamento antispam di marzo è durato dal 24 al 25 marzo. Il core update di marzo è iniziato il 27 marzo e si è completato ad aprile. Quelle finestre devono restare separate in un'indagine. Una pagina che perde clic in uno dei due periodi può avere un guasto tecnico, un cambiamento nella domanda delle query, un problema di canonical, uno spostamento dei concorrenti o un problema di qualità più ampio; il calendario non sceglie al posto tuo.

Il 13 aprile Google ha aggiunto il dirottamento del pulsante Indietro come violazione esplicita della policy antispam, con applicazione annunciata per il 15 giugno. Quella scadenza appartiene al calendario dei rilasci. È un comportamento concreto del browser da controllare: dopo che un visitatore segue un risultato, premere Indietro deve riportarlo alla pagina precedente, non intrappolarlo in una sequenza di navigazione inattesa. Mettilo alla prova in una sessione pulita del browser, su mobile e su desktop, poi esamina redirect, manipolazioni della cronologia e script iniettati. Rimuovi il meccanismo invece di mascherarlo con una modifica superficiale alla landing page.

Il contrasto tra il cambiamento di policy e le finestre degli aggiornamenti conta nel triage. Il dirottamento del pulsante Indietro è un difetto di interazione riproducibile; il suo test ha un superato o fallito chiaro. Una sovrapposizione con un core update è un contesto d'indagine, quindi serve evidenza segmentata. Tieni separati questi flussi di lavoro: correggi subito la navigazione ingannevole dimostrabile e usa i dati a livello di query e di pagina prima di decidere se sia giustificata una revisione più ampia dei contenuti.

Azione

I piani di migrazione devono coprire ogni variante di host

La guida di giugno sui trasferimenti di sito ha reso esplicito il consiglio sul Change of Address per tutte le varianti di dominio. Questo cambia l'inventario della migrazione: host di root, host www e ogni sottodominio pertinente hanno bisogno di una destinazione finale dichiarata, non di una convenzione implicita. Una mappa di redirect che copre solo un hostname preferito può lasciare esposte a utenti e crawler varianti duplicate, rotte o non verificate.

Costruisci l'insieme di test prima di spostare il traffico. Per ogni vecchia URL attiva, registra l'URL finale prevista, un redirect permanente diretto, lo status finale, il canonical, l'appartenenza alla sitemap e i contenuti critici renderizzati. Poi ripeti il test attraverso ogni variante pubblica di host. Aggiorna link interni, tag canonical e sitemap all'host finale; non dipendere dalle catene per riparare le vecchie convenzioni. Se una URL non ha un successore pertinente, restituisci la risposta di non trovato appropriata invece di mandarla alla home page.

Il controllo delle varianti di host dovrebbe includere il protocolto oltre all'hostname: root HTTP, root HTTPS, www HTTP e www HTTPS dove quelle varianti risolvono pubblicamente. Una migrazione fallisce spesso ai bordi — un'immagine o un target hreflang possono conservare un host vecchio, o un sottodominio legacy può saltare un redirect. Una mappa breve leggibile dalla macchina più controlli nel browser dà a crawler e persone un'unica destinazione finale.

Modifica di prodotto

Ritiro dei rich snippet FAQ e una modifica più ristretta sui dati prodotto

Maggio ha introdotto due decisioni di manutenzione dei dati strutturati molto diverse. Google ha smesso di mostrare i rich snippet FAQ dal 7 maggio, come registrato nei suoi aggiornamenti della documentazione. Una FAQ visibile può ancora rispondere a una domanda del cliente, ma un markup valido non implica più che quel particolare aspetto della Ricerca tornerà. Tieni le domande rivolte ai lettori dove sono utili; rimuovi l'implementazione solo-funzione solo dopo aver controllato modelli, analytics e dipendenze di accessibilità.

Gli stessi aggiornamenti di maggio hanno aggiunto hasAdultConsideration alla documentazione su prodotto e merchant. È un campo dal perimetro ristretto per record in cui il fatto è accurato e rappresentato con veridicità. Non è un miglioramento generico del feed prodotti e non va inserito per inseguire una funzione. La regola generale è conservare i dati semantici che corrispondono alla pagina visibile, validare il grafo e il consumer di destinazione separatamente e ritirare le promesse su un aspetto che il prodotto non offre più.

Per una FAQ, metti alla prova le domande visibili su desktop e mobile, poi chiediti se ogni risposta riduce una reale domanda pre-acquisto o di supporto. Se sì, il contenuto può restare anche senza incentivo del rich snippet. Per l'adult consideration, esigi una fonte fattuale nel record di catalogo e una rappresentazione visibile dove appropriato. Questo impedisce che una proprietà simile alla compliance venga trattata come flag SEO speculativo.

Azione

Controlli specifici per la prossima revisione

La prossima revisione dovrebbe creare un foglio di evidenze per superficie, non un punteggio unico. Per la discovery, registra paese, lingua, formato e il report di prodotto pertinente. Per la visibilità IA, conserva piattaforma, nome del report, date, unità e attribuzione. Per il lavoro di scansione, conserva header di risposta, dimensione del corpo, contenuti critici renderizzati, stato di canonical e robots. Per le migrazioni, conserva ogni host di partenza e la mappa delle rotte. Per lo schema, conserva il fatto visibile, la validazione del grafo e la policy attuale sulla funzione. Questi record rendono spiegabile un cambiamento successivo senza inventare una storia causale.

• Per Discover, confronta un paese e un formato di contenuto colpiti con il perimetro documentato del prodotto prima di cambiare i modelli editoriali.
• Per i report di Google, Bing e Yandex, conserva tabelle separate; non sommare mai citazioni, clic di Search Console e osservazioni orarie di query.
• Per una rotta pesante, cattura la dimensione della risposta grezza e i contenuti critici renderizzati prima e dopo ogni modifica di prestazioni.
• Per una migrazione, testa root, www e ogni sottodominio pubblico contro la mappa dei redirect, i tag canonical, la sitemap e una pagina renderizzata.
• Per i dati strutturati, distingui le informazioni visibili che restano utili da un formato di rich snippet che Google ha ritirato.
• Per ogni finestra di rollout, esamina le evidenze su query, landing page e tecnica prima di assegnare una causa a un aggiornamento.