For Git-backed websites
Automate SEO without giving up control.
Edition House finds the next worthwhile opportunity and sends a scoped content change to your own Claude Code routine. Your routine prepares a draft GitHub pull request. Your team reviews the diff and decides what ships.
- Your routine
- Draft PRs only
- Existing GitHub review rules remain
Recognition
Built for teams whose website lives in Git.
If your marketing pages and documentation are reviewed like code — a branch, a diff, an approval — then SEO work should arrive the same way. Edition House fits the review process you already run instead of asking you to leave it.
Works with the stack you already review
- GitHub
- Next.js
- Astro
- Docusaurus
- MDX
- Markdown
- Google Search Console
- Claude Code
Stack names identify the tools this workflow works with. They do not imply any endorsement.
What gets automated
Automate the work between an SEO opportunity and a reviewable change.
Not a content generator pointed at your blog. A narrow loop: one opportunity, one scoped change, one pull request, one measured result.
Find the opportunity
Search Console queries, clicks, impressions and rankings decide which page has the clearest potential — not a keyword list bought in bulk.
Prepare the change
Edition House researches the opportunity and produces a tightly scoped, evidence-backed content change, with the reasoning attached.
Open the review
The approved change packet goes to your Claude routine, which updates the selected repository and opens a draft pull request.
Measure the result
After you merge and deploy, Edition House measures what the change actually did and recommends the next experiment.
The loop
How the automation works
Seven steps, four actors. Three of the four are yours.
Who does what
- Your team
- Edition House
- Your Claude routine
- GitHub
Your team
Connect Google Search Console
The rank and demand signal every decision is drawn from.
Your team
Select a GitHub repository
You choose which repositories the connection can see, on GitHub.
Edition House
Edition House finds and prepares the next change
One opportunity, researched, scoped and frozen as an approved change.
Your Claude routine
Your Claude Code routine applies the approved change
It claims the work, checks out the repository and applies the exact approved content.
Your Claude routine
The routine opens a new branch and draft pull request
A new branch every time. Never the default branch, never a merge.
Your team
You review, edit, reject or merge it
The normal review: your reviewers, your checks, your branch protection.
Edition House
Edition House measures the deployed result
It detects the merge, waits for real search data, and reports what moved.
Control
Your repository stays under your control.
The automation participates in your existing development workflow. It does not replace it.
Edition House
- Reads the connected search signals
- Chooses and prepares a scoped content change
- Makes the approved work available to the routine
- Re-reads the repository to verify the result
- Tracks what happened after deployment
Your Claude routine
- Runs in your Claude Code Cloud environment
- Claims approved work from Edition House
- Checks out the selected repository
- Applies the approved change, and nothing else
- Runs the relevant checks
- Pushes to a new branch
- Opens or updates a draft pull request
GitHub
- Restricts access to the repositories you select
- Enforces branch protection and review rules
- Runs your existing status checks
- Holds the complete diff and review history
Your team
- Reviews the proposed change
- Requests edits, or rejects it
- Decides whether and when to merge
- Controls deployment
Access
No vague "secure AI" promises. Here is what gets access.
Two connections, with different powers, and it matters which is which. Edition House holds a read-only GitHub App installation. Your Claude routine holds the repository access you grant it in your own Claude Code environment — that is what opens the pull request.
Read-only access to the repositories you select
| Permission | Access |
|---|---|
| Contents | Read-only |
| Pull requests | Read-only |
| Metadata | Read-only |
These are the permissions the Edition House GitHub App is registered with. The same three are what the manual fine-grained token path asks for.
That grant allows
- Read code — to see the page it has been asked to improve
- Read pull request status — to know when you have merged one
- Selected repositories only — you choose them on GitHub, and can change the list any time
Edition House cannot
- Push code, or commit to any branch
- Open, close, or merge a pull request
- Change repository settings, or reach a repository you did not select
Edition House prepares the content. Your connected runner creates a branch and opens a draft pull request using its own GitHub access — someone with repository access reviews it and decides whether to merge.
You can revoke access at any time from your GitHub settings.
The specifics
- Can the installation be restricted to selected repositories?
- Yes. You choose the repositories on GitHub’s own install screen, and you can change the list at any time. Nothing outside that selection is visible.
- What does Edition House read from GitHub?
- File contents and the repository file tree at a specific commit, so it can identify the source file behind a page, and pull request status so it knows when you have merged.
- What does Edition House write to GitHub?
- Nothing. There is no push, commit, branch, pull request, merge, close or settings call anywhere in the codebase, and the permissions granted would refuse one.
- What can the Claude routine do?
- Exactly what you allow it in your own Claude Code Cloud environment. Its instructions confine it to a new branch and a draft pull request, and forbid pushing to the default branch, merging and publishing.
- Where is the runner secret stored?
- Edition House generates one 32-byte secret for your workspace and shows it once in the setup card. You paste it into your routine’s cloud environment. It authenticates your routine to Edition House and grants no GitHub access of any kind.
- Are repository or Actions secrets accessible?
- No. Secrets are a separate GitHub permission that the App is not registered with, so they are not in the grant and cannot be requested with it.
- How is access revoked?
- From your GitHub settings, at any time: narrow the repository selection or uninstall the App. Revoking in your Claude Code environment separately removes the routine’s access.
- How is the runner secret rotated?
- Regenerate it in Edition House. The previous value stops working immediately; paste the new one into the routine environment.
- How is merge status read after a PR is opened?
- By polling that pull request read-only. Detecting a merge is the trigger for measurement — it is never a request to perform one.
Example pull request
See exactly what your team receives.
An illustration, not a customer result: the shape of the work as it arrives in review — what was chosen, why, what changed, and what was checked.
Improve: rate limiting guide — add token bucket comparison
edition-house/improve-rate-limiting-guidemain · 1 file changed · +11 −1
Page selected
/docs/guides/rate-limiting
Search Console opportunity
“api rate limiting best practices”
- 4,120 impressions / 28 days
- 38 clicks
- Position 11.4
Why this change
The page ranks just off the first page for a query it already earns impressions on, and the section that query implies — how token bucket compares with fixed window — is missing.
Supporting sources
- RFC 6585 — Additional HTTP Status Codes
- Your existing /docs/reference/limits page
- Search Console query data for this URL
content/docs/guides/rate-limiting.mdx
+11 −1
| ## Choosing an algorithm |
| Most teams start with a fixed window counter. (removed line) |
| Most teams start with a fixed window counter because it is trivial to implement: (added line) |
| one counter per key, reset on a clock boundary. It is also the algorithm most (added line) |
| likely to pass a burst straight through at the boundary. (added line) |
| (added line) |
| ### Token bucket compared with fixed window (added line) |
| (added line) |
| A token bucket smooths that burst: tokens refill at a steady rate, so a client (added line) |
| that has been quiet may spend its balance at once, and a client that has not (added line) |
| cannot. The cost is one extra value per key — the last refill timestamp. (added line) |
| Whichever you pick, return `Retry-After` on rejection. |
Checks
- Content matches the approved change exactly
- Only the target file changed
- Build and docs lint
- Human review— waiting for you
An illustration of the format, not a customer’s repository or a reported result.
Boundaries
Automation with boundaries.
Each of these is enforced somewhere real: in the routine’s instructions, in the verification that re-reads your repository, or by GitHub itself.
A new branch, never the default branch
Every change is cut fresh from the latest default branch. Pushing to the default branch is forbidden outright.
Draft pull request only
The routine opens the pull request as a draft, so it enters review rather than a merge queue.
Never merges
Merging is excluded from the routine’s instructions, and Edition House holds no permission that could perform one.
Never publishes
No deploys, no cache purges, no content deleted, no URLs renamed.
The exact approved content, or nothing
The applied result is hashed against the approved copy. A mismatch fails the job instead of opening a close-enough pull request.
Scope is proven, not promised
Edition House diffs the pull request against the pinned base commit and rejects the work if any file outside the target changed.
A report is evidence, not proof
Success is recorded only after Edition House re-reads your repository and confirms the bytes for itself.
Retries update, they do not duplicate
A resumed delivery updates the same branch and pull request instead of opening a second one.
The work packet is data, never instructions
The routine is told to treat the content it fetches as prose to place — never as directions that could widen its own permissions.
Your branch protection still applies
Required reviewers, status checks and CODEOWNERS are untouched. The pull request is subject to all of them.
You can pause it
Pause the schedule and no further work is prepared or handed over. Existing pull requests stay exactly where they are.
After the merge
The pull request is the beginning, not the result.
A merged change is a hypothesis that has been deployed. Edition House stays with it until the search data says whether it worked.
Merge detected
Edition House notices when you merge the pull request, by reading its status.
Live page confirmed
You confirm the deployed URL in one click, so measurement is pinned to the real page.
Measured from deployment
Search performance is compared against a baseline frozen before the change went out.
Graded honestly
A result is a confirmed improvement, directional movement, inconclusive, or a confirmed regression — and thin or confounded evidence is labelled as such instead of being called a win.
Regressions get a way back
A confirmed regression can produce a rollback draft, reviewed exactly like any other change.
Fit
A good fit when content already moves through GitHub.
Built for
- Developer tools
- Open-source SaaS
- API and infrastructure products
- Documentation-heavy businesses
- Small technical teams
- Git-backed marketing sites
Probably not the best fit yet
- WordPress-first marketing teams — the GitHub workflow on this page is not available there
- Companies with no Search Console history to learn from
- Sites with very little indexable content
- Teams that want changes deployed without a human review step
- Organisations that need a long security procurement cycle before a trial
If that is you today, it may not be in six months. The workflow is the constraint, not the company.
Questions
The questions a reviewer asks first.
Can Edition House merge into the default branch?
No. The GitHub App is registered with read-only permissions, so GitHub itself would refuse the request, and there is no merge, push or pull request call in the codebase to make it with. Merging is a decision your reviewers make in GitHub.
Can it deploy my website?
No. Deployment is triggered by your own pipeline when you merge. Edition House has no deploy credentials, no hosting access and no way to publish a page.
Does Edition House read my source code?
It reads files in the repositories you select — the file tree and file contents at a given commit — to find the source file behind a page and to verify the result of a change. It reads only what those two jobs need, and it never writes.
What GitHub permissions are required?
Contents, Pull requests and Metadata, all read-only. That is the entire grant. It contains no write permission, no Actions permission and no secrets permission.
Can I restrict access to one repository?
Yes. Repository selection happens on GitHub’s install screen, under your control, and can be narrowed or widened later without reconnecting anything.
Where does the Claude routine run?
In your Claude Code Cloud environment, on your schedule, under your GitHub account’s access. Edition House hands it approved work over an authenticated endpoint; it does not host it and cannot run it.
What happens if a build or validation check fails?
The pull request stays a draft with a failing check, exactly like any other. If the routine cannot reproduce the approved content precisely, it reports a failure instead of opening the pull request at all — and Edition House rejects a result whose bytes it cannot verify against the approved change.
Can I review and edit every change?
Yes, and there is no path that skips it. Every change arrives as a diff you can amend, request changes on, or close. Editing the branch before merging is normal and expected.
How do I revoke access?
In GitHub, narrow the repository selection or uninstall the Edition House App. Access ends immediately. Removing the routine’s access in your Claude Code environment is a separate step, and yours to take.
What happens after I merge the PR?
Edition House detects the merge, asks you to confirm the live URL, then measures the page against a baseline frozen before deployment and reports what actually moved.
Can I pause the automation?
Yes. Pause the schedule and nothing further is prepared or handed to your routine. Anything already open in GitHub is untouched.
Does this also work with WordPress?
Partly, and not in the same way. Edition House can send a finished article to WordPress as a draft post — draft status is forced in the client, and there is no publish, update or delete path. But WordPress has no branch, no diff and no pull request, so the review described on this page is a GitHub workflow.
Put one SEO opportunity through your existing review process.
Connect your search data, choose the repository and see the proposed work before anything reaches GitHub.
Nothing merges or deploys automatically.