Tutorial

From sign‑in to a measured change, in eight steps.

Each step says where it happens in the app and the line it never crosses. Nothing reaches your site until a person approves it and a person merges it.

  1. 01Sign in and name a workspace
  2. 02Add a site and prove you own it
  3. 03Connect Google and your repository
  4. 04Crawl the site
  5. 05Read the advisory queue
  6. 06Draft a proposal
  7. 07Approve and deploy
  8. 08Measure the outcome
01

Sign in and name a workspace

Sign in with Google. On your first visit you name a workspace. It holds your sites, your keys and your data, and nobody else's.

  • Choose Continue with Google. We ask only for your name and email address.
  • Name the workspace. You become its owner and can rename it or invite people afterwards.
Boundary

Signing in connects nothing. Search Console, Analytics and GitHub are separate, later choices.

02

Add a site and prove you own it

Enter a name and the site's address (scheme and host, no path). You get a one-time DNS TXT record to add at your DNS host.

  • Add the TXT record exactly as shown. Each value has a copy box.
  • Press Verify. DNS can take a few minutes to propagate, and retrying is safe.
  • On Cloudflare, the DNS provider assistant can create the record for you with a scoped token.
Boundary

Nothing is crawled and no connector binds to a site until the DNS proof exists.

03

Connect Google and your repository

One Google sign-in connects Search Console and Analytics for every verified site whose property that account can see. The repository is where approved changes are written.

  • Choose Connect Google. Each site is matched to the property that covers its address.
  • For the repository, sign in with GitHub and pick the site's repository from a list. No token to copy.
  • If a connection stops working, a banner says so on every page, with a Reconnect link.
Boundary

Connections are read-only for Google. GitHub access opens pull requests, and merges one only when an owner or admin clicks Publish on a site that allows it.

04

Crawl the site

Trigger a bounded crawl. It reads the pages a visitor sees, renders JavaScript when a page needs it, and reports progress live.

  • Press Trigger new crawl. Only one crawl runs per site at a time.
  • Watch the progress bar. A finished crawl reports how many pages it read and how long it took.
  • If most pages come back identical, such as a loading screen, the crawl is marked failed and no findings are drawn from it.
Boundary

A crawl is read-only. It respects robots rules and rate limits and changes nothing on the site.

05

Read the advisory queue

Findings become ranked opportunities: the top 20, each with a score, a confidence, a risk level and the page it concerns.

  • Open Correction and validation to see what fixing it involves and how the fix will be checked.
  • Freeze a 20-item human review set to measure how often the ranking is right before you trust it.
Boundary

The queue ranks candidates. It makes no automatic changes, and the count of those is always shown: zero.

06

Draft a proposal

Draft proposal turns an opportunity into a reviewable change: an exact diff against the file, a preview of how it reads in search, and the policy result.

  • Read the diff. It is the whole change; nothing else is written.
  • Withdraw a draft you do not want. It stops counting toward approvals and can never deploy.
Boundary

Drafting is not approving. A proposal writes nothing to the site.

07

Approve and deploy

Another person approves. Riskier changes, such as canonical, robots or redirect edits, need more approvers. Deploy then opens a pull request on your repository.

  • An author can never approve their own change. Invite reviewers under Settings → Members.
  • Deploy opens the pull request. The change reaches the live site when a person merges it: on GitHub, or with Publish if an owner or admin has turned on Publish from SEO Autopilot under Adjust governance. Publish merges only the exact reviewed change; robots, redirect, configuration and template-wide changes are always merged on GitHub.
  • Request revert opens a revert pull request if a deployed change needs undoing.
Boundary

Deployments stop at the daily change budget, during a freeze window, and site-wide under the emergency freeze.

08

Measure the outcome

After a verified deployment, clicks and position are compared across a 28-day window before and after the change.

  • Check evidence completeness. Sparse data is labelled as sparse, not rounded up.
  • Read the annotations. They explain anything that weakens the comparison.
Boundary

A before-and-after comparison is an association. It does not prove the change caused the difference.

A second path

Write a new blog post

Fixing pages you have is one job; filling a gap with a page you do not have is another. An AI writes the first draft, and a person checks it, edits it and sends it through the same approval as every other change.

  1. a.

    Add your own AI key

    Settings → Keys

    Under Your AI keys, add an Anthropic (Claude) key, an OpenAI key, or both. The provider bills you directly. We show only the last four characters, and there is no shared key: without one, drafting stays off.

  2. b.

    Briefs come from the search terms people already use to find you. A new-post brief names the topic, the terms it targets and the sections it should cover. Dismiss one you do not want, with a reason.

  3. c.

    Write a draft

    Brief → Write a draft

    Pick Claude or OpenAI and name the author. The draft is written in the background from the brief, your real search terms and your existing pages, in a minute or two. Each draft shows its cost; a workspace spends at most $25 a month.

  4. d.

    Check every flag

    Draft → Review

    The draft lists what a person must check: each fact the AI relied on, any number it did not declare, links to pages that do not exist and overlap with a page you already have. Tick each one and note how you checked it. Edit freely; a diff shows what you changed from the AI's version.

  5. e.

    Send for approval

    Draft → Send for approval

    Once every flag is resolved, the post becomes a proposal like any other. A new page is always high risk, so it needs two approvers, neither of them the author. Deploy opens a pull request adding the post to your repository; it goes live when a person merges it.

  6. Boundary

    The AI never publishes. Its draft cannot be sent until a person has resolved every flag, and it reaches your site only after two approvals and a merged pull request. A published post can be undone: the revert removes the file.

Good to know

How far a site may go on its own

Each site has an operation mode, set under Adjust governance on the dashboard. Changing it needs a written reason, which is recorded against your name.

Observe
Measures only. The default. Every deployment is refused.
Recommend
Drafts proposals and deploys each one only after approval.
Autopilot
Deploys unattended within the budget and policy. Chosen deliberately, with a reason on record.

The agent workspace

From the dashboard, Agent workspace opens a chat about the selected site. The agent answers from stored evidence and can queue analysis, keyword clusters, content briefs and reports. It cannot publish a change: everything it suggests still goes through a reviewed proposal. The workspace itself uses no AI key; only blog drafts do, and only with yours.

Ready to start?

Step one takes about a minute.

Sign in with Google