I’m not an SEO expert: how I used an AI skill to audit my blog

Some tools are worth trying because they are popular.

Others make you rethink how you work.

I recently found Claude SEO, an open-source skill designed to analyze websites across technical SEO, content, performance, structured data, and AI-search visibility.

I decided to use it on this personal blog.

I did not expect it to uncover so many things worth reviewing.

My experience is building products, not running SEO audits

Throughout my years in software development, my focus has been building web applications.

Most of my experience is in building complete web applications across both frontend and backend. I have also worked on mobile projects, although to a lesser extent. I build products, solve architectural problems, and ship applications to production.

SEO has never been my specialty.

I know the basics: titles, metadata, performance, images, and a few good practices. But I do not know every technique, recommendation, and change that constantly appears around search, infrastructure, and visibility in AI-driven systems.

That is why this skill was so useful.

It did not replace knowledge I already had. It helped me spot blind spots in an area I do not work in every day, then turn them into concrete questions I could understand, review, and prioritize.

Cloudflare is still useful even if you are not an infrastructure expert

I have used Cloudflare in almost every project since I first found it.

I can set up what I need to deploy a site, manage DNS, add some security measures, and make everything work. But I have never considered myself an infrastructure expert.

That is where the skill was genuinely helpful.

The audit did not just tell me whether the site worked. It surfaced configurations and decisions I could evaluate:

• Cloudflare security options I had not enabled.
• Headers that could improve site protection.
• Performance details that were not on my everyday checklist.
• Image loading and optimization.
• Content and internal-linking recommendations.
• Newer pieces such as llms.txt.

Most of those things were not entirely new to me. The issue was different: I did not have a structured checklist to review them or enough time to research every area from scratch.

The skill turned a large, vague task into a concrete plan.

What I found while reviewing the blog

Not every outcome was a theoretical recommendation. Some improvements were very concrete:

• The blog did not have an llms.txt file; it now exists and accurately describes the site's content.
• The main load metric for /blog/ went from 4.3 seconds to 1.72 seconds.
• That page's weight dropped from 862 KB to 298 KB after fixing responsive image delivery.
• I added security headers and reviewed how they worked alongside Astro and Cloudflare Analytics.

None of those changes is spectacular in isolation. Together, they make the site faster, clearer for crawlers, and more robust.

The audit also surfaced improvements that were not on my initial radar:

• Canonical and hreflang tags on blog pages stopped pointing to old routes and now match each article's real URL.
• Every post now includes BlogPosting and BreadcrumbList structured data, plus a consistent author entity, instead of having no JSON-LD.
• Publication dates, an author bio, reading-time indicators, a table of contents, and visible breadcrumbs were added to every post.
• The blog went from having no internal links between articles to 15 cross-links through related posts.
• IndexNow submission is now integrated into the deployment pipeline, so new or updated URLs are notified without an extra manual step.

The technical audit score went from 62 to 90 out of 100, while the overall SEO health score went from 54 to 83. I do not treat those scores as a traffic promise: they are a way to verify that concrete issues were fixed and decide what is worth improving next.

Part of that improvement was also using the framework's tools correctly. In my experience with Astro, I explain why performance is not just about choosing a technology, but about how you use it in a real project.

The value was not getting a task list

I could have taken the report, applied every suggestion, and called the audit done.

That would probably be the worst way to use an agent.

After each recommendation, I read what it proposed and why. Sometimes I asked for an explanation. Other times I disagreed with the priority or chose not to make the change.

Not because the tool was necessarily wrong, but because a technical recommendation only makes sense within a project's context. It is the same principle I apply in making imperfect but correct decisions: the best solution depends on the problem, the risk, and the context.

Enabling a header, changing a caching policy, or adding a security rule can sound like an automatic improvement. There are still questions to answer:

• What exactly does it protect?
• Which part of the site could it affect?
• Is it necessary for this project?
• How will I verify that it did not break anything?
• What real problem am I solving?

AI can research faster than I can. It can review documentation, find configurations, and propose a plan.

But it does not know my project better than I do.

AI is not a tool for people who know less

AI is often described as a crutch for people without technical knowledge.

I disagree.

The people who get the most value from an agent are often those with a strong foundation. Not because they can ignore what the model does, but because they can challenge it.

They can spot a recommendation that does not fit the context. They can ask for an explanation. They can change the plan. They can separate a meaningful improvement from a configuration added only because it looks professional.

The difference is not whether you use AI.

It is whether you use it as an oracle or as a collaborator.

A skill does not replace knowledge: it organizes expertise

What is interesting about skills is that they do not magically turn a model into an infallible expert.

They give it a process.

In this case, the audit combined several areas I would usually review separately: content, performance, infrastructure, headers, images, schema, search visibility, and preparation for AI systems.

I could learn each of those areas in depth. In fact, I already knew some of them.

But a skill gave me a structured diagnosis and let me spend my time on what mattered most: understanding, validating, and deciding.

That changes the productivity conversation completely.

It is not about doing more things without thinking.

It is about spending less time figuring out where to start, so you can spend more time making better decisions.

The limits still matter

This does not mean installing a skill, giving it access to a project, and accepting all of its changes.

Skills, agents, and any automation should be reviewed just as you would review another person's work.

You need to understand which files it can modify, which commands it can run, which services it can access, and which data it can read. When a skill comes from a third party, it is also worth reviewing its instructions before giving it broad permissions.

You also need to keep judgment over its recommendations.

Not every SEO suggestion should be applied. Not every performance optimization is a priority. Not every security header makes sense without evaluating compatibility and risk.

Speed without review can create more work than it saves.

The best way I have found to work with AI

My workflow is simple:

1. Let the agent analyze and propose.
2. Read the diagnosis and ask for context when I need it.
3. Discuss or change decisions I disagree with.
4. Apply small, verifiable changes.
5. Confirm that the result actually improves the project.

I do not delegate judgment.

I amplify it.

For me, that is one of the most useful ways to work with AI today: not asking it to decide for you, but using it to go further in areas where you are still learning.

If you use Claude Code, Claude SEO is worth trying. And if you use Codex, the project also provides a Codex version to turn a general-purpose agent into a collaborator with a more specific process.

It may not make you an infrastructure, SEO, or performance expert overnight.

But it can help you ask better questions, uncover blind spots, and learn while improving a real project.