INSIDETHE AUTHORITY ENGINE
Most agencies treat it as a checklist run after writing. We apply it at three points, starting before a single word exists, so that by the time a page is published there is nothing left to optimise.
How it usually goes
A brief goes out, usually a keyword and a rough outline. A writer produces a draft. The draft comes back. Someone opens a plugin, sees a row of amber lights, and starts fixing.
Add the keyword to the H1. Push the density up. Write a meta description. Insert three internal links wherever they fit. Add alt text. Green lights. Publish.
Every one of those actions is correct in isolation. Performed at that point in the process, they achieve almost nothing.
Because by then the page is already built. The heading structure was decided by the writer's instinct rather than by how the subject is actually organised. The answer to the query is in paragraph four because that felt like a natural place to put it. The page targets an intent nobody verified against the results currently ranking.
None of that is fixable with a checklist. You can adjust the surface of a page after writing. You cannot restructure its meaning.
The result
Technically optimised pages that do not rank, and nobody can explain why, because everything on the checklist was green.
The three points
On-page work is distributed across the whole production process rather than bolted on at the end. That is why we call it engineering rather than optimisation.
At the brief
Before anyone writes, the page structure is already decided.
Target query and query network
Root query, refined variations, and follow-up questions - not one keyword.
Heading vector with HTML tags
Every heading in order, built from how the subject is structured and what ranking results contain.
Entity requirements
Which entities must appear, with which attributes, so the page does not read as incomplete.
Answer-first per section
Marked in the brief, section by section.
Internal linking, both directions
What this page links to, and which existing pages must be updated to link back.
Schema and format
Markup decided early. Tables, steps, definitions or lists based on what the SERP rewards.
During writing
The writer works to specification rather than to instinct.
Title and headings
Represent the query - do not restate the keyword.
First paragraph answer
Answer in the first sentence, then explain. What AI systems extract too.
Entity placement and density
Where they carry meaning, not scattered to hit a count.
Term co-occurrence
Words that belong together, in the proportions ranking content uses.
Passage-level sections
Lifted out and still make sense - for snippets and AI answers.
Tables, lists, clear sentences
Structured for machine extraction. Subject, verb, object. Low ambiguity.
At publishing
The mechanical layer, applied consistently and verified.
Meta, URL, heading tags
Verified - CMS editors break hierarchy constantly.
Images and internal links
Alt, compression, dimensions. Outbound and inbound links.
Schema, OG, canonical
Applied, validated, and checked.
Indexing confirmation
Not merely submitted - confirmed indexed. Crawled, currently not indexed is a common gap.
What this changes
When on-page work happens at all three points, a page goes live finished.
No round of revisions after publishing. No plugin telling you the keyword density is low on a page whose structure was wrong from the beginning. No separate optimisation project six months later.
It also means the work is verifiable. Every published page has a completed on-page record showing what was specified, what was implemented, and what was confirmed. That record is available to you at any time.
On-page for AI extraction
This is where on-page work has quietly become more valuable than it was two years ago.
When an AI system answers a question about software in your category, it assembles that answer from passages it can extract. Extraction depends almost entirely on on-page structure.
Pages that open with two paragraphs of introduction before reaching the answer. Passages that depend on the sentence before them. Comparisons rendered as prose. Anything that only makes sense in the context of the whole page.
The point
You do not need a separate AI content strategy for this layer. You need on-page work done properly, with extraction in mind. The pages that rank and the pages that get cited are largely the same pages, structured well.
Existing pages
Everything above describes new content. Most sites have far more existing pages than they will publish in a year, and many of those pages are close to ranking.
A page sitting at position twelve with a good backlink profile and a bad structure is the fastest win available on most sites. Moving it to position four produces more traffic than three new pages will.
Now
#12
After
#4
What retrofitting involves
Included in every plan
Content Revival
This runs inside Content Revival, which is included in every plan. Existing pages close to ranking get fixed before you wait on new publishing volume.
Volumes
What most on-page audits miss
Surface checklists stay green. These sit underneath and quietly cap performance.
Looks fine. Parses broken.
An H2 that is visually a heading but marked up as a styled paragraph. Or three H1s because a template inserts one and the editor added another. Invisible to a reader, meaningful to a parser.
Nobody goes back.
New pages link to old ones. Old pages are never updated to link to new ones. Half the value of internal linking is discarded because nobody goes back.
Readable. Hard to extract.
Every page opens with context before reaching the point. It reads well and it is close to unextractable.
Prose
Table
The single most valuable content type in software, written as paragraphs. Rebuilt as a table it becomes quotable by both search engines and AI systems.
Crawled, currently not indexed
Since March
The URL was submitted. Nobody verified. It has been sitting in Crawled, currently not indexed since March.
Who we do this for
Multifamily platforms, resident experience tools, HOA and community association software, maintenance systems, leasing and screening products, across the United States, United Kingdom, Canada and Australia.
We work in one market, which means the briefs already know your buyer, your competitors and the four vocabularies this product is sold under. On-page decisions depend on knowing what a query actually means to the person searching it, and that is market knowledge rather than technique.
Market knowledge first. Technique second.
Product types
Four markets, four vocabularies
Bought alone
Optimised page. Still does not rank.
Inside the system
Applied to every page we publish and revive
CORE
Included
COVERAGE
Included
AUTHORITY
Included
How this is delivered
On-page engineering is part of the system rather than something you buy separately.
Buying it alone would mean optimising pages that may be targeting the wrong queries, sitting in a structure that does not support them, on a site search engines may be struggling to render. That produces a well optimised page that still does not rank, and then everyone concludes on-page work does not matter.
It is applied to every page we publish and every page we revive, across all three plans.
Assess first
If you want to assess your current on-page state first, the Full-Stack SEO Audit covers it as part of the content layer, alongside technical, competitive and commercial.
See what the full audit covers →Objections
Better answered here than in a sales call. Open any one.
Our writers already know SEO.
Most do. The gap is usually not knowledge, it is that they are given a keyword and an outline rather than a specification. A writer who knows SEO well and receives a heading vector, entity requirements and an answer-first instruction per section will produce something materially better than the same writer working from a topic.
Knowledge is not the gap. Specification is.
Can we use your briefs with our own writers?
Yes, and some clients prefer that. We produce the Blueprint and the Semantic Briefs, your team writes and publishes. It costs less and works well when you have writers who understand the product.
Strategy from us. Writing from your team.
How is this different from what a plugin does?
A plugin checks the surface of a finished page against generic rules. It cannot tell you the heading structure is wrong for the query, that the page targets an intent the current results do not reward, or that the comparison should have been a table. Those decisions are made before writing and a plugin arrives afterwards.
Plugins arrive after the decisions that matter.
Does keyword density still matter?
Not as a target. Term frequency and co-occurrence patterns do matter, but as a consequence of writing thoroughly about a subject rather than as a number to hit. If you are counting, something has already gone wrong.
If you are counting, something has gone wrong.
What about AI written content?
The structure requirements are identical regardless of how a draft was produced. What matters is whether the page answers the query well, in a structure a machine can parse, with the entities the subject requires. Our writers work from briefs and every piece is reviewed against its brief before publishing.
Structure first. Draft source second.
The other pillars
Pages only compound when the rest of the Authority Engine is working with them.
Clears the path so search engines can reach, render and trust every page.
Builds every page so machines understand its meaning, not just its words.
Maps your entire subject and covers it in sequence, until your site becomes the source.
Builds the external recognition that makes everything else credible.
Puts you inside the answers buyers get from ChatGPT, Perplexity, Gemini and Google AI.
The AI visibility check shows where your product appears when a buyer asks an AI about software in your category. If competitors are being cited and you are not, on-page structure is usually a large part of the reason.
