One studio for technical SEO, GEO and the build.

They’re the continuous upkeep of everything that decides whether search engines can reach, read, and trust a site — crawling, rendering, indexing, speed, and structured data — kept healthy as the site changes. It’s the infrastructure layer, not the words on the page. A one-time audit finds the faults; the service is what stops them returning release after release.

Judge it by one real finding, not the sales deck. A credible finding pinpoints the fault, backs it with crawl or Search Console data, lists the exact URLs affected, and hands a developer a fix they can ship without a meeting. Tool exports with a logo on them aren’t findings. Ask, too, whether performance calls come from field data and whether they diff rendered HTML against raw.

It covers the mechanical layers that decide visibility: how the site crawls, whether pages actually index, what renders without JavaScript, how fast real users load it, where internal links send authority, and whether the structured data holds together. Ours works through those as six ordered gates. You get a ranked list of faults, each with evidence and a ready-to-build fix.

There’s no set price and no packages page — every audit is scoped and quoted in writing before anything starts. What moves the number is the real work involved: how many URLs and templates, how the site renders, and how much Search Console history there is to read. Send the domain and a fixed scope with a fixed figure comes back.

Two questions separate operators from resellers. First, who does the work — is the person selling it the one in your codebase, or does it hand off to a junior queue? Second, how do they prove a fix worked: "we deployed it" and "Search Console confirmed the recovery" are different claims. Then ask for one real finding and read whether it’s evidence or a tool export.

It opens with a full audit and settles into a monthly rhythm. The teardown sets a baseline; fixes ship in impact order through your developers or ours; each is verified against index coverage and field data before it’s called done; then the work shifts to catching regressions before releases cause them. You always have it in writing — what was found, what shipped, what the numbers did next.

At this studio, SEO spans four disciplines: technical SEO and audits as the foundation; on-page and authority work — content structure, keyword and competitor research, links, and local — for reach; generative engine optimization so AI answers cite you; and web development to ship the fixes. Eight services, one team, no hand-offs. Most engagements begin with an audit and expand from what it finds.

Prioritization and proof — not page count. A useful audit ranks every issue by what it costs in traffic, attaches the URLs and data behind each one, and orders the fixes so engineering knows what to ship first. A 300-item export of unweighted warnings is the opposite: noise with a cover page. Performance findings should come from real-user field data, and fixes should read like tickets.

The tells are in the depth. A premium audit diffs what a crawler sees against what actually renders, reads server logs where access allows, diagnoses Core Web Vitals per template from field data, and checks structured data as a connected graph rather than page by page. The other marker is the handoff: implementable tickets with acceptance checks, and a walkthrough where your team can interrogate every finding.

GEO is the work of getting a site quoted by AI answer engines — Google’s AI Overviews, ChatGPT, Perplexity, Copilot — instead of skipped. That means letting the right crawlers in, writing passages a machine can lift cleanly, and building the corroboration that decides which source an answer names. We run it on three surfaces: retrieve, parse, cite. It shares SEO’s foundation but aims at citation, not rank.

SEO competes for a spot on the results page; GEO competes to be the source an AI answer cites. They stand on the same foundation — crawlable, indexable, cleanly rendered pages — but diverge at the target: one optimizes whole pages for ranking, the other optimizes passages for retrieval and attribution. They’re measured differently too, since citations are tracked per engine rather than read off a single ranking.

Because more buyers now read an AI answer and never reach the ten blue links — and the sources those answers name are chosen by things you can engineer. Structure content for extraction, get corroborated across the web, open the right crawlers, and you get cited; ignore the channel and you’re summarized without credit or left out. The lead compounds, because engines keep returning to sources they already trust.

Ideally, yes — yet most builds bolt it on afterward. The ceiling on a site’s search performance is fixed by engineering calls: rendering approach, URL structure, load speed, how structured data is produced. Applying SEO after launch means paying to reverse decisions already shipped. We fold the requirements into the build spec from commit one, which is why treating "SEO" and "web development" as rival choices misreads how sites get made.

It’s set by the size and messiness of the URL inventory, not the rebuild. A few hundred pages migrate fast; a catalog in the hundreds of thousands takes however long a defensible one-to-one redirect map takes to build and verify — that map is where migrations are won or lost. We put the timeline in writing after seeing the inventory, and never trim verification to hit a date.