Technical SEO Audit Checklist: What to Check First Before You Blame Content

Quick answer

If you are running a technical SEO audit, do not start with title tags, alt text, or another round of content edits.

Start with one harder question:

Is the site giving Google one clean story about which URL should be crawled, indexed, and trusted?

That means checking this order first:

1. protocol and URL normalization
2. redirect integrity
3. canonical, noindex, robots.txt, and sitemap agreement
4. crawlability and fetchability
5. site structure and page ownership

If those layers are unstable, blaming content is usually just a way to waste two more weeks.

Most technical SEO audits fail before they start

They try to audit everything at once.

That is how teams end up treating these like the same class of problem:

• a redirect chain
• a sitemap full of parameter URLs
• a duplicated title tag
• a missing og:image
• one weak H1
• an inherited noindex

They are not.

Google can tolerate a lot of cosmetic mess. What it handles badly is contradiction.

If your site says:

• this URL is canonical
• no, that URL is canonical
• also, do not crawl it
• also, here is a sitemap with both versions

then you do not have a content problem first. You have a signal problem.

1. Protocol and URL normalization

Before Google judges quality, it has to decide which URL even represents the page.

That means you need one stable identity:

• one protocol
• one host
• one slash convention

Do not begin with a full crawler export. Start with the four homepage variants and one representative deep URL.

curl -I http://example.com
curl -I http://www.example.com
curl -I https://example.com
curl -I https://www.example.com
curl -I https://www.example.com/features
curl -I https://www.example.com/features/

You are looking for one boring outcome: every non-preferred version goes straight to the preferred version with a single 301.

The homepage is clean, but the templates are not.

Typical mess:

• the homepage redirects correctly
• /features and /features/ both return 200
• internal links still point to mixed variants
• the sitemap contains the preferred version, but nav links use the other one

That is enough to create duplicate candidates and muddy canonical selection.

That same failure mode shows up before launches all the time, which is why the narrower pre-launch checklist exists as a separate piece.

If you need a copy-pasteable baseline, this is the kind of app-level redirect rule I would rather ship before launch than debug three weeks later:

// next.config.js
module.exports = {
  async redirects() {
    return [
      {
        source: '/:path*/',
        has: [{ type: 'host', value: 'www.example.com' }],
        destination: 'https://www.example.com/:path*',
        permanent: true,
      },
    ];
  },
};

The exact rule depends on your stack and whether you prefer slash or non-slash URLs. The point is simpler: pick one form, enforce it once, and make sure your internal links and canonical tags vote the same way.

If you are handling normalization at the edge instead of in-app routing, the same rule can live in a Cloudflare Worker:

export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.hostname === 'example.com') {
      url.hostname = 'www.example.com';
      return Response.redirect(url.toString(), 301);
    }

    return fetch(request);
  },
};

2. Redirect integrity

Most redirect audits are too soft. They ask, “Does the old URL go somewhere?” The real question is, “Does it go to the right place, in one step, without creating a new conflict?”

Take a migration where the team moves its docs section from /help/ to /learn/.

At first glance, nothing looked broken:

• old URLs redirected
• new URLs loaded
• sitemap was updated

Then GSC started excluding the new URLs, and the team did what teams always do under pressure: they assumed the new pages were thin and started drafting content changes.

What was actually happening:

1. https://example.com/help/pricing-api returned 301 to https://example.com/learn/pricing-api
2. Cloudflare then normalized that to https://www.example.com/learn/pricing-api/
3. the final page self-canonicalized to https://example.com/learn/pricing-api
4. internal links pointed to the slash version
5. GSC URL Inspection showed the page was crawlable, but Google-selected canonical kept drifting

By the time someone opened DevTools Network, the content team had already prepared a rewrite pass for a page that was never being judged cleanly in the first place.

A weak technical audit does not just miss the bug. It sends the team into the wrong workflow.

• In Screaming Frog List Mode, crawl a sample of old URLs and export redirect chains.
• In browser DevTools Network, load one migrated page and confirm there is no hidden extra hop added by CDN or app-router logic.
• In GSC URL Inspection, paste the final URL and compare User-declared canonical with Google-selected canonical.
• If the redirect target permanently replaces the old URL, do not leave it as 302.

If the chain is longer than one hop, or the final canonical disagrees with the redirect target, this belongs in the top fix bucket. The post-launch version of that same story usually shows up as “traffic dropped after launch,” but the underlying failure is still canonical and redirect agreement, not mysterious content decay.

3. Canonical, noindex, robots.txt, and sitemap conflicts

Do not ask whether each signal exists. Ask whether they agree.

Take one important URL and compare these four things side by side:

1. GSC URL Inspection
2. page source
3. robots.txt
4. sitemap entry

Specifically:

• In GSC, look for Crawl allowed?, Indexing allowed?, User-declared canonical, and Google-selected canonical.
• In page source, confirm the canonical tag and meta robots tag.
• In robots.txt, confirm the path is not blocked.
• In the sitemap, confirm the exact canonical version is listed, not an old variant or filtered URL.

The conflict patterns that matter

• sitemap says index, meta says noindex
• canonical says self, robots.txt blocks crawl
• internal links reinforce /page/, canonical points to /page
• old parameter URLs remain in the sitemap
• template-level headers send X-Robots-Tag: noindex on a page everyone assumes is indexable

If this layer is dirty, do not move on to content. Move on to conflict resolution.

Once you confirm the conflict is page-level rather than template-level, the next branch is usually one of three: the URL is not indexing at all, it is stuck in discovered, or it was crawled and rejected. Those are covered in Why Your Page Isn’t Indexing: 17 Checks, Discovered - Currently Not Indexed: What to Fix, and Crawled - Currently Not Indexed: How to Fix.

4. Crawlability and fetchability

There is a big difference between “the page loads for me” and “Google can reliably fetch the thing we think we shipped.”

Go to Search Console -> URL Inspection -> paste the exact canonical URL.

Then read it in this order:

1. URL is on Google or URL is not on Google
2. Page fetch
3. Crawl allowed?
4. Indexing allowed?
5. User-declared canonical
6. Google-selected canonical

Then run Test live URL.

That split matters. Inspection data is based on Google’s last processed version. Live Test shows whether Google can fetch the page right now.

This is one of the easiest places to fool yourself. Live Test passes once, somebody screenshots the green result, and the team declares the page fixed. Meanwhile the cached inspection view still shows the wrong canonical, or Crawl allowed? flips across templates, or the WAF only challenges some requests during real crawl windows. A single successful Live Test is not proof that the indexing problem is solved.

The failure modes that keep getting misread as “weak content” are boring infrastructure problems:

• WAF or CDN rules challenge Google intermittently
• important content only appears after client-side rendering completes
• response behavior flips between clean 200 and soft-error patterns
• staging auth, geo rules, or header rules still affect one template family

At that point, DevTools and server logs are worth more than another rewrite.

The more detailed field-by-field breakdown lives in the GSC URL Inspection guide, but the important point here is simpler: do not confuse one successful Live Test with a stable indexing signal.

5. Site structure and page ownership

Sometimes the URL is crawlable, indexable, and technically clean. It still underperforms because the site does a poor job telling Google which page owns which topic.

At this point, the question is no longer “is the page accessible?” It is whether the site is helping Google make the right classification call.

What matters here:

• the homepage and main commercial pages state the site’s core topic clearly
• internal links support the page that should own the query family
• important pages are reachable through normal crawl paths, not just the sitemap
• overlapping pages are consolidated or clearly differentiated

If that layer is weak, the page may not be blocked. It may just be semantically blurry.

At that stage, Traffly’s Search Understanding Status, or SUS, is more useful than a generic crawl report. The question changes from “Can Google access this?” to “Does Google have enough aligned evidence to classify this page correctly?”

Once you are here, the problem is no longer pure technical SEO. An indexed page with no traction belongs in the indexed but not ranking branch. A page pulling the wrong query family belongs in the Google isn't understanding the page branch. Those are two different fixes, and merging them is another way teams waste time.

What must be fixed before launch, and what can wait 14 to 28 days

Most audit articles get vague here. They say “watch and monitor” without saying for how long.

Here is the cleaner version.

Must fix before launch

• homepage or core templates resolve on multiple protocol or host variants
• redirect chains or loops affect old ranking URLs
• 302 is used for permanent migrations
• canonical conflicts exist on money pages, category pages, or main docs pages
• sitemap includes URLs with noindex, blocked paths, old variants, or parameter junk
• important templates return unstable status codes or depend on fragile rendering
• core pages are effectively orphaned

Can usually be watched for 14 to 28 days after launch

• temporary canonical wobble on a small set of freshly migrated URLs
• short-term impression instability while Google remaps sections
• slower indexing on low-priority editorial pages
• smaller internal linking gaps on secondary posts that are not business-critical

That 14 to 28 day window is not an excuse to ignore clear breakage. It is for cases where the core signals are clean, but Google is still settling after a launch or migration.

Do not jump here until the technical layer is clean

• intent mismatch
• thin coverage
• weak proof or originality
• poor semantic calibration

The whole point of the audit is to stop you from blaming copy too early.

That is also how the rest of the Traffly content chain fits together:

• this article handles the top-level audit order
• Why Your Page Isn’t Indexing: 17 Checks handles page-level indexing diagnosis
• Page Indexed But Not Ranking? What to Check Next handles the post-indexing layer
• Pre Launch SEO Checklist for New Websites handles go-live prevention
• Traffic Dropped After Launch? What Is Normal and What Is Not handles the post-launch interpretation layer

Do not ask for a 200-point checklist. Get these five conflict layers right first.

FAQ

Can a marketer check canonical conflicts without server access?

Usually yes. GSC URL Inspection, page source, Screaming Frog, and the sitemap will expose most canonical disagreements. You only need deeper access when the conflict is coming from response headers, CDN rules, or inconsistent redirect logic.

How many URLs should I sample before I trust the pattern?

For a quick audit, start with 5 to 10 URLs that represent your homepage, category pages, money pages, migrated URLs, docs, and blog posts. If the same mismatch repeats there, you are probably looking at a template or rules problem.

Can I force a canonical update if Google ignores my tag?

Not directly. You can only make the rest of the signal stack harder to misread: align redirects, internal links, sitemap URLs, and self-canonicals, then wait for recrawl. If Google still chooses another canonical, it usually means the page cluster is still too noisy or too duplicative.

How long does Google take to process canonical fixes on a large site?

There is no fixed SLA. On a large site it can take days or a few weeks, especially if the old cluster is messy and crawl demand is uneven. That is why you fix the signals first, then monitor the canonical sample set instead of changing the page every day.