I decided to put together a bit of a contensious post today, primarily because my social feeds are filling up with AI content, from AI slop to SEO spam that's driven by AI be it through a Claude SEO skill, Codex, OpenClaw or Hermes. As we see agentic adoption grow, we're seeing work-flows follow the same automation pipeline, which is fine, I get it, automation can be useful to save time, money and increase productivity.

But, there also needs to be a line drawn between a genuine SEO automation and one that's purely spam or programmatic content abuse. In today's post, I cover "SEO agents" within Claude, primarily because this is where I see a lot of social posts.

Today we're going to look at Claude + SEO Skills to see if it's all its cracked up to be. The reason I've opted for Claude + SEO is primarily because I'm seeing a huge amount of posts on Linkedin promoting "SEO agents" and "firing your SEO agency" - you know the "I was paying an agency $5000 a month, I replaced it with a $20 claude code subscription etc".


So, let's dive in, are these "Claude Skills / Agents" actually doing anything of value? Note, there's a few different aspects to this and thats:


1. Using Claude Agents for analysis, auditing etc.

  1. 2. Using Claude Agents for programmatic content generation, posting, spam etc

WHAT IS CLAUDE SEO?

  1. Today we're going to be looking at:
    https://github.com/AgriciDaniel/claude-seo

    We can see its had a few thousand downloads:

I've seen Claude SEO automation posts prominently on LinkedIn in the last month.

So, firstly what is it?

On the Git repo it says:
Universal SEO skill for Claude Code. 25 sub-skills + 18 sub-agents covering technical SEO, E-E-A-T, schema, GEO/AEO, backlinks, local SEO, maps intelligence, semantic clustering, e-commerce SEO, international SEO, Google APIs, and PDF/Excel reporting. Optional DataForSEO, Firecrawl, and Banana extensions.

So, basically, its more of an AUDITOR, it looks at various things and presumably comes up with a report, recommendations etc.

INSTALLING CLAUDE SEO FROM THE CLI

So, I installed it, it was fairly straightforward in Windows, I simply ran the install from Windows Powershell, started Claude in the CLI and off I went. Note you can only use SEO skills for Claude from the CLI (command line interface) you can't use this from within the desktop app.

I started with a full site audit, I used our own wesbite to see what it would come up with. I kick started with the full site audit and let the process run.....

It took around 20 minutes all in all to go through around 40 pages in total.


Now what's key to note here is that we don't actually have a list of what is being audited and what the full scope of SEO checks are, I believe it's likely using a mix of pre-set checks along with AI orchestrated checks, I'd have to look into the code to see, but top level, it looks like it will just do the usual SEO checks and perhaps some "GEO" checks, but as most good SEOs will know, there's not really much that's unique to GEO from SEO.

Anyhow, a coffee later and the audit had completed:

Annnnnnnnnnnnd..............

It was pretty much what I had expected, low level "generalised" issues, many of which are NOT critical.

So, let's take a look, now, I will be the first to say, YES, at the point of running the audit some pretty basic things were missing i.e. robots.txt (primarily because we've just deployed the website via vercel and also because we literally have nothing to limit via robots.txt).

THE SUMMARY SEO ISSUES AT A GLANCE

So, a quick mini-debunking of what the audit cimplained about vs reality before we look at the MD OUTPUT files.

SO, headline findings were:

SEO Health Score: 41 / 100 — poor, but the gaps are mostly foundational and quick to fix.

The headline finding: This is an SEO/PPC agency that sells LLM SEO and AI Overview optimisation, yet its own site is missing every foundational

artefact search engines and AI crawlers rely on:

- No sitemap.xml (404 on every variant)

- No robots.txt (404)

- Zero JSON-LD schema on every page tested (8 pages)

- No llms.txt

- Broken /sitemap → 308 → /sitemap/ → 404 chain (a permanent redirect to a dead noindexed page — particularly bad)

- Title template "%s | Assertive Media" doubles the brand on pages whose title already contains it ("Lenovo EMEA Case Study | Assertive Media |

Assertive Media")

HEALTH SCORES:

These are truly a waste of time and pointless, they are MEANINGLESS. You can have a perfect 100/100 score and still not rank, equally, SCORING SYSTEMS do not correlate with rank, they are a tools own pre-determined scoring based on their own checks, but they don't properly account weight wise.

NO SITEMAP

Sitemaps are NOT important for 95% + of websites, sitemaps are MORE important if websites are large and have complex architecture or are more likely to have a lot of thin/near orphan routes for content. A sitemap provides a list of URLS, but, a PROPERLY BUILT website would naturally make content easily discoverable on a crawl.

There is no harm in a sitemap, but the idea that they are needed for SEO is a myth, Google and other user agents can crawl websites, sitemaps can be a fall back sure, but will adding one make a difference to your websites SEO profile?

No, not really, not unless you have a complex website architecture or substantial sub-folder coverage and pages buried deep in the websites architecture.

ROBOTS.TXT

Yes, this should be present BUT, it's not an issue if not present if your website doesn't have anything to exclude. For best practice one should be available even if it just contains a blanket Allow: /. BUT, not having one for our website makes no difference as we have nothing to block.

Again, the tool doesn't differentiate on this, its just a checklist item, if the robots.txt is not PRESENT its marked with a high severity.

In reality, if a website doesn't have anything to block not having one isn't going to make a difference.

If your website DOES have content that needs restricting via robots.txt then yes it is important.

ZERO JSON SCHEMA

Again! just because its missing doesn't make it a critical SEO issue, some sites don't even need it. In fact, we're watching Google slowly depreciate parts of structured data usage with the most recent being the depreciation of FAQ rich results.

YES, if your pages / website warrants SCHEMA by all means add it, but, again, the claude code SEO skill doesn't make the distinction, it just treats it as it SHOULD be present.

Google and other user agents are getting better at being able to extrapolate data without needing structured data, if anything, structured data is "complimentary" for confirmation as opposed to being an absolute requirement.

NO LLMS TXT

And AGAIN! not an SEO issue, and even if it were for GEO, where is the proof that LLMS.txt is being used? and even if it were, what do people think its supposed to achieve at this point? Whilst Google recently did 2 things, they basically confirmed that they treat GEO as "SEO", they equally did recently announce that LLMS.TXT would be included as part of lighthouse auditing.

So, yes there is likely to be a need for it, but from an SEO perspective no and from a GEO perspective, well, unlikely to add any tangible benefit.

BROKEN SITEMAP

This is NO different to the missing sitemap.xml, you can have XML sitemaps and page sitemaps (in HTML), again, it's exactly the same thing again! Most websites do NOT need a sitemap, a well built, well optimised website doesn't need a sitemap.

If your website IS reliant on it and it's not a large or complex site, than it's probable that you have a poorly built website or poor website architecture or poor accessibility issues.

A broken sitemap is NOT an issue, we don't even have a sitemap, so it's classed as broken when we don't even link to a sitemap page.

TITLE TEMPLATE

Yes, but not a big issue, highlighted it, fine, I'll let this one go, but, big SEO issue? no, minimal, Google rewrites titles on a huge volume of occassions now. It was good to flag an anomaly, so theres 1+ point to the automation there for using Ai to spot a pattern that clearly looks to be a mistake.

OK! So now, let's explore the report that was generated. So, I checked the output directory and we have a series of documents included downloaded HTML

The main report is in the FULL-AUDIT-REPORT Markdown file, the Claude SEO skill does offer the ability to export to PDF but you need to set permissions and credentials, I just opted to open in VS code instead.

So opening in VS code we see

We see the first summary of what we already covered, we see the TOP 5 CRITICAL ISSUES (notice the word critical here)

But, as I've stipulated above, these are NOT CRITICAL issues!

Critical issues are things such as:

  • Rendering - can the HTML be rendered properly?

  • JS utilisation - what page content is loaded in dynamically, menus? in-page JS button event loaded content?

  • Content quality - what does the content quality look like? unique content? value content?

  • Content NLP - topical coverage? good use of topical coverage with variant synonyms?

  • Internal links - how many? anhor utilisation? anchor consistency? higher weighted pages with low link counts?

  • External links - how many? quality? etc

There's loads more! but you get the jist.

To QUICKLY re-debunk the top 5 critical issues.

Sitemaps (both XML and actual sitemap pages) are generally not needed for most websites and if they are, you clearly have a poor internal link setup. Sitemaps had more value back in the day when websites had JS that Google couldn't render or crawl properly - those days are going. Search engines and user agents are much better at crawling.

Robots.txt - NOT important if you do not have anything to explicitly disallow. Should be present for best practice obviously, but will rankings change without one? no.

SCHEMA / JSON - Not critical but useful to include. There's a huge amount of emphasis on structured data for SEO but in reality Google seems to cope fine without it as do many other user agents, not only that but Google seems to be depreciating various aspects of structured data.

And in regards to SCHEMA for AI / GEO? Well, this is something I am on the fence with, we know LLMS do not render output, but they may be able to parse structured data out, however, a recent study from AHREFS titled "We Tracked 1,885 Pages Adding Schema. AI Citations Barely Moved" seems to show that adding SCHEMA made no discernible difference.

OK so, let's now look at the SEO Health Score breakdown:

So, we see that the Assertive site (this site) scores:

| Category | Weight | Score | Weighted | Status |
|---|---|---|---|---|
| Technical SEO | 22% | 30/100 | 6.6 | Critical |
| Content Quality | 23% | 55/100 | 12.65 | Needs work |
| On-Page SEO | 20% | 55/100 | 11.0 | Needs work |
| Schema / Structured Data | 10% | 5/100 | 0.5 | Critical |
| Performance (CWV) | 10% | 50/100 | 5.0 | Unmeasured — estimate |
| AI Search Readiness | 10% | 25/100 | 2.5 | Critical |
| Images | 5% | 50/100 | 2.5 | Adequate |
| **Total** | | | **40.75 / 100** | |

We see that the audit DOES include checks beyond technical SEO which is great, so let's see what is checked.


TECHNICAL SEO

CRAWLABILITY

So looking at the crawlability we see >

We see this is checking "top level" crawlability and not the wider crawlability - I deliberately hid the menu from the rendered for the crawl/audit, this would of had a significant impact on "crawlability".

I also had a number of pages with only 1-2 internal links, same thing this wasn't picked up but would play a crucial part in SEO so if you were to miss this during an audit, well, that wouldn't go down well with clients.

The core things missed here:

* Didn't highlight if crawlability was impacted by missing navigation or near-orphaned pages

  • * Didn't highlight what rendered output looks like vs requested output

Things that I would of added in here for CRAWLABILITY (because remember some items can be crossed between crawlability and indexability - things like canonicals affect both), this is what I would of added in for checks:

Indexability audit of actual pages
Noindex via meta robots and X-Robots-Tag HTTP header across templates. Claude SEO caught one noindex on /sitemap/, but there's no site-wide sweep for accidental noindex on real pages which is one of the single most common Next.js crawlability nullifiers.

Canonical tag audit
Presence, self-referencing canonicals, cross-domain/wrong-target canonicals, and canonical-to-noindex conflicts. Completely absent here. But, I did see this in indexability so I'll give claude SEO benefit of the doubt here.

HTTP > HTTPS redirect
Site passed HTTPS and HSTS, but there's no check that http:// actually 301s to https://. HSTS only protects repeat visitors, first-hit and crawler behaviour depends on the redirect.

Host canonicalisation (www vs non-www)
No check that one resolves and the other 301s. Both serving 200 = duplicate crawl space.

Trailing-slash policy consistency
The /sitemap > /sitemap/ 308 hints at an inconsistent trailingSlash config. Needs a site-wide check that the policy is uniform and not generating redirect hops on internal links.

Status code sweep across the URL set
Soft 404s (200-returning empty/error pages), 5xx, and a full redirect-chain/loop audit beyond the one the claude SEO agent spotted.

JS rendering / SSR vs CSR
Critical for Next.js. Is content in the initial HTML or hydrated client-side? Test rendered vs raw HTML (and whether Googlebot gets server-rendered output).

Sitemap content validity
Only indexable 200 URLs, correct <lastmod>, no noindex/redirect/404 entries, under 50k URLs / 50MB.

404 page returns a real 404 status

Separate from soft-404 detection; confirm your custom not-found actually serves a 404, not a 200.

Crawl depth / orphan pages
Click depth from homepage and pages with no internal links in.

Hreflang
Only if there's any international/multi-locale intent; otherwise skip.

Next indexability.

INDEXABILITY

Looking at indexability we see

We see here that canonicals are checked, so good. However, it didn't append variables to a URL to test if the canonicals were configured correctly in situations where auto-generating canonicals may be present (where if you were to append a parameter to the URL the canonical could also update to match the URL - and this does happen).

We see a check for noindex tags, that's fine, didn't see anything for nofollow however.

Here are some of the things I would add in here that relate to indexability, there will naturally be some cross-over with crawlability:

X-Robots-Tag HTTP header check

Meta-robots noindex is covered, but the header-level equivalent isn't. It's invisible in page source and a classic Next.js/Vercel footgun (a stray headers() rule in next.config.mjs or middleware can noindex whole route segments). This is a pretty big gap.

Scope of the noindex/canonical check

both findings say "tested pages" / "on tested pages." There's no statement of coverage: which templates, how many URLs, was it the full set or a sample? An audit claim of "no noindex" only holds if it's a site-wide sweep, not a handful of pages.

Canonical target validity

they're self-referencing and absolute (good), but no check that canonicals point to 200-indexable URLs (not to a redirect, 404, or noindexed page), and that the canonical host/protocol/trailing-slash matches the live URL exactly. With trailingSlash: true, a canonical missing the slash is a silent mismatch.

Redirect-chain depth on the ~150 redirects

"well-organised" doesn't confirm they're all single-hop 301s. Need a check for chains (A>B>C) and that none land on a 404/noindex. The /blog/<slug> → /blog/ consolidations especially risk pointing acquired link equity at a redirect that then canonicalises elsewhere.

Host canonicalisation (www vs non-www)

Does the non-canonical host 301 to the canonical one, or do both serve 200? Not addressed here or in crawlability.


HTTP>HTTPS redirect

still not confirmed anywhere (HSTS in crawlability isn't the same thing).

Parameterised / faceted URL handling

any query-string URLs (?utm=, filters, pagination) and whether they're canonicalised or left as duplicate indexable space. Likely minimal on a Next.js marketing site, but unmentioned. If using pre-render which can append ID URL paths, stuff like this becomes all the more important.

Sgnals

if /blog/ paginates (/blog/page/2/), confirm those pages are indexable/canonical-correct rather than canonicalising to page 1.

Soft 404 / thin-content indexability

pages returning 200 that Google may treat as soft 404s (empty category/tag archives left over from the Divi build).

  • Now, let's look at security headers:

    SECURITY HEADERS


These are all good, no issues here. This is the coverage we typically see in Screaming Frogs SEO Spider.

Now let's look at caching.

CACHING

Now looking at caching we see >

This is good and enough of a check so no complaints here.

URL STRUCTURES

Looking at URL structure, we see a general check for URL case, hyphen usage, trailing slash checks, no nested queries - this looks good.

However, there are a few other checks I would of added in including:

URL depth / nesting

The example is four segments deep (/digital-marketing/seo/industries/healthcare-seo-services/). No check on whether depth is justified or whether some templates bury pages too far from root. Worth confirming the deep nesting is intentional taxonomy and not accidental.

Length

No check on overall URL length, especially for the deeper industry/blog pages. Long isn't fatal, but it's a standard line item and ties to the depth point above.

Keyword stuffing / repetition in the slug

Seo appears twice in the example path (/seo/.../healthcare-seo-services/). Not a real problem, but a URL-structure audit should at least note path-level keyword repetition across the segmented industry pages.

Reserved characters / encoding

No check for spaces, uppercase escapes, underscores, or %-encoded characters anywhere in the URL set. "Lowercase, hyphenated" implies it, but it's not an explicit pass.

Consistency of the path taxonomy

Does every industry page follow the exact /digital-marketing/seo/industries/<x>-seo-services/ pattern, or do some break the mould? An audit claim should confirm the structure is uniform across the template, not just on the one sampled URL.

Stop words / redundant connectors

minor, but whether slugs include filler ("and", "the", "for") inconsistently.

OK next, lets look at rendering.

RENDERING

So here we see:

So I highlighted earlier that this was missing, but it's here broken out into its own section. We can see that it's actually looked at the rendering. I tested this on another website that was a CSR shell (REACT / VITE - a site I had built in lovable before they fixed their awful rendering issues). It detected this, so I give the claude SEO skill credit here.

Next, we see a quick technical fixes summary:

This is fair - but again, it's not crucial stuff, just nit bits.

OK so next we move on to content quality:

CONTENT QUALITY

Here we see an initial top level summary, it seems to have just picked out the odd URL as opposed to a page by page audit.

We see it just seems to pick out nit bits, it doesn't appear to delve into content all that much, we do see E-E-A-T checks, but again this appears very broad:

This isn't looking at specific pages, advising on where there may be issues with content be it things such as:

  • Content intent alignment

  • Content depth / coverage

  • Content NLP

  • Content prioritisation / ordering

  • Grammar

  • Readability

  • Tone of voice

  • Writing perspective

It just seems to pick out bits where something might be missing as opposed to a more detailed content audit.

Next, we see mentions of titles, encoding and meta descriptions:

Again, we see these are very narrow - it seems to be looking for things to flag as opposed to a page by page analysis - which could be a fairly big issue if this audit is being ran but not an independent content level audit following it.

We see moreso that it's highlighting things that are missing as opposed to fallacies in the meta data itself.

When we look at the broader content fixes we see >

For a content audit, this is totally unusable, it provides the most broad top level recommendations you could imagine.

It had completely missed the thin service pages that I put out for a test, I added some SEO service pages and only added around 250-500 words of content to them, these were not flagged despite being thin pages that would never rank (if even get indexed).


The recommendations are so broad, there's no context, no proprer content checks or audit, so I would say the tool fails here.

I could go into MASSIVE depth here, content audits are substantial and given the importance of high quality content / helpful content, missing these is just not acceptable - not that the claude SEO skill should be able to, but, given the marketing around the "I sacked my SEO agency and replaced it with thie claude SEO skill" - it's key to highlight this.

Core content checks missed

Thin-page detection across the site

It flagged one thin page (the Lenovo case study) by eye, but only because that page happened to be in the 4-page sample. There's no word-count distribution across all pages, no threshold, no list of every page under it. Thin pages are found by sweeping the whole URL set, not by noticing one.

Duplicate / near-duplicate content

No similarity check at all. This is the single biggest omission for an agency site with templated industry pages (healthcare-seo-services, financial-seo, etc.). Those are exactly the pages most likely to be 80%-identical boilerplate with the vertical name swapped. Not measured.

Conflicting / contradictory content

No cross-page consistency check (claims, stats, service descriptions, NAP, pricing) that contradict each other across the site.

Topical coverage gaps

No map of what the site covers vs. what it should cover for its target queries. No competitor topic comparison. "Strong depth" on the SEO page is asserted from word count alone, not from coverage of the actual subtopics that rank.

Depth / comprehensiveness vs. intent

Word count is a proxy, not a measure. 5,189 words could be padding. No assessment of whether each page actually satisfies the query it targets.

Search intent alignment

No classification of each page against intent (informational/commercial/transactional) or whether the content type matches. The "question-format H1 dilutes authority" note is a stylistic opinion, not an intent analysis.

NLP / readability / entity issues

no readability scoring, no entity coverage, no keyword cannibalisation check (huge for templated industry pages all chasing "<x> SEO"), no semantic relevance assessment.

Cannibalisation

Closely related: multiple pages competing for the same query. On a site with this many near-synonymous service pages, almost guaranteed, and entirely unchecked.

Heading hierarchy quality

It counted H1s and H2s but never checked the structure: H1>H3 skips, multiple H1s, whether headings describe content or are decorative. A count is not a hierarchy audit.

Meta description quality at scale

Caught one encoding bug by luck; no check for missing, truncated, duplicated, or templated meta descriptions across the site.

Content freshness / staleness

No last-modified or publish-date analysis, no stale-content flags.

Image content

No alt-text coverage, no check that images support the content.

Internal linking from a content angle

Orphaned content, contextual link depth, anchor relevance (overlaps with the crawl-depth gap from section 1).

Other key things to consider here:

Sample-to-population overreach

The agent examined 4 pages or at least that's what it has reported back on.
Homepage, the SEO hub, About, and one case study and produced a site-level score of 55/100. Nothing in the output establishes how many pages exist, how those 4 were chosen, or whether they're representative. For an agency site where our entire content risk lives in the dozens of templated industry and service pages, the sample deliberately (or accidentally) excludes the exact pages where the real problems could exist. A score derived from an unrepresentative 4-page sample isn't a conservative estimate.

Proxy-for-substance substitution.

Every "Content Quality" metric in the output table is actually a structural/technical attribute: character counts, word counts, tag counts, schema presence.

None of them measure content quality, there's no specific checks shown or highlighted here.

Word count doesn't tell you if a page is good; H2 count doesn't tell you if it's well-structured or well put together, schema presence isn't a content property at all.

The audit measured what's cheap to parse and labelled it "quality." It then padded the gap with an E-E-A-T section that is entirely narrative judgement ("Strong," "Adequate," "Good") with no underlying check producing those grades, so in short, they're empty metrics.

ON PAGE SEO CHECKS

Next we look at on page SEO checks, we see:

So again, very basic!

Fair enough, they are valid and certainly can be taken into consideration.

SCHEMA / JSON-LD

Here we see coverage for structured data, more emphasis here but again very broad.

We see they are highlighting where there are use-cases and which type could be used, so I'll give it another benefit of the doubt here, you could certainly action this.

Also, interestingly we can see

So it's staying up to date, the AI requests are in real-time and no doubt the claude SEO code base is being updated.

It has given us a code block too which we can copy and apply to the website:

Although I note here that the address is missing data that is available on the website sitewide

So to copy and paste this without manually checking would potentially leave your structured data with holes in it.

Now let's look at performance:

CORE WEB VITALS (PERFORMANCE)

Now looking at this we see that it couldn't run the check because we hadn't provided an API key so I will have to go back and run this test again.

It looks at the core data for the site, but again, very top level.

Next lets look at AI SEARCH Readiness

AI SEARCH READINESS

Here we see some AI search recommendations. We see these are pretty much just SEO recommendations dragged into the AI grouping. We see LLMS.txt being recommended, but how much impact this is likely to have on AI search performance? probably none.

If we look - AI CRAWLERS not having a robots.txt to use will mean they CRAWL BY DEFAULT! So it not being present isn't an issue.

JSON-LD / SCHEMA, well, this is covered in SEO, so naturally if you fix it there may be some tangible benefit, although there aren't enough studies in the wild that show correlation between structured data and AI inclusion or citation frequency.

Content in initial HTML? Well, this is pretty much important for everything including SEO, so I wouldn't say this is unique to AI search, most sites that are SSR or running pre-render will have content in the initial HTML, it's fair to check for AI as LLMS do not render (at least for now).

Author bylines - well, this is SEO.

Direct answer formatting on service pages - this would form part of a content audit and would make sense for end users, obviously you'll want to be answering questions people ask, so is this AI specific? partly, but, again, there isn't anything to suggest that LLMS will struggle to understand a question and answer if they aren't set out in a specific way.

Brand mention signals - well, how has this been arrived at when it hasn;t looked at external link or citation data?

Next, looking at the PHYSICIAN HEAL THYSELF LIST

We see some broad recommendations here to improve relevancy for specific content types, in this case LLM SEO where we see some top level ideas on things that could be done.

In all fairness these are ok and actionable, I would say there is top level value in these, nothing earth shattering but good nonetheless.

Looking at IMAGES we see

Minimal value here, we see some guidance around image counts, how many are present, we see some security recomm endations and things around alt text quality, byte size, formats are not directly measured, so it looks like these need to be ran as a dedicated audit?

Next, BACKINKS! one of the most important aspects of SEO because of weighting on brand.

BACKLINKS

The most contentious point in SEO and perhaps the dirtiest and hardest area to work on in respect of actually getting good links. A link profile can make or break a domain irrespective of many other things, ie you could build the worlds best website, create amazing content but if you do not have good links, probability of ranking goes down significantly.

We see here, that the backlink audit is pretty much non existent, there is absolutely nothing of value here, even if we used GSC and the moz API as suggested, I highly doubt we'll get much of an audit.

And finally looking at SXO or "search experience mismatches"

SXO - Search Experience Mismatches

We see that the recommendations are super thin here, again it';s likely picked these out. We see that it has looked at some of the key terms, but, keep in mind this is 3 of thousands of keywords, so it should be taken with a pinch of salt.

Optimising pages for specific queries is becoming less and less viable, instead, pages should be measured by serve rates for relevant query groups, something I like to call query counting.

So, in terms of search experience, there is little you can do with this - again, the data is so thin.

Now, on to the ACTION PLAN!

ACTION PLAN

We see an output in an action-plan.md file >

Now, I'm not going to pick through this primarily because this is just a summarisation of all the points that the original FULL SITE AUDIT generated.


Basically, it's just the ACTION ITEMS extracted from the full site audit with a little more elaboration in certain areas - but fundamentally we're getting the same thing:

Ultimately we get:

  • Top 5 Critical Issues (that really aren't)

  • Top 5 Quick Wins (which is literally of very limited value)

  • SEO Health Score Breakdown

  • Technical SEO (crawl, indexability, security, caching, URL structure, rendering, quick technical fixes)

  • Very brief content quality score, page netrics, top level E-E-A-T, titles, descriptions, encoding

  • On-page SEO so scores, schema, performance etc.

  • AI Search Readiness (again of very limited value)

  • Images

  • Backlinks

  • SXO

OK so I guess you are going to ask -

Can Claude SEO's AI powered SEO analysis replace an SEO professional?

NO, the answer is a unanimous NO.

Can Claude SEO's AI powered SEO analysis replace an agency?

No.

Can it replace true SEO expertise?

No.

The reality is whilst this COULD theoretically be useful in specific use cases such as a FREE spot check SEO audit for potential clients, the value of it would stop there.

Simply because there are far too many holes/gaps in the data for this to ever be considered good enough to replace a professional SEO audit or professional SEO working on a site.

It could definitely be used in examples of running FREE SEO Audits to speed things up and engage prospects, it could also be used for quick sanity and spot checks.

But, this ISN'T a replacement for true SEO.