Coding Agent

Turn technical SEO findings into pull requests you review.

Kanso takes a finding from your site analysis, prepares a small change to the right HTML file in your GitHub repository, shows you the diff, and opens a pull request only when you confirm. It never merges and never deploys.

Free to start · No credit card required. Pull requests need GitHub connected. See how it works

Review proposed change
Ready to review
Repository
acme-inc/website
Base branch
main
Branch to create
kanso/seo-geo/3f9a1c0b7d42-g1-9be41c07-5d2e8a
File
about.html (modified)
Diff
--- a/about.html
+++ b/about.html
@@ -1,6 +1,8 @@
 <!doctype html>
 <html lang="en">
 <head>
+  <link rel="canonical" href="https://acme.example/about">
+  <meta name="description" content="Acme Inc. builds inventory software for small retail shops. Meet the team behind it and how we work.">
   <meta charset="utf-8">
   <title>About Acme</title>
   <link rel="stylesheet" href="/site.css">
Checks KANSO ran
  • Passed: One file only
  • Passed: Matches the recommendation's findings
  • Passed: Modifies an existing file (no create or delete)
  • Passed: Path is safe
  • Passed: A static HTML document

And 9 more, including that the change is small and that no secret is added.

This creates a pull request for human review. It does not merge or deploy the change. Nothing is created until you confirm.

Illustrative example. The company, repository, page and pull request shown are invented, not real data.
The problem

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.

Findings stall before the fix

An audit says a page has no meta description or canonical link. Getting that into the code is a separate piece of work, and it waits.

A ticket for a small change

A one-line fix still means a ticket, a developer's attention and a review, so it sits behind bigger work.

Marketing and engineering are separate

The people who spot the issue are often not the people who can safely change the repository.

AI changes are hard to trust

A generated change you cannot see, scope or approve is a risk, however good the suggestion is.

Small fixes are repetitive

Titles, descriptions and canonical links come up page after page. Each one is simple, and each one takes time.

The reason gets lost

By the time a change reaches a pull request, why it was made and what it should achieve is often missing.

The Coding Agent does not replace your developers. It prepares small, reviewable changes so their time goes on reviewing them.

The difference

Without Kanso, and with it

Without Kanso
  • An audit lists the issue
  • Someone files a ticket
  • A developer investigates which file renders the page
  • A manual edit
  • A review
  • A pull request
  • Someone checks the live page
With Kanso
  • A finding from Kanso's site analysis, with the evidence behind it
  • The right HTML file located in your repository, and proven to be the page's source
  • A small, checked change with a diff you can read
  • The workspace owner confirms before anything is created
  • A pull request on a new branch, labelled as a proposal
  • Your own review and merge on GitHub
  • A check of the public page after it is merged
What it is

The step between a finding and a reviewable change

Kanso does not just tell you what to fix. For the changes it supports, it prepares the change and runs it through a controlled GitHub workflow. You are in control at every step that matters.

01

Finding

A problem Kanso's site analysis observed on a public page.

02

Patch

A small change to one HTML file, built by Kanso's own editor.

03

Preview

The diff, the values and the checks, before anything exists on GitHub.

04

Approval

The workspace owner confirms. Nothing happens without it.

05

Pull request

One commit on a new branch, and a pull request for your review.

06

Verification

After you merge, a check of the public page, on request.

It prepares the change. You decide what happens to it.

Findings come from the same site analysis the SEO Agent works from. Kanso only offers a code change for a finding it can fully address, and it stops at a pull request.

How it works

From a finding to a verified change in six steps

STEP 01

Connect

The workspace owner connects GitHub and chooses the repository.

  • Install the Kanso GitHub App on GitHub, with access to Contents and Pull requests
  • Choose the one repository this project's website lives in
  • Kanso never picks a repository for you, and archived repositories are refused
  • Only the workspace owner can connect, choose or disconnect
GitHub Agent
Connected repositoryConnected
acme-inc/website (private)
Branch: main
GitHub account
acme-inc
Access
Contents and Pull requests
Chosen by
The workspace owner

KANSO never picks a repository for you. It can only reach the one repository you choose.

Illustrative example. The company, repository, page and pull request shown are invented, not real data.
STEP 02

Prepare

A finding becomes a proposed change, or Kanso says why it cannot.

  • Starts from a supported finding in Kanso's public site analysis
  • Finds the page's HTML file and checks it really is the page's source
  • An AI model suggests only the wording of a title or description, and it is labelled
  • Stops, with a plain reason, if it cannot be sure which file to change
Potential code change
Observed on the page
https://acme.example/about
Meta description missingCanonical link missing
File KANSO located
about.html
KANSO found the page's heading "About Acme" in this file, and the file shows the same problems.
Proposed values
  • Meta description: Acme Inc. builds inventory software for small retail shops. Meet the team behind it and how we work. AI proposal
  • Canonical link: https://acme.example/about Derived
Illustrative example. The company, repository, page and pull request shown are invented, not real data.
STEP 03

Review

See the change before anything exists on GitHub.

  • The repository, base branch, the branch Kanso would create and the file
  • The exact values, and the diff, line by line
  • The 14 checks Kanso ran, including that the change is small and adds no secret
  • A diff preview, not a rendered preview or a build of your site
Review proposed change
Ready to review
Repository
acme-inc/website
Base branch
main
Branch to create
kanso/seo-geo/3f9a1c0b7d42-g1-9be41c07-5d2e8a
File
about.html (modified)
Diff
--- a/about.html
+++ b/about.html
@@ -1,6 +1,8 @@
 <!doctype html>
 <html lang="en">
 <head>
+  <link rel="canonical" href="https://acme.example/about">
+  <meta name="description" content="Acme Inc. builds inventory software for small retail shops. Meet the team behind it and how we work.">
   <meta charset="utf-8">
   <title>About Acme</title>
   <link rel="stylesheet" href="/site.css">
Checks KANSO ran
  • Passed: One file only
  • Passed: Matches the recommendation's findings
  • Passed: Modifies an existing file (no create or delete)
  • Passed: Path is safe
  • Passed: A static HTML document

And 9 more, including that the change is small and that no secret is added.

This creates a pull request for human review. It does not merge or deploy the change. Nothing is created until you confirm.

Illustrative example. The company, repository, page and pull request shown are invented, not real data.
STEP 04

Approve and create

Only the workspace owner can create the pull request, and only after confirming.

  • The owner chooses Create pull request, then confirms it in a second step
  • Kanso makes one commit on a new branch and opens a pull request against your default branch
  • The pull request is labelled as a proposal for human review, and Kanso's work stops there
  • If the file changed since the preview, Kanso creates nothing and tells you
Confirm and create
Owner confirmation

Create a pull request in acme-inc/website against main? This creates a pull request for human review. It does not merge or deploy the change.

After you confirm
Pull request created for review
Pull request #14 in acme-inc/website
A pull request is a proposal. It does not mean the issue is fixed.
Illustrative example. The company, repository, page and pull request shown are invented, not real data.
STEP 05

Track

Kanso keeps a list of the pull requests it created.

  • The owner can check each pull request's current state on GitHub, read-only
  • Open, merged, or closed without merging
  • You review and merge on GitHub, under your own rules. Kanso cannot merge
  • Kanso does not deploy. What happens after a merge is your own setup
SEO/GEO pull requests
SEO/GEO pull requests
#14 KANSO SEO: add a meta description and add a canonical link in about.htmlOpen
acme-inc/website · kanso/seo-geo/3f9a1c0b7d42-g1-9be41c07-5d2e8a
Not verified
Not provided
  • Merging the pull request
  • Deploying the change
  • Building or running your site
  • Editing framework, script or style files
Illustrative example. The company, repository, page and pull request shown are invented, not real data.
STEP 06

Verify

Once you have merged, ask Kanso to check the public page.

  • The owner starts it. Nothing runs on a schedule
  • Kanso fetches the one public page once and compares it with the proposal
  • The result is Verified, Unchanged or Inconclusive, and Kanso says why when it cannot tell
  • It checks the page, not rankings, indexing or traffic
Verification
MergedMerged on GitHub by a person. KANSO did not merge it.
Verified: the expected condition was observed
KANSO observed the expected change on the public page.
  • Meta description text
    Expected: The meta description is the proposed text
    Found: Meta description matches the proposal
  • Canonical address
    Expected: The canonical link is the proposed address
    Found: Canonical https://acme.example/about

A check looks at one public page, once. It does not show rankings, indexing, traffic or what every visitor sees.

Illustrative example. The company, repository, page and pull request shown are invented, not real data.
Scope

A narrow job, done carefully

The Coding Agent supports a small set of changes today. It is clear about the rest.

What it can change

  • Add a page title that is missing
  • Fill a page title that is empty
  • Add a meta description that is missing
  • Fill a meta description that is empty
  • Add a canonical link that is missing

In one static HTML file, inside its head.

What it does not do

  • Edit framework, script, style or configuration files
  • Change page content, structured data or links
  • Change more than one file in a pull request
  • Work out which file a framework or CMS renders
  • Merge, approve or deploy anything
  • Build, test or run your code
Capabilities

What the Coding Agent does

GitHub App connection

The workspace owner installs the Kanso GitHub App with access to Contents and Pull requests, using GitHub's own sign-in.

One repository, chosen by you

Kanso works against the single repository the owner picks for the project. It never chooses one for you.

Finds the right file

Looks for the page's HTML file in your repository, and stops rather than guess when it cannot prove which file it is.

Five supported changes

Add or fill a page title, add or fill a meta description, or add a canonical link, in one static HTML file.

A checked patch

Kanso's own editor makes the change, and validation proves it touches only what the finding is about.

A diff preview

See the exact lines, the values and 14 checks before you decide. AI-suggested wording is labelled.

Owner approval

Only the workspace owner can create a pull request, and only after a second, explicit confirmation.

Pull request tracking

The owner can check whether each pull request is open, merged or closed without merging.

Verification of the result

After merge, Kanso checks the public page once and reports Verified, Unchanged or Inconclusive.

Control

AI proposes. You stay in control.

Kanso is built so that nothing reaches your repository without the owner's explicit approval, and nothing reaches your website through Kanso at all.

You connect the repository

The owner installs the app and chooses one repository. Kanso cannot reach any other.

The change is small and bounded

One file, a handful of lines, and never a workflow, dependency manifest, environment, key or deployment file.

You review the actual diff

The preview shows the exact change and the checks that passed, with AI-suggested wording marked as such.

You confirm twice

Opening a pull request needs the owner to click, then confirm. The server refuses it without that confirmation.

It stops at a pull request

Kanso never merges, approves, deploys or force-pushes. The pull request is where its work ends.

It never overwrites your work

It only creates a new branch, and creates nothing if the file changed since the preview.

Where Kanso's work ends

A pull request is a proposal, and it does not mean the issue is fixed. Kanso does not merge it, approve it or deploy it, and its code has no way to do any of those. Review, branch protection and deployment stay with you. A passing check means Kanso observed the expected change on one public page. It is not a guarantee that the change is right for your site, or that it will affect your rankings.

Why GitHub

A boundary your team already trusts

Kanso uses a pull request as the point where its work ends and your review begins.

Your existing workflow

A pull request fits how your engineers already review and ship changes, with the tools and rules they already use.

Changes you can read

A diff shows exactly what would change, line by line, before it goes anywhere.

A record of what happened

Branches, commits and pull requests give you history you can inspect later. Kanso's own branches are named so you can recognise them.

Clear ownership

A person decides whether to merge. Your review and branch protection rules stay in your hands.

Compared

Kanso Coding Agent, a manual workflow, or a generic AI coding tool

Manual implementationGeneric AI coding toolKanso Coding Agent
Finding contextFrom an audit, by handWhatever you paste into the promptA finding from Kanso's site analysis, with its evidence
Repository accessYour own checkoutVariesThe Kanso GitHub App, on the one repository you choose
Supported changesAnything a developer can writeVariesAdd or fill a title or meta description, or add a canonical link, in one static HTML file
Proposed patchWritten by handYesYes, built by Kanso's own editor and checked
PreviewIn your editor or a local buildVariesA diff with checks. Not a rendered preview of your site
Human approvalCode reviewVariesThe owner confirms before anything is created
Pull requestOpened by handVariesYes, one commit on a new branch
Pull request trackingOn GitHubVariesThe owner can check open, merged or closed
VerificationSomeone checks the pageVariesA check of one public page after merge, on request
Automatic mergeNot applicableVariesNot provided. You merge on GitHub
Automatic deploymentYour pipelineVariesNot provided. Kanso does not deploy
Framework, script and style filesYesVariesNot provided
Building or running your codeYour toolingVariesNot provided. Kanso does not run your code

Tools and workflows vary. This describes the typical case of working by hand, or with a general AI coding tool that is not connected to your site analysis. Kanso's column describes only what it does today.

Part of Kanso, not a separate tool

The Coding Agent works from the same site analysis as Kanso's SEO Agent. Start with your website, and see the pricing page for which plans include it.

See pricing →

Got questions?

Coding Agent questions

Use cases

Where the Coding Agent is used

These use cases name this agent in their workflow. Each one says what it produces and where you stay in control.

Goal · Search and AI visibility

Ship Technical SEO Fixes

Turn supported technical SEO findings into GitHub pull requests you review. Kanso never merges or deploys.

Industry · Software & Technology

SaaS

Search, content and community research for software teams whose marketing loses to product work.

Industry · Software & Technology

Tech Companies

Search and content support for technology companies that sell to developers and buyers.

Industry · Commerce & Consumer

Ecommerce

Search and content drafts for online stores, built from your own site and Search Console data.

Industry · Media & Publishing

Publishers

Search, AI-readability and article drafts for publishers. Kanso does not publish to a CMS.

Browse all use cases

Turn the next finding into a reviewable change.

Kanso prepares the change and opens the pull request when you approve it. Your team keeps the review, the merge and the release. Enter your website to start.

Get started free · No credit card required