What we run

SEO growth, run for you.

Most SEO work dies at the handoff. The audit is fine, the brief is fine, and then a technical fix needs someone to open a pull request against the product repo and defend it to an engineer. Zway operators write the content and ship those fixes as PRs.

Last reviewed 27 August 2026

The failure mode

What breaks when AI does this alone.

The recommendation layer is not the bottleneck. Every SEO tool on the market can tell you that your pages render client-side, that your sitemap is stale, that nine templates share one title tag, and that your marketing site is on a subdomain splitting authority. What breaks is that fixing any of those requires opening a pull request against a repository owned by engineers who are shipping the product, then defending the diff in review against someone who has never heard of a canonical tag and has three higher priorities.

What our operators do here

Run the technical audit against the live site and the actual rendered DOM
Open pull requests in your repo for meta, schema, canonical, sitemap, and render fixes
Sit in code review and answer the engineer questions until the PR merges
Write and publish the content, in your CMS, not as a document handed over
Build internal linking as new pages ship, rather than as a quarterly cleanup
Do outreach for links by hand, to people who have a reason to care
Report on which fixes merged, which are stuck, and what is blocking them

Volume

What ships in a typical week.

Typical weekly output on the SEO channel
What	Typical volume
Published pages, briefed, written, and live	2 to 4
Pull requests opened against your repo	1 to 3
Internal links added across existing pages	10 to 30
Outreach conversations for links or mentions	5 to 15

Volumes are typical rather than contractual. They move with what the channel is actually returning.

What good looks like

The metric that matters

Non-brand impressions and clicks in Search Console, by page cluster

Realistic timeline

Movement at 3 to 4 months. Compounding from month 6. This one is genuinely slow.

The audit is never the problem

Ask any founder who has bought SEO before and they will describe the same artefact: a well-produced audit, somewhere between forty and a hundred and twenty findings, delivered on time, still open six months later.

Nothing was wrong with the audit. The findings were correct. The reason nothing happened is that roughly half of SEO for a product company is not marketing work at all. It is a change to the product codebase, which means a pull request, a review, and an engineer who has to be persuaded to spend an afternoon on a canonical tag instead of the feature on the roadmap.

That negotiation is where SEO programmes die. It is not a knowledge gap and it is not a tooling gap. It is that nobody owned the diff.

Which half of the work needs a repo

It helps to be concrete about the split, because it explains why a content-only arrangement stalls.

Work	Where it lives	Who normally blocks it
Keyword and cluster strategy	A document	Nobody
Writing and publishing pages	Your CMS	Approval, usually
Title, meta, and heading templates	Product repo	Engineering backlog
Schema markup	Product repo	Engineering backlog
Canonicals, redirects, sitemap	Product repo or config	Engineering backlog
Client-side rendering of key pages	Product repo, and it is real work	Engineering priorities
Site architecture and subdomain decisions	Product repo and DNS	Nobody wants to own it
Internal linking	CMS and templates	Falls between the two

Six of those eight rows need someone who can open a PR. If your growth arrangement stops at the document, you have bought the two easy rows.

What we actually do

The AI layer does the analysis: crawls the site, compares the rendered DOM against what is served, maps the keyword clusters against what you actually sell, and drafts both the content and the code changes.

An operator ships it. They write the pages and publish them in your CMS. They open pull requests against your repository for the technical fixes, with a description an engineer can review in ten minutes rather than a link to an audit. Then they answer the review comments, adjust the diff, and stay with it until it merges or until you decide it is not worth merging, which is a legitimate outcome we will report as such.

Access is normally a branch with no merge rights. Your engineers keep the merge button. If you would rather not grant access at all, we still write the diff and the test plan, and we work through whoever does, with the understanding that it will move slower.

The honest timeline

SEO is the slowest channel we run and we would rather say so up front.

Technical fixes can show up in crawl data within weeks. Content does not. Expect three to four months before non-brand impressions move in a way you would trust, and six months before the cluster compounds and new pages start ranking faster because the ones around them already do.

A domain with existing history moves faster than one registered last quarter. If you are pre-launch, the right sequence is to get the technical foundation and the first cluster shipped now so that the clock starts, not to expect traffic during the same quarter.

Links, and what we will not do

We do outreach by hand, to people with an actual reason to link: someone who cited a competitor, someone whose post is missing the thing you built, someone running a newsletter your buyers read. It is slow, and it produces a number that looks unimpressive next to what a link vendor would quote you.

We do not buy links, run private blog networks, or publish spun pages at volume. Those work until they do not, and the penalty attaches to your domain rather than to the vendor who sold them.

We also will not publish thin pages to hit a page count. A page that exists only to target a phrase is a page that argues against your product being serious, and your buyers read it too.

SEO questions

Why do you write pull requests instead of sending a list of fixes?

Because the list is the part that already works. Nearly every stalled SEO programme we have seen has a completed audit sitting in a document, with the technical items untouched for months. The fixes live in the product repo, so the only reliable way to get them done is for someone to write the diff, open the PR, and stay in review until it merges.

Do your operators actually have repo access?

Where you grant it, yes, usually with a branch they push to and no merge rights of their own. Your engineers still review and still hold the merge button. If you would rather not grant access, we produce the exact diff and the test plan and work with whoever does have access, but expect that route to be slower.

How long does SEO take for an early-stage startup?

Expect three to four months before you see meaningful non-brand movement, and six or more before it compounds. A brand-new domain is slower than a domain with existing history. Anyone quoting you results in six weeks is either counting brand queries you already had, or counting impressions on terms nobody searches.

Is SEO still worth it when AI answers are taking clicks?

It is worth it differently. The same pages that rank are the pages AI systems read when someone asks about your category, so the work overlaps heavily with getting cited in AI answers. What changes is measurement: fewer clicks per impression, and more value in being the source rather than the destination. We run both together for that reason.

Do you buy links?

No. We do outreach by hand to people with a genuine reason to link, which is slow and produces fewer links than a paid vendor would show you. Bought links are the single easiest thing for a search engine to detect at scale, and the downside lands on your domain permanently rather than on ours.

See what we would run on SEO.

Thirty minutes. You leave with the thirty-day plan either way.

Book a demo

30 minutes. You leave with the plan either way.