Great content on a technically broken site is a great meal served on a dirty plate. Missing titles, duplicate content, pages that return the wrong status code, a canonical tag pointing at the wrong URL, a homepage that takes six seconds to load: none of it shows up in a word count, and all of it quietly bleeds rankings. Technical SEO audits catch this class of problem, and doing them by hand is exactly the kind of tedious, repetitive checking that automation was made for. Here is how to build a continuous audit in n8n, and how each kind of business should run it.
What a technical audit actually checks
A technical audit is a checklist run against every URL on your site. Does the page return a 200, or is it quietly a 404 or a redirect chain? Does it have a title tag, and is it the right length, or is it missing, duplicated, or truncated in the results? Is there exactly one H1, or zero, or five? Is the page indexable, or is a stray noindex tag hiding it from Google? Does the canonical tag point where it should? How fast does it load, and does it pass Core Web Vitals? Is the structured data valid or malformed? None of these require judgment. They require someone, or something, to look at every page and check.
That is why it automates so well. A person auditing a 500-page site by hand will get bored by page 20 and start skimming, which is when the real problems slip through. A crawler checks all 500 pages with the same attention on page 500 as page one. The public n8n templates for this crawl the site, check each URL against the Google PageSpeed API, run an AI pass over the content, and generate a formatted report covering title lengths, H1 tags, speed scores, and keyword coverage. The crawl is mechanical; the AI layer adds triage on top.
Where AI helps, and where a plain crawler is enough
Be honest about the split, because it is easy to over-engineer this. A plain crawler already tells you which pages are missing titles, returning errors, or failing Core Web Vitals. You do not need a language model to know a 404 is bad. Where AI earns its place is in triage and explanation: turning a raw list of 800 issues into a short list of the ten that matter most, grouping related problems, spotting patterns a rule cannot (a whole section of thin, near-duplicate pages), and writing the fix in plain language so the person who has to act understands why. The crawler finds; the model prioritizes and explains.
The build, in plain terms
On a schedule, n8n crawls your URLs, collecting the on-page signals for each. For speed, it calls the PageSpeed Insights API per URL and records the Core Web Vitals. A processing step flags the failures against your thresholds. An AI step reviews the failures, groups them, ranks them by likely impact, and writes a one-line fix for each. The output goes somewhere a human will see it and act: a report, a spreadsheet, or tickets in your tracker. The Core Web Vitals thresholds themselves are documented at web.dev, so you are checking against real targets, not invented ones.
Schedule (weekly)
-> Crawl URLs (status, title, meta, H1, canonical, indexability, schema)
-> PageSpeed API per URL (LCP, INP, CLS)
-> Flag failures against thresholds
-> AI triage (group, rank by impact, write the fix)
-> Route (report / spreadsheet / tickets)For agencies
A continuous audit is one of the most defensible services an agency can offer, because technical debt is invisible to the client until you show it to them. Most businesses have no idea their migration six months ago left 40 pages returning soft 404s, or that a template change stripped the H1 from every product page. An automated audit across your whole book means you catch these regressions the week they happen, on every client, without a human remembering to look. That is the difference between an agency that reacts to a traffic drop and one that prevents it.
Run one audit flow per client property and turn the prioritized output into a monthly technical health summary: what broke, what you fixed, what is queued. This reframes technical SEO from an invisible cost into visible, ongoing protection, which is exactly the story that renews a retainer. Keep the human judgment in the loop, because deciding which issues are worth billing time against, and which are cosmetic, is part of what the client is paying for. The audit finds everything; you decide what is worth fixing.
For micro businesses
As a micro business you probably built your site once and have not looked under the hood since, which is completely reasonable when you are busy doing the actual work. But it means small technical problems sit unfixed for years: a slow-loading homepage, a handful of pages with no title, a contact page accidentally set to noindex. You do not need a weekly enterprise crawl. You need to look once, thoroughly, and then check occasionally. A single audit run will likely surface a few genuine issues you can fix in an afternoon and then largely forget.
Keep it simple. A monthly or even quarterly crawl of your handful of important pages, a speed check, and a short list of what is broken is enough. You do not strictly need the AI layer at your scale; the raw crawl output is short enough to read yourself. The point is that most micro-business sites have never been audited even once, so the first run alone is often worth more than everything else on this list. Fix the broken titles, speed up the homepage, make sure your money pages are indexable, and you have closed the gap that was quietly costing you.
For SMEs
An SME site is usually big enough and changes often enough that technical issues appear faster than anyone notices. New pages ship without titles, a CMS update changes URL structure, a marketing tag slows every page down. A monthly or weekly automated audit turns technical health into a standing signal instead of a fire drill after a traffic drop. Wire the prioritized output into wherever your team tracks work so the top issues become tickets, not a report that gets skimmed and forgotten.
The discipline for an SME is to connect the audit to your deploy process. If a release can break 50 pages, the audit should catch it within days and flag it loudly. Set thresholds that match your priorities, focus the alerts on your commercial pages, and make sure someone owns the queue. Tie the speed side to real targets so you are chasing measurable Core Web Vitals, not a vague sense that the site feels slow. Done right, one person keeps a growing site technically clean, which is a job that used to need either a specialist or a painful annual audit that found a year of accumulated debt at once.
For mid-market teams
At mid-market scale a site is large enough that no human could audit it, and important enough that technical regressions cost real money the moment they ship. The audit here is monitoring infrastructure, not a periodic task. It runs continuously across many properties, it has to distinguish a genuine new problem from known accepted debt, and it must route each issue to the team that can actually fix it without burying anyone. The failure mode is a daily report of thousands of issues that everyone learns to ignore, which is worse than no audit at all because it creates false confidence.
Build it like any production monitoring system. Baseline the known issues so the audit alerts on new regressions rather than re-reporting accepted debt every run. Set severity so a page returning errors pages someone immediately while a minor meta-length issue waits for the backlog. Route by ownership so front-end regressions go to engineering and content gaps go to the content team. Integrate the speed data with your real user monitoring so you are acting on what actual visitors experience, not just lab scores. The engineering is the same as any alerting system: the SEO knowledge is the easy part, and signal-to-noise is the whole game.
The mistakes that make audits useless
The first mistake is auditing everything and prioritizing nothing. An audit that reports 900 issues with no ranking is a way to feel busy while fixing little. Force a priority order, and act on the top of it. The second mistake is chasing a perfect score. PageSpeed is a means, not an end, and grinding a 92 to a 96 while your titles are duplicated across a hundred pages is optimizing the wrong thing. Fix what costs you rankings, not what moves a vanity gauge.
The third mistake is auditing and never verifying the fix. An issue marked resolved that was never actually fixed is worse than an open one, because it drops off the list while the problem persists. Re-crawl after fixes and confirm the signal changed. The fourth is treating the audit as separate from your workflow: a report that lives in a folder nobody opens is not monitoring, it is archaeology. The audit has to feed the same queue where work actually gets picked up, or it does not exist in any way that matters.
- Prioritize ruthlessly: a ranked list of ten beats an unranked list of nine hundred every time.
- Do not chase a perfect speed score: fix what costs rankings, not what nudges a vanity gauge from 92 to 96.
- Verify every fix: re-crawl and confirm the signal actually changed before you mark an issue closed.
- Feed the real queue: an audit that lands in a folder nobody opens is not monitoring, it is decoration.
Where to start
Run one thorough crawl of your site this week, even by hand, and fix the top five technical issues it finds. That single pass usually returns more than months of content work, because it unblocks pages that were already trying to rank. A crawlable, indexable, fast site is not an SEO trophy in itself; it is the baseline that lets everything else you publish actually compete, so skipping it quietly caps the return on all the content work you do on top of it. Then automate the crawl on a schedule so the next regression does not sit undiscovered for a year. Pair it with Search Console mining and on-page automation so the technical health, the demand signal, and the on-page mechanics all run continuously instead of never.
If you want a continuous audit wired to your deploy process and your team's queue, with the noise tuned down to the issues that actually move rankings, that is the kind of monitoring Elevi runs for the sites it manages, and you can talk to us about it. The performance side connects directly to how we build fast sites at scale in the first place.
