The Website Growth System™ (WGS) is an operating framework that runs a website's organic growth as one closed loop across four pillars: Search Intent, Entity, Conversion Rate Optimization and Tracking. It is not a ranking tactic and not a checklist. Its claim is narrower and harder: that traffic only becomes revenue when the four pillars feed each other, and that a website which cannot measure a conversion per URL cannot improve on purpose.
What the Website Growth System is
The Website Growth System is a specification for the order in which organic growth work is done and the numbers by which it is judged. It defines four pillars, the causal chain that connects them, the weekly cadence that keeps the chain running, and the condition under which the system may be called correctly implemented. That condition is a closed loop: a measured conversion must be able to change next week's content plan.
Three terms are used throughout this specification with fixed meanings:
- Pillar: one of four areas of responsibility, each with a required output and one metric. A pillar is not a department and not a job title.
- Loop: the path Intent → Entity → CRO → Tracking → Intent. The loop is closed when the last arrow carries a number, not an opinion.
- Money page: the URL a visitor reaches when they are ready to act. Every other page owes it a next step.
The framework is published as a working paper with a permanent identifier, and the four pillar pages below are its normative sections.
Why an operating framework and not an SEO checklist
An operating framework answers a question a checklist cannot: in what order, and measured by what. A checklist tells a team what exists to be done, which is why two teams can complete the same checklist and get opposite business results. The Website Growth System exists because ranking improvements and revenue improvements are not the same event, and a list of tasks cannot tell you which one you just bought.
In practice, sites that pass a technical checklist and still produce no enquiries fail for three reasons, and all three are ordering failures rather than missing tasks. The service page offers no next step. The content answers questions asked by people who are not yet deciding. And no measurement exists, so nobody can name the page that produced last month's customers.
| Dimension | Conventional SEO checklist | Website Growth System |
|---|---|---|
| Priority | Items are worked through in list order, with no ranking against a business goal. | Pages that can produce an enquiry are fixed first; topic coverage is widened afterwards. |
| Unit of measure | Positions, sessions, number of articles published. | Calls, form submissions and chat starts, attributed per URL. |
| Content | Written per keyword, often with no destination to hand the reader to. | Written per decision stage, each page owing one next step to a money page. |
| Cadence | A monthly report, with optimisation driven by whatever is noticed. | A weekly loop: read data, commit a backlog by impact, ship, log. |
| Entity and machine readers | Rarely addressed, or addressed last. | Named and declared from the start, as the condition for being quoted correctly. |
| Definition of done | Every item ticked. | The loop closes: a conversion is measured and it changes the next plan. |
The four pillars and the causal chain between them
The four pillars of the Website Growth System are Search Intent, Entity, Conversion Rate Optimization and Tracking, and they are not four independent workstreams. They form a causal chain in which each pillar hands a specific asset to the next one. Correct intent brings people who can still act, a clear entity earns their trust, the conversion path turns that trust into an action, and tracking measures the action and corrects the intent map.
| Pillar | Core responsibility | Required output | Metric | Failure without it |
|---|---|---|---|---|
| 1. Search Intent | The right need at the right decision stage. | An intent map; one owning URL per intent group. | Intent coverage across the target query set. | Traffic grows and nobody is ready to buy. |
| 2. Entity | Search engines and language models identify you correctly. | One canonical name per thing, terms defined on first use, one Organization node. | Citation in generated answers; consistency of brand mentions. | Good content that machines will not quote. |
| 3. Conversion Rate Optimization | A next step the reader is ready to take. | A stage-matched call to action; proof placed beside the claim. | Conversion rate per page. | Visitors reach the service page and leave. |
| 4. Tracking | Which URL produced a customer, and where the loss is. | Named events verified live; a three-column dashboard. | Leads attributed per URL and per query group. | Every decision is a guess and the loop cannot close. |
Each pillar has its own normative page: Search Intent, Entity, Conversion Rate Optimization and Tracking.
Why the loop has to close, and what an open loop looks like
The loop closes when a measured conversion changes the next plan. This is the one condition that separates the Website Growth System from a sequence of good practices, because all four pillars can be staffed, budgeted and worked on while the loop stays open. An open loop is the ordinary failure state of organic growth programmes, and it is difficult to see from the inside precisely because everyone is busy.
An open loop has a recognisable shape. Work is reported as output rather than outcome: articles published, pages optimised, positions gained. Nobody can name the URL that produced the last enquiry. Optimisation targets are chosen by whoever argues best in the meeting. And because the fourth arrow carries no number, the intent map is never corrected, so the same wrong pages are widened month after month.
Missing one pillar does not stop the site from working. It stops the loop from closing, which is a different and quieter kind of failure: the machine still runs, it just cannot learn.
Two different orders: causality and implementation
The order of causality and the order of implementation are different orders, and confusing them is the most expensive mistake available when adopting this framework. Causally the chain runs Intent, Entity, CRO, Tracking. When actually deploying, the correct order is close to the reverse: build measurement first, fix the pages nearest the money second, and widen content coverage last.
The reason is not subtle. If measurement is installed last, then everything built before it was built blind, and the first number arrives after the budget is spent. If content is widened before the money pages have a next step, the traffic that arrives has nowhere to go, and the report improves while the business does not.
So this specification states both orders explicitly, and a plan that follows the causal order as a work plan is out of specification.
The weekly operating cadence
The Website Growth System runs on a weekly cadence rather than a monthly report, and the cadence is part of the specification rather than a scheduling preference. A week is short enough that a wrong decision costs one week, and long enough that a shipped change can show a signal. A month is long enough for a team to finish being wrong before anybody notices.
| Step | Time box | What happens |
|---|---|---|
| 1. Read the dashboard | 30 minutes, start of week | Three questions in order: which pages have views but no key events, which pages gained impressions but hold a low click-through rate, and which pages hold traffic while leads stay flat. |
| 2. Commit a backlog by impact | 1 hour | Three to five items, not more. Each item carries the evidence from the data, the metric it should move, and one named owner. |
| 3. Ship | The rest of the week | Content, on-page, conversion path, internal links or technical work, in the order already committed. The order is not renegotiated mid-week. |
| 4. Log the change | End of week | What changed, on which URL, on which date. Without this log the following week cannot tell a result from a coincidence. |
The log written in step four is the part most often skipped and the part that makes the rest work. Without a dated record of what changed on which URL, the following week cannot distinguish a result from a coincidence, and the loop degrades into a sequence of confident guesses.
The 30-day deployment roadmap
The first thirty days of a Website Growth System deployment are not spent producing content. They are spent building the measurement, choosing the five to ten URLs nearest to an enquiry, and giving those URLs a next step. Content volume before measurement produces a better-looking report and the same revenue, which is the outcome this roadmap exists to prevent.
Week 1: targets, URL priority and the measurement layer
Week one must end with two artefacts: a priority list of five to ten URLs chosen because they are near an enquiry, and a dashboard that records calls, form submissions and chat starts. Conversion events are named and then verified live before any number from them is treated as evidence. The metric committed for the quarter is enquiries, not positions.
Week 2: the intent map and the internal links into the money page
Week two must end with a complete intent map and internal links that lead into the money page. Every target query is grouped into a decision stage, each group is assigned exactly one owning URL, and the pages that answer early questions are given a contextual link onward to the page that answers the next one.
Week 3: entity normalisation and the proof that supports each claim
Week three normalises the entity and places the proof. One canonical name is chosen per thing and used everywhere, important terms are defined at first use, the structured data declares a single organisation, and each claim that a reader has to believe gets its evidence placed next to it rather than on a separate page.
Week 4: the conversion path and closing the loop
Week four tunes the conversion path and closes the loop. Calls to action are matched to the decision stage of the page they sit on, forms are cut to the fields the next step actually needs, and the first weekly review is run against real numbers so that week five's backlog comes from data rather than from opinion.
Machine-readable output: structured data and AI retrieval
Machine-readable output is a consequence of doing the four pillars properly, not a fifth pillar. When intent is mapped, terms are defined, one page owns each topic and the structured data declares a single organisation, the content is already in the shape that answer engines and generative systems can quote. No separate framework is required for that, and this specification does not introduce one.
Five writing adjustments make the difference between content a machine can quote and content it cannot:
- Answer first: the two sentences after a heading state the conclusion, so neither a reader nor a retrieval system has to read the whole section to learn the position.
- One definition per term: each important term gets a sentence of the form "X is ..." at first use.
- Full names before abbreviations: write Google Search Console and Google Analytics 4 in full before using any short form, because an abbreviation alone is ambiguous to an entity resolver.
- Tables and lists for procedures and comparisons: structured blocks are parsed more reliably than the same content in prose.
- A declared graph: the page states in JSON-LD what it is, who wrote it, and which entity it belongs to, rather than leaving that to inference.
How the Website Growth System relates to Decision Ladder Navigation
The Website Growth System and Decision Ladder Navigation™ answer two different questions and are designed to be used together. Decision Ladder Navigation decides what each URL is for and where it hands the reader next, across five decision rungs. The Website Growth System decides how the whole site is operated and measured week by week, across four pillars.
The join between them is the Search Intent pillar. An intent map is a statement about which decision stage a query belongs to, which is the same statement a decision rung makes about a page. A team that has already structured its site by the five rungs has done a large part of the first pillar, and a team starting from this framework will find that the second half of the Search Intent pillar is a decision ladder by another name.
The Definition of Done rubric
A Definition of Done rubric exists so that "finished" is a measurement rather than an opinion. In this specification it is a scored checklist applied to a page or a release across the four pillars, and its purpose is to make a disagreement about quality resolvable by reading the score rather than by seniority. The full rubric is part of the deposited working paper.
What matters at specification level is the rule the rubric enforces: a page is not done because it was published, and a release is not done because the tickets are closed. Both are done when the pillar outputs exist and can be verified by someone who did not do the work.
When the Website Growth System applies, and when it does not
The Website Growth System applies when a website is expected to produce enquiries and when somebody is accountable for that number weekly. It does not apply, or applies only in part, where there is nothing to measure or nobody to act on the measurement. Naming that boundary honestly is part of the specification, because a framework applied where it does not fit produces ceremony rather than growth.
| Condition | In specification when | Out of specification when |
|---|---|---|
| Metric | The metric is enquiries, calls or form submissions, and one named person reviews it weekly. | The metric is positions, sessions or article count. |
| Content | Money pages are fixed first and articles lead into them. | Articles are published by inspiration and internal links have no destination. |
| Call to action | Each page carries a next step matched to its decision stage. | Every page carries the same contact prompt at the bottom. |
| Data | Tracking is verified, the dashboard is read weekly, and the backlog comes from it. | Only a monthly report exists and no page can be tied to an enquiry. |
| Entity | One name per service and per term, used consistently across the site. | The same service is called something different on each page. |
The Website Growth System compared with keyword-first SEO
Keyword-first SEO and the Website Growth System both require sound technical work and competent writing, and they differ in where they start and how they judge the result. Keyword-first practice starts from a list of queries to be ranked. This framework starts from a number of enquiries per month and works backwards to the pages, the trust signals and the measurement that could produce it.
| Point of comparison | Keyword-first SEO | Website Growth System |
|---|---|---|
| Starting point | A list of queries that should rank. | A target number of enquiries per month from organic search. |
| Order of work | Optimise each page for its chosen query. | Measurement and money pages first, topic clusters afterwards. |
| Content basis | Search volume and keyword difficulty. | Decision stage, with a next step on every page. |
| Measurement | Positions, organic sessions, pages in the top ten. | Enquiries per URL, conversion rate per page, return per channel. |
| Entity and machine readers | Usually skipped or postponed. | Normalised from the start as a precondition. |
| Optimisation rhythm | Monthly reporting, work handled on request. | Weekly loop: read, commit, ship, log. |
Rights, licensing and how to cite this specification
Applying the Website Growth System in your own work is free and needs no permission from anybody. You may use the framework in internal architecture, in commercial products and in client engagements without a fee and without asking. The name, the wording of this specification and its tables are the parts that are reserved, and the deposited paper carries an open licence for reuse with attribution.
- Free application: use the four pillars, the loop and the cadence in commercial and client work, with no fee and no prior authorisation.
- Reserved: the name Website Growth System™ and the original text, tables and diagrams of this specification.
- Deposit licence: the working paper on Zenodo is published under Creative Commons Attribution 4.0 International, so it may be redistributed and built upon with credit.
- Academic citation: cite the deposit, not this page, because the deposit carries the version and the permanent identifier.
Copyright covers expression, not ideas. Nobody needs permission to read this, build a four-pillar operating model of their own and call it something else. What is protected is the name, the words and the priority date.
One-click attribution snippet
Publishers and authors citing the framework can copy this standard attribution snippet:
Framework specified by <a href="https://danhnolan.com/en/wgs/">Danh Nolan (Website Growth System™)</a>. DOI: <a href="https://doi.org/10.5281/zenodo.22886877" target="_blank" rel="noopener noreferrer">10.5281/zenodo.22886877</a>. ORCID: <a href="https://orcid.org/0009-0007-7906-5091" target="_blank" rel="noopener noreferrer">0009-0007-7906-5091</a>.Applying WGS™ in commercial and client work is free and requires no permission. The deposit is published under CC BY 4.0. See full terms in the master specification.
Frequently asked questions about the Website Growth System
These are the questions asked most often about the framework itself rather than about implementing it: what it is, whether it replaces technical SEO, why the abbreviation collides with a geodetic standard, and how long the loop takes to close for the first time.
Does the Website Growth System replace technical SEO?
No. Technical SEO is a precondition of this framework rather than an alternative to it. A site that cannot be crawled or rendered will fail every pillar at once, so crawlability, indexation and page performance are assumed rather than restated here.
Why does the abbreviation WGS collide with the World Geodetic System?
Because the three letters were already taken, and pretending otherwise would be a naming error. The World Geodetic System, specifically WGS 84, is the reference frame used by the Global Positioning System, and it is far better known. This specification therefore declares the collision in its structured data instead of leaving an entity resolver to guess.
In what order do the four pillars actually run?
Causally they run Intent, Entity, Conversion Rate Optimization, Tracking, and then back to Intent. As a work plan the order is close to the reverse: build measurement first, fix the pages nearest an enquiry, then widen coverage. Both orders are stated above because using the causal order as a work plan is the common and expensive mistake.
How long before the loop closes for the first time?
The loop closes for the first time when a measured conversion changes the next plan, and how long that takes is not published here. The honest answer depends on variables this framework does not control: the state of the existing measurement, how many pages sit near an enquiry, and how quickly a change can be shipped. The 30-day roadmap commits to the sequence, not to a date.
Can a brand new website use this framework?
Yes, with one adjustment: a new site has no data to read in the weekly review, so the first cycles are run against the intent map and the conversion path rather than against numbers. The measurement layer is still built first, so that the loop can close as soon as any traffic exists.