Website Growth System (WGS)

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 an open technical specification 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.

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.

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.

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:

• 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 specification.

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.

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.

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 specification 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 specification on Zenodo is published under Creative Commons Attribution 4.0 International, so it may be redistributed and built upon with credit.
• 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.

Framework specified by <a href="https://danhnolan.com/en/wgs/">Danh Nolan (Website Growth System&trade;)</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>.

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.

Which specifications does the Website Growth System connect?

The Website Growth System connects five specifications: 4-ZIA for information architecture and landmarks, DLN for decision navigation, RCCOF for AI content generation, E-PROVE for proof stacking and PIOC for persona, intent, offer and CTA alignment. WGS is the operating system that runs them in one loop.

What does traffic without leads mean?

Traffic without leads is the failure WGS is built to remove: a site that gains impressions and sessions while inquiries stay flat. It usually means the pages answer the wrong stage of the decision, or that nobody can see which pages produce leads.

What happens in the Monday audit?

The Monday audit is a 30-minute review of the three-column dashboard, from Search Console impressions to GA4 sessions to GA4 key events. It looks for three anomalies: high views with low leads, high impressions with low CTR, and high traffic with zero key events.

How should FAQ answers be written under WGS?

FAQ answers should be two to four sentences long and answer the core question without preamble. It is one of the five content rules WGS applies so that AI engines can extract an answer directly.

How should the Website Growth System be cited?

The Website Growth System should be cited by its DOI, 10.5281/zenodo.22886877, with Danh Nolan as author and Zenodo as the repository. It is published under CC BY 4.0, so it may be reused with credit.