Florian Kluge Organic growth · technical B2B SaaS

Code review for the part of your site Google sees.

I'm Florian Kluge. Before each release I check whether it's about to cost you organic traffic, and I put the answer in writing — go, hold, or amend. Then I verify it in production within the hour. For teams who ship to a site that ranks.

One site, one repository, one release path 45 days €1,500–3,000 fixed

Why it exists

The tests pass. The deploy is green. And a robots rule, a noindex flag, or a canonical reset is on its way to production with nothing in the pipeline looking for it.

Google drops pages at the speed it recrawls them — so your most-crawled templates, the ones that earn, are the first to go.

Getting them back runs on Google's schedule, not yours. And the report that would tell you, Page Indexing, is the slowest surface in Search Console. By the time a traffic chart bends, it is already a recovery project.

How it works

Once, at start

The invariant map

I crawl and document what a deploy must never silently change: indexability, canonicals, redirects, structured data, rendered content, internal links. You approve the list. Every later check measures against it.

Before each release

The gate

A deliberately thin check — the configuration and directives that can pull pages out of the index, plus a judgment call on whether the release touches anything on the invariant map. Verdict in writing: go, go with notes, or hold.

Within the hour

Production verification

Invariants re-checked against real production, because staging and production are never quite the same machine. This is where a problem surfaces at T+1 hour instead of T+3 days.

What you hold after 45 days

  1. The invariant map

    The agreed record of what must never silently change.

  2. A verdict for every covered release

    Go, go with notes, or hold — each in writing, each dated.

  3. A production result within the hour

    No covered deviation observed, a finding raised, or unable to verify.

  4. The evidence file

    What was checked, what changed, what was cleared, on whose call.

  5. The near-miss record

    Every catch and every deliberate exception, dated.

Every artifact is inspectable by your own engineers.

The verdict, as an object

Release verdict Gate & T+0
Release
——————
Covered path
——————
Checks run
——————
Evidence
——————
Exceptions
——————
Not covered
——————
Decision
go go with notes hold unable to verify
Verified at
——————
Signed
——————

This is the blank template, not an example — no invented customer, no invented numbers. Every field is filled by hand and signed by the person who made the call.

Note the last two rows. A verdict carries a name, which means someone can be wrong in writing. That's the point of it: “unable to verify” is a real outcome, and it appears here because a gate that never says so isn't measuring anything.

What counts as success

A check isn't successful because it ran.

Checks ran on every releasenot the outcome
Reports delivered on timenot the outcome
A deploy was held or amended because of a findingyes
You ship faster because release-SEO fear stopped taxing the processyes
Something that slipped through was caught at T+1h, tied to the releaseyes

The bet, stated so you can hold me to it

If 45 days produce zero changed release decisions — nothing held, nothing amended, no post-deploy catch, and no felt change in how confidently you ship — then the pilot didn't earn its fee, and I'll say so in the final report. You're reading that here before you commit, because it's my kill signal too.

Fit

For you if

  • Organic is a revenue line
  • You ship regularly to a site that ranks
  • There's a staging environment on the release path
  • You've lived through one silent regression already

Not for you if

  • There's no staging environment
  • Organic doesn't matter to the business
  • You want ongoing SEO strategy or content work
  • You want a monitoring dashboard — this is a decision, not a tool

Scope honesty

No traffic or ranking guarantees — outcomes only Google controls are never promised. No dashboards or monitoring seats; monitoring tools are good at what they do and this doesn't replace them. No per-release deep audits — the deep pass happens once, at baseline. Nothing outside the one covered release path.

After 45 days there are three honest exits: extend to more release paths, standardize so your team runs the checks without me, or stop with the record in hand. The price is set so any of the three is a fine outcome for you.

Price

€1,500–3,000

Fixed. One site, one repository, one release path, 45 days. The exact figure depends on release-path complexity, is quoted after a 25-minute call, and doesn't move afterwards. No meters, no upsell, no retainer conversion pitch.

One pilot runs at a time

If the fit looks right, write to me — hello@floriankluge.com

Tell me what you ship, how often, and what went wrong the last time something slipped through. If it isn't a fit, I'll say so — that's the shortest useful answer I can give you.

Who you'd be working with

I've spent over a decade doing organic growth for technical B2B SaaS — the kind where the marketing site shares a repository with the product and ships when engineering ships.

The same lesson kept arriving: the expensive damage rarely comes from a bad strategy. It comes from an ordinary Tuesday deploy nobody reviewed. So I stopped writing audits that sat unread and started building the measurement instead — baselines per page type, evidence rules that say out loud when a result doesn't count, and going back to check whether my own recommendations actually worked.

The pilot is built the way I'd want it if I were buying: fixed scope, the verdict written down, and “I couldn't tell” allowed as an answer.