perfectdesign.

Search visibility · Checklist

Technical SEO Audit Checklist

This checklist audits whether Google can discover, fetch, render and index the pages you intend it to, and whether robots rules, noindex directives, canonicals, status codes and redirects agree with each other, including the risk carried by a redesign or a change of domain. Each item names the evidence that proves it, so the output is verified findings rather than a tool score. It does not diagnose page speed, does not implement fixes in your website code, and passing it guarantees nothing about rankings.

For
Business owners and marketing leads in Malaysia checking whether Google can find and index their website correctly, or checking a technical audit someone else delivered.
Reading time
8 min
Last reviewed
On this page

Can intended pages be discovered?

Google finds URLs by following links and reading sitemaps; it states that a sitemap helps discovery but guarantees neither crawling nor indexing. Page indexing rows under "Discovered - currently not indexed" show what Google found but has not yet fetched.

0 of 4 checked · saved on this device

  • robots.txt is at the root of each host and returns 200 or 404, never a 5xx.

    Evidence: "curl -I" on the file for each protocol and host. A 5xx halts crawling for 12 hours; Google then reuses the last good copy for up to 30 days.

  • No robots.txt rule blocks a template you want indexed, or the CSS and JavaScript pages need to render.

    Evidence: The "Crawl allowed?" field in URL Inspection for each sampled URL, and page indexing rows under "Blocked by robots.txt".

  • The XML sitemap is submitted or named in robots.txt, returns 200, and lists only absolute, canonical, indexable URLs.

    Evidence: The Sitemaps report status, plus a crawl of the sitemap URLs exported with status, canonical and robots columns. Google crawls sitemap URLs exactly as written.

  • Every intended page has a plain HTML link (an "a" element with an "href") from an indexed page; no orphans.

    Evidence: A crawl export filtered to zero internal inlinks, checked against the sitemap. Google only discovers "a href" links; the internal linking guide covers repairs.

Are directives and canonicals consistent?

Google calls a canonical preference a hint, not a rule, and weighs HTTPS, redirects, sitemap presence and the "rel=canonical" annotation together, so the audit checks that those signals agree. A noindex only works when the page can be fetched; a page blocked in robots.txt can still be indexed from links elsewhere. The robots, noindex and canonical guide explains each directive.

0 of 5 checked · saved on this device

  • No intended page carries noindex in its meta tag or an "X-Robots-Tag" header, and no page is both blocked in robots.txt and noindexed.

    Evidence: The raw HTML head and "curl -I" headers per sampled URL, the "Indexing allowed?" field in URL Inspection, and page indexing rows under "Excluded by noindex tag".

  • Every indexable page declares one canonical: an absolute URL that returns 200 and is itself indexable.

    Evidence: Crawl export columns for the canonical URL, its status and its robots state; count pages with none, two, or one pointing at a redirect or a noindexed page.

  • Google's selected canonical matches the declared one on every template.

    Evidence: "User-declared canonical" and "Google-selected canonical" in URL Inspection (the live test does not check this), and page indexing rows under "Duplicate, Google chose different canonical than user".

  • Protocol and host variants (http, www, trailing slash, letter case, tracking parameters) reach the canonical URL in one permanent redirect, which internal links and the sitemap also use.

    Evidence: "curl -I" on each variant of three sampled URLs recording every hop, and the crawl count of internal links to non-canonical URLs.

  • Sort, filter and pagination variants follow a written rule, and Bahasa Malaysia and English versions each declare their own URL as canonical.

    Evidence: One rule per variant type with two URLs proving it, and the canonical tag read on both language versions of one page.

What is rendered versus source-visible?

Google crawls, then renders with an evergreen Chromium, then indexes. Rendering is queued after the crawl, can be deferred and, Google says, can fail, so anything that exists only after JavaScript runs is a risk to record. The test compares raw HTML with Google's rendered HTML; how fast it loads is a separate question for the Core Web Vitals guide.

0 of 3 checked · saved on this device

  • Each template's primary content (headings, copy, product or service details, prices) is in the raw HTML, or confirmed in the rendered HTML where JavaScript injects it.

    Evidence: Two columns per sampled URL, "in raw HTML" (from "curl" or view-source) and "in rendered HTML" (from URL Inspection or the Rich Results Test), marked yes or no.

  • Title, meta description, canonical, robots meta and "a href" links are identical in raw and rendered HTML, and single-page routes use real paths rather than "#" fragments.

    Evidence: The same comparison for the head plus a link count per template. Google may skip rendering when raw HTML contains noindex, so a script removing it later does not help.

  • Everything needed to render loads for Googlebot, and a missing product or bad route returns 404 or 410 (or noindex), never a 200 saying "not found".

    Evidence: The live test's page resources and console output (its screenshot exists only for live tests), "curl -I" on a deliberately wrong URL per template, and page indexing rows under "Soft 404".

Do status codes and redirects say what you mean?

Google reads status codes literally: a 200 is considered for indexing, any 4xx except 429 drops the URL from the index, and 5xx or 429 slow crawling and, if persistent, remove it. Permanent redirects (301, 308) pass the canonical signal to the target; temporary ones (302, 303, 307) keep the source in results. Google treats JavaScript redirects as a last resort because rendering may fail, and follows up to ten hops.

0 of 3 checked · saved on this device

  • Every intended page returns 200 on a plain fetch and in URL Inspection; removed pages return 404 or 410.

    Evidence: The crawl export status column for all sitemap URLs, "curl -I" on known removed URLs, and page indexing rows under "Not found (404)" and "Soft 404".

  • No sampled URL, and never robots.txt, returns 5xx or 429 during the audit window.

    Evidence: Timestamped "curl -I" results, page indexing rows under "Server error (5xx)", and Googlebot entries in server logs if available.

  • Permanent moves use a server-side 301 or 308 reaching the target in one hop: no temporary codes, delayed meta refresh, JavaScript redirects, long chains or loops.

    Evidence: A "curl -IL" trace listing the status and "Location" of every hop, and page indexing rows under "Redirect error".

If the site has moved, or is about to

0 of 2 checked · saved on this device

  • A URL map lists every old URL and its one-to-one destination, each row tested; retired URLs return 404 or 410, not a catch-all redirect.

    Evidence: The mapping spreadsheet with status and "Location" filled from a fetch of every old URL after launch. Google warns against pointing many old URLs at one unrelated page such as the home page.

  • Redirects stay for at least a year, old and new sitemaps were both submitted, and the Change of Address tool was used only for a domain change (not http-to-https, www or path moves).

    Evidence: The Sitemaps report showing both files, the Change of Address status, a written retention date, and the page indexing report filtered by the new sitemap over successive weeks, new URLs rising as old ones fall.

Which findings are verified?

Crawl tools produce lists by their own rules; Google's reports say what Google did; a fetch says what the server did. This group checks that every finding was tested, not assumed, and that unknowns are written down rather than skipped.

0 of 2 checked · saved on this device

  • Every finding is labelled measured, partial or hypothesis, carries at least three affected URLs and a site-wide count, and only measured findings become fixes.

    Evidence: The findings table below with every column filled, and the "source" shown against each page indexing reason: the website or Google's systems. The Search Console guide explains each report.

  • Each fix has a named test and a verified-on date recorded in three states: raw response changed, live test passed, indexed version updated.

    Evidence: Three dated entries per fix. Google says it may take months to revisit a page, and "Validate fix" in Search Console typically runs up to about two weeks.

Recording findings

One row per finding, not per URL. The status column stops a tool's warning becoming work before anyone has confirmed it. The rows are hypothetical, for an imagined Malaysian online retailer.

Findings template (six columns)
FindingAffected URLs (sample)StatusTest to confirmFix ownerVerified on
Filter URLs indexed instead of the base category/shoes/?sort=price and 311 moreMeasuredURL Inspection: Google-selected canonical on three filter URLsWeb developerPending
Product price appears only after JavaScript runs/product/lace-runner/ (all product pages)PartialRendered HTML in URL Inspection contains the priceWeb developerPending
Crawl tool flags "thin content" on 40 tag pages/blog/tag/...HypothesisRead the page indexing reason for five of themMarketing leadNot started

How to use the result

Do not total the items into a score; read the marks by group, because one fail in discovery or directives on an important template outweighs many passes elsewhere.

  • Pass: the named evidence was collected and shows the intended state on every sampled URL and in the site-wide count.
  • Partial: it holds for some templates or one side of a comparison; log the gap as a finding.
  • Unknown: the evidence could not be collected; record why and who can grant access, never a pass by default.
  • Not applicable: the item does not apply (no JavaScript rendering, no migration planned); write the reason down.

Fix in chain order for the most important pages first: discovery and fetch, then directives and canonicals, then rendering, then redirect hygiene. The complete SEO audit guide shows where this pass sits beside content, links and local presence.

What to do next

  1. Choose the URL sample across every template and fetch each URL with "curl -I" and with URL Inspection.
  2. Work through discovery and directives first, labelling every finding measured, partial or hypothesis in the table.
  3. Give measured findings to whoever maintains the website, and date each fix only when the raw response, live test and indexed version have all changed.
  4. Before a redesign or change of domain, run the migration items on a staging copy and keep the URL map to check against afterwards.

Where to go next

Rather have this handled?

This is part of how we run technical seo for Malaysian businesses. Ask us about your site — no pitch, a straight answer.

Ask about your site