How Seoryx turns SEO signals into shipped, verified work.

A public explanation of the decision method behind Seoryx: hard gates, demand estimation, feasibility signals, action labels, evidence packs and verification windows.

// Deep enough to show the system is real. Public-safe by design — the private operating parameters stay internal.

The purpose

SEO tooling has never been short on data. Rank trackers, crawlers, keyword databases and analytics platforms will happily surface thousands of issues, opportunities and metrics for any site. The scarce thing has never been information. The scarce thing is a decision — one that a person can own, an engineer can ship, and a team can later prove was worth the time.

The goal is not another score. The goal is one operational decision per important URL.

Seoryx is an execution-and-verification layer, not a dashboard. It sits between the SEO tools you already run and the engineering process that actually ships changes. It consumes first-party search data, analytics, crawl output and external keyword signals, and it converts them into a single, defensible action for each URL that matters. Then — and this is the part most tools skip — it opens a verification window to check whether the shipped work moved the numbers.

This document explains how that decision is made. It is written to be read by a technical investor, a senior SEO operator, or an engineer evaluating whether the system is real. It is deliberately deep. It is also deliberately public-safe: it publishes how Seoryx thinks, not the private operating parameters — the exact thresholds, coefficients and rank tables — that make the system safe and hard to game in production.

The four-layer model

Every important keyword-and-URL pair passes through four layers, in order. The order is the point. A recommendation is only as good as the checks it survived on the way to being made.

The four layers are evaluated sequentially, and any of them can stop or reshape the outcome:

• Gate — hard risk checks. If a critical risk fires, the recommendation does not ship. Gates run first, because a beautifully scored idea on a page that should not be touched is worse than no idea at all.
• Demand — estimated search demand, built from first-party search data and trusted external sources, expressed with a confidence interval rather than false precision.
• Feasibility — how realistically that demand can be captured: difficulty, the authority gap, SERP softness, cannibalization risk, internal linking and content fit.
• Action — a single categorical output: defend, attack, improve, merge or monitor. One decision, not a menu.

The result of the four layers is never a floating number that a person has to interpret. It is a categorical action with the evidence attached. That is a deliberate design choice: scores invite endless debate; a labelled action with its reasoning invites a ticket.

Risk gates

The most important thing a serious SEO system does is refuse to recommend work that should not be done. Most tools express caution as a soft penalty — they nudge a score down and let the item drift lower in a list. Seoryx treats real risk as a hard gate: a binary stop that removes the recommendation from the queue before it can become a work order.

A hard gate is a stop, not a discount.

The kinds of conditions that trigger a gate include (described in shape, not exact rule):

• Pages explicitly excluded from optimization — retired URLs, legal or brand-protected pages, or paths the operator has ruled out.
• Serious cannibalization — where two URLs are competing for the same intent and pushing one would damage the other.
• Risky merge scenarios — a consolidation that would put an existing winner at risk.
• Unwinnable or low-quality opportunities — cases where the realistic upside does not justify engineering time.

Because gates are binary and evaluated first, they protect the rest of the pipeline from spending effort — human and machine — on work that is not safe to ship. What Seoryx publishes here is the shape of the gates and the categories of risk they catch. The exact conditions that trip them stay internal, both because they are tuned operating parameters and because publishing them would tell people how to route bad work around the guardrails.

Demand estimation

Before deciding whether a URL can win a query, Seoryx estimates whether the query is worth winning. Demand estimation is built to resist the two failure modes that quietly wreck SEO prioritization: trusting a single noisy number, and trusting the wrong source.

Sources and provenance

The primary signal is first-party: clicks and impressions from Google Search Console, which describe how a site actually performs, not how a generic market behaves. This is complemented by trusted external keyword sources for coverage where first-party data is thin. Every value carries its provenance — where it came from and how much it should be trusted — so that later stages can weigh a confident first-party figure differently from a rougher external estimate.

Two estimates, reconciled

Demand is derived two ways — from clicks and from impressions — and the two are reconciled rather than one being taken on faith. Clicks describe realised interest; impressions describe latent interest. Reading them together, with the site’s own click behaviour, gives a more honest picture than either alone.

Project-calibrated click-through

A generic, industry-average click-through curve by position is a blunt instrument — a brand in one niche behaves nothing like a long-tail affiliate page in another. Where there is enough first-party data, Seoryx calibrates the click-through curve to the project itself, learning how that specific site converts impressions into clicks by position. Generic curves are used only as a fallback when first-party data is too thin to calibrate.

Confidence and anomalies

Demand is expressed as a range with a confidence interval, not a single figure that pretends to a precision the data does not support. Implausible spikes — the kind produced by bot bursts or tracking artefacts — are capped and down-weighted rather than trusted, so a one-off anomaly cannot inflate a page’s apparent opportunity.

Semantic propagation

When a query has no first-party signal at all, demand is not simply set to zero. It is estimated from semantically similar keywords the site already has data for, using dense text embeddings, so that genuinely valuable but as-yet-unmeasured queries are not invisible. The exact formulas, curve values and coefficients behind all of this stay internal.

Feasibility estimation

Demand answers “is this worth winning?”. Feasibility answers “can this site realistically win it, now?”. Feasibility is a composite judgement, not a single difficulty number, because a single difficulty number hides most of what actually decides an SEO fight.

The signals that feed feasibility include:

• Keyword difficulty as an estimate, not truth. Difficulty scores are useful inputs, but they are treated as noisy estimates to be adjusted, never as a settled probability of ranking.
• The authority gap. A keyword that is hard for a brand-new domain may be reachable for an established one. Feasibility is judged relative to the gap between your site and the incumbents, not in the abstract.
• SERP features. The presence of features — packs, panels, AI answers — changes the real difficulty of a result, and is accounted for rather than ignored.
• SERP softness. Instead of asking only “how hard is this keyword?”, Seoryx asks “are the current top results actually dislodgeable?”. Thin content, weak authority, mismatched intent or weak titles among the incumbents can open a window even on a keyword that looks hard on paper.
• Content fit and depth. Whether the target page can plausibly satisfy the query, and what it would take to make it competitive.
• Cannibalization. Overlap that would set two of your own pages against each other can block a recommendation entirely and reroute it to a merge.
• Internal linking and anchor safety. Whether the site can support the page with internal links, and whether the anchor-text mix stays within a safe, natural distribution.

Seoryx publishes the signals that feed feasibility. It does not publish the multipliers, weights or thresholds that combine them — those are the tuned parameters that make the estimate accurate for real sites, and they are exactly what a competitor would need to reproduce it.

URL mapping

A recommendation is only as good as the URL it points at. Send the right work to the wrong page and you get confident, wasted effort — a new page built where one already exists, or an optimization applied to a URL that was never going to rank. For that reason Seoryx treats URL mapping as part of the decision, not a minor preprocessing step.

Mapping a keyword to a URL follows a ladder, from most to least authoritative signal:

• Manual hints — explicit operator guidance is honoured first.
• Brand-page lookup — known brand and entity pages are resolved directly.
• Curated site structure — the site’s intended architecture, where it has been defined.
• First-party raw URL signals — what actually receives impressions and ranks for the query today.
• Semantic fallback — embedding-based similarity when the stronger signals are silent.
• Unmapped — an explicit state when confidence is not high enough to choose. Deferring is better than guessing.

Action layer

The output of the four layers is a single categorical action per URL. Not a score to be interpreted, not a list of twelve suggestions — one decision, chosen from a small, unambiguous set.

• DEFEND — protect an existing winner that is at risk.
• ATTACK — pursue an opportunity the site can realistically take.
• IMPROVE — upgrade an existing page that is underperforming its potential.
• MERGE — resolve overlap or cannibalization by consolidating.
• MONITOR — do nothing yet; keep watching until the signal is clear.

Why one action is worth more than a list

A backlog of three hundred suggestions is a to-do graveyard: everything is flagged, nothing is owned, and no one can say what shipping any single item would earn. Reducing each URL to one action changes the economics of the whole workflow. There are fewer vague recommendations to argue about. Ownership is clear — a person can take “IMPROVE this URL” and run with it. The handoff to Jira is clean, because a decision maps naturally to a ticket. And verification becomes possible, because a single, discrete change is something you can actually measure afterwards.

Decision trace

Every recommendation Seoryx makes carries a decision trace — a record of how it was reached, so a human can audit it rather than trust it blindly. Transparency is not a nicety here; it is what lets a senior SEO lead accept or overrule the system with confidence.

The trace connects the signal that triggered the recommendation, the evidence that supports it, the single action chosen, the work order that carries it into execution, and the verification window in which it will be checked. An operator can follow that chain end to end: why this URL, why now, what to do, what “done” means, and how the result will be judged.

Evidence pack → Jira work order

A recommendation that lives in a dashboard changes nothing. The output of Seoryx is designed to be a ticket someone can ship — an evidence pack wrapped in a Jira-ready work order.

A work order carries:

• Source signals — the data behind the decision, from search performance to competitive context.
• Affected URLs — the page or pages the work touches.
• Reason this page should move now — the case for prioritising it over everything else in the queue.
• Acceptance criteria — an explicit definition of done, so an engineer or writer knows when the work is complete.
• Owner handoff — the ticket is assignable and trackable, not a floating suggestion.

The work order is written to be Jira-ready — delivered into Jira, the tracker integration supported today, or exported for another tracker. Seoryx does not auto-publish CMS changes or push edits to a live site on its own — a person confirms the work and ships it. The system’s job is to make the decision, the evidence and the definition of done unambiguous; a human still owns the deploy.

Verification window

Most SEO work is fire-and-forget: a change ships, the sprint moves on, and six weeks later no one can say whether it helped. Seoryx closes that loop with a verification window.

When a change is marked done, Seoryx locks a baseline period from before the change and schedules a post-change measurement period after the deploy. It then compares the two using Search Console data — clicks, click-through rate and position deltas for the affected URL — and it does so with an awareness that search results move for reasons that have nothing to do with your edit. Ranking volatility, seasonality and algorithm updates are all noise the window has to account for.

A verification window is not causal proof. It is a disciplined way to stop treating SEO work as fire-and-forget.

This is stated plainly because the alternative — implying that a before-and-after delta proves your change caused it — is both wrong and dangerous. Seoryx does not claim guaranteed ranking uplift, and it does not present a windowed measurement as causation. What it provides is discipline: a defined baseline, a defined post-change period, a volatility-aware comparison, and an honest outcome label instead of a shrug.

AI Assistant & lesson memory

Seoryx includes an AI Assistant with project context — a conversational layer that knows the project it is working on and can answer from its data, rather than a generic chatbot bolted on the side. Around it sits a curated lesson memory that is worth describing precisely, because “AI SEO” is a phrase that invites overclaiming.

Curated RAG lesson memory

As operators accept and reject the system’s recommendations, those decisions are captured as lessons. Accepted lessons — with their provenance intact — can be retrieved into future reviews, so that a judgement made once informs similar decisions later. This is retrieval-augmented: the assistant looks up relevant, human-approved lessons and brings them into context. It is curated and provenance-gated, and a human remains in the loop on what becomes a lesson and what gets retrieved.

Reviews can draw on more than one leading model, and the writing workflow is supported by content-quality checks and an advisory AI-writing detector (below). What Seoryx does not claim — because it would not be true — is a live self-learning model, a production autonomous agent that acts without a human, or any training of a proprietary model on customer data. The learning that happens is explicit, curated and reviewable.

Content quality layer

When a work order involves writing, Seoryx applies a content-quality layer to keep the output from being the generic, forgettable copy that AI writing tools produce by default.

• Content QA — structured checks on a draft before it is treated as ready.
• Helpfulness and experience checks — E-E-A-T-style signals that ask whether the page actually demonstrates first-hand knowledge and serves the reader.
• An advisory AI-writing detector — a fast, heuristic signal that flags prose which reads as machine-generated.

The AI-writing detector is explicitly advisory. It is a signal, not ground truth, and it can be wrong in both directions — so it is used to prompt an operator to look harder, never as an automatic gate that blocks publishing. Its purpose is practical: to help operators avoid shipping generic AI copy and to support, not replace, the person doing the writing.

Validation & regression safety

A decision engine is only trustworthy if it can be checked against reality and defended against its own regressions. Seoryx treats validation as part of the methodology, not an afterthought.

• Prediction snapshots. Each run records what it predicted, so predictions can later be compared against what actually happened rather than quietly forgotten.
• Later measurement. After a maturation period, snapshots are measured against high-trust ground truth, producing honest accuracy over time.
• Golden-set tests. A fixed set of reference scenarios guards scoring, action mapping and output contracts against regressions when the method changes.
• A signal registry. Each signal is defined once, canonically, so the same concept is not computed three inconsistent ways across the system.
• Observability. Runs are traceable, so a surprising recommendation can be explained after the fact.
• Cache and idempotency. Deterministic keys and idempotent jobs keep pipeline runs reproducible and cheap — reliability is part of correctness.
• Methodology versioning. The method itself carries a version, so changes to how decisions are made are deliberate and auditable, not silent.

The specifics — which fixtures, which metrics, which internal registry entries — stay internal. What matters publicly is the posture: predictions are recorded and later scored, regressions are caught by tests, and the method evolves under version control rather than by drift.

What stays internal

This page explains how Seoryx thinks. It deliberately does not publish the private operating parameters that make the system accurate, safe and hard to game in production. That is an operational-security decision, not secrecy for its own sake — publishing the exact boundaries would let a competitor clone them and let low-quality work learn to route around the gates.

The following are intentionally excluded from any public methodology:

• Exact thresholds and cut-offs
• Coefficients, weights and multipliers
• Vendor rank tables and how data providers are reconciled when they disagree
• Implementation file maps and internal module structure
• Internal decision rules and their catalogue
• Client and project identifiers
• Internal brand and product code-names
• Private, vertical-specific heuristics
• Raw configuration and operating settings
• Security-sensitive details

The public page explains how Seoryx thinks. It does not publish the private operating parameters that make the system safe in production.

Run the methodology on one site

The fastest way to judge a decision method is to watch it decide on URLs you already understand. Put one site through Seoryx: let it gate the risky work, estimate the demand, weigh the feasibility, choose one action per important URL, write the evidenced work order, and open the verification window after you ship.

Request a trace See the workflow overview