Four ways a site
earns its keep.
Build, findability, speed, and the publishing that keeps it growing. Most projects need two of the four. The audit says which.
Find out which ↗Open the one you came for.
They run in the order a project does: build it, make it findable, make it fast, keep it publishing. Most sites need two.
We build custom sites rather than assembling plugins. That means server-rendered HTML a crawler can read without executing JavaScript, images served in modern formats at the right size, and a build that fails loudly when a page regresses. The result is a site that stays fast after the launch photos are taken.
- Custom Next.js build, server-rendered and statically cached
- Responsive layouts tested from 320px up
- WCAG 2.2 AA accessibility pass
- Core Web Vitals budget enforced in CI
Content cannot rank on a page Google will not index. We audit what the crawler actually sees: redirect chains, canonical conflicts, orphaned pages, render-blocking resources, and structured data that fails validation. Then we fix it in the codebase, not in a report you have to hand to someone else.
- Full crawl audit with prioritised, severity-ranked fixes
- Schema.org structured data, validated against Rich Results
- XML sitemap, robots and canonical strategy
- Search Console setup and indexation monitoring
Slow sites lose rankings and conversions at the same time. We profile the real bottleneck rather than guessing, usually third-party scripts, unoptimised images, or a font loading strategy that blocks the first paint. Each change is measured before and after, on field data, not just in the lab.
- Lab and field performance profile (Lighthouse + CrUX)
- Prioritised fix list, ranked by impact per hour of work
- Implementation of the agreed fixes
- Before/after measurement on real user data
A site that never publishes stops growing. We set up the research, the templates and the quality gates so new pages ship consistently and each one targets a query someone actually searches. Every page is checked against the same brand voice and factual sourcing rules before it goes live.
- Keyword research and topic-cluster map
- Page templates wired to structured data
- Editorial voice and factual-sourcing guidelines
- Monthly performance reporting against target queries
Worth saying out loud.
This works when
- You need a site that stays fast as content grows
- Search visibility matters to how you get customers
- You want to own the code, not rent a page builder
This is not for you if
- You need it live this week
- A template would genuinely do the job
- You want someone to maintain an existing WordPress install
Which do you need? Usually two.
What people ask once they have read the four and are working out where they sit.
Pricing depends on scope, which is why it follows the audit rather than preceding it. Send the site URL and what you are trying to fix, and you will get a scoped estimate rather than a number pulled from a rate card.
Both. Technical fixes and builds usually work as fixed-scope projects. Content systems and ongoing SEO work better as a retainer, because the value compounds over months rather than arriving at handover.
Yes for audits, performance work and technical SEO. Those depend on what the crawler and the browser receive, which is platform-independent. New builds are usually Next.js, because it gives the most control over speed and rendering.
You do. That includes the repository, the deployment configuration and the documentation. There is no proprietary layer that would require us to stay involved.