Website Development
A Website Development Agency That Builds for Search From Day One
OnlyConversion is a website development agency practising conversion focused web design and SEO friendly website development. We build fast, crawlable sites on Shopify, WordPress and headless CMS for businesses whose current site is holding them back. Search performance is designed in from the first commit rather than retrofitted, and you own the code, the content and the hosting.
We'll audit your current site and show you what is costing you traffic, before you've paid us anything.
Left-hand figures are typical of a JavaScript-rendered site. Right-hand figures are measured from this page.
Who this is for
This is for businesses whose website is the bottleneck
We're a fit if
- Your site is slow and you have been told to fix it without being told what to fix.
- You publish content that never ranks, and nobody can explain why. Very often the answer is that Google is not receiving it.
- Traffic arrives and does not convert. The problem sits in the page rather than in the ad account.
- You are locked into an agency-built site you cannot edit, on a platform you did not choose, with no access to the code.
We're not a fit if
- Budget is the deciding factor. Template-led studios and marketplaces build competent sites for a fraction of what we would charge, and for many businesses that is genuinely the right call.
- You need a template configured and handed over quickly. That is a real and useful service, and specialists in it will serve you faster than we would.
- Sign-off runs through a committee with no single decision-maker. Design by consensus tends to cost more than it should and satisfy nobody, so it is worth naming the decision-maker before anyone quotes.
- You want the site rebuilt without measurement attached. Without a baseline, neither of us could say afterwards whether the new site is better, and we would rather not take that project.
The problem
Most website redesigns fail in the HTML, and never touch it
Mockups get reviewed. Measurements do not.
A site gets rebuilt because it looks dated. A designer is hired, the visual language is refreshed, and the new site launches to internal approval. Six months later the rankings have not moved, the site is still slow, and nobody can say why.
The reason is that the visible layer was the only layer anyone examined. Underneath, the page is still assembled in the visitor’s browser after the fact, so a search crawler receives an almost empty document. The images are still full-resolution photographs scaled down with CSS. The layout still shifts as fonts arrive. None of that is visible in a design review and all of it is visible to Google.
This is not obscure. It is the single most common technical failure we find, and it survives redesign after redesign because the people commissioning the work are shown mockups rather than measurements.
A website is a technical product with a visual surface. Judging it only on the surface is how businesses end up paying twice.
A redesign that ignores the HTML changes how the site looks and nothing else.
Same speed, same crawlability, same conversion rate, new colours.
Every technical decision on this list is cheap at the start and expensive later.
Rendering strategy, URL structure and image pipeline are close to free on day one and close to a rebuild on day four hundred.
So we settle the technical decisions before anyone opens a design tool, and we publish the standard we hold ourselves to.
The standard
SEO friendly website development, built for search from day one
This is the standard every site we build is held to. It is published here so you can hold us to it, and so you can measure whoever built your current site against it.
Rendering and delivery
- Server-rendered or statically generated. The full page arrives in the HTML response, before any JavaScript runs.
- No content that depends on client-side JavaScript to exist. Interactivity may; content may not.
- Assets served from a CDN close to your market rather than from one origin server.
- HTTP/2 or better, Brotli compression, and immutable caching on fingerprinted assets.
Semantic structure
- One H1 per page, containing the page’s primary keyword, and no skipped heading levels.
- Landmarks, lists and tables marked up as what they are rather than as styled divs.
- Every image carries meaningful alternative text, and decorative images are hidden from assistive technology.
- Keyboard navigable throughout, with a visible focus state on every interactive element.
Structured data
- JSON-LD generated from the page’s own content, never hand-maintained alongside it.
- Organization and WebSite on every page; Service, BreadcrumbList and FAQPage where they apply.
- Visible breadcrumbs that match the BreadcrumbList exactly.
- Validated against the Rich Results Test before launch and on every subsequent release.
Crawl and indexation
- Sitemap generated at build from the route registry, so a new page cannot be forgotten.
- robots.txt that explicitly admits AI crawlers rather than blocking them by omission.
- One canonical URL per page, self-referencing, with trailing slashes consistent site-wide.
- Redirect map for every legacy URL, so existing rankings survive the migration.
Images and media
- AVIF and WebP with correct fallbacks, sized to the layout rather than scaled down in CSS.
- Width and height on every image, so nothing shifts as the page loads.
- Lazy loading below the fold, eager loading and preload for the largest element above it.
Performance budget
Google’s published thresholds for a "good" experience. We treat them as a ceiling rather than a target, and a build does not ship over budget.
- LCPLargest Contentful Paint
- Under 2.5s
- INPInteraction to Next Paint
- Under 200ms
- CLSCumulative Layout Shift
- Under 0.1
How long until the main content appears
How quickly the page responds when tapped
How much the layout jumps while loading
Proof by demonstration
Audit this page
It would be a poor advertisement to publish that standard on a page that failed it. So here are this page’s own numbers. View source, disable JavaScript, run it through Lighthouse. Nothing here is asking to be taken on trust.
| Measurement | This page | Notes |
|---|---|---|
| Words readable with JavaScript disabled | 4,149 | The entire page. Turn JavaScript off and nothing changes |
| Scripts that cannot block first paint | 7 of 7 | Every one is async or module-guarded |
| Fonts served from our own origin | 19 files | Four preloaded. No third-party font request |
| External origins contacted before paint | 0 | Nothing loads from a domain we do not control |
| Total CSS for the entire site | 50KB | One file, shared across every page |
| Structured data blocks | 4 | Generated from this page’s own content |
| Heading levels with no skips | 1 H1, 20 H2, 37 H3 | A clean outline for crawlers and screen readers |
| Raster images shipped | 0 | Every figure on this page is inline SVG, so it scales without a download |
If your current agency cannot produce this table for your site, that is the answer to why it does not rank.
What's included
What we actually do
Technical audit and architecture
What is wrong with the current site, what is worth keeping, and how the new one should be structured. Rendering strategy, URL design and the redirect map are decided here rather than discovered later.
Web design and build
Interface design and front-end build together, so nothing is designed that cannot be built fast. Responsive design is component-driven, so the site grows without a website redesign each time.
CMS and content modelling
A content model your team can actually use, on a CMS chosen for your workflow rather than our convenience. Editors get fields, not a blank rich-text box.
Ecommerce
Shopify and WooCommerce builds, including feed quality, faceted navigation that does not create thousands of junk URLs, and checkout that gets out of the way.
Website migration
Moving platform without losing rankings. Redirect mapping, content parity checks, and a staged cutover with the ability to roll back.
Conversion work
Page structure, form design and the specific things that make people leave. Measured, rather than argued about in a meeting.
Platform choice
Shopify, WordPress, WooCommerce or headless
There is no best platform, only a best fit. Most bad builds start with a platform chosen before anybody asked what the site needed to do.
| Platform | Best for | Avoid when | Build effort | Who can edit it |
|---|---|---|---|---|
| Shopify | Straightforward ecommerce that needs to be reliable more than unusual. Shopify development is the fastest route to a working store | Your catalogue or checkout logic is genuinely unusual, or content is the main event | Low to moderate | Anyone, with no developer |
| WordPress | Content-led sites publishing often, where editors need real control. WordPress development suits teams who write frequently | Nobody will own maintenance. An unmaintained WordPress site is a security problem waiting to happen | Moderate | Anyone, with training |
| WooCommerce | Ecommerce bolted onto a content site that is already earning its traffic | Ecommerce is the whole business. At volume you will fight the platform | Moderate to high | Anyone, with training |
| Headless | Performance-critical sites, multiple front-ends, or a design system spanning products. Headless CMS development is the fastest option and the least forgiving | The team is small and non-technical. It is the fastest option and the least forgiving | High | Editors via CMS, developers for structure |
This site is a headless build, statically generated. That is the right answer here and it would be the wrong answer for a small business publishing twice a week.
How we work
How we work
We do not publish a delivery schedule, because the honest duration depends on scope, on how many legacy URLs need mapping, and on how quickly your side can approve things. The order does not change.
- 01
Audit and architecture
The current site measured properly, then the decisions that are expensive to change later: rendering, URLs, content model, redirect map. You get this whether or not you continue.
- 02
Content model and structure
What types of page exist, what fields they have, how they relate. Done before design, because designing without it produces pages that cannot be reproduced.
- 03
Design
Interface design against real content, never lorem. If it does not work with your longest product name and your shortest description, it does not work.
- 04
Build
Component-driven, reviewed against the performance budget as we go rather than at the end, when it is too late to be cheap.
- 05
Migration and QA
Redirects tested one by one, content parity checked, schema validated, accessibility audited, budget confirmed on real devices.
- 06
Launch and handover
Staged cutover with a rollback path. Then the handover pack, and training for whoever maintains it.
Step one stands on its own. Plenty of clients take the audit, fix the worst of it in house, and decide they do not need a rebuild after all.
Proof
REETUS, cybersecurity
A cybersecurity firm with a site that was slow, hard to find in search, and generating enough spam enquiries that the real ones were getting lost. The brief was a modern site. The actual problem was that nothing underneath it had been built for search or for lead quality.
What we did
We rebuilt the site with search visibility designed in rather than added afterwards: server-rendered pages, a clean URL structure, structured data generated from the content, and an image pipeline that stopped the page weighing several megabytes. Form handling was rebuilt to filter automated submissions without adding friction for real enquirers.
Results
- PageSpeed score
- 95+
- Spam enquiries
- Down 90%
- Mobile responsive
- 100%
Client-reported results.
Ownership
What you own, and what you get on the last day
This is the section international buyers read first, and the one most agencies leave vague. Ours is specific because the answer is simple: all of it is yours.
- The code
- Full source in your own repository, transferred on completion. No licence, no obligation to keep us, and nothing held back as a retention mechanism.
- The hosting and domain
- In your account and your name, billed to you. We never hold the domain or the hosting login over you.
- The design files
- Editable source files rather than exported images, including the component library and the design tokens the code is built from.
- The content
- Everything written or produced for the build, and the CMS it lives in, with the content model documented.
- Third-party accounts
- Analytics, Search Console, tag manager and CMS, all created under your email addresses from the start rather than transferred later.
- The build pipeline
- Deployment configuration and environment setup, documented well enough for another developer to deploy without calling us.
- The redirect map
- Every legacy URL and where it now points, as applied. A future migration builds on this rather than starting again.
- The measurement baseline
- Rankings, Core Web Vitals, crawl stats and conversion rate captured before we touched anything, so the launch can be judged honestly.
- Font and asset licences
- Purchased in your name, so the licence is yours and does not lapse when the engagement ends.
- The decisions
- A written record of what was chosen and why, including what we recommended against, so a future team is not guessing at intent.
The handover pack
- Repository access with a written commit history, not one commit called "initial"
- Environment and deployment documentation good enough for another developer to deploy without calling us
- The content model, documented, so future pages match the existing ones
- The redirect map as applied, so a future migration can build on it
- Recorded training for whoever maintains the site
- A written list of what we would do next, including the parts we did not do
We would rather you could leave easily and choose not to. Agencies that make leaving expensive are usually the ones who need to.
Measurement
How you'll know it's working
A rebuild is easy to declare a success because the new site looks better than the old one. That is not evidence. These are.
Technical, verifiable immediately
Confirmed at launch
- Core Web Vitals inside budget on real devices, not just in the lab
- Every legacy URL either resolving or redirecting, with none left to 404
- Full content present in the HTML response with JavaScript disabled
- Structured data validating with no errors
Commercial, which takes longer
Watched over the following months
- Indexed pages, and crawl errors trending down in Search Console
- Organic sessions and impressions against the pre-launch baseline
- Conversion rate on the pages that matter, measured against the old site
- Lead quality, not just lead volume
The measurement we insist on
A baseline captured before we touch anything. Rankings, Core Web Vitals, conversion rate and crawl stats, recorded and shared. Without it, a launch cannot be judged, and a surprising number of agencies quietly prefer it that way.
If a rebuild is not the answer
We will say so. A large share of the audits we run end with a list of fixes to the existing site rather than a proposal to replace it. That is a worse outcome for us and a better one for you, and it is the reason the audit is worth having.
Tools & stack
The stack we work in
- Front-end
- Next.jsReactAstroTypeScriptTailwind CSS
- CMS
- WordPressSanityContentfulPayload
- Ecommerce
- ShopifyWooCommerceShopify Hydrogen
- Hosting and delivery
- VercelNetlifyCloudflare
- Measurement
- Google Analytics 4Google Search ConsoleLighthouse CI
We choose the stack against your team and your content, not against what we most enjoy working in. If the honest answer is a WordPress theme configured properly, we will tell you that.
Engagements
How engagements work
Three shapes, depending on what you need.
Technical audit
Your current site measured against the standard published on this page, with the fixes specified in priority order. Yours to keep and to implement with anyone, including your existing developer.
Build
A full project: architecture, design, build, migration and handover. Fixed scope agreed upfront, with a written change process so nobody is surprised.
Ongoing development
For sites that keep growing after launch. New templates, new features and continued performance work, on a retainer rather than a project.
What determines scope
- How many unique page templates the site genuinely needs, which is usually fewer than expected
- Whether content is migrated, rewritten, or produced from scratch
- How many legacy URLs need mapping, and how bad the existing structure is
- Ecommerce complexity: catalogue size, variants, and anything unusual in checkout
- How many languages and markets
- Whether integrations exist and are documented, or exist and are not
What you own
The code, the repository, the design files, the content, the hosting, the domain and every third-party account. Transferred on completion, with no licence to renew and nothing held back.
We do not publish rates. A five-page brochure site and a two-thousand-product store are both "a website", and a single number covering both would be useless to you. You will have one on the first call, once we know which you are.
Why OnlyConversion
Why work with us
01We publish the standard and then meet it on our own site
The spec on this page is not aspirational. The page you are reading was built to it, and the audit table above is measured from this build rather than written by a copywriter.
02We are the agency that has to rank the site afterwards
We run SEO for clients, which means a badly built site becomes our problem six months later. That is a strong incentive to get the technical foundation right the first time, and most build-only agencies do not have it.
03You can leave whenever you like
Code, repository, hosting, domain and accounts are yours from the first day and stay yours. No retainer required to keep the lights on, and no login only we hold.
FAQ
Frequently asked questions
Cost and timing
What this takes to start
How much does a website cost?
It depends almost entirely on how many distinct page templates you need and whether content is being migrated or written from scratch. A brochure site and a large ecommerce build are both "a website" and differ by an order of magnitude, so a published number would mislead you either way. We will give you an accurate one on the first call.
How long does a website take to build?
It depends on scope, on how many legacy URLs need mapping, and realistically on how quickly your side can review and approve. The sequence is set out on this page. Anyone quoting a duration before seeing your current site and your content is guessing, and you should treat the number accordingly.
Can you make our current site faster instead of rebuilding it?
Frequently, yes, and it is often the right answer. Many sites are slow because of a handful of fixable things: unoptimised images, render-blocking scripts, and third-party tags nobody has audited in two years. The technical audit will tell you whether you have a fixable site or a structural problem, and we will say which even when the answer costs us the larger project.
How the build runs
What actually happens
Do you do the design as well as the build?
Yes, and we prefer to. Design and front-end build in one team means nothing gets designed that cannot be built inside the performance budget, which is the usual cause of a beautiful site that loads slowly. If you already have a designer we will work to their files.
Can you work with our existing developer or in-house team?
Often, and sometimes that is the better arrangement. We frequently do architecture, technical standards and the performance work while an in-house team builds. Tell us early and we will scope it that way rather than pricing a full build you do not need.
What is the difference between static, server-rendered and client-rendered?
Client-rendered means the page is assembled in the visitor’s browser, so the initial HTML is close to empty and a search crawler may receive nothing useful. Server-rendered means the page is assembled on request. Static means it is assembled at build time and served as a finished file, which is the fastest of the three. We use static or server rendering, never client-only rendering for content.
Ownership and risk
The part most agencies leave vague
Do we own the code?
Yes, entirely. Full source in your own repository, transferred on completion, with no licence and no ongoing obligation to us. The same applies to the design files, the hosting, the domain and every third-party account, all of which are created in your name from the start.
Will we lose our search rankings when we migrate?
Not if the migration is done properly, and this is where most rebuilds cause damage. Every existing URL is mapped to its new destination before launch and tested individually, content parity is checked page by page, and we capture a full ranking baseline beforehand so any drop is visible immediately rather than three months later.
What happens if something breaks after launch?
Defects in what we built are fixed at our cost, and that does not expire on a date. Beyond that you can take an ongoing arrangement or take the site in house entirely. The handover pack is written to make the second option genuinely viable rather than nominally available.
Next step
Find out what your website is costing you
We'll measure your current site against the standard published on this page and tell you what is fixable, what is structural, and what we would do in which order. You get the findings whether or not you work with us.
Free. No obligation.
Tell us what you’re trying to fix
Service interest is pre-set to Website Development.