An AI Agent Workflow to Map Keywords to Existing Hub Pages

Before you write anything new, check the keyword against your own site's real inventory. A strict four-category schema and one model call per keyword catches near-miss false positives a broad semantic search would miss.

Why this matters before you hit publish

Every new tool page, workflow, or blog post you add either strengthens an existing topic cluster or splits it. On a site with 384 tools and 198 workflows, the second outcome is easy to trigger by accident: a keyword that looks new might already be answered by a tool page you shipped six months ago, or by a workflow that covers the same job from a different angle.

The fix isn't a human scanning a spreadsheet before every content decision. It's a small agent step that runs once per candidate keyword, checks it against your own site's real inventory, and returns a clear verdict: link to what already exists, or confirm this is genuinely new ground.

This is a pre-publication check, not a post-publication audit. Auditing pages that already exist and quietly get no traffic is a different job with a different fix (usually internal linking or a rewrite). This workflow runs earlier -- before a single word of new content gets written -- so the fragmentation never happens in the first place.

The agent workflow

Step 1: Pull your own inventory as structured data, not a page scrape.

If your site already exposes a machine-readable catalog (a JSON endpoint, a sitemap, a CMS export), use that directly. Scraping your own rendered HTML to figure out what you already have is slower and noisier than just reading the data you already maintain. We use our own tools.json and workflows.json endpoints for this -- the same files built for AI assistants to cite us are also the fastest way for our own agent to check its own inventory.

Step 2: Define a strict classification schema before writing a single prompt.

The schema needs more than "match" or "no match." A binary schema forces the model to guess on genuinely ambiguous cases. Four categories cover most real situations:

• existing_tool_page -- one tool page answers this keyword directly
• existing_workflow_page -- one workflow page answers this keyword directly
• ambiguous_multi_match -- more than one existing page is a plausible answer, and picking one is an editorial call, not an automatable one
• content_gap -- nothing in the inventory answers this keyword

Each classification also requires a matchedSlugs array (empty for a true gap) and a one-sentence reasoning field. The reasoning field matters more than it sounds like it should -- it's what lets a human catch a wrong call in five seconds instead of re-researching the keyword from scratch.

Step 3: One model call per keyword, with the inventory as context.

For a catalog this size, the full tool and workflow list (name, slug, category, and the one-line "best for" description) fits comfortably in a single prompt alongside the candidate keyword. No retrieval step, no vector database -- just the real inventory and a forced-schema output. If your catalog grows past what fits in one call, filter to the top category-relevant subset first, but keep the same schema.

Step 4: Route on the verdict, don't skip straight to writing.

existing_tool_page and existing_workflow_page mean the answer is: add an internal link from wherever this keyword surfaced, don't write anything new. ambiguous_multi_match goes to a human for a five-minute call. content_gap is the only verdict that becomes a candidate for the actual content calendar.

A real worked example

We ran this against our own live inventory (384 tools, 198 workflows, pulled fresh from tools.json and workflows.json) with four keywords that would plausibly come up in normal content planning.

"AI voice cloning tool" -- classified existing_tool_page, matched to elevenlabs. Clean call. ElevenLabs' own listing is built specifically around "voice cloning and narration that needs to sound genuinely human." Nothing to write; link to the existing page.

"AI meeting notes tool" -- classified ambiguous_multi_match, matched to both granola (a tool page) and turn-meeting-notes-into-action-plans (a workflow page). This is the case a binary schema would get wrong. Someone searching this phrase might want a product recommendation, or they might want the repeatable process. Both existing pages are legitimate answers to different intents behind the same words -- that's an editorial routing decision, not something worth forcing a model to guess on.

"AI tool for translating video subtitles" -- classified content_gap, with zero matched slugs. This one is worth dwelling on, because a looser check would have false-positived here. We have a tool page for Submagic, and Submagic does captions. But Submagic's whole positioning is animated, viral-style captions for short-form video -- a styling problem, not a translation problem. A keyword-overlap check ("subtitle," "caption") would have wrongly routed this to Submagic's page. The schema's reasoning field is what catches this: the model has to state why a match counts, and "it also involves captions" isn't the same job as "it translates subtitles into another language."

"AI tool for GitHub code review" -- classified content_gap, zero matches in either inventory. No tool page positions itself around automated code review, and no workflow walks through building one. This is a legitimate new-content candidate, not a mis-routed match to our general coding category.

Two clean matches, one honest ambiguous case, one near-miss caught before it became a bad internal link, and one real gap. That's what the check is supposed to produce.

Why one structured call beats a broad semantic search

A plain semantic search over your own content will often surface Submagic for "subtitle translation" -- the embeddings are close enough that it looks like a match. That's the failure mode this workflow is built to avoid. Forcing the model to commit to one of four category labels and justify the pick in plain language turns "this seems related" into "this specific page answers this specific job," which is the actual question a routing decision needs answered.

Where this breaks

• A cached inventory goes stale fast. If you pull the catalog once and reuse it for a month of keyword checks, new pages you shipped in week two won't show up as matches, and you'll get false content-gap verdicts. Pull fresh each run, or at minimum, timestamp the pull and treat anything older than a few days with suspicion.
• Too few categories forces bad calls into "ambiguous." If the schema only has three options instead of four, keywords that are genuinely one clean match get shoved into the catch-all bucket, and the whole point of automating the easy cases disappears.
• This does not replace a human spot-check. Run a sample of the verdicts past a person before trusting the automation at scale, the same way you'd trust any other agent output that feeds an editorial decision.

The three-question recipe

If you want to build this for your own site: what's your inventory source (a real data export, not a scrape), what's your exact schema (enough categories to avoid forcing ambiguous calls, plus a reasoning field), and what's the one call that takes a keyword and the inventory and returns a verdict. That's the whole workflow. No multi-agent framework, no vector database required for a catalog that fits in a single context window.