Can automation replace a human SEO audit entirely?

No. Automation owns the repeatable layer: status codes per user agent, sitemap coverage, canonical conflicts, structured data, metadata. Humans still own positioning, keyword intent and whether a page deserves to exist. Viewfy handles the first category and opens those fixes as pull requests, so your review time goes to judgment calls instead of typos.

How often should the audit run?

Continuously, because your CDN and framework config change without anyone thinking about SEO. A deploy that adds bot protection can block AI crawlers the same day. In our Show HN scan of 383 products, 17% were blocked from Claude, and almost none of those blocks looked intentional.

What is llms.txt and does an audit check it?

It's a plain-text file describing your product for AI retrieval, similar in spirit to robots.txt but for meaning instead of permission. It belongs in an automated audit because it's a static file with a small blast radius, which makes it ideal pull request material rather than a roadmap discussion.

Will an automated pull request break my build?

It shouldn't, because the scope is deliberately narrow: content files, meta tags, sitemap entries, robots rules, structured data. No dependency bumps, no route changes, no refactors. Your CI runs on it like any other branch, and you close it if the diff looks wrong. That's the whole safety model.

SEO Audit Automation: What a Manual SEO Audit Misses

A manual SEO audit misses roughly 40% of technical issues, because humans check pages while crawlers check headers, redirects and CDN rules. Viewfy automates the SEO audit and opens the fix as a pull request on your repo.

Not a report. A diff.

The gap isn't laziness. It's surface area. A person opens ten URLs, squints at titles, notices a missing meta description, and writes it down. Meanwhile the thing costing you rankings is a 403 your CDN returns to one specific user agent, or three high-intent routes that never made it into sitemap.xml.

What does a manual SEO audit actually miss?

It misses everything that only exists in the request layer. Titles, headings and copy are visible in a browser, so humans catch those. Status codes for non-browser agents, redirect chains, canonical conflicts between prerendered shells and SPA routes, and sitemap coverage are invisible unless you go looking with a crawler.

A real example from our own repo, since it's the one we're allowed to be blunt about: frontend/public/sitemap.xml omitted three of the best pages on the site. The free audit route, the merged-PR proof wall and the house-rules page were all indexable, all high intent, and all absent from the sitemap. Nobody noticed in a manual review because every one of them loads perfectly when you click it.

That's the pattern. Manual audits test the happy path with a human browser. Search and AI crawlers do neither.

Why do AI crawlers see a different site than you do?

Because they arrive with a different user agent, no JavaScript patience, and no cookies. Your CDN, your bot protection and your framework's rendering mode each get a vote, and they don't always agree with your robots.txt.

We scanned 383 Show HN products with scripts/tier1_scan.py. 27% were unreadable to AI crawlers. 17% were outright blocked from Claude. These are launched products with real users and, in most cases, a robots.txt that says yes while something upstream says no.

That's the check almost no manual SEO audit includes, because it isn't an SEO habit yet. It's a GEO habit: will a model retrieving your page actually get bytes back, and are those bytes readable without executing your bundle?

What does SEO audit automation change about the workflow?

It changes the output format. An audit tool ends with a list of problems. Automation ends with a branch you can review, and that difference decides whether anything gets fixed.

Recommendations create work. Pull requests remove it.

We wrote about the mechanics of this in marketing automation for developers and how it plugs into review flow in GitHub marketing integration. The short version: a fix that arrives as a diff inherits your CI, your reviewers and your deploy pipeline. A fix that arrives as a PDF inherits your backlog.

Fact	Detail
Delivery format	SEO and AI visibility fixes opened as a pull request on your repo
Also included	A daily blog, plus posts on X and Threads
First post	Free, no card
Show HN scan sample	383 products
Unreadable to AI crawlers	27%
Blocked from Claude	17%

What belongs in an SEO pull request, and what never does?

Belongs: sitemap entries, robots and meta tags, canonical tags, structured data, llms.txt, alt text, heading structure, redirect rules, and copy that lives in a single i18n or content file. Never: refactors, dependency bumps, route changes, or anything touching app logic.

The test is whether a reviewer can approve it in under two minutes without loading context. On our own frontend, all landing strings live in one translations file and the landing shell is prerendered separately from the app shell, so a copy or meta change can't break a route. That's the kind of blast radius an automated PR should stay inside.

If a fix needs an architecture conversation, it isn't a pull request. It's an issue with a proposal.

Which issues should you automate first?

Start with reachability, then coverage, then content. In that order, because a beautifully optimized page that returns 403 to GPTBot is worth zero, and a perfectly written page that isn't in your sitemap is worth close to it.

Reachability

Fetch your top ten URLs with the user agents that matter, including AI crawlers, and record the raw status and the byte count of the response before JavaScript. If the body is an empty div, you have a rendering problem dressed as an SEO problem.

Coverage

Diff your sitemap against your actual route table. Every high-intent page should be in both. Our own audit and proof pages weren't, which is a two-line fix that a human audit had walked past more than once.

Content gates

This is where automation gets opinionated and should stay narrow. Our house style bans em dashes and filler words and requires each post to add something the internet doesn't already have. If the generator can't pass its own lint, it shouldn't open the PR.

Is SEO audit automation worth it for a small team?

Worth it if your bottleneck is implementation, not diagnosis. Most founders already suspect what's broken. What they don't have is an afternoon to confirm it, write the fix, and get it reviewed while they're shipping features.

If your bottleneck is strategy, positioning or a category you can't name yet, a tool won't solve that. We laid out the honest split in AI growth agent vs an agency, and where scheduling tools stop being enough in Viewfy vs Hootsuite.

One caveat on numbers: any proof stat we publish gets pulled live from the database, and the proof strip on our landing page hides itself when the count is zero. Same discipline applies to your audit. A number you can't regenerate is a number that starts lying.

How do you get an SEO audit that ends in a diff?

Drop a URL at viewfy.ai and get the crawl-level check plus your first post free, no card. If the fix looks right, merge it. If it doesn't, close it and you've lost a review, not a sprint.