Turn a technical SEO finding into a pull request you review.
When Kanso's site analysis finds a supported problem, the Coding Agent finds the HTML file in your GitHub repository, prepares a small change, shows you the diff, and opens a pull request only after the owner confirms. You merge it. Kanso never does.
Free to start · No credit card required. See how it works
At a glance
Between an audit and a fix, work gets stuck
Finding a technical issue is quick. Getting a correct, reviewed change into the code is where it slows down.
A ticket for a one-line fix
A missing meta description still means a ticket, a developer and a review.
Small fixes repeat
Titles, descriptions and canonical links come up page after page, each one simple and each one slow.
AI changes are hard to trust
A generated change you cannot see, scope or approve is a risk, however good the suggestion is.
From a finding to a change you can read
Kanso prepares the change and stops at a pull request. Your review and your merge stay yours.
- An audit lists the issue
- Someone files a ticket and hunts for the file
- A manual edit, a review and a pull request
- A finding from Kanso's site analysis, with its evidence
- The right HTML file located and checked, and a small diff you can read
- A pull request on a new branch, after the owner confirms
One agent finds, one prepares
The SEO Agent produces the finding. The Coding Agent turns a supported one into a pull request.
SEO Agent
Analyses your public site and writes recommendations, each with the evidence behind it.
- It produces
- The finding and recommendation a fix starts from.
- Where it fits
- The first step.
Coding Agent
Finds the HTML file for the page in your repository, prepares a small change and, after the owner confirms, opens a pull request.
- It produces
- A diff preview, a pull request, and a check of the live page after you merge.
- Where it fits
- Everything from the preview to the check.
From finding to a verified change
Six steps. The first is a one-time setup.
- 01You
Connect one repository
The workspace owner installs the Kanso GitHub App on GitHub, with access to Contents and Pull requests, and chooses the one repository the project uses.
Start from a supported finding
A recommendation is eligible only when everything it found is among the five changes Kanso supports and rests on current analysis evidence. A mixed recommendation is never fixed in part.
Find the file and prepare the change
Kanso looks for the page's static HTML file and stops if it cannot prove which file it is. A model proposes only the wording of a title or description, labelled as an AI proposal. Kanso's own editor makes the change.
- 04Kanso, then you
Preview
You see the repository, the branch Kanso would create, the file, the exact values, the diff and the checks it ran. Nothing exists on GitHub yet.
Confirm and open the pull request
Only the workspace owner can continue, and only after a second explicit confirmation. Kanso makes one commit on a new branch, opens a pull request, then stops.
- 06Kanso, then you
Merge, then check
You review and merge on GitHub under your own rules. Afterwards the owner can ask Kanso to look at the public page once and report Verified, Unchanged or Inconclusive.
What you receive
Each artefact appears before the next step can happen.
A checked diff
The exact lines, the values and 14 checks, shown before anything is created. AI-suggested wording is labelled.
A pull request
One commit on a new branch, opened against your default branch and labelled as a proposal for human review.
Pull request status
The owner can read whether each pull request is open, merged or closed without merging.
A verification result
Verified, Unchanged or Inconclusive, from one look at one public page. It does not show rankings, indexing or traffic.
The owner confirms. You merge.
Nothing reaches your repository without explicit approval.
Kanso does
- Locates the file and prepares a small, bounded change
- Shows the diff and the checks before anything exists on GitHub
- Opens a pull request on a new branch, then stops
You decide
- Whether the preview is right, as the workspace owner
- Whether to confirm, twice
- Whether to merge, under your own review rules
- Whether to ask for verification
Kanso never
- Merges, approves or deploys anything
- Overwrites a branch or touches your default branch
- Edits workflows, dependency manifests or deployment files
Where this fits
Situations, not results. A change is offered only when your repository and the finding qualify.
A page has no meta description
The finding is eligible, Kanso proposes wording, and you review the diff.
A page is missing its canonical link
Kanso derives the address from the page's own observed address and adds the link.
A page title is empty
Kanso proposes a title to fill it, and you read it in the diff first.
How Kanso approaches code changes
Each point is something the product does today.
A boundary your team already trusts
A pull request is where Kanso's work ends and your review begins, with your own rules and branch protection.
Changes are small and bounded
One file, at most 12 changed lines, and never a workflow, dependency manifest or deployment file.
Nothing is committed on stale data
Kanso re-checks that the file has not changed since the preview before it commits.
What Kanso does not do here
This is a narrow workflow on purpose. These are the limits.
It does not merge or deploy
Kanso has no way to merge, approve or review a pull request, and it does not deploy.
It handles five changes, not all of SEO
Add or fill a title, add or fill a meta description, add a canonical link. Structured data, content, links, redirects and sitemap fixes are not supported.
It does not support framework or CMS sources
It edits one static HTML file, and stops when it cannot prove which file produces the page.
It does not build or run your code
Kanso does not build, test or run your code. It works through GitHub on the repository you chose.
The preview is not a picture of your site
It is a diff of the code change, not a rendered preview.
It does not promise results
Verified means a condition was observed on one page. It says nothing about rankings, indexing or traffic.
Related use cases
Get Found in AI Search
Check how readable your site is to AI systems, estimate how citable it looks, and turn the gaps into actions.
Findings about AI readability are tasks for you; Kanso does not prepare pull requests for GEO changes.
Turn Search Console Data Into Content
Turn Search Console opportunities into long-form article drafts in your brand voice, for you to review and publish.
For missing content rather than missing tags, the Writer Agent drafts articles.
Questions about this use case
What changes can Kanso make?
Five, all in the head of one static HTML file: add or fill a page title, add or fill a meta description, and add a canonical link.
Can Kanso merge or deploy?
No. Its code has no merge, approval or deploy call. A person merges on GitHub.
Who can create a pull request?
Only the workspace owner, after previewing the change and confirming a second time.
What if my site uses a framework?
Kanso looks for the page's static HTML file and stops if it cannot prove which file produces the page. It does not edit framework or CMS sources.
How does Kanso verify a change?
After the pull request is merged, the owner can ask Kanso to fetch the public page once and compare it with the proposal. The result is Verified, Unchanged or Inconclusive.
Does Kanso read my whole repository?
No. Only the one the owner chose, and only its file list and the single HTML file that appears to be the page.
See plans and pricing · All use cases
Get a small SEO fix into review without a ticket.
Enter your website. Once your repository is connected, a supported finding can become a pull request for you to review.
Get started free · No credit card required