What changed in search in the first half of 2026

Bing began showing publishers where their pages were cited in AI answers. Google changed Discover, retired FAQ rich results and introduced dedicated AI impressions reports. Alongside those visible changes, crawler limits, browser navigation and domain migrations gave technical teams plenty to check. This review connects the January–June changes to the reports, pages and release decisions they affect.

Data

The sequence that changed operating decisions

The sequence matters because the events answer different questions. January removed practice-problem structured-data documentation and introduced Preferred Sources guidance. February brought a regional, US-English Discover Core Update and Bing’s first public AI Performance preview. March combined separate spam and core rollout windows with a technical explanation of how Googlebot processes responses. April completed the core rollout and added back-button hijacking to the spam policy. May retired the FAQ rich-result appearance and published generative-AI guidance. June added Search Console AI reporting, migration clarification, Bing’s expanded AI views and Yandex hourly query monitoring.

This ordering also prevents category errors. A publisher can act on a crawler-response fault immediately, even if it happens during a core update. A feature retirement calls for a template and content decision, while a reporting launch calls for a measurement definition. Put the event beside the affected page evidence rather than in a single undifferentiated “algorithm update” column.

Product change

Discover and Preferred Sources

Google’s February Discover Core Update began with US-English scope and guidance about local relevance, timely original expertise and less sensational content. That makes the first review question geographic and editorial: was the affected audience, language and format inside the documented surface? A Discover movement outside that context is not evidence that a general page template needs to change. Check the content’s location cues, topical expertise, publication timing and the actual Discover report before treating impressions as a universal ranking signal.

Preferred Sources followed a different path. Google documented the feature in January, expanded it to all Search languages in April, and added AI Overviews and AI Mode to the documented scope in May, as recorded in its documentation updates. Publishers can share a button or link that helps readers choose them as a preferred source. The reader makes that choice; schema markup cannot make it on their behalf. Give returning readers a clear publication identity and a convenient way to select it.

A practical Discover check starts with the content itself: confirm the visible date, topic, local relevance and original reporting or analysis. Then compare the affected country and language with the feature’s published scope. If a site serves several markets, do not use a US-English update as an explanation for every locale. Keep editorial improvements tied to the audience that can actually encounter the surface.

Product change

AI reports: keep the surfaces separate

In February, Bing AI Performance introduced citation-oriented reporting. Its June expansion added Intents, Topics, Citation Share and Compare in Bing’s follow-up release. Those reports help an owner investigate how Bing AI experiences cite pages; they are not a substitute for sessions, Google rankings or an AI Overview measurement. Their question is citation visibility within Bing’s defined reporting surface.

Google’s June Search Console AI reporting announcement introduced dedicated views for impressions in generative AI features across Search and Discover. Those impressions also remain included in overall performance reporting; the dedicated views initially reached a subset of sites. Yandex added hourly Query Monitoring data, a different kind of report for popular search queries. Keep these products separate by platform, unit and reporting window. Adding clicks, citations and preliminary hourly values would obscure what each report actually measures.

zoom_in

For a dashboard, define the row before exporting data. One row might mean Google Search Console clicks for a URL group; another might mean Bing citations for a topic; a third may mean hourly Yandex query observations. Give each row its own property or market, date range and time zone. This removes the temptation to draw a smooth chart from measures that were never designed to be added.

Action

Crawler processing and the 2 MB boundary

Google’s March crawler explanation made an old but easy-to-miss constraint operational: Googlebot processes a limited amount of response content, with a practical two-megabyte boundary for the HTML response. The lesson is not to count bundle size and stop. Inspect the actual status, final URL, response body, canonical tag and the critical content present in the rendered result. If essential instructions or content arrive too late, a browser view on a fast connection can hide the failure.

For a large JavaScript route, take one representative URL and save the raw response headers and bytes. Then compare what arrives in initial HTML with what appears after rendering: main content, canonical, robots directives, structured data and links to the next meaningful pages. Move non-critical payload out of the critical path where that evidence supports it, but do not remove content simply to meet a byte number. The acceptance condition is that the required page meaning remains reachable and renderable within the crawler’s practical constraints.

zoom_in

The two-megabyte boundary is especially relevant when a template sends large serialized data, navigation payloads or duplicated markup before its main content. Locate the byte cost in the returned document, not only in JavaScript build output. If the canonical or body text is supplied client-side after a long chain of work, make that dependency explicit and test it with the same route parameters a crawler can request.

Action

Spam rollout and back-button hijacking

The March spam update ran from 24 to 25 March. The March core update started on 27 March and completed in April. Those windows must remain separate in an investigation. A page losing clicks across either period may have a technical break, a change in query demand, a canonical problem, a competitor shift or a broader quality issue; the calendar does not choose between them.

On 13 April, Google added back-button hijacking as an explicit spam-policy violation, with enforcement announced for June 15. That deadline belongs in the release calendar. This is a concrete browser behaviour to audit: after a visitor follows a result, pressing Back should return them to the prior page, not trap them in an unexpected navigation sequence. Test it on a clean browser session and on mobile as well as desktop, then inspect redirects, history manipulation and injected scripts. Remove the mechanism rather than masking it with a superficial landing-page change.

The contrast between the policy change and the update windows matters in triage. Back-button hijacking is a reproducible interaction defect; its test has a clear pass or fail. A core-update overlap is an investigation context, so it needs segmented evidence. Keep these workstreams separate: fix demonstrable deceptive navigation directly, and use query- and page-level data before deciding whether a broader content review is justified.

Action

Migration plans must cover every host variant

June’s site-move guidance made Change of Address advice explicit for all domain variants. That changes the migration inventory: root host, www host and any relevant subdomain need a stated final home, not an implied convention. A redirect map that covers only one preferred hostname can leave duplicate, broken or unverified variants exposed to users and crawlers.

Build the test set before switching traffic. For each live old URL, record the intended final URL, one direct permanent redirect, final status, canonical, sitemap membership and rendered critical content. Then repeat the test through each public host variant. Update internal links, canonical tags and sitemaps to the final host; do not depend on chains to repair old conventions. If a URL has no relevant successor, return the appropriate not-found response rather than sending it to the homepage.

The host-variant check should include protocol as well as hostname: HTTP root, HTTPS root, HTTP www and HTTPS www where those variants resolve publicly. A migration frequently fails at the edges—an image or hreflang target may retain an old host, or a legacy subdomain may skip a redirect. A short machine-readable mapping plus browser checks gives both crawlers and people one final destination.

Product change

FAQ retirement and a narrower product-data change

May introduced two very different structured-data maintenance decisions. Google stopped showing FAQ rich results from 7 May, recorded in its documentation updates. A visible FAQ can still answer a customer’s question, but valid markup no longer implies that this particular Search appearance will return. Keep reader-facing questions where they are useful; remove feature-only implementation only after checking templates, analytics and accessibility dependencies.

The same May updates added hasAdultConsideration to product and merchant documentation. It is a narrowly scoped field for records where the fact is accurate and represented truthfully. It is not a generic product-feed enhancement and should not be inserted to pursue a feature. The general rule is to preserve semantic data that matches the visible page, validate the graph and target consumer separately, and retire promises about an appearance that the product no longer offers.

For an FAQ, test the visible questions on desktop and mobile, then ask whether each answer reduces a real pre-purchase or support question. If yes, the content can remain even without a rich-result incentive. For adult consideration, require a factual source in the catalog record and a visible representation where appropriate. That prevents a compliance-like property from being treated as a speculative SEO flag.

Action

Specific checks for the next review

The next review should create one evidence sheet per surface, not one master score. For discovery, record country, language, format and the relevant product report. For AI visibility, retain platform, report name, dates, unit and attribution. For crawl work, retain response headers, body size, rendered critical content, canonical and robots state. For migrations, retain every input host and route mapping. For schema, retain the visible fact, graph validation and the current feature policy. These records make a later change explainable without inventing a causal story.

• For Discover, compare an affected country and content format with the documented product scope before changing editorial templates.
• For Google, Bing and Yandex reports, retain separate tables; never sum citations, Search Console clicks and hourly query observations.
• For a heavy route, capture raw response size and rendered critical content before and after any performance change.
• For a migration, test root, www and every public subdomain against the redirect map, canonical tags, sitemap and a rendered page.
• For structured data, distinguish visible information that remains useful from a rich-result format that Google has retired.
• For any rollout window, examine query, landing-page and technical evidence before assigning a cause to an update.