SEO & LocalPublished February 21, 2026Updated October 27, 20266 min readBy Brand Butter

The Technical SEO Audit Checklist: What Canadian Businesses Should Fix First

A technical audit that hands you three hundred warnings sorted alphabetically is not an audit. It is a crawl export. What you need is the short list of problems that are actually costing you visibility, in the order to fix them.

Fix in order of damage

Crawling tools report everything they find, and they find a lot. A missing alt attribute and a sitewide noindex tag can appear on the same report in the same colour. Treating them as equal is how businesses spend a month fixing trivia while their most important page is invisible.

The checklist below is organized as a triage. Each tier depends on the one before it. There is no point polishing page titles on pages Google cannot index, and no point chasing speed scores on a site whose old URLs all return errors.

If you are not sure whether you need a one-time audit or ongoing work, start with SEO audit vs ongoing SEO. If you are about to rebuild your site, use the website migration SEO checklist instead; migrations have their own failure points.

Tier one: can search engines reach the site?

These problems can remove a site or a section from search entirely. Check them first, every time.

  • robots.txt. Make sure it is not blocking important sections, or the whole site. Blocks left over from a staging environment are a classic launch-day mistake.
  • noindex tags. Check that important pages do not carry a noindex directive, in the page code or in HTTP headers. Some content management systems have a single setting that hides the whole site from search engines; check it is off.
  • Server errors and availability. Pages that intermittently return server errors, or a site that is frequently down, get crawled less and can drop out of results.
  • HTTPS. The site should load securely, with a valid certificate, and every http address should redirect to its https equivalent.
  • XML sitemap. It should exist, list only the canonical, indexable URLs you want found, and be submitted in Google Search Console and Bing Webmaster Tools.
  • Crawler decisions. AI providers publish the names of their crawlers. Decide deliberately which ones your robots.txt allows, rather than inheriting a setting from a plugin, a security service or a hosting default you never reviewed.

A useful detail: robots.txt controls crawling, not indexing. A page blocked in robots.txt can still appear in results if other sites link to it, and Google cannot see a noindex tag on a page it is not allowed to crawl. If you want a page out of the index, allow crawling and use noindex.

Tier two: are the right pages indexed?

Once search engines can reach the site, the question is whether they index the right version of the right pages. Search Console’s page indexing report and URL Inspection tool are the primary sources here.

  • Important pages not indexed. Look at the reasons given. “Crawled, currently not indexed” on key service pages often points to thin or duplicated content rather than a technical fault.
  • One address per page. The www and non-www versions, trailing slash and no slash, and upper and lower case should each resolve to a single version with a redirect. Tracking and filter parameters should not create indexable duplicates.
  • Canonical tags. Each page should point to itself or to the true original. Canonicals pointing to redirected, broken or non-indexable URLs send mixed signals. Remember that a canonical is a hint, not an order.
  • Redirects. Old URLs, especially those with links from other sites, should redirect in a single step to the most relevant current page. Chains and loops waste crawling and dilute signals. Redirecting everything to the home page is not a fix.
  • Soft 404s and thin pages. Empty category pages, placeholder pages and near-duplicate location pages are often the real reason a site’s important pages struggle.
  • Internal competition. Several pages targeting the same search intent can split visibility. How to avoid keyword cannibalization covers diagnosis.

Tier three: can machines read the content?

A page can be indexed and still be poorly understood.

  • Content in the HTML. Google can render JavaScript, but rendering can be delayed, and many other crawlers, including some used by AI assistants, may not run scripts at all. Key text, links and facts should be present in the page source, not loaded only after interaction.
  • Crawlable internal links. Navigation and in-content links should be real links with addresses, not buttons that run scripts. Important pages should be reachable within a few clicks of the home page. See how to audit internal links.
  • Titles and headings. Each page needs a unique, descriptive title and one clear main heading. Duplicate titles across many pages usually signal a template problem.
  • Structured data. Organization and LocalBusiness markup, and other types where they apply, should be valid and should match what is visible on the page. Markup that claims things the page does not show can be ignored or penalized. Structured data helps machines read your facts accurately; it is not a ranking shortcut.
  • Bilingual sites. For English and French versions, each page should list its language equivalents with hreflang, and those references must point both ways. Common faults include missing return links, hreflang pointing to redirected URLs, and French pages that are canonicalized to the English version, which tells Google not to index them separately. Bilingual website planning covers the setup.

Tier four: page experience on a phone

Speed and stability matter mainly because slow, jumpy pages lose visitors, and Google’s page experience signals reflect that. Core Web Vitals measure loading (Largest Contentful Paint), responsiveness (Interaction to Next Paint) and visual stability (Cumulative Layout Shift). Search Console reports them from real visitor data where there is enough of it.

Focus on fixes with real impact: oversized images, heavy third-party scripts (chat widgets, multiple tracking tags, embedded video players), fonts that shift the layout as they load, and pop-ups that cover the content on phones. Do not chase a perfect lab score at the expense of features that serve customers. Evaluating website performance beyond page speed puts speed in its proper place.

Check usability on a real phone too: text readable without zooming, buttons far enough apart to tap, forms that work with a phone keyboard.

Tier five: housekeeping

These are worth doing, but only after the tiers above:

  • Broken internal links and links to pages that redirect.
  • Missing or duplicate meta descriptions on important pages.
  • Descriptive alt text on meaningful images, which also helps accessibility.
  • A helpful 404 page that returns a genuine 404 status.
  • Orphaned media files and old PDFs that outrank the pages that replaced them.

What you can safely ignore: meta keywords, warnings about text-to-code ratios, and most tool-specific health scores. They measure the tool’s opinion, not search engine behaviour.

How to run the audit

You need three sources. Google Search Console, for what Google actually sees and indexes. A crawler that walks the site the way a search engine does. And a page experience tool, such as PageSpeed Insights or Lighthouse, run on your most important templates rather than every page.

Audit by template, not just by page. Most sites are built from a handful of templates (home, service, location, article, contact), and a fault in one template repeats across every page that uses it. Fix the template and you fix hundreds of pages at once.

The output should be a short, ranked list: the problem, the pages affected, why it matters, who fixes it and how you will confirm it is fixed. For a typical established business site, the list that matters is rarely longer than a page. An illustrative case: a regional insurance brokerage’s audit finds three things that matter (French pages canonicalized to English, a sitemap full of redirected URLs, and service content loaded by a script) and a long tail of warnings that do not. Fixing those three, in that order, is the project.

After the fixes

Use the URL Inspection tool to request recrawling of the most important fixed pages, resubmit the sitemap, and watch the page indexing report over the following weeks. Technical fixes can show results relatively quickly, though indexing changes take time to settle. Then schedule a lighter check every quarter and after every significant site change, because technical problems are rarely fixed once; they are reintroduced by plugins, redesigns and well-meaning edits.

A technical audit is the first stage of our SEO and AI visibility work for exactly that reason: everything else depends on it.

Key Takeaways

  • Triage by damage: access, then indexing, then readability, then page experience, then housekeeping.
  • robots.txt controls crawling, not indexing; use noindex on crawlable pages to keep them out of results.
  • One address per page, single-step redirects and correct canonicals stop signals being split.
  • Keep key content and links in the HTML, since not every crawler runs JavaScript.
  • On bilingual sites, check that hreflang references point both ways and French pages are not canonicalized to English.
  • Audit by template, and deliver a short ranked list with owners, not a crawl export.

Frequently Asked Questions

How often should a business run a technical SEO audit?

A full audit once a year is reasonable for a stable site, with a lighter quarterly check and a check after every redesign, migration or major plugin change. Most technical problems are reintroduced by changes rather than appearing on their own.

Can I do a technical SEO audit myself?

You can cover the essentials with Google Search Console, a crawler and PageSpeed Insights, especially the access and indexing checks. Interpreting canonical, redirect, rendering and hreflang problems, and deciding what matters, is where experience helps.

What are the most common technical SEO problems on business websites?

Leftover blocks or noindex tags from staging, duplicate versions of pages, redirect chains and old URLs that were never redirected, thin or near-duplicate pages, content that loads only through scripts, and hreflang errors on bilingual sites.

Does site speed affect Google rankings?

Page experience, including Core Web Vitals, is one of many signals, and it rarely outweighs relevance. The bigger cost of a slow site is visitors leaving before they act. Fix real problems on phones rather than chasing a perfect score.

Let’s talk

Want this applied to your situation?

Describe the situation in a few lines and we’ll reply with a frank read on what to do first. Or skip the form and book thirty minutes. No deck, no pressure.

What happens next. A senior strategist reads every inquiry and replies personally, usually within two business days. The first conversation covers your situation, what you’ve tried, and whether we’re the right fit. If we aren’t, we’ll say so and point you somewhere better.

We reply from hello@brandbutter.ca and never share your details. Privacy