The Engineering Standard Behind Every TVS Website

Every website TVS builds is measured against a detailed internal specification — seven ranking gates, an AEO layer, a pre-deploy checklist, and a document that is updated every time search changes. Here is what that means in practice.

Most websites are built to no documented standard. A designer has a preferred layout. A developer has a preferred stack. The client has preferences about colours. The result is a website that looks acceptable and does not rank — because looking acceptable and being technically correct for search are two entirely different things, and nobody in the room was working from a specification that treated them as the same problem.

TVS builds every website against an internal engineering standard. That document is the single technical authority for every decision we make on every build — from the framework we use, to the schema types we implement, to the anchor text rules we enforce, to the infrastructure we deploy to. It is updated when Google changes, when AI search changes, when our own research produces findings that the standard does not yet reflect.

This article describes what that standard covers and why the existence of it matters for the businesses we build for.

Why a standard exists at all

The gap between a website that exists and a website that ranks is largely invisible to the naked eye. Two websites can look similar — similar layouts, similar content depth, similar photography quality — and perform completely differently in search. The difference is almost always in the decisions that are not visible: the structured data, the canonical URL configuration, the internal link anchor text, the schema type, the image loading attributes, the title tag construction.

These are not complex decisions. They are consequential ones. A title tag written as “Home | Business Name” and a title tag written as “Electrical Contractor Umhlanga | Smith Electrical” are not equivalent. The second one contains the information Google needs to understand what the page is about and where it serves. The first one contains neither.

Multiplied across every page on every site, these decisions compound. A site where every page has been built against a consistent specification that enforces correct title structure, correct schema, correct canonical configuration, correct internal link discipline — that site outperforms one where decisions were made case by case, developer by developer, without a documented standard, almost every time.

The standard exists because the alternative — deciding these things from scratch on every build — is slower, less consistent, and more likely to miss the things that matter.

The framework choice

Every TVS site is built on Astro — a static site framework that outputs clean HTML with no client-side JavaScript by default. This is not an aesthetic preference. It is a technical decision grounded in what Google’s ranking systems actually measure.

Core Web Vitals — the technical performance metrics that feed into Google’s ranking signal — are directly affected by how a site is built. A statically-generated Astro site, served from a well-configured server, reaches the thresholds that matter (Largest Contentful Paint under 2.5 seconds, no layout shift, fast interaction response) without the performance engineering overhead that JavaScript-heavy frameworks require to reach the same benchmarks.

This means a TVS site starts with a performance advantage baked into the build architecture — not bolted on later as an optimisation project.

The seven ranking gates

The engineering standard is organised around seven gates that every TVS website must pass before going live. A site that fails any single gate cannot perform optimally on the others — the gates are not a checklist of nice-to-haves, they are a dependency structure.

The first gate is technical health — the Core Web Vitals thresholds, sitemap presence, no redirect chains between key pages. This is table stakes. A site that fails here is structurally penalised regardless of content quality.

The second gate is search intent alignment — every page has a unique headline, a unique title tag structured around the primary keyword and location, a unique meta description written to generate a click. These are not SEO tricks. They are how Google understands what a page is about and whether to show it for a given query.

The third gate is E-E-A-T — experience, expertise, authoritativeness, trustworthiness. Named principals on the About page. A real address. Verified social profiles. Consistent NAP (name, address, phone) across every surface where the business appears. LocalBusiness structured data with the correct business type. These are the signals Google uses to classify whether a business is a real entity worth sending search traffic to.

The fourth gate is topical authority — the site’s pages are organised around the business’s actual service areas, with a clear hierarchy, consistent internal linking, and no off-topic content that dilutes the semantic signal the site is sending about what it does and where it does it.

The fifth gate is user signals — the site is mobile-first, fast, and designed to keep people on the page long enough to get what they came for. A site that answers the user’s question before they leave — before they return to the search results and try a different result — sends a positive signal back into Google’s ranking systems. A site that doesn’t loses position over time.

The sixth gate is real-world trust — Google Business Profile with NAP matching the schema on the site, a Maps embed, consistent information across directories. This is the bridge between the site and the offline business it represents.

The seventh gate — and the one that most web agencies have not yet added to their standard — is AEO: Answer Engine Optimisation.

The AEO layer

AI-powered search has changed what it means for a business to be discoverable. Google’s AI Overviews, Gemini, ChatGPT, Perplexity — these systems do not send users to websites. They extract answers from websites and present them directly. A business that is not structured for extraction is invisible in this layer regardless of how well it performs in traditional search.

Every TVS site ships with a llms.txt file — the AI equivalent of robots.txt, a plain-text document at the site root that tells AI crawlers exactly what the business does, where it operates, how to contact it, and what its services are. This file is read by AI search engines during indexing and influences how confidently the AI can describe and cite the business.

Every TVS site also implements rich structured data beyond the basic LocalBusiness schema — FAQ schema on the homepage, Service schema on each service sub-page, and OfferCatalog schema for businesses with public pricing. These additional schema types make specific aspects of the business citeable as factual data points by AI systems. A business with a specific price in an OfferCatalog schema can be cited in an AI answer to “how much does a bathroom renovation cost in Durban” in a way that a business with “pricing available on request” cannot.

The AEO layer is not a speculative future concern. It is measurable now: a site built to the TVS standard passes the Agentic Browsing audit in Google’s PageSpeed Insights, the tool that measures whether a page is structured for AI agent interaction. Sites not built to this standard do not.

The pre-deploy checklist

Before any TVS site goes live — as a demo or as a production site — it goes through a pre-deploy checklist drawn from the engineering standard. That checklist covers over sixty individual checks across visual design, SEO, structured data, technical implementation, content quality, and deployment configuration.

Every title tag. Every canonical URL. Every internal link anchor (generic phrases like “click here” and “read more” are specifically prohibited — they trigger a named ranking demotion in Google’s internal systems). Every schema field. Image loading attributes. Structured data type accuracy. The relationship between the sitemap URL, the canonical URL, and the final URL the browser serves — these three must be identical on every indexable page or the site has an indexing problem that will quietly suppress its performance over time.

This checklist is not run casually. It is the gate between a build and a deployment. A site with unchecked items does not go live.

The document is updated

The engineering standard is a living document. It is updated when research produces findings that the current standard does not yet reflect.

The most significant update in recent months followed the publication and analysis of a large cache of Google’s internal ranking documentation — a leak from Google’s internal systems that surfaced the actual signals, weights, and named demotions that Google’s algorithms apply. TVS’s research team analysed this documentation and identified a number of signals that were not reflected in the existing standard.

Several of these findings are now in the engineering standard. The prohibition on exact-match keyword domains (a named demotion in Google’s internal systems, not a theory). The hostAge sandbox period for new domains (and what to tell clients about their ranking timeline as a result). The lastSignificantUpdate signal for content (which means that updating a post’s date without updating its content does not refresh Google’s freshness assessment of that page). The anchorMismatchDemotion applied to pages with generic internal link anchor text.

These are not widely known. They come from documented evidence, and the engineering standard was updated to reflect them within days of the analysis being completed.

This is the model: the standard is current, because the people building it are continuously researching what is actually happening in search — not what the conventional wisdom says should be happening.

What this means for a client

A TVS website is not built the way most websites are built. It is built against a specification that was produced by months of research, refined by real-world data from a market intelligence system monitoring 249 businesses daily, and updated continuously as search evolves.

The specification exists so that the decision-making behind every build is deliberate, consistent, and grounded in what actually works — not in what looks good, not in what is fast to implement, and not in what the client happened to ask for without knowing what they should have asked for.

The website is the implementation of a research-backed standard. The research is what makes the standard worth having.


TVS builds websites to an internal engineering standard that is updated as search evolves. Why this standard exists now — and what changed in search to make it necessary — is at Why the Window for Fixing This Is Closing. The full infrastructure behind the service is at The Systems We Built So We Could Do This Properly. If you want to understand how your current website measures against that standard, run a visibility check or speak to us directly.