What to Do After Keyword Research: The Spreadsheet Isn’t the Plan

After keyword research, the next step is clustering. Group the list by which queries return the same URLs, and a few thousand rows become a few dozen intents; everything that follows works on those intents, not on the raw export. The last market entry I sized came in at 1,400 rows. Clustered, it was 30 to 40 intents. The intents turned out to be four pages. The spreadsheet was never the plan. It was raw material for a much shorter document that says which intent becomes which page, in what order, with what inside, linked to what.

Below is that document in the order I build it. The pages ranking for this query give one list of steps for every site. In practice there are three sequences, depending on what the site already is, and most of the real decisions sit in that branch. The steps come first anyway, because they’re the question.

What to do after keyword research, step by step

Eight steps, in the order they run. Each has its own section below.

• Cluster the list by SERP overlap, so the unit is the intent, not the keyword. A few thousand rows become a few dozen intents.
• Read the SERP for each intent and write down the page type it accepts: service page, guide, tool, comparison, category, or someone else’s marketplace.
• Map one intent to one URL, existing or new, in a table with page type, role and order.
• Set the order by distance to revenue and distance to a page that already ranks. Volume is a column, not the sort key.
• On an existing site, audit first: keep, improve, merge or delete per URL, and ship the merges before the first new page.
• Brief each page with the coverage the SERP expects plus one gain it doesn’t have, named before writing.
• Write, edit twice, link, publish. One pass for facts, one for the patterns that read as generated, then contextual links in three directions.
• Measure the cluster in Search Console, not the article, and refresh it quarterly.

On a new site step 5 doesn’t exist. On a site that can’t be rebuilt, steps 2 and 6 shrink to whatever the template can hold. Which is the next section.

What to do after keyword research depends on the site: new, rebuildable or frozen

Everything after clustering hangs on one question: are we building pages, or working with pages that already exist?

A new site. Nothing to audit. Clustering, then two reads before any page is drawn: a commercial audit of the top ten for every commercial cluster, so the service and category pages get built with the blocks the ranking pages carry and one block none of them has; and a topical map of the informational clusters, so the blog is planned as clusters in an order rather than a list of titles. Mapping comes after both, because you don’t know the page types until you’ve read the SERPs, and on a build the map is the input to the architecture, rendering and CMS decisions that get made before the first line of code.

An existing site that can be rebuilt. The audit comes first and hands back one verdict per page — keep, improve, merge, delete — before the keyword list touches anything. Merges happen before new pages get written, so a new page doesn’t spend its first months competing with the one it was meant to replace. Then the commercial audit runs on the commercial pages that survived, and its output is new blocks, new entities, new text in the template. When the rebuild is a full redesign, the migration side has its own sequence, and the B2B website redesign piece covers what gets exported before design starts.

An existing site that won’t be rebuilt. This is half of the projects I see, and it appears in no guide. The client has a template, a design, a development queue that isn’t taking SEO tickets this year. The commercial audit is skipped, because its output has nowhere to go. What’s left is the text layer of the existing pages: entities, coverage, titles, H1 and H2, internal links. That is a ceiling. The audit should say where it is. Some commercial clusters can’t be closed without a block the template doesn’t have. Those go to the blog as an interim page, or they aren’t taken, and the plan lists them by name.

Keyword clustering by SERP overlap: from keywords to intents

The guides in the top ten work in keywords: one main keyword per page, a pillar for the broadest term, supporting pages for the rest. The engine works in intents, and the two disagree often enough to matter. “SEO audit checklist,” “technical SEO audit,” “SEO audit cost” and “SEO audit services” share a head term and get four different result pages. “What does an SEO audit include” and “SEO audit checklist” share no head term and get the same one. So the grouping that holds is by result page — and once you group that way, the number of pages to build drops to what the SERP will support. Any tool that clusters by SERP overlap gives this read. Ours is one of them.

Two settings decide whether the read is any good. The first is the overlap threshold: how many of the top ten URLs two keywords must share before they count as one intent. Set it low, at two or three shared results, and unrelated intents get glued together; set it high, at five or six, and the clusters shatter back into single keywords. Somewhere around three to four is where the groups line up with pages, and the right number drifts with the niche, so it’s worth checking a few clusters by hand before trusting the whole run. The second is what the overlap is measured against. Hard clustering asks every keyword in the group to share URLs with every other keyword. Soft clustering only asks each one to share URLs with the head term, and it produces bigger, looser groups that map badly to pages. Parent-topic grouping is a shortcut on top of that: it files a keyword under whatever page already ranks first for it, so a variant lands under a broader term whenever one page happens to rank for both. It’s fast, and it quietly merges intents that want separate pages. For mapping to pages I use hard clustering at the stricter end, and I run it per country and per device, because the same keyword returns a different top ten in the US and the UK, and sometimes on mobile.

The screenshot is our own audit export. “seo audit,” “SEO audit services” and “seo audits” fold into one commercial cluster at 33.2K searches a month. “SEO audit tools” is a separate cluster at 4.9K, because its result page is tool pages. “technical SEO audit” stands alone at 7.8K, and “how to do SEO audit,” 880 a month, is the one informational intent in the set. Eleven keywords, four pages. The fourth is a different kind of page from the other three.

Same head term, four result pages. The volume column is why the informational one comes last.

Within a cluster the variants don’t each get a URL. The head term is the primary keyword; it takes the title, the H1 and the URL. “Cost,” “checklist,” “examples,” “template” are the secondary keywords, and they usually live as H2 blocks inside the one page that owns the intent, each in the format the SERP shows for that variant: a table for cost, a list for checklist, a definition block for “what is.” The long-tail phrasings under those don’t need a block at all. They’re how people type the same question, and a block that answers it catches them. A variant becomes its own page only when its SERP is a different set of URLs or a different dominant format.

Pillar and supporting pages fall out of the same read. The pillar owns the head intent, supporting pages own the intents whose SERPs split off from it, and a “supporting page” that shares the pillar’s result page is a section of the pillar, not a page. Writing a page per variant is how a site ends up with fourteen pages answering one question and none of them ranking.

SERP format and page type: service page, guide, tool, comparison, category

Before an intent is assigned to a page, the SERP says what kind of page it will accept. A page of another format doesn’t get in.

The features around the ten blue links are part of that read. A video carousel or a YouTube result in the top five says the intent is partly video, and an article there either embeds one or accepts a lower ceiling. Shopping results or a product grid say transactional, and the page that ranks is a category. A local pack says a location page plus the Business Profile. The People Also Ask box is the list of sub-questions the page has to answer, in the order Google shows them, and four or more PAA questions on one query usually means the intent is informational even when the wording sounds commercial. I read the full top ten rather than the top three, because the top three skew to brands and tools that rank on domain rather than format, and they don’t tell you what a non-brand page needs to be.

The intent labels most tools attach — informational, commercial, transactional, navigational — are shorthand for this read, and they’re too coarse to build from. “Commercial” covers a SERP of agency service pages and a SERP of comparison tables, and those are different pages with different blocks. The label is where I start. What I map from is what the top ten is made of:

The marketplace row saves the most budget. When a SERP is G2, Capterra and two marketplaces, the intent isn’t yours to rank for on your own domain, and the plan says so instead of scheduling a page that will sit at position 40 for a year. The last row sets the ceiling. On the SERP for this article’s own query, positions 2, 3, 4 and 7 are two Reddit threads, a Quora answer and a video, so the realistic target for an article is a slot between 5 and 9.

Keyword mapping table: one intent, one URL, page type, role, order

The mapping table is the shortest document in the process, and everything else gets checked against it. One row per intent. The columns: cluster, intent, page type from the SERP read, URL (existing or to be created), role, order. When two intents land on the same existing URL, that’s a merge or a split to decide now. When a new URL lands next to an existing one that already ranks for half the cluster, that’s cannibalization caught before anything is written.

Ours, for the audit cluster on neon-tm.com, looks like this:

Those six columns are the whole of a keyword-to-URL mapping spreadsheet. The templates people download for it add a dozen more, and I haven’t seen one of the extra columns change a decision.

Keyword prioritization: search volume, keyword difficulty and distance to revenue

The export gives two columns everyone sorts by, and each misleads in its own way. Search volume is a per-keyword number, but the unit is the intent. A cluster of forty phrasings at 50 searches each is a 2,000-search page, and it sits below a single 800-search keyword in every tool’s sort. So volume gets read at the cluster level, after clustering, or it gets read wrong. Keyword difficulty is a backlink proxy: the tools estimate it from the link profiles of the pages ranking, which says nothing about whether those pages are any good. A KD of 60 over ten thin pages is a softer SERP than a KD of 30 over three deep ones, and only the SERP read tells them apart. The proxy also differs by tool. The tools build it differently. Some estimate difficulty almost entirely from the number of referring domains pointing at the top ten pages; others fold in the authority of those domains, the SERP features present and how competitive the phrasing is. So the same keyword can read easy in one tool and hard in another. A KD is comparable inside one tool and nowhere else, and it’s a starting filter, not a verdict.

Order is the column people skip. It decides the first quarter. Volume doesn’t set it. Distance to revenue does, and distance to a page that already ranks. A commercial cluster with a page sitting at position 12 comes before a big informational cluster with nothing behind it, because the first needs a push and the second needs a year. Within the blog, the pillar gets written first only when nothing supporting exists yet. On a site that already has three supporting articles and no pillar, the pillar is the gap and goes first.

The practical sort is three tiers. Striking distance first: existing pages at positions 5 to 20 on queries with any volume, because a link and a block move them in weeks. In Search Console that’s the Performance report over the last 28 days, position filter greater than 4 and less than 21, sorted by impressions, with a floor I set at 50 impressions on a small site and 200 on a large one; what’s left is pages Google already shows and nobody clicks. Then commercial intents with a SERP the site’s page type can enter. Then everything informational, in the order the topical map gives, which is a section below. A cluster that lands in none of the three gets written down and not scheduled. Those three tiers, with dates against them, are the content calendar; there’s no separate document. Backlinks sit outside this plan. The order assumes the domain’s link profile is what it is, and where a cluster needs links the site doesn’t have, the row says so and the cluster waits.

Why researched keywords don’t rank: five mistakes and one that isn’t

Most of the keyword lists I’m handed come with a previous attempt attached. The pages exist and the rankings don’t. It’s almost always one of five causes — two of which show up under a named status in Search Console.

And the one that isn’t a mistake: a page younger than six weeks sitting at position 80 or 90 on a domain that was rebuilt this year. That’s age. On a young domain it’s normal, and this page is an example of it, published in September on a domain rebuilt over the summer. The check is impressions in Search Console rather than position. If the page is getting impressions on the queries it was built for, the fix is waiting. If the impressions come from a neighboring topic instead, the page drifted, and showing that is the topical map’s job.

Of the five, cannibalization is the one most often guessed at and easiest to confirm. Filter the Performance report to the exact query, open the Pages tab, then look at the dates rather than the totals. Two URLs taking turns, each with a few days of impressions and then nothing, is cannibalization. Two URLs both getting impressions every day on the same query isn’t. Google is showing both, usually because the query has two intents, and the fix is to split them cleanly rather than merge.

Commercial keywords by site type: ecommerce, listings, services, SaaS, local

For every commercial cluster, the top ten gets read as a set of blocks: which of them carry pricing, a comparison table, a calculator, specs, reviews, a location grid, a FAQ, and which block none of them has. The output per page is two short lists, the blocks the page needs for parity and the one or two it can own. The B2B audit article shows that read against a top five with a screenshot, so I won’t repeat the mechanics here. What changes by site type is where the clusters land:

Facets and listing matrices are where the index decision gets expensive. That decision belongs to the ecommerce SEO audit, and at scale, where the unit stops being the page and becomes the template, to the enterprise SEO audit. The facet rule needs a number to be usable. I index a facet when the combination has its own query in the list, at least eight to ten products behind it, and the count holds across a quarter; below that it gets a canonical to the parent. The rule is written into the template rather than decided URL by URL. On a frozen site the whole table collapses to one row: the existing pages, the entities and text they can carry, and a note per cluster naming the block that would be needed to compete and isn’t there.

Topical map: which cluster first

A topical map usually gets described as coverage, the list of subtopics a site needs before it reads as owning a topic. In the sequence its job is order: which cluster first, which second, what stays unwritten because it would pull the site’s center somewhere it shouldn’t go. It’s also the check on what’s already published, whether the articles sit where you thought they sat. The method is on the topical map page. The reading of our own site is the useful part, so here it is.

neon-tm.com, rebuilt this summer, run through the map on September 6. Twenty-two pages, five clusters. The densest cluster holds fifteen pages; four topics are held by a single page each, and three of those single pages are the service pages, web development, digital experience design and the services index, each alone on its topic. A keyword list would have scheduled another audit article, because that’s where the volume is. The map put the design pages first, because the audit cluster is dense and the design cluster is one page. That’s the order decision, and it’s the one a keyword list can’t make.

Cannibalization and dilution inside a site

Cannibalization is what the mapping table exists to prevent. On a site with history it has usually happened before the table does. Two URLs answer one intent. Google picks one, then the other, and in Search Console the query trades landing pages week to week. The map catches it as pairs of pages sitting too close together, and it catches the milder version too: the same paragraph doing the same job in several articles. That isn’t two pages on one intent yet. It’s how it starts. Ours had 44 duplicated sections across 22 pages, and one of them was a paragraph on the March 2024 helpful-content signal that I’d written into four articles and read as clean every time. It now lives in the B2B article, and the other three link to it.

The fix depends on what the two pages are. Same intent, same page type: merge, 301 the weaker into the stronger, where stronger is the URL with more impressions on the shared queries over the last twelve months and, second, more referring domains. Same intent, different page type, a guide next to a service page: keep both, take the shared head term out of the guide’s title and H1, and link the guide to the service page on that term, so one of them steps out of the query. Near-duplicates the business has to keep, regional variants for instance: canonical, not noindex, because noindex takes the page’s links out with the page. And a merge into the homepage isn’t a merge; the homepage’s intent is the brand, and the redirected query lands on nothing.

Dilution is the opposite finding, an article that sits far from everything else on the site. Ours is a piece on designing interfaces around human central vision. The map’s advice for that case isn’t “delete”. Decide whether it’s a focus mistake or the seed of a cluster, and if it’s a seed, grow the cluster around it. It’s the seed, and it’s why the design pages are second in the order above.

Content audit on an existing site: keep, improve, merge, delete

On an existing site nothing in the sections above starts until the audit has run: the content audit on the blog, the SEO audit on the rest. What this plan needs from them is one column, keep, improve, merge or delete per URL, and one rule. Merges and deletions ship before the first new page, so the new page doesn’t inherit a competitor from inside the site. Merges are 301s to the strongest survivor, one to one, with any redirects left over from earlier migrations collapsed so the chain doesn’t stack. Googlebot follows only a short run of hops before it gives up and reports a redirect error, so a merge that lands on a URL that itself redirects twice more can pass nothing and index nothing. The ways a merge redirect passes nothing are covered in the 301 redirect piece on this site; the short version is that the homepage is not a merge target.

On our own blog the column came back clean: nine articles, health score 76, all nine graded Strong, nothing flagged for rewrite or deletion. The AI-likelihood column ran 15 to 35% per article. That’s what careful human writing scores on those detectors, so the number is there for a person to look at and the threshold for suspicion sits well above it. The other kind of column, where half the blog grades Rewrite or Delete, is in the B2B article’s screenshot. Most existing sites hand back that one.

Content brief per article: coverage map and information gain

Every page in the mapping table gets a brief before a word is written, and the brief has two layers that most briefs merge. The first is what the encoder expects: the entities, the co-occurring terms, the sub-questions a document about this intent has to answer to be read as a document about it. That’s the coverage map — it sets the H2s, one per sub-question, in the format the SERP shows for that block. The second layer is what the page adds that the ranking set doesn’t have, scored passage by passage against the pages already ranking. The B2B article carries its own score — 47 passages, 29 of them new, an index of 60% against a top five scoring in the 30s and 40s. It runs before writing, so the gain goes into the brief as a claim to be checked, not as a hope.

The coverage map has three inputs, all public: the H2s of the top ten, the People Also Ask questions with their follow-ups two levels down, and the terms that co-occur in at least three of the ten pages. That gives six to eight sub-questions per intent. More than that and it’s two intents. The gain layer is measured against passages, not pages. On the query map for this article, the top five gave 145 passages. A sub-question counts as silent when the closest passage sits below 0.648 similarity and as answered above 0.742, both quartiles of that corpus rather than fixed numbers, and 34 of the 94 sub-questions came back silent. Those 34 are the brief’s gain list. Anything above the upper bar is consensus and gets a short block. Anything below the lower bar is where the page can be the only answer on the SERP.

So the brief names the gain up front: the screenshot that will be in the page, the number from a report, the case with a date, the parameter nobody in the top ten has typed. If the brief can’t name one, the page waits. A case invented to fill the slot doesn’t help. It’s assembled from what’s already in the top ten, so it scores as an echo, and a reader or an AI answer that tries to verify it finds nothing behind it. One article with a measured insight moves a cluster further than a hundred pages that restate the SERP.

The rest of the brief is short. Facts that carry a date or a number, listed for verification. The three things in the page that couldn’t have been written a year ago. What goes in the first hundred words. Which two or three pages on the site the article links to, and which link back. What the article does not cover, named, so it doesn’t drift into the neighboring cluster.

Editing: the fact pass and the marker pass

The page is written by a person, or under one who reads every sentence and cuts what they wouldn’t say aloud. There are two edits. The first is for facts and dates against the brief’s list. The second is for the patterns that make a text read as generated, whoever wrote it: the antithesis repeated eight times, the announcement before every list, the tidy aphorism closing every section. That pass is separate because an editor reading for facts doesn’t hear rhythm. A page that survives both and still says nothing new against its SERP goes back to the brief, since the gap wasn’t in the writing. A cluster of pages written “for the cluster” with no gain in any of them is what Google’s spam policies now file under scaled content abuse, and it doesn’t build authority, whoever wrote it.

Contextual internal links: pillar, supporting and commercial pages

Internal links run in three directions, and the crawlers report one. Supporting article to pillar and back. Article to the commercial page it feeds, one or two contextual links inside the text where the reader is ready to ask for the service, never a banner. And commercial page to the article that answers the question a buyer has before the form, which is the direction that gets built least, because service pages are written by a different team from the blog.

On our own site the crawler said the linking was done: 34 pages, 618 internal links, zero orphans, average click depth 1.0. Its recommendations said something else. Fifteen of the 34 pages get their links only from navigation, footer and homepage widgets, none from the body of another page. The three core pages the map flagged as starved each got a named donor page — and the donors turned out to be the service pages, which link to nothing in the blog. Navigation makes a page reachable. Contextual links are what say it’s about something. Two rules for the contextual ones: the anchor is the target page’s primary keyword or a plain phrase around it, never “read more” or “this article”, and on those fifteen nav-only pages the anchors were menu labels, which is one reason a page can have eight inlinks and rank for nothing. And the link has to sit where a reader would click it. A link in the last paragraph of a 3,000-word article gets crawled, and it’s the least-clicked position on the page.

Publishing: on-page, Request Indexing, the Pages report

On-page is a short list. A title that isn’t the H1. A description written as a pitch. A URL that is the query and nothing else. The primary keyword in the title and H1, the secondary ones in the H2s where they already are. Article and FAQPage schema where the page has a FAQ, alt text on every screenshot, a dateModified that moves when the page does. Then the sitemap picks the URL up and URL Inspection’s Request Indexing gets it fetched the same day. Request Indexing has a small daily quota per property, enough for a handful of URLs a day, so it’s for the pages that matter this week, not for the whole sitemap. The sitemap’s lastmod is read only while it has been accurate historically; a lastmod that ticks on every build teaches Google to ignore it, and it should agree with the schema’s dateModified and the date shown on the page. The Indexing API isn’t a shortcut here; Google’s documentation limits it to JobPosting and BroadcastEvent pages, and plugins that fire it for articles are working outside what it’s for.

Seven to fourteen days later, each new URL gets read in Search Console’s Pages report. Indexed is the expected outcome. Discovered – currently not indexed is a crawl-allowance problem, common on new sites, and it clears on its own or with a link from a page Google already visits often. Crawled – currently not indexed is a quality or duplication verdict. On a page written to a brief it usually means the page landed too close to an existing one, which sends you back to the map. Duplicate, Google chose different canonical than user on a new article means an old one is still answering the same intent, and the merge that should have happened first didn’t. The technical SEO audit guide on this site walks each status to its cause.

Search Console: read the cluster, not the article

An article’s Search Console line is noise for the first two months. The cluster’s line isn’t. I filter the Performance report by a regex on the cluster’s folder or slug pattern and read impressions, clicks and position for the cluster as one object, week over week, for 30 to 60 days before touching anything. Titles and descriptions get rewritten first, against the queries that already bring impressions and low click-through; those are how people phrase it, and they rarely match the brief. Then the cluster’s striking-distance pages — positions 5 to 20 on queries above a volume floor — get the push: a contextual link from the strongest page in the cluster, one pass on the block that answers the query, nothing else. The regex is the folder plus the cluster’s slug stem, /insights/.*seo-audit for the audit cluster here, applied to the Page dimension. Search Console runs RE2, so lookaheads don’t work and an OR is written out as (technical|enterprise|international). Position in that report is the average of the page’s top position per impression, so a cluster at “position 8” can be one page at 3 and four pages at 12. Impressions and clicks first, position last. Rank tracking outside Search Console is optional at this stage. The impressions column already says which queries the page is a candidate for.

One thing changed how that line is read this year. Search Console now counts each follow-up inside an AI Mode conversation as a new query with its own impression and position, per Google’s documentation from August 2026. A cluster whose impressions jumped over the summer may have gained conversation depth rather than reach, which is why the click column didn’t move with it.

Quarterly refresh: decay, cannibalization, dateModified

The plan doesn’t end at publication. It turns into the audit that started the existing-site branch. Every quarter the cluster gets the same reads as a stranger’s site, the decomposition a rankings loss audit runs on a drop: which articles decayed, measured as impressions against their own peak rather than against the cluster, where decay for me is a drop of more than 30% against the page’s own 90-day peak for two consecutive 28-day windows, since a one-window drop is usually a SERP change or a season and gets left alone; which two now answer one intent, which is what cannibalization looks like from inside a site that used to be clean; which fact in each page carries a date older than a year with a newer one available. The refresh is the brief again. Three things that weren’t true a year ago, or the page doesn’t get a new dateModified. A site that was new when the plan was written is an existing site twelve months later, and from then on it runs the existing-site sequence.

Open question: how many articles a cluster needs

The number everyone asks for is how many articles a cluster needs before the site reads as an authority on the topic. Five? Fifteen? Does one page that ranks count for more than ten that don’t? I don’t have it, and I haven’t seen anyone who does. Our densest cluster is fifteen pages; the design cluster is one, and what moves it from one page to a cluster is the map reading it as one, not a count. The nearest thing to a number I can defend is gain per page, measured against that page’s own SERP. If someone publishes a controlled test — same site, two clusters, one padded to twenty restatements and one held to five pages with measured gain — I’d read it before I believed any threshold.

Frequently asked questions

After keyword research, what is the next step?

Clustering. Group the list by which queries return the same URLs, and a few thousand keywords become a few dozen intents. Every step after that — the SERP read, the mapping table, the order — works on intents. None of them can be done on the raw list.

How long does keyword research take?

The research is the short part: a day or two for a market. Turning it into a plan takes longer, and it’s the part that decides anything. Clustering 1,400 rows into 30 to 40 intents is an afternoon with a SERP-overlap tool. Reading 30 SERPs for format is a day. The mapping table is an hour once those two are done. On an existing site the long part is the audit that has to run first. How long that takes depends on how many pages there are and how many of them turn out to be the same page.

Is keyword research still important in 2026?

The list is. The keyword as a unit is less so. AI Mode fans a query out into sub-questions and assembles an answer from several pages, so what a page has to cover is the set of sub-questions behind an intent rather than a phrase. Clustering by SERP overlap is what turns a keyword list into that set.

By 2028 I’d expect the mapping table and the per-page gain score to be what a content plan is, one row per intent and one number per page, and “publish 40 articles this quarter” to read the way “build 500 backlinks” reads now. The sequence above on your own site, from the audit to the map to the brief, is what our SEO service runs.