What replaced frequency ranking in keyword extraction
Frequency answers a narrow question: which string repeats most. That is not the same question as what a page is about, and on real pages the 2 answers come apart badly. A navigation label sitting in every section outranks the argument the page makes. "Churn" and "customer attrition" read as 2 separate topics because they are 2 separate strings. A thesis stated once, in the opening paragraph where the writer put the whole point, sinks under the boilerplate around it.
One live run made the gap concrete. The post's navigation read "Home / Pricing / Docs / Log in" and its footer read "Cookie preferences / Privacy policy". None of those came back. What did come back was "feature gap" and "logo retention", each mentioned exactly once, and both of them the actual subject of the post.
What it reads, and what it deliberately skips
2 inputs. The page text, pasted in or fetched from a URL you drop in the box above the textarea. And, optionally, the keyword you believe the page targets.
Navigation, cookie notices, footers, author bios and calls to action are skipped by rule. They are on the page and they are not what it is about. Generic filler that would fit any page in the industry, "best practices" and "digital marketing", goes the same way unless the page argues about it.
Fetching works on server-rendered pages. A JavaScript-only app, a paywall or a consent wall returns very little text, and the output looks thin because the input was. Select the article in your browser and paste it instead.
The 4 roles, and the cap on core topics
Every term comes back carrying exactly one role.
- Core topic - the page's actual subject.
- Subtopic - something the page genuinely covers underneath that.
- Named thing - a product, company, person, place or standard.
- Qualifier - intent or qualifier wording: "free", "for agencies", "vs", "2026".
At most 3 terms may carry the core topic role. A page about everything is about nothing, and a list of 9 equally weighted "main topics" tells you nothing you can act on. If your page really does have 6 competing core subjects, the output will still show 3, and the honest reading is that the page wants splitting.
Each term also carries a why: one clause on what the page says about it, taken from the text. Not "it appears often", which the prompt bans, because that was the old tool's whole answer.
Every number on screen was counted, not written
The model is forbidden from emitting a number at all. No counts, no densities, no percentages, no scores.
Times used and density are computed in your browser, against the text you pasted, after the terms come back. Matching is whole-word and ignores case and punctuation, so "SEO," and "seo" are the same token, while "keyword" does not match inside "keywords".
The reason is narrow and worth stating plainly. A model-supplied count is a number nobody verified, and on a keyword tool that is the exact figure people copy into a client report. Density above 3.5% is flagged, and the flag means look at this, not you have been penalized.
The most useful row is often the one where the label and the count disagree. A term marked core topic with a count of 0 or 1 means the page is arguing something it barely names, which is precisely what a search engine struggles to match it to. A frequency ranker could never surface that row.
Checking the target keyword against the extracted terms
Fill in the second field and you get a verdict on it: on-topic, partial or off-topic, plus one sentence of evidence drawn from the page.
Partial is the answer that earns the field its place. It usually means the page touches the keyword and spends its length somewhere else, which is the failure that survives every on-page checklist. The keyword is in the H1, in the intro and in a subheading, and the body is about something adjacent.
Leave the field blank and no verdict appears.
The one-sentence summary and the missing keyword list
Above the table sits a single sentence naming what the page is about, phrased the way a person would say it out loud. Read that first. If it does not match what you meant to publish, nothing further down the table will rescue the page.
Below the table sits the missing list: 3 to 5 subtopics a reader would reasonably expect on a page about this, and does not get. It comes back empty when the page is genuinely complete.
That list is the reason to run this on somebody else's page. Extract a competitor's article, read what it covers, then read what it left out. The second list is the brief for yours.
Where the output will be wrong
- Normalised plurals lose their count. Terms are normalised to one form, so a page that only ever writes "keywords" can return the term "keyword" with a count of 0. The role and the why are still right. The integer is what undershot.
- Long pages are read to about 24,000 characters, roughly 4,000 words. Counting runs over everything you pasted, but term selection only saw the front of it, so the tail of a very long page can go unrepresented.
- Thin input gives generic terms. Below a few hundred words there is not enough page to have a subject.
- It reads one page and nothing else. No search volume, no difficulty score, no SERP data. It tells you what your page is about, never what anyone searches for.
- Languages without spaces between words tokenize badly for the counting step, so Chinese, Japanese and Thai text will get sensible terms with unreliable numbers beside them.
- A human check runs first. Generation costs money, so an invisible Cloudflare check runs before the first extraction. One check covers a 30-minute window, not one run.
Copy terms hands you the list as plain lines. Download CSV gives you term, role, occurrences, density, word count and the why: the version worth pasting into a brief. If you would rather not run this loop by hand on every page you publish, that is the work BlazeHive automates end to end.