How Do You Build a Keyword to Page Map for a Site You Inherited?

You have inherited a site with hundreds of pages. Where do you start?

Start with what the site already earns, not with what you think it should target. Pull the queries Google already sends the site, group them by landing page, and you have a map of what the previous owner actually built, whether or not they meant to build it.

Every time I take over a site, the first question is the same: which page is supposed to rank for what? Nobody who inherits a site can answer that on day one, and almost nobody who built it wrote it down. The map is how you find out.

This is a tutorial for that specific situation. You have access to Google Search Console, a few hundred pages, and no institutional memory. Here is how I do it.

What is a keyword to page map, and why build one?

It is a single sheet with one row per page and the queries that page is the best answer for. That is the whole artefact. Its value is that it converts a vague site into a set of commitments, so every later decision has something concrete to be measured against.

Without it you are guessing. You publish a new post and cannot tell whether it competes with something you already own. You rewrite a page and cannot tell what it was ranking for before. You delete something and find out three weeks later that it was the site's second best entry point.

With it, all three of those become five minute checks. The map is not a strategy document. It is closer to an inventory, and inventories are boring right up until the moment somebody asks what you have.

Where does the raw data come from?

Search Console, specifically the Performance report. Google documents that this report lets you group data by dimension, and the tabs above the table are Queries, Pages, Countries, Devices, Search appearance and Dates. The two you need are Queries and Pages.

Note the default window. Google states that the default view of the report shows click and impression data for your site in Google Search results for the past three months. Three months is usually too short for an inherited site, because seasonal pages and slow burners will not show up. Widen the range before you export anything.

If the site is large enough that exports become painful, this is the point where a bulk export into BigQuery pays for itself. Check Google's current documentation for the export row limits in the interface, because that limit is what decides whether you can do this in a spreadsheet at all.

How do you pull the pages and queries without drowning in rows?

Work page first, then query. Open the Pages tab, sort by impressions, and take the pages that account for the bulk of the site's impressions. Then for each of those pages, filter to that page and read its query list. You are sampling deliberately, not exporting everything.

The reason to go in this order is that a query first export gives you tens of thousands of rows with no structure, and you will spend your afternoon building pivot tables in Google Sheets or Excel instead of thinking. Page first gives you a shape immediately: a few pages do most of the work, and a long tail does almost none.

For each page, I write down at most five queries. More than five and you are recording noise. The exercise is to identify what a page is for, and a page that is genuinely for fifteen different things is a finding in itself, not a row to be filled in.

How do you decide which query owns which page?

The page with the most impressions for that query owns it, unless a better candidate exists and is simply not ranking yet. Ownership is a decision you are making, not a fact you are reading. The data tells you what happens now, and you are deciding what should happen.

This distinction matters more than it sounds. On inherited sites I routinely find the wrong page ranking for a valuable query, usually a blog post that accidentally outranks the actual service page. The data says the blog post owns it. The right answer is often to make the service page the owner and rework the post to support it.

Write the decision in the sheet, not just the observation. A map that records what is happening is a report. A map that records what should happen is a plan, and the difference is one extra column.

What do you do when two pages claim the same query?

Pick one to own it and change the other. Do not leave it unresolved, because an unresolved overlap means both pages keep splitting the same intent and neither gets strong. The fix is usually to narrow the loser rather than delete it.

Narrowing means rewriting the second page so it answers a genuinely different question, and linking it to the owner. This is more work than deleting, and it is nearly always the better outcome, because the second page usually has real value that was aimed at the wrong target.

Deletion is right when the second page has nothing distinctive to say. If you go that route, redirect it to the owner rather than letting it disappear. The full triage is its own job and I have written about how to work through cannibalisation on a live site separately.

How do you spot the pages with no query at all?

Compare your full URL list against the Pages tab. Anything in that list which never appears in the Performance report is earning nothing, and on an inherited site that is often a large share of the pages. Those pages are the map's most useful output.

Get the URL list from your sitemap, or from a crawl with something like Screaming Frog if the sitemap itself is not trustworthy. A page with no impressions is either not indexed, not relevant to anything anyone searches for, or invisible because nothing links to it. Those are three different problems with three different fixes, so the next step is to work out which one you have rather than rewriting on instinct.

Internal linking is the cheapest of the three to test and fix, which is why I check it first. If a page has no internal links pointing at it, that is worth resolving before you conclude the content is the problem, and auditing orphan pages is the way to find them at scale.

Why should you not verify the map by searching yourself?

Because your own search results are not representative, and Google says so. The documentation notes that even if a query appears in your list, you might not see your site in results if you run the same query yourself, because results are specific to the time, place, device and recent activity.

I mention this because it is the single most common way people talk themselves out of good data. They see a query in the report, search it on their own laptop, do not see the site, and conclude the report is wrong. The report is not wrong. The personal search is not a measurement.

If you need to share findings, Search Console's Share button exists, though Google notes that the link grants access only to the current view of the report. For anything broader, export to a sheet and share the sheet, which is what you wanted for the map anyway.

What should you do next?

Block two hours, widen the date range past the three month default, and build the map for your top thirty pages by impressions. Thirty is enough to reveal the site's real structure, and it is small enough that you will actually finish in one sitting.

Then rebuild it quarterly rather than continuously. A map you refresh every week becomes a chore you abandon. A map you refresh four times a year stays accurate enough to be trusted and cheap enough to survive.

If you have just taken over a site and cannot tell what it is supposed to be ranking for, that is a good problem and a solvable one. Send me the situation and I will tell you where I would start. Let's chat.