Umbodi is an SEO agent that 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. You read the diff and merge it, and then it re-crawls the page to know the fix actually went live.
A GitHub App on the repositories you pick. Nothing merges without you, and nothing reaches production except through your own deploy.
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. Your review, your merge, your deploy.
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.
The same review every other change to your site goes through. An agent that writes to production is a change nobody read.
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 concern per pull request. Not a sweep across forty files that has to be taken or left whole.
Stated as a projection and labelled as one. A measured rank and an expected lift never share a number here.
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. The change is a diff you review and merge like any other. Umbodi never has write access to your production site.
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 makes to a repository arrives as a pull request. Nothing is merged without you, and nothing reaches production except through your own deploy. 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.
Run the audit first and read what it finds. The pull request is the step after you agree with it.