Google has been moving the results page away from fixed modules for a couple of years, and a Google Research paper, Generative UI: LLMs are Effective UI Generators, spells out where that road may end: a model writes the entire page, including the HTML, CSS and JavaScript, from scratch for each query. Google’s own announcement said in November 2025 that this was live in AI Mode for Google AI Pro and Ultra subscribers in the U.S., and the evidence further down suggests it has spread since.
The usual reaction to news like this is to ask how we optimize for it, but I think that is the wrong first question, because the paper treats search as a tool the model calls and the retrieval layer underneath is the same one we have been engineering relevance for. What changes is how results are presented, not how they are selected, so what breaks is measurement.
The page we are trying to measure is no longer a stable object, which takes the argument I made in 2020 about rank tracking, that there was never one SERP to rank on, a step further. I’ve been saying all year that I expect this to be the year hyperpersonalization comes to the core SERP and not just the generative surfaces. That will make any single capture of the SERP even less representative of what anyone else saw.
That means rank tracking, as we’ve historically done it, cannot be trusted to describe performance on its own. In fact, we may need to start verifying SERPs the way we already verify generative AI visibility, with repeated checks and a distribution of results rather than a single daily pull.
How generative UI works
The Generative UI paper describes a system with three parts, shown in the diagram below. A tool server gives the model access to Google Search and to image retrieval and generation, a system prompt tells the model what to build and how to plan it, and a set of post-processors cleans up the page before it reaches the browser. The user’s prompt and the system instructions go into the model, which calls its tools as it works and returns a single page of HTML, CSS and JavaScript that the browser renders as-is. Any changes the user asks for loop back in as a new prompt.
The system prompt does most of the steering, and the paper publishes an illustrative version of it in an appendix, taken from an early research prototype. Its first rule is to build an interactive app, so that even a simple question such as the time in Tel Aviv should come back as a working clock rather than just a line of text. Before writing any code, the model is told to interpret the query, decide what needs to be searched, plan where its images will come from, and brainstorm roughly a dozen components and interactive features. Search is mandatory for entities and facts, the model is told to issue follow-up searches when its first results open new questions, and every factual claim in the interface has to be supported by what it retrieved.
Images follow the same logic. For each one the model chooses between generating an illustration and retrieving a real photo of a named person, product or place, and the page simply points an image tag at the matching endpoint so the browser fetches it directly without passing through the model. Placeholders and mock data are forbidden, so when an element has no real data behind it the instruction is to remove it from the page. The post-processors are mostly mechanical fixes for JavaScript, CSS and API keys, but one of them injects code that detects and reports client-side errors, which gives Google a way to see where generation fails across every page it serves.
Because so much of the behavior lives in the prompt, small changes to it produce a consistent look. The authors show the same system rendering pages in a “Classic” style, with the model adapting its images and icons to match, and they note that a page takes a minute or two to generate, which streaming roughly halves in perceived wait.
One caution on how far the paper goes. None of its examples is a classic search results page. They are dynamic content experiences, such as a skyscraper comparison, a pizza guide and a decor planner, and the text of the paper never uses the word SERP or mentions AI Mode. Google Search appears in it as a tool the model calls and as a baseline (the top-ranked result the generated pages are compared against). The link to the results page comes from Google’s own announcement, which says Generative UI is live in AI Mode, and from my inference that the same machinery can render a SERP. So read the paper as evidence of what the technology can do to presentation, and read the SERP claims as my own conclusion, based on the applications below.
There is evidence that it has moved toward core Search since then. At I/O 2026, Google said Search, using the agentic coding of Gemini 3.5 Flash and Antigravity, can “build the ideal response, in the right format for your question” on the fly, and that these generative UI capabilities, which assemble interactive visuals, tables, graphs or simulations into a custom layout, would be available to everyone in Search this summer at no charge. The mini apps and trackers come later, starting with AI Pro and Ultra subscribers in the U.S. Then, according to CrawlVision and Relevant Audience, which both cite a Google post from August 19, 2026, generative UI started rolling out in AI Overviews, after launching globally in English in AI Mode.
Where the SERP sits on the generative UI spectrum
Google Cloud’s generative UI guide describes generative UI as a range of strategies and not one technology, with three points on a line that runs from control to flexibility. At the controlled end is Static GenUI, where the agent picks from a fixed library of components that developers built by hand, so the agent decides which components appear and the developers decide what they look like. In the middle is Declarative GenUI, where the agent returns a structured description such as JSON of the cards, lists and widgets it wants and the client renders it. At the flexible end is Open-Ended GenUI, where the agent writes raw HTML and CSS and the frontend renders it, which the guide says buys unlimited creativity at the cost of security and styling risk.
That gives us a better way to say what the paper is and what the SERP might be. The paper’s system is Open-Ended GenUI, since the model writes the whole page. The results page we have today looks to me like Static GenUI: a fixed library of modules (organic results, AI Overviews, People Also Ask, the local pack, shopping, ads) that Google built, with a system deciding which ones to show, in what order and filled with what. It is probably static and declarative at once, because Google has said it is adding components such as interactive visuals, tables, graphs, simulations and trackers that Search assembles into a custom layout, which is the Declarative pattern of a system describing a layout from a vocabulary of parts. That is also why generative UI is about presentation more than selection, and it would explain why Nozzle’s poisoned SERPs (see below) still looked complete and normal, because the template stays intact while the content inside it changes.
Patent evidence fits the same reading, because the “Using large language models to generate user interface components” patent describes a model choosing from a UI component library, which is the static or declarative end of the line.
Ultimately, the retrieval layer underneath is the same one that already powers AI Overviews and AI Mode, so what changes is the output: instead of summarizing retrieved passages into a block of text, the model plans a set of interactive features, searches to ground each of them, and renders the result as a page.
Users prefer it and why Google will go further
In the Generative UI paper, the authors asked people which they would rather use, the generated page or what searchers see today, and that comparison is the part of the paper I think matters most for what Google does next.
In the authors’ human evaluations, the generated page was preferred over the top-ranked search result 90% of the time on the LMArena prompts and 73.5% of the time on the information-seeking prompts, and it was at least comparable to pages built by paid human developers in about half of cases. Those figures come from the authors’ own prompts and raters, so I would not treat them as a measure of Google’s production traffic, but they point in one direction: when people are shown an interactive page built for their question next to the first blue link, most of them pick the page. The paper also shows how quickly this improves, with output errors on the LMArena prompts falling from 60% on Gemini 2.0 Flash-Lite to 0% on Gemini 3, which means the reliability objection to this approach is disappearing with each model generation.
That is why I expect Google to keep moving in this direction. A page that users prefer keeps them on Google’s own surface for longer, gives Google control over what is shown and how it is framed, and can be rebuilt for each person, which fits my view that this is the year hyperpersonalization comes back to the core SERP and not just the generative surfaces. Google’s I/O post already says Search builds these responses with agentic coding, and the improvements in the paper remove the main reason to hold back.
What do the patents say?
I couldn’t find a single patent that validates my hypothesis exactly. The closest one aimed at Search is US12536233B1, “AI-generated content page tailored to a specific user,” granted January 27, 2026. It describes a machine-learned model that generates a page from the user’s query plus contextual information such as previous queries, with each component annotated with content generated for that query. It is framed around an organization’s landing page rather than open-ended search, and it doesn’t say the page is grounded in retrieved results or written as HTML, so it points in the same direction without matching the paper.
Google has also filed a family of applications on language models generating interface components, including WO2025072505A1, WO2026072958A1 and US20260044253A1. Those cover task widgets built from a device’s apps and on-screen context, not search results pages, and the paper does not cite any of them. While it supports my machine media thesis, my read is that the patents show the direction and the paper shows the mechanism.
Here is what each patent describes, and what it leaves out compared with the paper.
| Patent | Priority date | What it describes | What it does not describe |
|---|---|---|---|
| AI-generated content page tailored to a specific user (US12536233B1) | July 25, 2024 (granted Jan 27, 2026) | A model that processes the query plus contextual information, including a previous query, to generate a page whose components (a call-to-action button, a product feed, an AI chatbot) are filled with content generated for that query. If a landing page’s score passes a threshold, the results page gets a link to the AI-generated page. | HTML or code generation, citations, or any statement that search results feed the generation. Landing pages are scored to decide whether the link appears, but their content is not described as the source of the generated page. |
| Using large language models to generate user interface components (WO2025072505A1) | Sept 28, 2023 | A prompt that specifies the output format, allowed data types and a UI component library, plus an API library and sub-LLMs for disambiguation. The model returns generated JavaScript that returns components from that library, and the instructions can be generated dynamically at runtime, with a cache for instructions retrieved from a device. | Web search, streaming or latency handling, and how the generated code is sandboxed. |
| Using language models to generate user interface components (WO2026072958A1) | Sept 30, 2024 | A model that reads context from background apps, identifies tasks, finds the apps that can do each one, scores their priority and generates an interface with a component per task. | A user query as the trigger, and any search tool. |
| Dynamically generating user interface components (US20260044253A1) | Aug 12, 2024 | An input on an interface component plus the content on screen is turned into a prompt, the model suggests outputs, and the system generates instructions for a new set of components. Its example is asking where to buy the pillows in a video. | How sources for those answers are found, and any web search. |
Three things connect this to a generative SERP. The first is the timeline, because the earliest of these was filed in September 2023, which means Google had been working on a model that writes interfaces for roughly two years before the paper described it applied to Search. The second is that the “AI-generated content page tailored to a specific user” patent is the only one that touches the results page itself, and what it describes is a results page that changes depending on the query, context such as a previous query and a score computed about the pages it would otherwise link to. That is a SERP that no two people necessarily see the same way. The third is the architecture in the “Using large language models to generate user interface components” patent, where a model is handed a vocabulary of components and a set of tools and writes code against them, which is the same shape as the paper’s system, with a component library in place of free-form HTML and application APIs in place of Google Search.
What none of them describes is the piece the paper adds, which is a free-form page grounded in live search results and written fresh for each query. My conclusion is that the patents show Google has built the interface layer and the personalization layer, and the paper shows the retrieval-grounded version of it. For measurement, the patent evidence points the same way as the paper does, because a page assembled per query from account context and live retrieval has no canonical version to rank on.
The same dynamism makes poisoned SERPs possible
While Google has served blank and poisoned SERPs through deterministic methods for many years, there is a new breed in the wild. Nozzle’s poisoned SERP research looked at 27.5 million results collected between August 20 and October 9, 2026, and found that complete, normal-looking pages started coming back with most of a keyword’s usual sites swapped out. There was no error and no captcha, so the only way to see it was to compare a keyword against its own history. Poisoned SERPs went from 0.17% of results in the baseline period to 8.0% since September 13, and they peaked at roughly a quarter of all SERPs on September 27 through 29.
The table shows how much of the previous check’s content each part of the page kept, and the damage is uneven. Each figure is a retention rate for that part of the page on its own, meaning the share of what the part showed on the same keyword’s previous SERP that it shows again, so the rows are independent of each other and the Normal and Poisoned columns are not meant to add up to 100%. Normal is Nozzle’s baseline period, August 20 to September 9.
| Share of the previous SERP retained | Normal | Poisoned |
|---|---|---|
| Organic result sites | 88.5% | 20.7% |
| People also search for | 87.9% | 30.7% |
| AI Overview sources | 68.8% | 42.3% |
| People also ask | 87.4% | 46.9% |
| Local pack | 85.8% | 60.5% |
| Knowledge panel | 88.3% | 72.9% |
| Shopping | 92.8% | 92.2% |
| Ads | 70.6% | 83.7% |
A few details stand out to me. Shopping and ads came through almost untouched, and ads were actually more stable than usual, while organic results and the sources behind AI Overviews took the hit. The instrument also mattered, because on the same days in late September and early October one collection route returned 1% to 7% poisoned SERPs while another returned 9% to 30%. For a site, the effect was stark: where a project’s own site was one of a keyword’s usual top-10 results, it was missing from the top 10 on 58.6% of poisoned SERPs compared with 2.7% normally. And it varies by market, since legal SERPs peaked at 51.3% on September 27, “near me” phrases ran at 11.4% against 7.8% for everything else, and brand searches were lowest at 5.3%.
Most of it passes quickly, which is the part that makes it dangerous for reporting. Eighty percent of poisoning spells lasted a single SERP, and the usual sites were back within three days for 77.9% of poisoned SERPs. Nozzle’s example is “white label local seo” on desktop in the US, where all nine page-one sites from October 4 were gone by October 7, replaced by a WordPress tool, Reddit, USA.gov and county government sites, while the page’s HTML size barely moved (720 KB to 728 KB), which is exactly why nothing looked wrong.
Nozzle’s interpretation is that Google is responding to bulk scraping for AI answers and that rank trackers are caught in the same net. The connection to generative rendering is my own inference, and neither Nozzle nor the paper makes it.
My argument is that when a results page is assembled by a model from retrieved material for each request, rather than looked up from a fixed set of templates and rankings, then serving a different assembly to a request that looks like a scraper is cheap and nearly invisible. The flexibility that gives us per-query interfaces and personalization is the same flexibility that lets Google hand a suspected bot a plausible page that is quietly wrong.
And I fear that Google is just getting started with the shenanigans.
Meet Genraggle: a proof of concept for a generative SERP
When I first saw SGE at Google I/O in 2023, I built Raggle to develop intuition for how retrieval augmented generation worked in web search, and I wanted to do the same thing here. So I built Genraggle in the same spirit, by reading the paper closely and replicating the architecture as faithfully as the published tools allow. It sends a query to Gemini with the paper’s system prompt and a single Google Search tool, lets the model search and plan, and renders the page it writes inside a Google-style results page, with a panel beside it showing every search the model made and what came back.
The prompt and the tool
The paper’s Appendix A.5 contains the full system prompt, roughly 2,450 words once the page numbers are stripped, and I use it verbatim apart from filling in the date and location placeholders. I made two additions that are not in the paper and are labeled as such in the code. The first is a Google results page style variant, which uses the same mechanism the paper uses for its “Classic” and “Wizard Green” styles. The second is an instruction to cite each fact with a link to the search result it came from, because the paper’s screenshots show citations but its prompt never asks for them, and I needed to see which retrieved pages end up on the generated page.
The model gets one function, google_search, backed by Serper, and it can call that function as many times as it needs before it writes the page.
Images work the way the paper describes. The model writes ordinary <img> tags that point at /image?query= for real photos of named things and /gen?prompt= for generated illustrations, and the browser fetches them directly from small endpoints on the same server, backed by Serper image search and a Gemini image model. A short chain of post-processors then does the same kinds of cleanup the paper lists in Appendix A.6, including escaping image URLs, swapping hallucinated local icons for generated ones, and injecting the JavaScript that reports client-side errors.
Simulating poisoned SERPs
Genraggle has a switch for poisoned results, modeled on what Nozzle measured. When it is on, each result the model would have seen is swapped, at a rate you set, for a lower-ranked result from the same SERP, drawn from positions 11 to 30, and at higher levels the knowledge graph, answer box and People Also Ask blocks disappear. The model is never told, which is the point, because a poisoned SERP does not announce itself either.
This simulates the symptom and says nothing about how Google produces it. It exists so that we can ask a measurable question: when the retrieved set changes, what happens to the page that gets generated?
Like Raggle, this is a research artifact and not a production system. It has no Google index, no click data and no personalization, its search snippets are thinner than Google’s passages, its images come from different indexes, and it has none of the production feedback loop that the error reporter feeds at Google. A page also takes anywhere from one to three minutes to generate with the Pro model, which is slower than the minute or two the paper reports for Google’s own implementation, and the screenshots below came from the faster Flash model.
What the generated pages looked like
To see what the model builds when it is free to design the page, and how the SERP may evolve as a result, I ran Genraggle once on ten queries that have little in common. Every run used Gemini 3.8 Flash with no poisoning, and for each query the model decided for itself which interface the topic deserved and then wrote it. Here are the queries:
- how much does a kitchen remodel cost
- best project management software for small teams
- how to start a vegetable garden
- best laptops for programming 2026
- roth ira vs 401k
- things to do in lisbon for 3 days
- should i buy or rent a home
- how to train for a half marathon
- best coffee makers under $200
- nyc to boston train vs bus
The screenshots below show some of the interactive components it added, captured after I moved sliders, picked options and ticked boxes to confirm that they respond. Each one sits inside a results page, so I re-ran the kitchen remodel query and captured the whole SERP, with the Genraggle header and search box, the AI Overview and the generated calculator all on the same page.
Queries with numbers in them got calculators, and each screenshot below shows what the component is and what I think it does to the sites that used to answer the question. I did not check the math inside any of them, and a model writing its own financial calculator for a person who may act on it is exactly the situation where I would want someone to.
For “how much does a kitchen remodel cost”, the component is a cost estimator with a live total, which answers in one interaction the question that a remodeling cost guide spends a full article approaching. This is the clearest case of the generated page absorbing the job the ranking pages used to do: the reader gets a number without visiting the contractor, home-improvement or marketplace sites that supplied the cost ranges, and those sites are left feeding a tool that sends them very little traffic.
For “roth ira vs 401k”, the model wrote a simulator with sliders for contribution, time horizon and return and a comparison of after-tax value. Personal finance publishers have long used calculators like this to earn links and email signups, so a generated version on the results page competes with their strongest asset, and it puts the model’s assumptions in front of the reader without the editorial review those pages carry.
For “should i buy or rent a home”, the model added a breakeven simulator with a verdict panel, which turns a question that used to send people through several articles and a spreadsheet into one interaction on Google’s page. The open web loses the visit and also the framing, because the assumptions that decide the verdict now belong to the model and not to an author a reader can evaluate or hold accountable.
Queries about choosing between options got comparison tools. The New York to Boston page sorted the options into cards with filter chips for fastest, cheapest and most traffic-proof, and it added a button to simulate a route delay. The Roth page added a comparison table with a selector that highlights one column, and the laptops page added a compare tray that collects whichever machines you pin from the results. The coffee maker page put recommendation cards inside its AI Overview, each one labeled with a role such as best value drip or best budget espresso and linked down to the relevant result.
For “nyc to boston train vs bus”, the model built an at-a-glance comparison with filter chips and a card for each way of making the trip. Travel aggregators and transit sites spend years tuning exactly this layout, and when it appears on the results page the reader may never need the operator’s own schedule or booking page, which pushes those sites toward being the data source behind the comparison and not the destination.
The same “roth ira vs 401k” page also got a side-by-side comparison table with a selector that highlights one column. It replaces the head-to-head comparison article by restructuring the sources into a table the model designed, so the publishers whose pages supplied each cell are cited in the margin and not read.
For “best coffee makers under $200”, the AI Overview itself carried labeled recommendation cards that link out to the full reviews. This is the friendliest of the components for the open web because the links point outward, but the cards decide which reviews get seen and how each one is summarized, so review sites now compete to be a card and not simply to rank, and a site described poorly in its own card loses the click either way.
For “best laptops for programming 2026”, the model added a quick compare tray that collects the machines a reader pins from the results. It makes Google the place where the comparison happens, which moves the product-comparison step, where affiliate publishers and retailers earn most of their revenue, off their pages and onto the results page.
Nine of the ten pages loaded and responded the way I expected, while one, the half marathon page, had a JavaScript error that left part of its training schedule blank, which is a reminder that a generated page can simply be broken for the person who receives it. Each of these is a single sample from a single run, and a second run of the same query would likely produce a different set of components, which is the measurement problem this post is about. The Lisbon page, which turned a travel query into a three-day plan builder, is the one I think shows where this goes next.
For “things to do in lisbon for 3 days”, the planner is the most personal of the components, with day tabs, a checklist that crosses off stops and a budget estimator the reader can change. It is also the best preview I have seen of hyperpersonalization on the core SERP, a page rebuilt around the traveler and not the query, and for the open web it means the travel blogs and guides whose itineraries the model learned from are replaced by a plan the reader never has to leave.
Taken together, these ten pages are why I think the probabilistic SERP is a paradigm shift and not a new feature layered onto the old one. For twenty years the results page was a ranked list that we could treat as a fixed object, and everything we built, from rank tracking to click-through models to the way we talk to clients about position, assumed that the list existed and could be read. A page that a model composes for each query, chooses the components for, and rebuilds for each person is a draw from a distribution, and users prefer that draw to the top-ranked result in most of the paper’s comparisons. When the interface itself is sampled, the unit that matters is no longer the position but the probability of being retrieved, cited and used across many samples, and the work of measuring and defending that probability is what the rest of this post is about.
How we move forward
A probabilistic SERP changes what we can honestly claim, so the practical response is to treat every observation as one draw from a distribution and to build our collection and reporting around that distribution. These are the changes I would make first.
- Take several samples a day and judge each against the last verified one. Compare each new capture of a keyword with the previous verified capture, flag any that swapped out most of the usual page-one sites as poisoned and set it aside, because Nozzle found that 80% of poisoning spells last a single SERP.
- Report visibility as a rate with its spread. For each query that matters, record how often the client is retrieved and how often it is cited, each with a confidence interval across different days and locations, since a figure with a spread is more honest than a position with a date on it.
- Use average position only as a trend. Search Console’s average position is a mean across many SERPs, none of which any searcher saw as “7.3”, so the daily roll-up of verified captures should be read the same way.
- Sample the generated surfaces directly. Run each query many times in Google and report the share of runs that retrieve or cite the brand, which is how genAI tracking already works and which fits what I laid out in my accuracy vs. precision post, that with no true value to check against, what earns trust is precision from repeated collections under controlled conditions.
- Segment by what changes the page. With hyperpersonalization we need to run the same keyword across locations and personas and treat the spread between segments as a finding, not as noise.
- Anchor every tracker to Search Console and referral traffic. Between personalization, per-query generation and whatever Google is doing to suspected scrapers, a rank tracker sees one slice, so if impressions and clicks hold steady while a tracker shows a crash, question the tracker, because a real ranking change tends to persist.
- Stress-test with a simulator. Genraggle lets you perturb the retrieved set and see what the page does, which is the quickest way to learn how much a citation depends on the exact results the model was handed.
No matter what we do, we should expect the price of rank tracking to go up significantly.
This is just the beginning
A generative SERP gives Google a results page that can be personalized, rebuilt for every query and, if my read is right, quietly degraded for traffic it does not trust. The history points in that direction. In September 2025 Google posted a role titled Senior Engineering Analyst, Search, Anti-scraper, which covered investigating abuse patterns, building countermeasures and measuring how well the defenses work. Google sued SerpApi in December 2025, and when a court dismissed the broad claims in July, the fight moved to the technical layer, where we have since seen goto redirects, blocked IPs and rank trackers returning bad data and, according to Nozzle, poisoned results served to suspected scrapers. My read is that generative UI is what makes this practical, because a model that composes the page can hand a request it distrusts a thinner or reshuffled page, and nothing about that page looks like a block.
If the trajectory holds, I expect Google to move from blocking suspected scrapers to degrading what they see by degrees, with a trust score for each request in place of an on and off switch, and a generated page makes that cheap because a thinner answer can still look complete and cited. Hyperpersonalization will blur together with suspicion, so a drop in a tracker will not tell us which one caused it. Trackers will answer with more sophisticated collection, which will produce yet another disagreement between vendors, like the one already visible between Ahrefs, Semrush and Sistrix on the same spam update, and I suspect the reputable vendors, who have to stay traceable, will be hit hardest, which would make the tools willing to evade detection the least trustworthy ones.
The work of earning retrieval does not change, but how we prove that we earned it does, and I expect that to be the part of our discipline that gets rebuilt first.
