Technical SEO audit checklist (NZ SME)

Start with a safe baseline (before you change anything)

A lot of SEO damage happens because changes are made without a baseline. Before you touch metadata or URLs, capture what you have and make the work reversible.

For current professional context and related proof pages, use About John Finnerty and the Projects hub. These pages help keep technical notes connected to maintained owned assets.

• Record current homepage title, H1, meta description, and canonical URL.
• Export or screenshot the current Search Console Performance summary (3 months is usually enough).
• Back up the site (or at least the pages you are about to edit) and note how to roll back.
• Write down who controls the domain registrar, DNS hosting, and website hosting.

If domain control is unclear, start with the DNS and email checklist first, because it is hard to fix SEO if you cannot reliably control DNS and redirects.

1) Canonicals and redirects (pick one preferred URL)

Your site should have a clear preferred URL format, usually HTTPS + www or HTTPS without www. Whatever you choose, everything else should redirect in one hop.

• Confirm http:// redirects to https://.
• Confirm your non-preferred host redirects to your preferred host (www vs non-www).
• Confirm the final URL returns HTTP 200 and self-canonicalizes to itself.
• Avoid multiple hops (e.g., http to https to www to trailing slash) if you can.

If you are unsure what your site currently does, treat this as a hosting/technical SEO task, not a content task. This is one of the fastest ways to remove confusing crawl signals.

Audit output: create a URL inventory first

Before you diagnose rankings, build a small URL inventory. The inventory does not need to be fancy. It needs to show which pages matter, whether they are indexable, which URL is canonical, and where each page sits in the site. This prevents the audit from becoming a pile of disconnected observations.

• URL and page type: homepage, service page, profile page, project note, blog article, topic hub, or utility page.
• Status code: expected 200, redirect, missing, blocked, or intentionally noindex.
• Canonical URL: what the page declares, what the sitemap lists, and what internal links point to.
• Search Console state: indexed, crawled, discovered, alternate canonical, duplicate, excluded, or not yet inspected.
• Priority: keep, improve, merge, redirect, noindex, remove from sitemap, or monitor.

For an SME site, this inventory often reveals the real problem faster than a ranking tool: thin pages, outdated URLs, no internal links, inconsistent canonicals, old redirects, or important pages that were never added to the sitemap.

2) Indexability and robots rules (avoid mixed signals)

Make sure Google is allowed to crawl and index the pages you want to rank. Mixed signals are common: a page can be listed in a sitemap but marked noindex, or canonicalized somewhere else by mistake.

• Confirm important pages are not noindex and not blocked in robots.txt.
• Exclude utility pages from sitemaps if they are intentionally noindex, follow.
• Check you are not accidentally canonicalizing multiple pages to the homepage.

If Search Console says "Discovered - currently not indexed", treat it as a signal to improve the page's usefulness, distinctiveness, and internal links, not just to press "Request indexing" repeatedly.

Robots and sitemap consistency checks

Robots rules, sitemap entries, canonicals, and noindex tags should tell the same story. A common audit finding is not one broken file; it is four files and tags giving Google slightly different instructions.

3) Sitemaps (make discovery easy)

A good sitemap is a list of your canonical, indexable URLs. It should not be a dump of everything that exists on the server.

• List only canonical URLs (the same URLs your pages self-canonicalize to).
• Keep lastmod accurate for the pages you actually update.
• Make sure Search Console shows "Success" for your sitemap, and the discovered-page count is plausible.

If you are expanding service pages and blog pages, update the sitemap in the same deployment so Google can find the new URLs quickly.

How to interpret Search Console without overreacting

Search Console is a diagnostic surface, not a scoreboard. Use it to separate discovery, crawl, indexing, canonical selection, structured-data eligibility, and performance. A page can be valid and still not rank well; a page can be indexed and still need better content or stronger internal links.

4) Titles, headings, and meta descriptions (match intent)

This is not about stuffing keywords. It is about making the page's intent obvious. A good title and H1 should tell a human, in one line, what the page is for.

• One H1 per page.
• Titles should be unique across pages and describe the page's actual job.
• Meta descriptions should be written for click-through clarity, not as a ranking trick.

If you have many services, it is normal to have multiple same-domain results when each page has a distinct job and useful content.

Title links and snippets are suggestions, not total control

Google can rewrite title links and snippets when it thinks another piece of page content or external anchor text better fits the query. That means the audit should check more than the <title> tag. Look at the visible H1, prominent headings, navigation labels, internal anchor text, Open Graph title, and whether the page actually answers the intent the title promises.

• Make each title unique and descriptive, with the most useful topic near the front.
• Make the H1 match the page's job without duplicating every word in the title mechanically.
• Write descriptions for clarity and click usefulness, knowing Google may choose another snippet.
• Use internal anchor text that describes the destination page naturally.

5) Structured data (only what is true and visible)

Use structured data to clarify what a page is, not to claim things you cannot back up. For most SME sites, a simple set works: WebSite, Organization/ProfessionalService, Person, plus Article for blog posts and Service for service pages.

• Validate JSON-LD is parseable (one broken comma can invalidate the whole block).
• Use BreadcrumbList if you have clear navigational hierarchy.
• Do not mark pages as "available now" or imply scale/adoption you cannot prove.

6) Internal links (build a clean graph)

Google learns what your site is about by following links. A clean internal link graph also helps readers find the right page without guesswork.

• Link from hubs to supporting pages (e.g., Services to each service page, Blog to each article).
• Link supporting pages back to the relevant hub and one or two related pages.
• Avoid creating near-duplicate "city pages" that only exist to rank.

A good pattern is: one service page that describes the service clearly, plus one or two articles that support it with useful checklists.

7) Performance and mobile sanity checks

If a site is slow or hard to use on mobile, it tends to underperform. You do not need perfection, but you do need basic sanity: the page loads, the content is readable, and nothing breaks on a phone.

• Confirm hero images are not enormous (WebP can help on modern browsers).
• Check there is no horizontal scroll on small screens.
• Make sure important navigation and contact paths work on mobile.

For a "launch hygiene" checklist that covers more than SEO, see the website launch checklist.

8) Measurement (keep it honest)

SEO changes take time to process. Use Search Console to track impressions and clicks, and treat a single day's movement as noise. A simple practice that works is: make a small batch of improvements, validate, then measure again after a crawl window.

• Track a few key queries you care about, but avoid obsessing over exact rank.
• Track which pages are actually earning impressions (that tells you what Google understands).
• Write down what you changed and when, so you can connect cause and effect later.

What a useful audit deliverable should include

A technical SEO audit is only useful if it turns into work someone can safely do. The deliverable should separate urgent blockers from quality improvements, and it should include validation and rollback notes so the site can keep improving without chaos.

Turn audit findings into the right next action

Once the audit separates blockers from improvements, route each finding to the page or workflow that best matches the evidence. That keeps the fix practical and avoids treating every issue as a generic SEO problem.

Audit project proof pages as part of the same system

Project sites, source archive deployments, and repository-backed case studies need the same technical audit discipline as a main business website. The details are smaller, but the signals still need to agree: canonical URL, live page, repository, project note, sitemap state, and internal links.