SEO web development.
Development with the ranking requirements in the spec — new builds, repairs shipped from audit findings, and migrations that keep their traffic.
SEO and web development as one discipline
SEO web development means the ranking requirements are in the specification before the first component gets written — rendering strategy chosen per route, performance budgets enforced in the build pipeline, URL architecture designed so it can't sprawl. We build new sites that way, and we repair sites that weren't built that way.
A lot of our development work arrives as an audit finding with a ticket attached: we fix what the audit finds, in the same studio that found it.
The usual arrangement splits this work across two vendors. An SEO shop writes recommendations; a development shop receives them as backlog items competing with feature work; and the spec loses fidelity at every hand-off until "server-render the category templates" ships as a loading spinner with better alt text. We don't run that relay. The engineers implementing the fix sit in the same studio as the people who diagnosed it — often they're the same people — so nothing gets lost in translation, because there is no translation.
What we build
Production work in the stacks we actually ship. Next.js and React front ends in TypeScript, where rendering strategy is a per-route decision and the framework's defaults get overridden the moment they'd cost indexation. Shopify builds and theme surgery in Liquid — including the unglamorous work of auditing which installed apps are injecting render-blocking scripts into every template and removing the ones that don't earn their cost. WordPress where WordPress is the right call, with plugin sprawl treated as the performance liability it is. Headless architectures when content operations genuinely demand one — and a straight answer when they don't, because a headless build you didn't need is complexity you'll be paying interest on for years.
E-commerce carries its own discipline: catalog URL design, faceted navigation that can't compound into infinite crawl space, variant canonicalization, structured product data generated from the catalog itself. It gets treated as a specialization, not a template category.
Two builds on our public roster show the range — Settlebrook, an AI web tool in Next.js, TypeScript, and Tailwind, and Citrus House Craft, a Shopify build with theme work in Liquid on Dawn. Both have full case pages under projects. We also build the client systems that run behind a site — CRM configuration, booking and payment flows, pipelines on GoHighLevel and Stripe — as an implementation line inside development scope. Plumbing we're good at, not a discipline we market.
Build to Tolerance
Every build here runs on a rule we call Build to Tolerance: the SEO-critical properties of the site are written into the spec as measurable limits, and the build isn't done until it's inside them. Four tolerances, checked per template, not per site.
Rendering
Every route's rendering strategy — static, incremental, server-rendered — is chosen at spec time as an indexation decision, not inherited from whatever the framework defaults to. Client-side-only content is a documented exception with a reason attached, never an accident. Before launch we diff raw responses against the rendered DOM template by template, so "the crawler sees what users see" is a verified property rather than an assumption. Server-rendered output carries a second payoff now: several AI crawlers execute little or no JavaScript, so the same discipline that gets you indexed gets you retrieved by answer engines.
- GEO Server-rendered output is what answer engines can retrieve.
Performance
Core Web Vitals ceilings go into the spec — LCP under 2.5 s, INP under 200 ms, CLS under 0.1 — and the pipeline enforces them on every change, the same way we gate our own releases. Budgets, not post-mortems: a regression fails the build before it ships instead of surfacing in field data six weeks later. Image pipelines, font loading, and every third-party script get designed against the budget from day one, because retrofitting performance is always the expensive version of the same work. When a marketing tag would blow the INP budget, the spec says so before it's live on a million pageviews.
Crawl surface
URL architecture is designed closed. Canonical rules written before templates exist. Parameters and facets bounded so they can't mint URL spaces no one intended. Pagination with a deliberate crawl path, redirects returning correct codes from the first deploy, and sitemaps and robots directives generated from the same source as the routes themselves — so they cannot drift apart, because there's nothing separate to drift. The audit finding we refuse to write against our own work is "crawl budget consumed by URLs nobody designed."
Meaning
Structured data ships as typed components fed by the same data modules as the visible page. The schema can't claim something the page doesn't show, because they share a source of truth. One organization entity, connected nodes, no orphan references — the standard we hold other sites to in audits is the standard our builds have to clear, and it's checked against the rendered DOM before launch, not the source.
SEO website migration
A migration is the highest-stakes project in this discipline. Done carelessly, it converts years of accumulated rankings into 404s in an afternoon, and the loss registers slowly enough that the launch party happens before the drop does. Our migration work — replatforms, redesigns, domain moves, framework changes — treats the traffic as the cargo and the new site as the vehicle.
The sequence is unglamorous, which is the point. Full URL inventory first, assembled from the crawl, the sitemaps, Search Console, and analytics — every URL that has ever earned an impression or a link gets an explicit fate: kept, redirected, or deliberately retired. The redirect map is built one-to-one wherever a counterpart exists; blanket redirects to the homepage are how link equity dies quietly. We crawl the staging build against the inventory before anything switches — parity on titles, canonicals, structured data, and internal links, not just "the pages exist." Then launch runs with the instruments on: index coverage, crawl stats, and the redirect log watched live, while a wrong mapping is still cheap to correct. E-commerce migrations get extra ceremony, because a catalog multiplies every mistake by the SKU count.
A migration is also a technical SEO event wearing a development costume — rendering, canonicalization, and crawl paths all change at once, which is exactly why this page owns the work and the technical SEO practice inherits the monitoring after. If you're mid-planning and your current vendor's migration plan is a spreadsheet with two columns, talk to us before the switch, not after the drop.
Where this connects
Development is the implementation arm of everything else on this site. The Six-Gate audit produces ticket-ready findings; this is the team that ships them. Technical SEO retainers keep what we built inside tolerance as the site keeps changing. And when a rebuild is being weighed against a repair, we'll tell you which one the evidence supports — rebuilds sell better, but they aren't always the right engineering call, and we'd rather lose the bigger invoice than defend the wrong one.
Start a project. Send the domain and what's driving the change; scope comes back fixed and in writing.
- ↗SEO Auditticket-ready findingsProduces the ticket-ready findings this team ships.
- ↗Technical SEOkeeps it in toleranceKeeps what we built inside tolerance as it changes.
- ↗Projectsthe public rosterReal builds with case pages: Settlebrook, Citrus House Craft.
SEO web development FAQ
Is SEO part of web development?
It should be, and on most builds it isn't. The decisions that set a site's search ceiling — rendering strategy, URL architecture, performance characteristics, how structured data gets generated — are development decisions, made deliberately or made by default, but made either way. Treating SEO as a layer applied after launch means paying to reverse those decisions later. That's the case for SEO web development as one discipline: requirements enter the spec, not the backlog. It's also why "SEO versus web development" is a false choice — one defines the requirements, the other implements them.
How long does a website migration take?
As long as its URL inventory demands — the calendar is set by mapping and verification, not by the rebuild itself. A site with a few hundred URLs moves quickly; a catalog with hundreds of thousands takes as long as a defensible one-to-one redirect map takes, because that map is the whole ballgame. Rushing it is how migrations lose traffic. We scope the timeline in writing once we've seen the inventory, and we don't compress the verification stage to hit a launch date.
Can you fix an existing site, or do you only build new ones?
Fixing existing sites is most of the job. The typical engagement starts from an audit finding — a rendering fault, a crawl-space leak, a failing template — and ends with the fix deployed and verified, no replatform involved. We rebuild when the evidence says the foundation can't be repaired economically, and we show you that evidence rather than assert it. If a vendor's first answer to every finding is a rebuild, that's a sales motion, not an engineering judgment.
Let's build somethingworth finding.
One brief. One reply within a working day. Evidence, not a pitch.
Prefer email? hello@rankingtank.com