Before you build a page for that keyword, run three checks

Keyword tools are built to find opportunities, so they find them. Closely related terms get split into separate rows, each carrying its own volume figure, and the arithmetic appears to point one way: a page for every variation.

The bill arrives after publication. Each URL then needs a defensible place in the site's structure and enough distinct value to stay worth keeping. When several pages address the same underlying need, they compete for the same queries and split the visibility the site had already earned.

A keyword earns a page of its own on three conditions. It can pull in a distinct set of queries, it can support content that is genuinely different, and it makes the site's structure stronger rather than more crowded. Each of those can be tested before anything gets built.

The first check costs nothing and frequently ends the discussion. Open Search Console, find which page currently appears for the keyword, then look at every other query that URL is picking up. That tells you two things: whether Google already regards the page as relevant to the wider topic, and whether more than one of your pages is chasing the same set of searches.

Take a SaaS company weighing a page aimed at CRM for freelancers. It may already be collecting impressions on freelancer searches through the CRM for small businesses page it has. If it is, the question is no longer whether to build the new page but whether the current one can serve those visitors more clearly. Publishing a second URL at that point spreads relevance across two similar pages instead of concentrating it in one.

The same check surfaces cannibalisation. If two of your URLs keep displacing each other for the same searches, the site already carries more overlap than it can support, and adding a third makes the tangle harder to unpick.

By the end of this step you are choosing between three routes: expand what exists, consolidate what overlaps, or carry the keyword forward to a proper independence test.

That test rests on three separate kinds of evidence, and any one of them alone is thin.

Start with how Google itself treats the two queries. Pull the top ten organic results for the candidate keyword and for the primary keyword of the nearest existing page, and set them side by side. The number of URLs appearing in both is the signal — the more the two sets share, the more Google is treating the searches as versions of one need.

Suppose a company already ranks for invoice software for small businesses, now wants a page targeting invoicing software for freelancers, and finds that seven of the ten results are common to both. That is a strong hint the two needs overlap in Google's view. The productive question then is whether the existing page can absorb what freelancers specifically want — recurring invoices, expense tracking, the tax records someone operating alone has to keep — without losing its focus. If those fit naturally, expanding is the cheaper and safer answer.

A separate page becomes easier to defend when the two result sets diverge and the product genuinely supports a distinct freelancer workflow. Dedicated features and real customer examples strengthen the case further.

Do not stop at counting shared URLs, though. Look at what kind of page Google is rewarding in each set. If one query returns category pages while the other returns individual product pages, that difference can justify two URLs even when several results appear on both.

The second kind of evidence comes from writing the outline before writing the page. A keyword can look convincingly distinct inside a research tool and still produce something that reads like a page you already have. Drafting the headings and setting them next to the closest existing page exposes that quickly.

The questions to ask are whether the new page tackles different problems, and whether it needs evidence and examples of its own.

Consider a vendor targeting CRM for real estate agents alongside CRM for mortgage brokers. The first page has real material: capturing leads from property portals, pipelines for buyers and for sellers, matching properties to people, following up after an open house. The second has entirely different material — application stages, document collection, communication with lenders, and the compliance workflow wrapped around all of it. Those pages can stand apart, provided the product actually supports both processes and the difference can be shown through screenshots, integrations or named customers.

Where both outlines lean on the same feature set and repeat the same claims, the honest answer is one broader page with a section for each audience.

The outline exposes something else worth catching early: whether the page needs its own conversion path. A page written for mortgage brokers might lead to a demo built around document handling, while a general CRM page leads to a product tour. A different next step is a good sign the page has a role of its own.

The third check is structural. Decide where the page will live before anyone writes it. Name its parent, name the sections that will link to it, and then ask whether somebody browsing the site could find it without going through Google first.

An ecommerce team planning a category for women's waterproof trail running shoes has a strong case when enough products match, inventory is stable, the page sits naturally under the broader women's trail running category, and buying guides and adjacent categories can point at it. The case collapses when two products match and availability moves week to week. An indexable URL is then just a thin page somebody has to maintain, and a filtered view inside the parent category does the job better.

The logic transfers to SaaS. An industry page should slot into the existing product and solution hierarchy and draw support from related use cases or customer stories. If the only internal link you can find for it is from one ageing blog post, the page is sitting outside what the business actually sells.

The case is strongest when all three checks agree: Google separates the queries, the content stands on its own, and the site has somewhere to put it. When the evidence comes back mixed, take the least disruptive option available and review the result before committing to another permanent URL.

Four outcomes are possible, and only one of them is a new page.

Build one where the keyword shows its own search pattern and the page has a clear job to do. A security firm with a broad penetration testing services page has a good case for a cloud penetration testing page if the results are full of specialist cloud providers and dedicated service pages, and if the firm can describe a different testing process, address risks specific to cloud environments, and support the page with case studies. The URL should sit beneath the broader service and collect links from related cloud pages.

Expand what you have when the existing page already earns visibility for the keyword and the topic fits its remit. A payroll platform whose product page is already picking up impressions for payroll software for contractors can add sections covering how contractors are brought on, when they get paid, and what tax paperwork the platform produces. Afterwards, watch whether those queries settle there. Revisiting a separate URL makes sense later if the query develops a pattern of its own, or if the product gains a dedicated contractor workflow.

Merge when several URLs chase one cluster and none of them has a distinct purpose. Three pages — one for employee onboarding software, one with the word digital in front of it, one with the word online — are the standard example. If their results overlap heavily and they keep swapping places, they are dividing relevance between them. Consolidation should keep the strongest material from each, point internal links at the surviving page, and redirect the others where that makes sense.

Use a template when demand genuinely repeats — across integrations, locations, product categories or structured data. A project management tool building pages for Slack, Salesforce and Microsoft Teams needs each one to carry specifics: setup steps, the workflows it supports, screenshots, the use cases people actually have. Launch a handful first and check indexing, which queries they attract and how people behave on them, before generating the rest.

Publishing a page is a hypothesis rather than a conclusion. Set a review date far enough out that the URL has been crawled, indexed and given time to gather enough impressions to show a pattern.

Then go back to Search Console. A page that has earned its place will be accumulating a recognisable cluster of queries, and those queries will stay with it rather than bouncing between URLs. Compare it against whichever page previously covered the topic; if both keep turning up for the same searches, their roles are still blurred, and the titles, internal links and content focus need sharpening.

Finally, check whether visitors do the thing the page was built for — request the demo, browse the products, start the trial, move deeper into the site. A page can attract its own queries and still fail at the job it was created to do, and that is worth finding out before the next fifty keywords come out of the tool.