Skip to content
Home/AI-Assisted SEO Workflows

AI-Assisted SEO Workflows

I build these for teams I am already running, not as demos. Four of them are in use: an internal linking dashboard, an overnight rank and competitor report, automated briefs and quality checks, and page structure aimed at AI answer surfaces. Built with Claude, ChatGPT and MCP.

4
Tools built and in use
70%
Less time from analysis to change
Daily
How often the rank reports run
9
Years in SEO

What I have built

Four things, all taken from an idea to something a working team opens. Each one exists because a task was eating a disproportionate part of somebody's week.

  1. Internal linking dashboard

    Reads every internal link on the site and maps how link distribution actually falls, per page. Given a piece about to publish, it says which existing pages should point at it and which it should point at. Finds orphans, which no report starting from a URL list can do.

    Streamlit · Google Sheets · Claude · MCP

  2. Daily rank and competitor monitoring

    Runs overnight across tracked keywords and competitor pages, then writes a short report on what moved and what to do about it. The output is recommendations the desk can act on, not a data dump they have to interpret at 9am.

    Automated workflow · Claude · MCP

  3. Content operations automation

    Brief generation from SERP and query data, optimisation checks before publishing, and a helpful content quality pass that flags pages not answering the question they were written for. Advisory only, never blocking.

    Claude · ChatGPT · MCP

  4. AI search visibility

    Structuring pages with schema and direct answer formats so they can be cited by AI answer surfaces, then using Search Console AI reporting to track visibility as that data becomes available. The newest of the four and the least settled.

    Schema · Search Console

Why most internal SEO tools die

Almost every team has a dashboard somebody built that nobody opens. The build is rarely the reason. These six are, and I have been on the wrong side of most of them.

  1. It lives somewhere nobody goes

    A tool behind a login the team does not already have gets opened twice. Everything I have built that survived runs where the work already happens, which for content teams has usually meant Google Sheets.

  2. It answers the builder's question

    SEOs find crawl depth distribution fascinating. An editor wants to know what to write today. A dashboard that answers the first question and not the second is a dashboard that gets bookmarked and forgotten.

  3. It blocks something

    The moment a quality check can stop a piece publishing, the desk finds a way around it, and now you have both a broken process and no data. Every check I build is advisory. It is a worse tool and a far better outcome.

  4. Nobody owns the maintenance

    APIs change, sheets get renamed, someone leaves. A tool without an owner has a half life of about four months. Worth deciding who that is before building, not after it breaks.

  5. It gives an answer with no reasoning

    A recommendation a person cannot argue with is a recommendation they will not trust. Showing why a page was suggested is what turns the output from an instruction into an opinion someone can overrule, which is when it starts getting used.

  6. It automated the wrong half

    The reliable split is that machines do the gathering and people do the deciding. Tools that invert that produce a lot of output nobody asked for, and the team quietly goes back to doing it by hand.

What I work on

Working out what is worth building

Most SEO teams have two or three tasks eating a disproportionate amount of the week, and they are rarely the ones people complain about. Finding those is a shorter job than building anything and it decides whether the build is worth it.

Outcome: You build the thing that gives you a day back, not the thing that demos well.

Building it

Streamlit applications, automated reporting workflows, and integrations with the data you already have in Search Console, Sheets or a crawler. Built with Claude, ChatGPT and MCP, which is what makes a one person build realistic at all.

Outcome: Something running, not a specification.

Connecting to your existing data

Search Console, analytics, crawl exports, rank tracking and whatever lives in the spreadsheet everyone actually uses. The integration work is usually where these projects stall, and it is not the interesting part, which is precisely why it gets skipped.

Outcome: One place where the numbers agree with each other.

Getting it adopted

The build is the easy half. Fitting it to how the team already works, sitting with them while they use it, and changing it when they do not is the part that decides whether it exists in six months.

Outcome: A tool that is still running after I stop looking at it.

Content structured for AI answers

Schema markup and direct answer formats designed to be quotable by AI answer surfaces, with Search Console AI reporting used to track it. This area is moving fast and I would rather say what is uncertain about it than oversell it. Related to the technical setup.

Outcome: Pages built to be cited rather than hoping to be.

Handing it over

Showing your team how the thing works so they can extend it, rather than leaving a black box with my name on it. Usually paired with the editorial process it sits inside.

Outcome: The tool outlives the engagement.

How I build one

Five rules, the second of which is the one that matters.

01

Find the hours, not the annoyance

People complain about tasks they dislike, which are not always the tasks eating the week. I would rather look at where the time actually goes than at where the frustration is, because those are different lists.

02

Automate gathering, never deciding

Pulling, cross referencing, checking structure and surfacing patterns are jobs a machine does better and more consistently. Judging what matters is not, and every tool I have seen fail had that boundary in the wrong place.

03

Build it where the team already is

The best tool nobody opens is worth less than a mediocre one in a tab they already have. This constraint has shaped more of my builds than any technical consideration.

04

Ship something small that works

A narrow tool doing one thing well gets used and then extended by demand. A complete platform gets built for six weeks and abandoned, usually because the requirements were guesses.

05

Show the reasoning

Every recommendation should carry why. It is more work to build and it is the difference between a team following the tool and a team trusting it, which are not the same relationship.

"AI should take work off the team, not take the thinking away from it. Automate the gathering and leave the deciding alone."

Harsh Sharma
Harsh Sharma
SEO Consultant, Gurugram

Work I can point at

Two tools in daily use and the process change that made them worth having.

In daily use

The internal linking dashboard

Maps the link graph across a site and recommends which pages should link to the piece about to be published.

Streamlit on Google Sheets
Built with Claude and MCP
In daily use

Daily rank and competitor monitoring

Runs overnight, reads what moved, and writes the desk a short report with content recommendations attached.

Automated overnight
Recommendations, not just data
Process

Cutting analysis to implementation by 70%

The tools were only half of it. The rest was rebuilding how a finding reaches someone who can act on it.

70% less time to ship a change
MoveUp Media

Frequently Asked Questions

Analysis, structure and repetition. Reading ranking movement and summarising what changed, generating the research half of a content brief, checking whether a page answers its own question, mapping internal links, and building the tools that do all of it. What I do not use it for is writing the articles.

Something is eating a day of your team's week

Tell me what it is and I will tell you whether it is worth automating, including if the answer is no.

Send me a siteUsually reply within a day