A use case deserves its own page when the people in it have a need your other pages do not answer, and you can show evidence that is true for them and not for everyone else. If the only thing that changes from one page to the next is the industry name, the town or the job title, the use case belongs in a section of a broader page, or nowhere yet.
That test is stricter than “could someone search for this?”. Almost any combination of product, industry and place could be searched for. The useful question is whether a separate page would tell that reader something the rest of your site does not.
Why near-duplicate pages are a poor bet
Google’s spam policies describe two patterns that variant pages can fall into. Scaled content abuse is “when many pages are generated for the primary purpose of manipulating search rankings and not helping users”, no matter how the pages are created. Doorway abuse includes pages aimed at specific regions or cities that funnel users to one page, and “substantially similar pages that are closer to search results than a clearly defined, browseable hierarchy”.
Google has also addressed this for AI features directly. Its guide to generative AI search says that creating separate content for every possible variation of how people might search, including fan-out queries, “primarily to manipulate rankings or generative AI responses” violates the scaled content abuse policy, and that a high quantity of pages doesn’t make a website higher quality or more relevant to users. The same guide asks for “non-commodity” content: material that goes beyond common knowledge.
Rewording does not solve this. The scaled content policy’s examples include generating many pages through automated transformations such as synonymizing where little value is provided, and Google’s guidance on generative AI content says using AI tools to generate many pages without adding value for users may violate the scaled content policy. A page made distinct by vocabulary alone is still the same page.
None of this says use-case pages are bad. A clinic, a law firm and a retailer often have genuinely different problems, and a page that addresses one of them well is the kind of content Google’s people-first questions describe: does it provide original information, and does it offer substantial value compared with other pages? The rubric below is a way to answer those questions before a page exists.
A publish, combine or decline rubric
Score each proposed page against five questions. Answer from material you have, not material you intend to write.
| Question | What a “yes” looks like | What a “no” looks like |
|---|---|---|
| 1. Is the need distinct? | This audience asks something others do not: a different workflow, constraint, integration or regulation. | The questions are the same as on your general page. |
| 2. Does the swap test fail? | Replace the use case name with a sibling (another trade, another city). Several sentences become false. | Every sentence is still true after the swap. |
| 3. Is there unique evidence? | A feature, integration, setup step, pricing term or documented customer example that applies here specifically. | Only general claims about the product. |
| 4. Do buyers ask for it? | The use case appears in sales calls, support tickets, lead forms or Search Console queries. | It came from a keyword list or a template. |
| 5. Will someone keep it true? | A named owner checks the page when the product or the facts change. | Nobody would notice if it went stale. |
The decision follows from the answers:
- Publish when questions 1 to 3 are all “yes” and at least one of 4 and 5 is too.
- Combine when the need is real but small, or shared with other use cases. Cover it as a section of a broader page, or organize one page around the shared workflow instead of the audience.
- Decline when the need is not distinct or the evidence does not exist yet. Write down what would change the answer.
The second question does the most work. Generic copy survives the swap test because it was never about the use case in the first place.
The rubric applied to four fictional use cases
Crewpost is an invented scheduling product for trade businesses. The four proposed pages, the evidence and the decisions below are illustrative. They are not real data or Seenvero customer data.
| Proposed page | Distinct need? | Swap test | Unique evidence available | Buyers ask? | Decision |
|---|---|---|---|---|---|
| Crewpost for heating and cooling contractors | Yes: recurring maintenance-contract visits and seasonal peaks | Fails: contract visit rules do not apply to most trades | Recurring-visit feature with a documented setup; a supplier catalogue integration; one approved customer example | Yes, in sales calls | Publish |
| Crewpost for plumbers | Partly: emergency call-outs, which electricians share | Passes: swap “plumbers” for “electricians” and the draft stays true | Out-of-hours dispatch, which is not specific to plumbing | Yes | Combine into one page on emergency call-out dispatch |
| Crewpost in each of 30 towns | No: the software works the same everywhere | Passes for every town | None that differs by town | No | Decline |
| Crewpost for property managers | Yes: tenant access windows and billing per building | Fails | None yet: per-building billing is planned, not shipped, and no customer uses it | Occasionally | Decline for now, revisit when the feature ships |
Each page that survives needs its own evidence list before writing starts:
| Page | Evidence that must be on it |
|---|---|
| Heating and cooling contractors | How a maintenance contract becomes scheduled visits, with screenshots of the actual setup; what the supplier integration syncs and what it does not; the approved customer example with its scope and date; limits, such as contract types the feature does not handle. |
| Emergency call-out dispatch | How out-of-hours jobs are assigned and who is notified; response-time data only if Crewpost measures it; examples from plumbing and electrical work, each labelled as which trade it comes from. |
The town pages show why location is a special case. For a business with a real office, staff or service conditions in a place, a location page can carry distinct facts: an address, opening hours, a local team, coverage limits. For software that works identically everywhere, 30 town pages would carry 30 copies of one message, which is the doorway pattern Google describes.
Decide the structure before writing
A combined page is not a consolation prize. “Emergency call-out dispatch” answers a question that plumbers, electricians and locksmiths all ask, and it can be more useful to each of them than three thinner pages. It also gives one URL the evidence that would otherwise be spread across several.
If you already have overlapping pages, choose the one you want to keep and merge the useful material into it. When you retire a duplicate, Google’s documentation says a permanent redirect signals that the target should be the canonical URL, and that redirects are the method to use when you want to get rid of existing duplicate pages. Point the redirect at the page a visitor to the old URL would most want, not at the homepage. A later article in this series covers auditing a whole site this way.
The same reasoning applies to a single customer question. Our article on whether a question deserves an FAQ entry or a full guide uses a similar test at a smaller scale.
Check how AI answers treat the use case
Before publishing a use-case page, look at what assistants say when a buyer in that situation asks for options. Write the question the way the buyer would: “Which scheduling software handles maintenance contracts for a heating firm with eight engineers?” rather than a keyword.
In Seenvero, you can track such questions as prompts, grouped into topics with the country each is asked from, and see per-prompt visibility for your own brand. The Sources view shows which domains and pages answers cite on the questions you lose, so you can see whether assistants are reading a competitor’s dedicated page, a general directory or your own general page. These are questions you chose, not observed customer searches or search volume.
What you find is an observation, not a rule. If answers to the heating question cite pages that explain contract scheduling in detail, that tells you what evidence readers are being given. It does not prove that a dedicated page is why those pages were cited, or that yours would be. Record the questions and their answers before the page goes live, so you can compare the same prompts afterwards.
Publish, then check it was worth it
None of the Google guidance cited here gives a safe number of pages or a safe publishing speed, so do not plan around one. Plan around the rubric: publish the pages that pass, and do not publish the ones that fail just because a template makes them easy.
After a page is live, check that it is indexed, that it is linked from the pages where a reader would want it (see our article on connecting guides to product evidence), and whether it starts to receive the visits and enquiries the use case was supposed to bring. If it is not indexed, look at the page before looking for a technical cause: is it actually distinct from your other pages?
See how questions, answers and cited pages fit together in Seenvero’s sample report, which uses an explicitly fictional brand, then run the five rubric questions on the next use-case page on your list.
Common questions
Is it safe to publish one location page per town we serve?
Only if each page carries facts specific to that place, such as a local office, team, hours or service conditions. Pages that differ only by town name match the doorway examples in Google’s spam policies.
Can AI help write use-case pages?
Yes, for research and drafting, as long as the facts come from you and each page is reviewed. Google warns that generating many pages with AI without adding value for users may violate its scaled content policy. The rubric applies however the page is drafted.
How many use-case pages should a site have?
As many as pass the rubric. Google says a high quantity of pages does not make a site higher quality, and there is no target number that makes a thin page useful.