How to Build a Keyword Map for Existing and Planned Pages

When you manage a website, a keyword map helps you decide which page should serve each search need. It connects groups of related searches to existing or planned URLs. Those connections show gaps and clarify each page's purpose, so you can avoid creating pages that repeat one another.

A search need, also called search intent, is what a person wants to learn or do when they search. Map pages to those needs rather than assigning one page to each exact phrase. Search data can show which pages appeared for particular queries, but a map does not guarantee that a page will be indexed or rank.

Map search needs to page decisions

A useful keyword map records related queries, the page that best serves them, and why you assigned them to that page. It helps you plan pages and find gaps; Google does not require this format.

A page can address several queries when they call for substantially the same answer. For example, searches phrased as “keyword mapping” and “how to map keywords to pages” could belong to one page if the search results and the content needs point to the same task. A different phrase deserves a separate page when it signals a distinct need that the existing page does not satisfy.

Use a spreadsheet or database to record each decision. Include the URL or proposed URL, page purpose, and topic group. Then add a representative query, related queries, evidence, planned action, and relevant internal links. For a planned page, also record what useful information it will add that existing pages do not provide. These fields make the map useful for decisions rather than just a keyword inventory.

Gather evidence before assigning URLs

Start with the pages your site already has. Combine a crawl, which checks your site's URLs, or a content inventory with your sitemap and, where useful, a CMS export. Flag redirecting URLs, duplicate versions, and pages that are not intended to appear in search. A sitemap helps Google discover URLs, but it does not guarantee that Google will crawl or index them, as Google’s search documentation explains.

Next, look at search performance. In Google Search Console’s Performance report, filter for a query and open Pages, the report view that lists the URLs Google showed for it. Clicks and impressions help show whether a page has appeared and attracted visits. They do not explain why Google selected that URL or prove that it is the best page for every related query. Google recommends examining performance trends, rather than treating average position as a fixed rank a person will see in every search. See the Performance report overview and its common tasks and use cases.

Search Console data also has limits. Google hides some queries to protect searchers' privacy and limits the number of rows shown in the table, so the visible query list is incomplete. A missing query does not prove that nobody searches for it or that your site has no relevant page. Check the report’s data-discrepancy guidance before treating small differences or gaps as decisive evidence.

Keyword tools offer another input, with their own limits. Google Ads Keyword Planner estimates average monthly searches based on settings such as location and Search Network. It also groups close variants, or searches with similar wording. Its competition measure describes competition among advertisers; it tells you about paid-search competition rather than organic SEO difficulty. Treat volume as a clue about demand. It does not forecast organic visits, and volume alone does not justify publishing a page. Google describes these limits in its guidance on Keyword Planner forecasts.

Assign existing pages by purpose

For each query group, ask what the searcher needs and which current page delivers that answer most clearly. Search Console can reveal URLs that have appeared for a query; reviewing the actual pages tells you whether those URLs serve the same purpose or different ones.

For example, an illustrative home-services site might have one page about emergency plumbing and another about water-heater installation. Those pages cover related services, but they serve different tasks. If a broad “plumbing services” page also mentions both, that alone does not mean it should replace the focused pages. Decide based on what information the visitor needs and whether each URL contributes distinct value.

Record an action for every mapped page: keep it as is, improve it, consolidate overlapping content, redirect a retired URL, or plan a new page. If you choose to consolidate, preserve the URL that best fits the ongoing purpose and handle the old URL deliberately. Do not merge pages merely because they share a word or appear for the same broad topic.

A practical check is to compare page purpose, page type, and the results shown for representative queries. Search results are a snapshot and vary with context, so overlap can inform a decision but does not supply a universal merge threshold. More than one of your URLs appearing for a query is a reason to investigate, not proof of harmful “keyword cannibalization.”

Search-result data also needs validation before you compare URLs. In one US English Google organic-results snapshot on November 11, 2026, eight queries returned 65 rows; 63 of the listed URLs were Google redirect wrappers rather than direct destination URLs. Comparing the raw URL strings showed no overlap, but unresolved wrappers did not establish that the destination pages had no overlap. The useful conclusion was that destination overlap could not be determined from those fields. Check that a data export contains usable destination URLs before relying on it to group queries or diagnose competing pages.

Plan new pages only for distinct needs

A keyword tool can suggest a phrase, but it cannot decide whether your site should have a page for it. First check whether an existing page already answers the need. If it does, improve that page when an update would make the answer clearer or more complete.

Plan a new URL when the need is distinct and the site can provide useful information or a service that the existing pages do not. Record its purpose and likely internal links before publication. If you cannot explain what a new page will help a reader do or understand, the phrase alone is not a strong reason to add it. Google’s people-first content guidance cautions against publishing content primarily to attract search traffic without adding value.

Keep a planned-page row marked as planned until the URL exists and you have checked it. After launch, use Search Console’s URL Inspection tool to review reported information about crawling and indexing, including which URL Google treats as the main version when duplicate or very similar pages exist. Inspection can help diagnose a page’s status, but indexing still does not guarantee that Google will show it for a particular query. See Google’s guidance on inspecting a page.

Check the page and its connections

A topic assignment only helps if the page supports it. Make sure the title describes the page accurately and distinctly. Google may generate a different title link in search results when it judges the supplied title inaccurate or unclear; repeating a target phrase does not ensure that Google will use the title you wrote. See Google’s recommendations for title links.

Check that important pages have relevant internal links. A descriptive link from a related page helps visitors understand where the link leads and helps Google discover the destination. The link should fit its sentence naturally; the map does not require repeated exact-match anchor text. Google explains how to create crawlable links.

Also check whether duplicate or near-duplicate URLs point to the version you intend Google to use. A canonical URL is the preferred version among duplicate or very similar URLs. Google treats redirects and rel="canonical" annotations as strong signals, while sitemap inclusion is a weaker signal. Use these signals for duplicate URL versions, not to force two genuinely different pages into one. Google details these signals in its guidance on consolidating duplicate URLs.

Review the map as the site changes

Revisit assignments when you update content, publish a new page, or see a meaningful change in query and page performance. Compare similar date ranges when possible, and note the period and evidence behind each change. Search Console’s query data is incomplete, and its reported page can reflect Google’s chosen canonical rather than the duplicate URL a visitor reached. Treat the map as a working record of decisions, not a complete account of every search or URL relationship.

For example, if two URLs appear for one query, inspect their content and purpose before consolidating either. If the pages answer different needs, keep the distinction clear. If they substantially repeat the same answer, decide whether one page should take over and update links and redirects accordingly. A data pattern can identify what to review; it does not establish the cause or the right fix by itself.

Google says that its standard SEO practices remain relevant to AI Overviews and AI Mode, with no additional requirements or special optimizations for those features. A map organized around clear reader needs and related topics supports sound content planning, but Google’s guidance does not establish that a particular map increases the chance of selection in an AI-generated answer. See Google’s guidance on AI features.

Key Takeaways

• Map needs to pages: Group queries when they call for substantially the same answer, and separate them when the reader’s task or the page’s purpose is distinct.
• Use Search Console as evidence: Filter by query and inspect the Pages dimension, while remembering that reported queries are incomplete and do not reveal why Google selected a URL.
• Require a reason for new pages: Publish a planned URL when it adds useful value for a distinct need, not just because a tool lists another phrase.
• Check before consolidating: Multiple URLs appearing for a query signal a need to investigate, not proof that they harm one another.
• Verify the underlying URLs: Resolve redirect wrappers and check canonical, indexability, titles, and internal links before drawing conclusions from a map.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com