The technical principles we build to

Every URL ships its own document

A route that does not return its own fully-formed HTML is not really a page as far as a crawler reading the initial response is concerned. Each URL should emit a distinct title, a self-referencing canonical link, its own meta description and its own body content before any JavaScript runs.

This is not a theoretical preference. The NorthGuard audit found nineteen routes returning byte-identical HTML, because the site shipped a client-rendered shell with no server-side rendering and no prerendering. Crawlers reading the initial HTML — and Google, before its rendering phase completes — had to execute JavaScript just to discover that the routes differed at all. Moving the site onto prerendering so each route emits its own document at build time removed that dependency. A Schkovl co-founder holds a partner stake in NorthGuard Window Film, so this is not an arms-length client relationship; the full disclosure is on the case-studies page.

The same defect appeared on a second engagement in a different form, which is what turned the observation into a principle rather than an anecdote.

Verify what production actually serves

Code that exists in a repository is not code that runs in production. On the GlassGuard engagement, production traffic was being served as a static deployment — a file server reading pre-built HTML — while the site's own server-rendering code assumed a live server that never ran there. Everything depending on that server, including server-side redirects, was silently doing nothing.

The rule that follows: check the deployed artefact, not the source. Fetch the URL, read the bytes that came back, and compare them against what the code claims should have happened. A build that passes locally and a production response that is correct are two different facts.

Legacy URLs get the same treatment. Six old service-area pages from a previous host were mapped to their new locations so that existing links and search-engine records resolve instead of returning a 404.

Structured data and answer-engine readability

Prospects increasingly research vendors through generative interfaces that synthesise an answer with no click involved. Ranking on a results page and being cited inside an answer rely on overlapping but distinct signals, so we build for both.

In practice that means structured data, direct-answer content, and pages precise enough to be quoted accurately. Clarity and markup appear to matter more to answer engines than they historically have to traditional ranking, which is the one place where a small business can outcompete a larger, vaguer competitor on equal terms.

Performance and mobile-first as build constraints

Core Web Vitals and mobile-first responsive layout are treated as constraints on the build rather than as a post-launch optimisation pass. A slow, generic or template-assembled site loses visitors before the copy is read, which makes performance a conversion problem before it is ever a ranking problem.

Standard tooling, because handover has to be possible

Builds run on open, standard tooling that another team could take over. The ownership commitment depends on it: a repository the client owns but only its original authors can operate is not genuinely transferable.

That rules out proprietary frameworks and hosted builders for custom work, and it is the reason a staging environment, repository access and shared communication channels are part of how a project runs rather than a courtesy extended at the end.

Agentic systems run on least privilege and human approval

Agentic AI systems are built with least-privilege permissions and human approval gates. An agent's access to a system is not an implied permission to act in it — access to an inbox does not imply permission to send messages or to read unrelated correspondence, and creating or changing an appointment requires explicit rules rather than inferred intent.

Boundaries are drawn by consequence. Factual lookups against approved, current information are separated from disputes, policy exceptions and anything involving money, and there is always a defined path to a person. When a dependency is unavailable — a calendar connection that cannot be reached, for instance — the correct behaviour is to explain the limitation and hand off, not to promise a slot it cannot verify.

A demo is not an acceptance test

A successful demo tends to use the questions the builder anticipated. Real users ask oddly phrased things, combine two requests in one message, or go straight outside scope, and an agent that has only been tested against a script has not been tested for the environment it is about to enter.

So readiness is scored against a test set built from real, anonymised past enquiries — typically fifty to a hundred — with three outcomes tracked separately: a correct answer, a safe refusal where the system recognised it lacked the information, and a correct escalation to a person. A confidently wrong answer is the failure mode that damages trust, and its rate needs to be as close to zero as the system can achieve.

Testing continues after launch. Products, prices and policies change, and an agent that scored well at go-live drifts if nothing re-tests it. A defined re-testing cadence is part of the engagement rather than an optional extra.

Re-run the test that found the gap

Every build ships behind measurement, and the closing step is to re-run the same test that identified the problem in the first place. If the number has not moved, the work is not done.

That is also why the measurement has to be chosen before the build rather than after it. A metric selected once the work is finished will tend to be the one that happens to look good.

Where to go next

Last reviewed

The facts on this page were last checked against published Schkovl sources on 2026-09-20.

Everything here is drawn from material already published on this site. If something looks wrong, our editorial standards and corrections policy explains how to have it corrected.