The technical foundation behind every build.
None of this is visible at a glance, and that's sort of the point — it's the unglamorous, unskippable work that decides whether a site actually gets found, used, and trusted, long after launch day. Here's exactly what's in every project we ship, with real examples, not just claims.
Real Schema.org structured data
Every site gets structured data matched to what the business actually is — Dentist, InsuranceAgency, LocalBusiness — with a real street address, not a placeholder. This is what lets Google and AI assistants understand and accurately recommend a business, instead of guessing from page text alone.
Semantic HTML throughout
Proper heading hierarchy (one H1, logically nested H2s and H3s) and real landmark elements — <nav>, <main>, <footer> — instead of a pile of generic <div> tags. This is how screen readers and search engines actually parse a page's structure, not just its words.
Mobile-first, responsive by default
Every layout is built and tested down to 390px wide, not adjusted afterward and hoped for the best. That includes details easy to miss — like a bio photo and its text staying readable on a phone instead of overlapping awkwardly.
Accessibility baked in, not bolted on
Visible focus outlines on every interactive element, prefers-reduced-motion respected for anyone who's set that preference, and every clickable thing is a real <a> or <button> — never a styled <div> with a click handler that a keyboard or screen reader user can't reach.
Honest, current content — not stuffed keywords
The real city and region show up naturally in the title tag, the meta description, and the visible copy itself — because that's what actually moves local search rankings and gets a business recommended by AI assistants, far more than any <meta name="keywords"> tag (which Google has ignored since 2009).
A documented system behind it
This isn't reinvented from memory on every project. There's an internal design system and checklist — covering accessibility, local SEO, and a discovery process — that every new build runs through before a single line of code gets written, so quality doesn't depend on remembering everything correctly each time.
Bugs we actually found and fixed — not hypotheticals
Anyone can claim a thorough QA process. Here's proof from real builds, each one logged in our internal design system doc so it can't quietly happen again.
The link that wouldn't open
A client's page failed to load on iPhone and iPad until we traced it to a canonical URL pointing at a domain that was never actually registered — a stale placeholder left over from an earlier draft.
The sideways-scrolling page
A code example inside a content grid quietly stretched an entire page wider than the screen on mobile — a well-known CSS Grid default that's easy to miss unless you actually measure scroll width, not just look.
The invisible footer text
A single global text-color rule, written for a light background, silently overrode the correct color on one dark footer — making real content nearly unreadable until checked directly.
The AI code review that was confidently wrong
An AI tool reviewed this exact site and flagged a "missing" hero element and a footer contrast failure — both stated with full confidence. We checked anyway: the element had been intentionally replaced weeks earlier, and the actual contrast ratio was 12.78:1, nearly three times the WCAG minimum. Two real fixes from that same review got kept; the two wrong ones didn't.
The site that compiled itself in the browser
A government-benefits directory was loading React, ReactDOM, and a full JSX compiler from a CDN and recompiling its entire page on every single visit — no build step, ever. Performance scored 36. Rewriting it as plain HTML with a few hundred lines of ordinary JavaScript took it to 97 that day, with no change to what the page actually said — and the current live build measures a verified 100 across every category.
The fix we thought was finished
A contrast audit on a client site fixed five failing color pairs and was logged as done. A second pass turned up two more — including the same near-failing color reused by a second CSS rule the first audit never checked — plus a footer heading level that skipped a step, unrelated to color entirely. Logged the actual lesson: check every text/background pair on the page in one pass, not just the ones already flagged.
The menu that ran out of room
Adding two new links to our own mobile navigation pushed the menu past a hardcoded 500px height cap, clipping the last few links — including the "Start a Project" button — with no way to scroll down and reach them. Fixed with a viewport-relative cap and internal scrolling. The same pass turned up this page still loading three separate Google Fonts the homepage had dropped for performance back in 11.17 — meaning the two pages of our own site were quietly rendering in different typefaces. Both fixed; zenmasterworks.com is back to Performance 100, Accessibility 100, Best Practices 100, SEO 100.
The search box that went silent
A perfect Lighthouse Accessibility score doesn't mean a blind visitor can actually use a page. Checked by hand, not by automated score: a live search box updated its results as you typed with zero feedback for anyone who couldn't see the change — no announcement, no count, nothing. Fixed with a status region that now announces "12 programs found" as you type. Same pass also caught a "Skip to main content" link that stayed invisible even when keyboard-focused, three pages missing that link entirely, a search field with no accessible name beyond a placeholder, and 105 decorative icons across six files that screen readers had no reason to announce but were never explicitly told to skip.
Real devices, not just a resized browser window
A page that looks right in desktop dev tools can still fail on an actual phone. Every build gets checked on real devices and real sharing methods — including the specific way the iOS bug above was hiding: a link sent over text message, not just typed into a browser.
What's actually running under the hood
What's in every build
- Real, crawlable HTML — content is readable by search engines and screen readers immediately, with no JavaScript required just to display it
- Plain files you own outright — move hosts, switch designers, or hand it off any time, with nothing trapped inside a proprietary builder
- Analytics only when you ask for it, on your own account — never a hidden third-party tracker
- Lightweight by default — no framework loaded just to render a button
What we don't do
- Recycled templates resold as “custom”
- Keyword-stuffed copy written for robots instead of people
- Fabricated testimonials or inflated stats
- Vendor lock-in that holds your own site hostage
SEO isn't a checkbox. It's the difference between being found and being invisible.
A beautiful site nobody can find isn't actually doing its job. The technical foundation is what makes everything else — the design, the copy, the calls-to-action — actually reach someone searching for exactly what a business offers.
- Structured data on every project, not just the "important" ones
- Mobile tested at real phone widths, every time
- Accessibility checked before launch, not after a complaint
- Real city and region content, never generic boilerplate
This is what's already in your free build.
Every one of these is already part of the site we build for you before you pay anything — not an upsell, not a "premium tier." Just the standard.
Start Your Free Build