Umbodi is an autonomous agent for search and AI-answer visibility, and it works with GitHub. It audits your site, writes the fix, and opens a pull request on your repository — it never pushes changes to your site directly. By default you read the diff and merge it; then it re-crawls the page to know the fix actually went live.
A GitHub App on the repositories you pick. By default nothing merges without you. Merging on its own is a separate switch, off until you turn it on.
Both modes open the same pull request. They differ in who presses merge.
Umbodi opens a pull request on the repository you chose. A person reviews the diff and merges it. Umbodi never pushes to your default branch, and nothing reaches production except through your own deploy.
You turn on merging separately, and it only takes effect with automatic publishing and the schedule also on. Umbodi then merges its own pull request when your required checks pass, waits for the deploy, re-reads the live page, and reverts the change if it is not there.
It never merges or reverts on missing evidence: a check it cannot read means wait, and a page it cannot fetch means retry, then give up and say so. It writes content and discoverability files only, and it can never edit its own gates, tests or CI.
A revert in autonomous mode lands as one forward commit on your default branch that restores the files exactly as they were before its merge — no force push, and no history rewritten.
Most tools stop after the second. The fourth is what tells you the work was real.
Reads your sitemap, crawls every page it can reach, and records what is costing you visibility.
Titles, descriptions, structured data and whole pages, drafted as the actual file change. Not a to-do item.
On the repository you chose, as a branch and a diff. By default you review it, merge it and deploy it.
Applied means a crawler saw the change on the live page. A merged pull request that never deployed still reads as not applied.
Every SEO plugin that edits your site directly is asking for a permission no other vendor gets.
By default, the same review every other change to your site goes through. In autonomous mode your required checks are the gate: nothing merges unless they pass.
A merge you regret is a revert. A direct write you regret is an incident, and you find out from your traffic.
Your git history says what changed, when, and why — in the place your team already looks, not inside a vendor dashboard.
If a reviewer cannot tell what a change is for, the change is not finished.
One page per pull request, or one batch of discoverability files — sitemap, robots.txt, llms.txt. Never a sweep across forty files that has to be taken or left whole.
Each pull request names the audit findings it addresses, by code, so a reviewer can check the change against what was measured — not against a promised lift.
If it could not open the pull request it names the reason — the app not installed on that repository, for instance — rather than reporting a clean run that published nothing.
Umbodi does. It audits your pages, writes the fix, and opens a pull request against the repository your site is built from. By default the change is a diff you review and merge like any other; merging on its own is a separate opt-in. Umbodi never writes to your production site directly.
Umbodi installs as a GitHub App on the repositories you choose. It opens pull requests on those repositories only, and if the installation stops covering a repository it says so by name rather than reporting a clean run that published nothing.
No. Every change it proposes to a repository arrives as a pull request, and by default nothing is merged without you. If you separately turn on autonomous merging, it merges its own pull request only when your required checks pass, then re-reads the live page and reverts the change if it did not land. For sites that are not in a repository, Umbodi prepares the exact block for you to paste instead.
After a change ships, Umbodi re-crawls the live page and checks the fix is present in what a crawler receives. Applied means a re-crawl saw it, not that a job returned a success code — a merged pull request that never deployed still reads as not applied.
Only if you turn it on. Autonomous merging is off by default and needs its own switch, with automatic publishing and the schedule on. With it on, Umbodi merges when your required checks pass, then verifies the live page and reverts if the change did not land. It never merges on a check it could not read.
Run the audit first and read what it finds. The pull request is the step after you agree with it.