The Context Void
Everyone claims they can build a website in ten minutes with AI. I watch founders launch apps in hours that generate massive MRR, and that’s fantastic for them. But when you’re building a public-facing website, how it’s built dictates how it performs.
With front-end web development, there’s no hiding your bad code. Anyone, and more importantly any search engine crawler, can see it.
Building a page has never been the actual challenge. The challenge is balancing a client’s business objectives with an ever-growing list of tracking pixels, CRM integrations, accessibility laws, and shifting Google performance standards across a dizzying number of devices.
For years, web development was a forced compromise. Developers gave clients visual page builders so they could manage their own content, and accepted the resulting code bloat and slow load times as the cost of doing business. I inherited other people’s messy code, stared at the architecture, and tried to figure out why they made the decisions they did.
AI disrupted that model, but it introduced a new trap.
Years ago, a business coach asked me the difference between knowledge and knowing. Knowledge is education. You learn a concept and understand the rules. Knowing only comes from applying those concepts repeatedly and building expertise over time.
AI has infinite knowledge, but it doesn’t know.
It made code cheap, but it didn’t replace experience. I use AI in my own workflow every day to diagnose issues and write code to a standard. A model can generate what you ask for in seconds. It can write the markup, but it can’t architect a system that survives real-world business requirements.
The Experiments and the Pivot to Measurement
I needed to test where that boundary was. In January, I ran a baseline test. I handed Gemini an approved client copy document and gave it a simple prompt to build an industry-appropriate website. In minutes, it generated the files, pulled placeholder images, and added micro-interactions.
Then I read the page, and to make the design look good, the AI had selectively rewritten, trimmed, and omitted entire sections of the approved copy. When I forced it to use the exact text, the design fell apart. It lost all style and flow because the model lacked the practical experience to assess a narrative and recommend a custom layout around it.
That first experiment ended in a split effort. The AI conceptualized roughly half of the site, and I manually implemented the rest. It saved me almost zero time. The tool proved highly effective for forensic code analysis provided I gave it highly explicit instructions, but as a primary builder, it failed.
A few months later, Claude Cowork was released, and I decided to run the same experiment. I fed it a similar prompt, identified the specific business vertical, and asked for a mobile-first build.
The code quality was decidedly better. I was impressed at first glance, but the structural flaws remained. The output was just a selection of isolated modules. It felt like a generic template rather than a website that told a cohesive story or followed best practices. That was the most surprising takeaway: the model had access to all the knowledge in the world, but it simply wasn’t using it.
I realized the chat interface was the limitation, so I moved to the terminal and spent six weeks building a comprehensive, automated Claude Code project. The goal was to force the model to apply the web development best practices it already knows but rarely executes unless explicitly commanded. I built complex decision trees to govern the architecture.
The outcome was identical. In my quest to make sure the AI strictly followed the rules, I ran straight into a wall of sameness. Every site it generated felt generic. You can teach a model the rules of CSS, but you can’t program twenty years of design judgement.
That failure exposed the real opportunity.
I stopped trying to automate taste and focused entirely on the technical foundation. AI is terrible at open-ended creativity, but it excels at writing performant markup.
So I kept the system and moved the judgement back where it belonged. I make the architectural decisions. AI writes the markup to them. Every site I ship runs through that pipeline and gets verified against the same instruments.
To be very clear: this approach is entirely about technical optimization, not written content. AI can’t replace a firm’s unique expertise or voice, but it can ensure the technical foundation carrying that message is flawless.
To eliminate AI hallucinations and gaslighting, I decided that external measurements had to be the only acceptable bar. I tied the system directly to Google PageSpeed Insights for performance and WAVE for accessibility. I also required strict schema architecture so the technical foundation could be read by AI crawlers. If a website is built well, it will score well on those independent platforms. The most effective way to leverage AI was to ensure it produced code that strictly met today’s standards.
In the traditional agency model, these technical requirements were always treated as expensive add-ons. A client would buy a website and then receive a separate statement of work for thousands of dollars to fix accessibility issues or optimize speed. Clients naturally pushed back, wondering why it wasn’t included in the first place. It wasn’t that agencies were trying to be deceptive. Fixing these issues manually was highly labour-intensive, which is why they were sold as separate buckets. It was simply the reality of the industry at the time.
I realized I could use AI to bridge this gap. I set out to build my own system.
The Reality Check (Auditing 824 Accounting Firms)
Websites don’t scream when they break. They fail silently. A slow page quietly turns visitors away before they ever see what you do. A missing sitemap forces search engines to guess your structure. Missing schema makes your business invisible to emerging AI tools. Poor accessibility alienates users and creates legal exposure.
I needed to validate how widespread this digital rot actually is.
I built a prospecting tool that drew firms from Google Business Profile listings across roughly 100 Ontario cities and towns, stratified by population band so that small towns weren’t drowned out by Toronto. I kept only firms that had made at least a minor investment in their marketing by maintaining a profile with a linked website.
Google ranks its listings partly on profile completeness and review activity, which favours firms already doing some marketing. That biases this corpus toward the better-maintained end of the market, which means the real picture is probably worse than what follows.
Between September 16 and 23, 2026, I audited those homepages. Each site was graded on a pass or fail matrix across four pillars: performance, accessibility, search groundwork, and AI readability. I wrote the software that runs the audit. It uses Google’s own performance testing and WebAIM’s own accessibility engine, which means every number below can be reproduced on the public versions of both tools. What’s mine is the reading of the results, not the measuring.
Not every site could be measured on every test, and the population is worth stating plainly before any percentage is.
| What was counted | Sites |
|---|---|
| Listings scanned | 869 |
| Excluded from the benchmark | −45 |
| Firms with their own website | 824 |
| Broken sites: error pages, expired accounts, parking pages | −24 |
| Live sites | 800 |
The 45 exclusions are listings that aren’t an accounting firm’s own working website: 10 law firms, 9 dead domains, 7 not serving, 5 duplicate firms, 3 not a firm, 2 insolvency trustees, 2 other professions, 1 duplicate site, 1 wrong URL, and 5 that aren’t a website at all. That last one is a judgement call. A Facebook page, a booking page, a directory profile and another firm’s client portal are all real listings, and none of them is a site of its own.
From the 800 live sites, each check reached a different number of them.
| Check | Measured | How it gets there from 800 live sites |
|---|---|---|
| Speed | 791 | −2 where the speed test scored only a block page, −7 with no complete result |
| Accessibility | 791 | −4 Cloudflare challenge pages, −5 with no WAVE result |
| Speed and accessibility both | 783 | Same count, different sites: 8 are in speed only, 8 in accessibility only |
| Search and AI readability | 751 | −44 that blocked our own fetch, −5 with no HTML captured |
| All four pillars | 741 | Measured on every one of the above |
Every figure below names which of those it sits on.
The results were staggering. Of the 741 sites measurable on all four pillars:
Exactly 3 met the standard on every one. Fewer than 1 in 200.
One of those three is a single-page business card rather than a full website.
That failure rate invites an obvious objection: the bar must be unreasonable. It’s Google’s bar and the W3C’s, not mine, and these sites cluster nowhere near it. The typical firm scored 62 on mobile where Google calls 90 good. The bar is entirely reachable by anyone aiming at it.
Almost nobody is aiming at it, and that’s the actual finding.
The Anatomy of Silent Failure
A broken website rarely takes itself offline. It stays live, looks functional to the business owner, and quietly turns away prospects.
The Accessibility Failure
WCAG 2.0 set the minimum contrast ratio for body text, and it carries forward into WCAG 2.2. In Ontario, the AODA makes WCAG 2.0 Level AA conformance a legal requirement for organizations with 50 or more employees.
- 77.5% of the 791 sites measured for accessibility fail basic text contrast standards.
- 28.7% of those 791 have at least one form field with no label.
To a prospect using a screen reader, those fields don’t exist. These are automated findings, and automated testing only reaches roughly a third of what accessibility actually covers. It catches the obvious failures. Everything it can’t see (keyboard navigation, mobile touch target sizes, focus behaviour, whether alt text actually describes anything) sits underneath these numbers unexamined.
The Infrastructure Fragility
The technical infrastructure is equally fragile. These are professional practices actively collecting names, emails, and phone numbers through forms on unencrypted pages.
- 49 firms, about 1 in 15 of those where both connection checks completed, force visitors to land on an unencrypted HTTP page.
- 30 have working HTTPS but don’t send plain http visitors to it.
- 19 have no working HTTPS at all.
The Speed Illusion
Speed metrics present an illusion of competence. Lab measurements vary wildly from run to run.
- 31.7% of the 1,541 device tests with three or more runs saw the score swing by more than 10 points.
One site scored 93, then 83, then 41 on the same day. The page was the same size each time and its main content loaded just as quickly. What changed was the third-party scripts on it, which kept the browser busy three times as long on the last run as on the first. That’s why a screenshot of one good score from an agency proves very little.
Each site was tested three times on the same day, with more than an hour between runs for every site but one. The spacing is deliberate. Google caches a result for about 30 seconds, so back-to-back runs return the same number and tell you nothing. The test itself holds the conditions steady, throttling the connection and simulating the same device every time. So when a score moves 50 points in a day, it isn’t the network. It’s what the page loaded.
Google also collects loading times from real Chrome users, but only for sites with enough traffic to measure. That’s about 1 in 10 of these firms, 81 of 824. For everyone else the lab test is the only measurement that exists, and nobody knows what their visitors actually get, including them.
A lab test measures how a site is built, under one standard set of conditions. It doesn’t promise that every visitor suffers. It says the margin has been spent, and the visitor on a weak signal in a parking lot is the one who finds out.
The AI Blindspot
Finally, there’s the AI blindspot. The test looks for structured data: a machine-readable summary of who the firm is and what it does, sitting in the page’s code where a crawler can find it. Without it, an AI has to work your services out from your prose, and mostly it doesn’t bother.
Only 57.3% of the 751 readable homepages passed. A modern AI crawler can’t recommend your firm if it can’t parse your services.
These firms paid for websites assuming the code would remain stable. But the web shifted, the standards evolved, and their digital assets silently failed.
The Project Model is Broken
Websites are traditionally sold as projects. A business pays a large upfront fee, whether it’s $5,000 for a local firm or six figures for an enterprise, and the agency delivers a finished product.
The scope is detailed, the design is approved, and the handover is finalized. The agency takes all the right steps. But those steps represent a single moment in time, not ongoing compliance. While an agency might sell a retainer for SEO or content updates, the technical foundation is almost always abandoned on launch day.
Most organizations view a website as a one-time capital expense. They pay the invoice assuming they won’t have to buy another site for five years. When an agency eventually tells them their site is failing and requires a complete rebuild, the client’s reaction is often frustration: Was it built wrong the first time?
It wasn’t built wrong. It was built to the exact standard of the day it launched. Then the standard moved, the site didn’t, and nobody was checking. That’s drift. The failure is that no one told the client that digital standards shift constantly, and that ignoring those shifts breaks their web presence.
The result is a capital asset that begins depreciating the day it goes live. Building a website as a static project is a broken model.
Treating the Web Like a Utility
A website must be treated as a utility, not a car purchase. When there’s a problem with the power grid, you expect it to be fixed and updated. Your web presence should operate the same way. It shouldn’t be locked behind static, project-based work.
AI made producing code cheap. It did not make producing correct code cheap, because correctness is judgement and verification, and those are still mine. What changed is that the cost no longer has to land as a lump sum on day one.
I’ve fundamentally changed how I service small and medium-sized businesses, particularly compliance-heavy professional firms. I no longer mandate large upfront build fees.
Instead, I treat the website as a service. Clients pay a flat monthly fee based on the size of their site. That fee includes the build, the hosting, ongoing maintenance, and continuous technical verification across speed, accessibility, findability, and AI readability. Every site on this model is re-verified every 90 days. This is how I protect against drift.
Each build is delivered to a strict, verifiable standard: a mobile Google PageSpeed score of 90 or better and a desktop score of 95 or better, both measured as the median of multiple runs, zero detected errors in WebAIM’s WAVE engine, accurate schema architecture, and coverage verified in Google Search Console with no errors. I’m not selling manual human accessibility testing. I’m applying rigorous automated benchmarking to ensure the technical foundation remains sound.
Automated testing flags what’s measurable. Whether a site actually works for someone navigating by keyboard or listening to a screen reader is a question only a person testing it can answer. That’s a different service, and no automated result should ever be called compliance.
There’s only one boundary: third-party marketing bloat. I guarantee the performance of the foundational build. If a client requires heavy CRM integrations, Google Tags, or tracking pixels, I benchmark and verify the pristine site first. Then, I implement their tracking. They get to see exactly what their marketing scripts cost them in load time. I protect the foundation, and the client decides how much performance they’re willing to trade for analytics.
A monthly fee gives them a new website alongside ongoing technical verification with the results in writing, new pages as needed, and coverage monitored in Search Console. Every two years I offer a full design refresh on the same terms as the original build. That ends the traditional rebuild cycle and keeps their digital presence current.
My benchmark findings confirm a harsh reality. Websites that fall below standard don’t take themselves offline. They don’t tell you something is wrong. They just quietly continue to exist. That is what I’m setting out to stop.
I’m publishing the complete 2026 CPA Digital Baseline Report, with the full failure rates and the testing methodology across all 824 audited firms. Subscribe and you’ll get it when it lands.
