A checklist in a blog post is useful. A checklist you can actually open, fill in, and hand to someone is more useful. That's the difference this post is trying to make.
We wrote a full technical SEO audit checklist covering 40+ points across crawlability, architecture, on-page signals, performance, and security. This post is the practical companion to that one: a template structure you can copy into a spreadsheet, a step-by-step process for running it, and a way to turn the results into something your team actually acts on instead of a document that sits in a folder.
If you already know what a technical audit covers and just want the template, skip to the structure section. If you want the reasoning behind each check, read the full checklist first — this post assumes you know what canonical tags and crawl budget are and focuses on the "how do I actually run this" part.
The reason a template matters more than the checklist alone is simple: a checklist tells you what to check, but it doesn't tell you what to do with 40 findings once you have them. Most people who run their first technical audit end up with a long, unsorted list of problems and no clear sense of what to fix on Monday morning. A good template solves that by forcing you to record scope and severity as you go, not after the fact when you've forgotten the details.
Who This Template Is For
The shape of a technical audit changes a little depending on who's running it, so it's worth being specific about your situation before you start filling in a template.
In-house SEO or marketing teams usually run this quarterly or after major site changes — a redesign, a CMS migration, a big content push. You have the advantage of deep familiarity with the site, which means you can spot anomalies faster, but you also have the disadvantage of not seeing your own site with fresh eyes. Use the template as a forcing function to check things you'd otherwise assume are fine because "they've always been fine."
Agencies run this template repeatedly across different client sites, which means consistency matters more than depth on any single audit. A standardized template lets you compare notes across accounts, train junior team members faster, and produce a deliverable that looks the same (and builds trust) whether it's audit number one or number fifty for your team.
Freelancers and consultants often need this template to do two things at once: run a genuinely useful audit, and produce something client-facing that demonstrates value. The severity scoring section later in this post matters especially for you, since a plain list of 40 issues can overwhelm a client who doesn't know SEO, while a prioritized, scored list reads as expert judgment.
Whichever camp you're in, the underlying structure below works the same way. What changes is how much narrative and explanation you wrap around the raw findings.
One more note before we get into the structure: this template is deliberately spreadsheet-based rather than a fixed PDF form. A PDF looks polished, but it's dead the moment you print it — you can't filter it, sort it by severity, or track fix status over time. A spreadsheet, or a shared doc with a similar structure, stays alive as a working record you'll actually return to, which matters more than how professional the first version looks.
Template Structure Walkthrough
Build this as a spreadsheet — Google Sheets or Excel both work fine, and a shared sheet makes collaboration easier than a static PDF. Here's the column structure that's worked well in practice.
Column 1: Check ID. A short reference number for each check (matching the checklist categories: crawl-01, arch-04, perf-12, and so on). This makes it easy to reference a specific finding in a Slack message or a ticket without retyping the whole description.
Column 2: Category. Crawlability, Architecture, On-Page Technical, Performance, or Security. Grouping by category lets you filter and see, for instance, whether your performance issues are worse than your architecture issues at a glance.
Column 3: Check description. The specific thing you're checking — "Robots.txt doesn't block CSS/JS," "Hreflang tags are reciprocal," and so on, pulled from the full checklist.
Column 4: Status. Pass, Fail, or Needs Review. Keep this to three options. More granularity here just slows down data entry without adding useful signal.
Column 5: Severity. Critical, High, Medium, or Low. This is the column that turns a raw list into a prioritized action plan — more on how to score this below.
Column 6: Affected URLs / scope. Is this a single-page issue or a template-wide issue affecting thousands of pages? This single field does more to inform prioritization than almost anything else in the sheet, because a template-wide issue at Medium severity often deserves more urgent attention than a Critical issue on one obscure page.
Column 7: Evidence / notes. A screenshot link, a Search Console export reference, or a one-line note on how you found the issue. Six months from now, you or a teammate will want to know why something was flagged, and "trust me" doesn't hold up in a re-audit.
Column 8: Recommended fix. A short, specific instruction — not "improve performance" but "compress hero images on the product template and add explicit width/height attributes."
Column 9: Owner. Who's responsible for fixing it — a specific person or team, not "someone."
Column 10: Fix status and date. Open, In Progress, Fixed, Won't Fix (with a reason). This turns your audit from a snapshot into a living tracker you can revisit.
Ten columns sounds like a lot, but most of them take seconds to fill in once you've found an issue. The investment pays off the first time someone asks "did we already know about this?" six months later and you can just search the sheet.
How to Run the Audit, Step by Step
Step 1: Pull your baseline data first. Before touching a single row of the template, export your Google Search Console coverage report, crawl stats, and Core Web Vitals data. Also run a full-site crawl with a tool like Screaming Frog. Having this data open in tabs before you start prevents you from re-running the same export five times as you go.
Step 2: Work through crawlability and indexability first. Check robots.txt, sitemap health, noindex tags, and crawl stats before anything else. If you find a page or section that's blocked from crawling, note it and move on — don't get distracted investigating deeper issues on pages Google can't even reach yet, since some of those "issues" might resolve themselves once crawlability is fixed.
Step 3: Move to site architecture. Check for orphan pages, click depth, and URL structure using your crawler's export. This step benefits from visualizing the site as a graph if your tool supports it — orphan pages and overly deep sections tend to jump out visually in a way a spreadsheet row doesn't convey.
Step 4: Check on-page technical signals. Canonical tags, hreflang (if applicable), structured data, and duplicate metadata. This is usually the most time-consuming section because it requires spot-checking individual pages rather than just reading an aggregate report, especially for structured data validation.
Step 5: Run performance checks. Pull Core Web Vitals field data by template rather than by individual URL — you want to know if your product template has a systemic LCP problem, not just that one product page happens to be slow. Supplement with Lighthouse or PageSpeed Insights for diagnostic detail on the worst offenders.
Step 6: Finish with security and accessibility. Check the Security Issues report, confirm HTTPS is fully enforced, and do a quick pass on alt text and heading structure. These checks are usually faster than the earlier sections.
Step 7: Score severity and assign owners. With all findings logged, go back through and assign severity and ownership before sharing the document with anyone. A half-finished audit with no prioritization creates more anxiety than clarity for whoever receives it.
Budget more time than you think for step 4. On-page technical checks always take longer than they look because you keep finding one more edge case worth spot-checking.
A Worked Example
Say you're auditing a mid-sized ecommerce site — a few thousand product pages, a blog, a handful of category pages. Here's roughly how the findings might land in the template.
You start with crawlability and find that the sitemap includes about 200 URLs returning 404s, left over from products discontinued last year and never removed from the feed. That's a Medium severity finding — it wastes some crawl budget but doesn't block anything important. You log it as arch-related in the Crawlability category, note the affected count, and assign it to whoever owns the product feed integration.
Moving to architecture, you find that category filter combinations (color plus size plus price range) are generating around 40,000 unique, mostly duplicate URLs, many of which are getting crawled. That's a Critical finding, because it's actively diluting crawl budget away from the actual product and category pages you want ranked. You flag the scope as "sitewide, faceted navigation" and recommend a parameter-handling rule plus selective noindex on low-value filter combinations.
On the on-page technical pass, you discover the product template's canonical tag has a bug: it's pointing to a staging URL that got hardcoded during a recent deploy and never caught in testing. Every single product page — a few thousand of them — is technically telling Google to consolidate onto a URL that returns nothing. That's Critical, template-wide, and gets flagged for same-day attention once found. This is exactly the kind of issue that looks tiny in a code diff and enormous in its actual impact, and it's also exactly the kind of thing a quarterly manual audit might miss for weeks if nobody happens to inspect page source on a random product page in between audits.
Performance checks show LCP passing comfortably on desktop but failing on mobile for the product template, driven by an unoptimized hero product image served at full resolution regardless of viewport. That's High severity — template-wide, real user impact, but not blocking indexing entirely — and gets scheduled into the next sprint.
By the time you're done, you don't have "40 things wrong with this site." You have one Critical fix that needs to happen today (the canonical bug), one Critical fix that needs a slightly bigger conversation about faceted navigation strategy, one High severity performance fix for the next sprint, and a Medium cleanup task for the product feed. That's a roadmap, not a wall of findings, and it's a completely different document to hand to an engineering team than a raw 40-row list would be.
Interpreting Results and Severity Scoring
Not every failed check deserves the same reaction, and treating them all equally is how technical audits turn into ignored 40-item to-do lists that nobody works through.
Critical severity: anything that blocks crawling or indexing for a meaningful set of pages. A sitewide accidental noindex, a robots.txt block on a whole section, a broken sitemap. These get fixed immediately, often within the same day they're found, because every day they persist is measurable lost visibility.
High severity: template-wide issues that affect indexing quality or user experience but don't fully block a page from being found. A canonical bug affecting an entire product template, a Core Web Vitals failure on your highest-traffic page type, hreflang reciprocity failures on an international site. These get scheduled for the next development sprint.
Medium severity: issues affecting a smaller set of pages, or issues with clear but not urgent impact. Orphan pages on low-traffic content, minor structured data gaps, individual duplicate meta descriptions. These get batched and worked through over the following month or two.
Low severity: cosmetic or best-practice items with minimal measurable impact. Alt text on decorative images, minor URL structure inconsistencies on old content you're not actively promoting. These get fixed opportunistically, when someone's already working in that part of the site for another reason.
A useful gut check when scoring: ask how many pages a fix affects and how much traffic those pages carry, combined. A Critical-sounding issue on a single page nobody visits is often less urgent in practice than a Medium-sounding issue on your template used by 4,000 pages.
Turning Findings Into a Fix Roadmap
An audit that ends at "here's a spreadsheet with 40 rows" hasn't actually accomplished anything yet. The roadmap is the part that turns findings into results.
Group your Critical and High severity items into a first phase, and put a real date on it — two weeks is a reasonable target for most sites, since these are usually a small number of high-leverage fixes rather than a huge volume of work. Communicate this phase separately from everything else, because leadership and stakeholders care about "we fixed the things that mattered" far more than "we fixed 40 things."
Batch Medium severity items into your regular development cycle rather than treating them as a separate initiative. If your team runs two-week sprints, allocate a fixed, small percentage of sprint capacity to technical debt from the audit rather than trying to squeeze it all into a dedicated project that competes with feature work for priority (and usually loses).
Low severity items go into a backlog that gets worked on opportunistically. Don't pretend you're going to schedule dedicated time for alt text on decorative images. You're not, and that's fine — just don't let them get lost entirely by leaving them off the tracker.
Re-check your Critical and High items after the fix window closes, using the same method you used to find them originally. A fix that wasn't verified is just a hope.
Automating Recurring Audits
Running this template by hand quarterly is a reasonable starting point, but most teams eventually hit a wall: sites drift out of compliance between audits faster than a quarterly cadence catches. A new template ships with a canonical bug, a plugin update quietly re-enables noindex on a section, a redesign breaks internal linking to a whole category — and you don't find out until the next scheduled audit, months later.
The practical fix is separating "deep audit" from "continuous monitoring." Keep the full manual audit on a quarterly or biannual cadence for the judgment-heavy work — architecture review, content-adjacent technical decisions, competitive context. But put the mechanical, repeatable checks — crawl errors, noindex changes, broken canonical tags, Core Web Vitals regressions, new security issues — on continuous automated monitoring that flags problems within days, not months.
This is exactly the gap tools built for ongoing technical monitoring are meant to close: instead of rediscovering the same category of issue every quarter, you get alerted when something changes, close to the moment it happens, on the specific pages or templates affected. The audit then becomes less about discovery and more about strategic review — which is a better use of your time anyway.
Think about the canonical bug in the worked example above. If that had gone unnoticed for a full quarter between audits instead of a day, that's three months of every product page telling Google to consolidate onto a dead staging URL. Nobody would have noticed from the outside until organic traffic on the whole product catalog had already dropped, and by the time the quarterly audit caught it, you'd be doing damage control instead of a quick same-day fix. That gap between "when a problem starts" and "when a quarterly process catches it" is the actual cost of relying on scheduled audits alone, and it's usually much bigger than people expect until they've lived through one incident like it.
FAQ
Is this template a replacement for a paid SEO audit tool?
Not entirely. This template gives you the structure and process to run a thorough manual audit using free tools like Search Console and a crawler. Paid platforms add automation, historical trend tracking, and continuous monitoring that a manual quarterly process can't match. Many teams use a template like this for judgment-heavy review and a tool for the recurring mechanical checks.
How long does a full audit take using this template?
For a small to mid-sized site (under a few thousand pages), plan for one to two full days of focused work using the step-by-step process above. Larger or more complex sites, especially international ones with hreflang requirements, can take a week or more, mostly because of the spot-checking required for on-page technical signals.
Do I need developer help to run this audit?
Not to find the issues — most of the checks use Search Console, a crawler, and browser tools that don't require code. You'll typically need developer involvement to implement fixes, especially anything touching templates, server configuration, or site-wide code changes.
What's the difference between this template and the full checklist post?
The full checklist post explains what each of the 40+ checks means and why it matters. This post is the operational companion — the spreadsheet structure, the step-by-step process for running it, and the scoring system for turning results into a prioritized plan.
How often should I re-run the audit using this template?
A full audit every quarter is a reasonable default for most active sites, with continuous automated monitoring covering the highest-risk categories (crawl errors, indexing changes, Core Web Vitals) in between scheduled audits.
Can I use this template for a single-page or one-off audit instead of a full site?
Yes. The column structure works the same way at any scope — just filter your check list down to whichever checks are relevant to the page or section you're reviewing, and skip the site-wide checks like crawl budget or sitemap structure that don't apply to a single-page review.