Transcript
Intro
Ask Google's Deep Search one question and, by Google's own description, it can fire off hundreds of searches before it answers. Your site gets measured against all of them. Most sites respond in one of two bad ways: one thin page that answers almost nothing, or a separate page for every possible question. Both lose, and today we fix it.
This episode gives you a rule for deciding, for any query, whether it gets a page, a section or nothing, and a clean way out when several pages fight over one intent.
Templates and answer types
First, stop looking at queries one at a time. Dune Part Three release date is one query, but it's also one instance of a pattern: a film, followed by release date. In our thirty film pull from the attribute episode, release date showed up for twenty two films. That's one template, asked twenty two times.
Thinking in templates changes the question you ask. Not does this query deserve a page, but does this template deserve a page type. If it does, every film gets one, built the same way. If it doesn't, it becomes a section in an existing page type, and you never write a one-off page for it again.
Templates also nest. In the Dune Part Three suggestions we pulled on the nineteenth of October 2026, release date came in UK, Japan and US versions. That's a second template, film plus release date plus country, and it tells ReelRadar something useful: the release dates page should be a table by country, not one lonely date.
Do this for every template in your niche and you get a short table that runs the whole site. For ReelRadar, film plus trailer is a page type, film plus where to watch is a page type, and film plus release date plus country is a page type. Film plus cast is a section. Director plus movies ranked is a list page in the outer ring, and box office gets nothing.
Next, the type of answer. Some queries want an entity back: who directed Dune Part Three wants a name, and the name is Denis Villeneuve. Others want a description: what is it about wants a few sentences. That split is our working model, and it shapes the page more than the topic does.
Entity answers are short and they belong near the top: a date, a name, a list of services. They rarely deserve a whole page, unless the value is complex, like dates across many countries. Description answers need room, and they're where a page can show judgement, so they make better candidates for a page of their own.
The classic mistake is answering an entity question with a description. Someone asks when the film comes out, and the page opens with three paragraphs about how long fans have waited. The date is in there somewhere, but the searcher has already gone. Value first, story second.
You can usually read the answer type off the results before writing a word. A short fact on top means an entity answer. Video results mean people want to watch something. A list of articles means a description. Build your page in the shape the results already show.
Fan-out
Now back to the opening. Google says AI Mode uses a query fan-out technique, breaking a question into subtopics and searching for them all at once, and Deep Search takes the same technique further. Google's documentation says AI Overviews may fan out too, across subtopics and data sources.
That changes what coverage means. A page that answers only the head question, when is Dune Part Three out, gives the system one passage to use. A page that also answers the follow-ups, how long it is, which book it adapts, which formats it's shot for, gives it several. Follow-up questions used to be the long tail. Now they're the shopping list.
There's a trap on the other side, and Google has named it. Its 2026 guide to generative AI search says that creating separate content for variations such as fan-out queries, mainly to manipulate rankings or AI responses, violates its scaled content abuse policy. So the answer to fan-out is better pages, not more pages.
That gives you a simple stance. Answer follow-up questions where a reader would expect them, inside the page that owns the main intent. Give a follow-up its own page only when it's a real intent with its own demand, not because a machine might search for it.
So where do you find the follow-ups? Autocomplete, which we're about to use. The people also ask boxes on the results page. And the follow-ups AI Mode suggests after it answers. Collect them per template, not per page, and you've got the section list for each page type.
Page, section or nothing
Let's do it live. We pulled Google's autocomplete for Dune Part Three on the nineteenth of October 2026: the plain query, plus one request for every letter of the alphabet. That gave us two hundred and fifty one unique suggestions. Now we sort them for ReelRadar into three piles: own page, section, or nothing.
Own pages first. The film page itself, for plot and synopsis searches. A trailer page, because trailer, final trailer and teaser all want a video. A release dates page by country, for the UK, US and Japan versions. And a where to watch page for streaming and HBO Max searches, a placeholder today that becomes the most important page on the day the film leaves cinemas.
Sections next. Cast, including searches for individual actors, and runtime, including how long is the movie. Age rating and parents guide, and which book it's based on, which people asked in several different ways. Formats like IMAX, seventy millimetre and Dolby, and the soundtrack. Each is a real question, and each is worth a few lines on the film page.
And nothing. Box office predictions belong to a different kind of site. Popcorn buckets, collectible figures and eBay listings are shopping. Wallpapers and logo files aren't ReelRadar's business, and searches naming one particular cinema belong to that cinema. Searches for leaked footage get nothing, on principle.
Some suggestions sit right on the line, and that's where judgement earns its pay. Tickets is a big intent, but ReelRadar doesn't sell them, so it becomes one line linking out to cinemas. Versus Avengers Doomsday compares two December films, which belongs in a release calendar, not on the Dune page.
Here's the decision tree behind every call we just made. If a query doesn't fit the site's purpose, it gets nothing. If it's the same intent as a page you already have, it's a section on that page. Only a query with its own demand, its own intent and its own kind of answer gets a page.
Try the tree on a different niche. A dental clinic sees searches for implant cost, implant cost per tooth and how much are dental implants. Same intent, three phrasings, so that's one page with a clear price section. Implant recovery time is a different question with its own answer, so it's a section, or a page if the demand is big. Implants versus bridges is a comparison, and comparisons usually earn their own page.
Two pages, one query
Now the mess this tree prevents. Meet an earlier ReelRadar, before it had a plan, in example data. Search Console, one query, dune part two streaming, over ninety days. Six different ReelRadar URLs collected impressions for it, and that's never a good sign.
One page leads: the where to watch guide. Behind it stands a crowd of near twins. Is Dune Part Two streaming yet, Dune Part Two digital release date, how to watch Dune Part Two at home, and a streaming guide that nobody on the team remembers writing. Same question, four different outfits.
Now watch it over time. Each day we took the URL in the best position for that query. Across ninety days, the top URL changed thirty one times. Google kept trying a different twin in the slot, because ReelRadar kept offering it a different twin.
And the clicks show the cost. Four hundred and ten clicks in ninety days, spread across five pages. The runner-ups sat at average positions between eleven and nineteen, where hardly anyone clicks, and every one of them answers the same question as the main page, only slightly worse.
That's cannibalisation in its real form. Not two pages that happen to share a keyword, but many pages written for one intent, each a slightly reworded version of the same question. Every new twin gives Google another candidate to test, and none of them builds up the clicks and links the main page needs.
Notice the one page that doesn't belong in the crowd: Dune Part Two on 4K Blu-ray, with the disc extras. It showed up for this query too, but it answers a different question, owning a copy rather than streaming one. That page stays. Sorting by intent, not by shared words, is the whole skill.
How does a site end up like this? In our experience it usually starts with a keyword export. Every variant of a question gets its own short article, each one sensible on its own, and nobody steps back to notice they all answer the same thing. That's the page-per-keyword habit, and it's exactly what the decision tree is there to stop.
Merge or split
So here's the rule we use. If two pages serve the same dominant intent and give the same answer, merge them: move anything useful from the weaker page into the stronger one, then redirect the weaker URL. If they serve different intents, or the same entity from different angles, keep them apart and make each one clearly about its own question.
Why a redirect? Google's documentation calls a redirect a strong signal that the target should become the canonical. For ReelRadar's twins, that's the fix: fold the streaming variants into the where to watch guide, redirect each old URL to it, and leave the Blu-ray page alone, because it has a different job.
A merge has a few steps that people skip. Pick the survivor by clicks and links, not by which page you like. Move anything genuinely useful across. Point every internal link at the survivor, redirect the old URLs, and take them out of the sitemap. Then watch that query in Search Console for a few weeks and see the swapping stop.
Check your internal links while you're there, because they often start the fight. If half your site links to the streaming yet page with the anchor where to watch, you're telling Google the twin is the answer. After a merge, every internal link to the topic should point at the survivor, with an anchor that matches its job.
Films have a classic split case too. A film is a work, with a plot, a cast and a director. It's also a product, with formats, prices and places to watch it. One page can hold both while demand is small. When where to watch grows into a big intent of its own, it splits off into its own page, and the two pages link to each other.
And sometimes two pages for one keyword is simply fine. When a query mixes intents, one page can answer one part and another page the other. Google said in 2019 that it usually shows no more than two results from the same site in the top results, with exceptions when they're especially relevant. Two good results serving two different needs is a win, not a problem.
The test that separates the two cases is stability. If both pages hold steady positions and each earns clicks for its own reason, leave them alone. If the top URL keeps swapping, positions sag and neither page earns much, you've got one intent split across several pages, and it's time to merge.
To find these on your own site, open the Performance report, filter to one important query and switch to the Pages tab. More than one page with real impressions is your first flag. Then compare by date, and if the page with the most impressions changes from week to week, look closer.
Rule out one false alarm first. Sometimes the Pages tab shows a homepage twice, once on https and once on an old http www address. URL Inspection will report the old address as a page with a redirect, with the https version chosen as canonical. That's two addresses for one page, which is housekeeping, not cannibalisation.
Two claims on trial
Claim one. One keyword, one page. Every keyword you target gets exactly one page, and every page gets exactly one keyword.
The unit is wrong. A page serves an intent, and one intent covers dozens of keywords: ReelRadar's streaming twins were one intent written five ways. Meanwhile one keyword can carry two intents, and two pages can serve it well. A page per keyword is exactly how a site builds a crowd of twins. Placebo.
Claim two. Fix cannibalisation with a canonical tag. Point the weaker page at the stronger one and the problem goes away.
Google describes canonicalization as choosing the representative URL for duplicate or very similar pages. Two pages answering one intent in different words aren't duplicates, and Google says it may pick a different canonical than the one you set. Meanwhile both pages stay live, confusing readers and your own internal links. Same intent means merge and redirect, and different intents need different jobs, not a tag. Placebo.
Wrap up
Here's the episode on one screen. Queries are templates, and templates decide page types. The answer type decides the page's shape. Fan-out rewards follow-up coverage inside the right page, not a page per sub-question. And many pages for one intent get merged, not tagged.
The query to page decision tree is free on the episode page at irongoo.com. Next time, we write the pages themselves, so the right answer comes first and machines can read them without you writing for robots.
