Web Development
Method 21 builds websites that are fast, editable by the people who own them, and legible to the systems that decide whether a company gets found. We run the search programs on the sites we build, which changes what we build.
What we build
Marketing sites, technical product and specification sites, e-commerce, and web applications where a business process needs to live online. Most of our work is WordPress, some is Shopify, and some is custom where a platform would be doing more harm than good.
Rendering decides whether a site can be found
Most AI crawlers do not execute JavaScript, and they operate on short timeouts. Content that only appears after the browser runs a script is invisible to them, even when it looks perfect to a human visitor. Google is the exception that proves the rule: it renders JavaScript, but documents the deferred, resource-limited process it uses to do it.
The test takes ten seconds and needs no tools. Open a key page, choose View Source rather than Inspect, and search the raw HTML for your headline and your first paragraph. If they are not there, the page is empty as far as those systems are concerned, and no amount of content or link building will fix it.
This is the single highest-return technical decision in a build, and it is made early. A site rendered on the server or generated as static files is readable by everything. A client-rendered single-page application is readable by browsers and by Google, and largely invisible to the rest.
What else is decided at build time
Several things that are cheap to get right during a build and expensive to retrofit afterwards.
| Decision | Why it matters later |
|---|---|
| Server-side rendering | Determines whether AI crawlers and non-JavaScript clients can read the page at all |
| Time to first byte | Slow responses get abandoned by crawlers on timeout and by people on impatience. Google's Core Web Vitals put good Largest Contentful Paint under 2.5 seconds, which in practice needs server response well under half a second |
| Semantic HTML and heading order | Engines extract passages from structure. Headings used for visual size rather than hierarchy make a page harder to quote |
| URL structure and depth | Pages buried three or more levels down read as unimportant. Changing URLs later triggers relearning and volatility |
| Structured data | Reinforces what the business is and keeps facts consistent across the site |
| Accessibility | Focus states, contrast, labels and landmarks are straightforward during a build and awkward to add to a finished site |
A site built without these decisions is not broken. It just starts every subsequent search program in a hole, and the first months of that program get spent digging out.
How a build runs
- Discovery. What the site has to do, who it is for, what the sales process actually looks like, and what the current site gets right.
- Architecture. Page structure, URL plan and template set decided before design, because they are the expensive things to change.
- Design. Templates rather than page-by-page compositions, so the site stays coherent as it grows.
- Build. Server-rendered, componentised, with content editable by your team without a developer.
- Launch. Redirect mapping, analytics and tracking verified before the switch, not after.
What happens to rankings during a rebuild?
They wobble. Even a technically flawless migration causes temporary volatility while engines relearn the site. Anyone who promises otherwise has not done many.
What reduces the damage is a complete redirect map from every old URL, keeping the URL structure where it already works, and not treating a redesign as an excuse to reorganise everything at once. Running paid traffic to key pages immediately after a migration also helps, by feeding engines the engagement signals they are busy relearning.
What we build on
| Platform | Best fit |
|---|---|
| WordPress | Content-led marketing and technical sites where the team needs to publish without a developer |
| Shopify | Product sales where payments, inventory and checkout should be someone else's problem |
| Custom applications | A business process that no off-the-shelf platform models properly |
The design, responsive, UI and UX and e-commerce pages cover each area in more detail.
Frequently asked questions
Do we own the site when it is finished?
Yes. You own the code, the hosting account, the domain and the content. Nothing is built on a proprietary platform that only we can maintain, and nothing stops working if you stop working with us.
Can our team edit it without a developer?
That is the intent. Content, pages and images should be editable by a marketing person. Structural changes and new templates are development work, and we are clear about which is which before launch.
Do we need a rebuild, or a fix?
Often a fix. Rebuilds are warranted when the platform blocks what the business needs, when the site cannot be rendered or read properly, or when the structure fights every attempt to add to it. If your site needs three specific repairs rather than a rebuild, we would rather say so.
Do you host?
We can, and we are equally happy handing a build to your existing host or IT team with documentation. What matters is that the hosting is fast enough and that someone is clearly responsible for updates and backups.
See where you stand
We will review your current search visibility and show you what buyers find when they look for what you do.
Contact Us