AI SEO With Claude: A Redesign Audit for the Dev Team

Build Diary · 04 ·

AI SEO with Claude — a redesign audit, handed to the dev team.

I used Claude to run an on-page SEO audit across three redesigned SaaS pages — pulling live markup, Search Console and Keyword Planner — then handed the developers a fix list instead of editing production. Every step timestamped.

Build time
4h 30m
Bugs fixed
2
Breakthroughs
3
Dead ends
2
  1. Start

    Three redesigned pages, one rule: rewrite headings only.

    A real-estate AI SaaS rebuilt its site on a staging environment and wanted the redesign checked for SEO before launch — homepage, photo editing, and renovation. My constraint: I could only rewrite existing headings, never add or remove them. So the method had to be diagnostic, not creative. For each page Claude pulled the live markup, the Search Console queries it already ranked for, and Google Keyword Planner volumes, then reviewed it element by element: title, H1, every heading, canonical, hreflang, schema, and internal links.

  2. Eureka ✦

    The homepage ranked for a phrase that wasn’t in its H1.

    The shift: stop guessing the target keyword — read what the page already ranks for, then put that phrase where the page can use it.

    Search Console showed the homepage earning hundreds of clicks for its single biggest non-brand term while that exact phrase appeared nowhere in the H1. The page was quietly ranking on page-2 strength alone. That one data point reframed the whole audit: the job wasn’t to invent keywords, it was to align each page’s visible headings with the demand it was already attracting but under-serving.

  3. Eureka ✦

    One money term, one page — the anti-cannibalization rule.

    The shift: treat the site as a portfolio of intents, not a pile of pages — and assign each head term an owner.

    The tool pages were all drifting toward the same big generic terms, which means none of them would win any of them. So we set an architecture rule and reused it on every page: the homepage stays a hub that links to tools and lists them in its meta description, but never targets their terms in its title or H1; each tool page owns exactly one head term. This rule did more for the projected rankings than any single heading rewrite.

  4. Bug 01⏱ ~40 min · 🧠 reusable lesson

    The same five template bugs shipped on every page.

    Symptom
    Every redesigned page repeated the same defects: the canonical pointed at the staging host, OpenGraph/Twitter tags were missing entirely, the “How It Works” H2 rendered twice (desktop + mobile), the blog strip shipped “Mock placeholder” cards with empty images, and CMS editor artifacts (data-editable-*, a dev-host API URL) leaked into the public HTML.
    Root cause
    These aren’t content problems — they’re template-level and identical everywhere, baked into the shared layout and the editor build. No amount of heading rewriting touches them.
    Fix
    They became a dev-team punch list: move canonical to production, add the OG/schema set, render one H2 and CSS-toggle, populate or hide the blog, and strip editor artifacts from the production render. Handed over, not hand-edited.
  5. Bug 02⏱ ~30 min · 🧠 reusable lesson

    Broken hreflang and a CTA pointing at three different hosts.

    Symptom
    On the photo-editing page, the hreflang alternates for en and x-default pointed at the homepage instead of the page itself, and the primary call-to-action used three different app hosts across the page (one with an extra dev. subdomain that was likely dead).
    Root cause
    Self-referencing alternates were templated wrong, and the CTA links were authored by hand at different times against different environments.
    Fix
    Point each alternate at its own URL and collapse the CTA to one canonical app host. My call on the headings: keep the strong H1 as-is, front-load “Real Estate” in the title, and rewrite the duplicated bottom content block so it stops cloning the homepage copy.
  6. Dead end⏱ ~25 min

    Pushing edits straight to staging — until it 502’d.

    While we were lining up changes, a staging deploy fell over with a 502 and the developer called a freeze. The plan to push edits as they were found died on the spot; touching it further would have made debugging the outage harder.

    Slack thread: homepage returned a 502 after changes, developer says stop pushing changes
    The freeze, in Slack. (Translated to English; the request payload with session cookies is redacted; names shown as roles.)

    What I learned: on a shared staging build, the SEO reviewer doesn’t own the deploy. Agree on a delivery channel first — section by section, as payloads the dev applies — so an audit never collides with an outage.

  7. Dead end⏱ ~20 min

    Trusting keyword numbers from a bad tool run.

    Early on, a batch of keyword volumes came back from a flaky data pull and I started building the renovation strategy on them — a big, low-competition, fast-growing cluster. It looked too good. Re-querying Google Keyword Planner cleanly told the real story: the head term was mid-competition, and the phrase the page’s title leaned on (“ai renovation software”) had effectively zero demand.

    What I learned: re-pull suspicious numbers before they become a strategy. One clean confirmation call is cheaper than a plan built on noise.

  8. Eureka ✦

    The “renovation” page was actually an interior-design page.

    The shift: audit the rendered HTML, not the URL or the brief — the page’s real intent lives in its H1 and copy.

    The page lived at /renovation, but its real H1 was “AI Interior Design and Renovation” and almost all of its content — hero, tool cards, FAQ — was interior-design. It was the redesigned successor of the old interior-design page. The owner then made the call: this page is renovation only, the standalone interior-design page is retired. That decision changed everything downstream — title, H1, FAQ, and a required 301 redirect — and none of it would have surfaced from the URL alone.

    Slack thread: agreeing to apply SEO changes section by section once the deploy is fixed
    Coordinating the section-by-section handoff once the deploy was healthy. (Translated; names shown as roles.)
  9. Shipped

    Three review docs + a dev punch list, ready for launch.

    Each page got a self-contained review: a complementary, non-cannibalizing title and H1, a copy-paste meta-tags table, JSON-LD with no invented data (real price kept, ratings left as a marked placeholder rather than faked), and an element-by-element heading pass. The cross-page template bugs went to the developers as a single list, and the strategy decisions — hub-and-spoke architecture, renovation-only scope, the 301 — were written down so the handoff survives the chat.

The honest accounting

Where the time actually went.

Active working time across three chats — idle gaps excluded. Most of it went to pulling clean data and writing the handoff, not to the heading rewrites themselves.

Setup & data
60m
Debug bugs
55m
Dead ends
60m
Eureka moments
35m
Polish & ship
60m

Takeaway: the single biggest time-saver would have been agreeing the delivery channel — section-by-section payloads to the dev — before the deploy broke, not after.

Questions you might have

The real questions about this.

Can Claude actually do an SEO audit, or just write content?

It can audit. The useful pattern is feeding Claude the live page markup plus Search Console queries and Keyword Planner volumes, then having it review element by element: title, H1, headings, canonical, hreflang, schema, and internal links. It is not a crawler — you bring the data — but it is fast at spotting intent mismatch, cannibalization, and missing tags across many pages.

What is keyword cannibalization and why did it shape the audit?

Cannibalization is two pages competing for the same money term, so neither ranks well. The fix was an architecture rule: each money term belongs to exactly one page. The homepage stays a hub and links to tools without targeting their terms in its title or H1; each tool page owns its own head term.

Why hand the work to the dev team instead of editing the pages directly?

The redesign was on a staging build behind a CMS editor, and mid-audit a deploy returned a 502, so the developer froze changes. We agreed to apply edits section by section and I handed over each change as a payload rather than touching production. Several fixes — canonical pointing at the dev host, broken hreflang, stripped editor artifacts — are template-level and only the dev team can ship them.

What were the highest-impact fixes found?

Re-pointing titles and H1s to the terms each page could actually win, fixing hreflang that pointed at the homepage instead of the page itself, moving canonicals from the dev host to production, adding missing OpenGraph and BreadcrumbList/SoftwareApplication schema, and removing placeholder blog content before launch.

Build Diaries · A series on shipping AI-built work to production — every minute timestamped, every dead end shown, every breakthrough named.

Leave a Comment

Your email address will not be published. Required fields are marked *

Scroll to Top