SEO Checklist
Explore
Make technical checks reproducible

Technical SEO Checklist

A technical SEO checklist is a set of tests for how a website is discovered, fetched, rendered and prepared for indexing. Run the applicable checks, record the response you observed, and retest after each fix.

Free to useNo account neededSaved in your browser
Connected page tiles and a magnifying glass leading toward a highlighted preferred page.
An editorial illustration
Your working checklist

Make progress. Keep the evidence.

SEO Checklist · Technical SEO Checklist · Content version 1.1.0 · Sources checked 2026-10-07. Untested is not a pass. Evidence is entered by the person completing this checklist.

16 checks

Test crawling and HTTP responses

Crawl and response checks establish whether intended public pages and resources can be fetched. Test the final response, not just how the page looks in your browser.

Verify the final HTTP response

Find delivery failures on intended live pages.

Steps, evidence & next actionCritical · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Request an important URL and follow any redirect.
  2. Record the final status, content type and expected main content.
PassThe intended live page returns a successful response and its expected content.
FailThe route returns an error, unintended login, empty page or error message with a success response.

If it fails: Repair routing or delivery; use an appropriate error response when content is truly unavailable.

Retest: Repeat the same request after the change.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: A 200 response alone does not prove indexability or indexing.

Requested/final URL, status, timestamp and response excerpt. Keep confidential data out of shared exports.

No result recorded yet.
Reference: HTTP status codes and Google crawling · Google Search technical requirements

Test the relevant robots.txt rules

Keep intended crawl paths available.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Fetch the production robots.txt.
  2. Evaluate rules for the relevant crawler and sample important URLs and resources.
PassRules match the approved crawl policy without accidental important-page or resource blocks.
FailAn applicable rule unintentionally disallows an important URL or needed resource.

If it fails: Change only the unintended rule and verify representative allow/block cases.

Retest: Fetch the new file and repeat the same rule tests.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: A missing robots.txt is not automatically a defect. Robots.txt does not keep private content secure.

Crawler, exact rule, sample path and expected result. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Introduction to robots.txt

Match redirect behavior to the real move

Send users and crawlers to the correct destination.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Test retired, alternate-host and moved URLs in scope.
  2. Record each hop and whether the move is intended to be permanent or temporary.
PassEach tested move uses the intended behavior and reaches a relevant live destination without a loop.
FailA redirect loops, leads to the wrong page or misrepresents a temporary/permanent move.

If it fails: Correct the mapping and avoid unnecessary intermediate hops.

Retest: Test the original URL and update internal references to the preferred destination.

Not applicable: Not applicable when there are no moved or alternate URLs in scope.

Source, status/hops, intended move and final target. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Redirects and Google Search

Test a genuinely missing URL

Avoid presenting an error page as ordinary content.

Steps, evidence & next actionMedium · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Request a URL that should not exist.
  2. Inspect the status and visible error page; compare a deliberately removed page if relevant.
PassA missing page returns an appropriate 404 or 410 and a useful error experience.
FailMissing pages silently return the homepage or a misleading 200 error response.

If it fails: Fix the error route; redirect only when there is a relevant replacement.

Retest: Repeat the missing-page request and check a valid route still works.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Test URL, status and visible behavior. Keep confidential data out of shared exports.

No result recorded yet.
Reference: HTTP status codes and Google crawling

Check indexing and canonical signals

Indexing checks compare your preferred-URL policy with directives and search-engine evidence. Eligibility is different from actually being indexed.

Inspect page and response indexing directives

Find unintended exclusions and conflicting controls.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Inspect the HTML robots meta tags and applicable HTTP X-Robots-Tag headers.
  2. Compare the effective directive with the page’s intended search status.
PassThe directives match the intended indexing policy.
FailAn intended search page has an unintended noindex, or an excluded page lacks its planned control.

If it fails: Correct the responsible template or header rule.

Retest: Reinspect the response and rendered document.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: Google must be able to crawl the page to see noindex; do not block that fetch in robots.txt.

URL, meta/header directive and intended state. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Block indexing with noindex

Compare declared and intended canonical URLs

Resolve conflicting preferred-URL signals.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Inspect HTML or HTTP canonical declarations for sample pages and duplicates.
  2. Compare their target with the preferred URL, internal links and sitemap.
PassDeclarations match the approved preferred-URL design without contradictory targets.
FailA declaration points to the wrong page or conflicts with the intended mapping.

If it fails: Correct the canonical configuration and align related references.

Retest: Reinspect live output and, when available, later Google-selected canonical data.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: Canonical declarations are preferences. Google can select a different URL; no declaration is not automatically a failure.

Sample URL, declared target, expected target and conflicting signal. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Consolidate duplicate URLs

Validate the sitemap against live preferred URLs

Keep your discovery inventory accurate.

Steps, evidence & next actionMedium · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Open each sitemap used by the site.
  2. Check URL format and sample listed pages; compare exclusions, redirects and meaningful modification dates.
PassThe sitemap contains intended canonical search URLs and accurate update values where supplied.
FailIt lists unintended exclusions, broken/obsolete URLs or fabricated lastmod dates.

If it fails: Fix the sitemap generation source rather than repeatedly editing output by hand.

Retest: Reopen the sitemap and inspect a sample after regeneration.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: Submission to a search engine is a hint, not a promise of indexing.

Sitemap URL, sample discrepancies and source-generation rule. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Build and submit a sitemap · Bing sitemap discovery and monitoring

Compare indexed evidence with a live test

Avoid confusing older search data with the current response.

Steps, evidence & next actionHigh · SEO lead

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Inspect a priority URL in the verified Search Console property.
  2. Record its indexed status and crawl date; use a live test to investigate present behavior.
PassThe record distinguishes live behavior, indexed data and unresolved differences.
FailAn old indexed result is described as a live test, or a live pass is treated as confirmed indexing.

If it fails: Investigate the specific discrepancy before requesting another crawl.

Retest: Repeat the relevant test after the fix and review new indexed evidence when available.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: The live test cannot predict which canonical Google will select.

URL, indexed status, crawl date, selected canonical and live-test result. Keep confidential data out of shared exports.

No result recorded yet.
Reference: URL Inspection tool

Verify rendered content and navigation

Rendering checks establish what content and links are actually available. A page that appears after your personal login or a special interaction may not represent the public response.

Compare source and rendered main content

Catch content that disappears during rendering.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Inspect the HTML response and rendered DOM for the main answer and important links.
  2. For JavaScript-driven pages, inspect the rendered output in an appropriate search testing tool where available.
PassExpected main content and important links are present in the tested rendered output.
FailThe rendered page is empty, incomplete or depends on unavailable resources.

If it fails: Fix the rendering dependency; consider server-rendered or pre-rendered content where appropriate.

Retest: Repeat the same rendering test after deployment.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: Your browser’s successful render alone does not prove every crawler receives the same result.

URL, missing content, failed resource and rendering evidence. Keep confidential data out of shared exports.

No result recorded yet.
Reference: JavaScript SEO basics

Inspect crawlable internal links

Make navigation destinations discoverable.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Inspect representative navigation and contextual links.
  2. Check for real anchor elements with valid href destinations and useful link text.
PassImportant destinations use crawlable links that resolve as expected.
FailNavigation relies only on non-link click handlers or malformed destinations.

If it fails: Use proper anchors for navigation and repair broken targets.

Retest: Inspect the updated DOM and follow the link with the keyboard.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Source page, link markup and target. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Crawlable links and descriptive anchor text

Check mobile content parity

Avoid losing primary information on the mobile version.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Compare primary content, headings and metadata on mobile and desktop.
  2. Check that important mobile content is not gated behind a user interaction needed to load it.
PassMobile users and the tested mobile crawler can access equivalent primary content.
FailThe mobile version omits important content or applies unintended different indexing controls.

If it fails: Fix responsive templates or mobile-serving configuration.

Retest: Repeat the comparison after deployment.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Page/template, mobile versus desktop difference and test method. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Mobile-first indexing best practices

Check the preferred HTTPS route

Catch broken or conflicting secure delivery.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Open the preferred HTTPS host and representative pages.
  2. Check certificate validity, insecure dependencies and HTTP/host-variant redirects.
PassThe preferred HTTPS route works without certificate or mixed-content problems.
FailA certificate failure, insecure dependency or HTTPS-to-HTTP redirect undermines the intended route.

If it fails: Have the infrastructure owner correct the certificate, dependency or route.

Retest: Repeat checks on the preferred host and its intended variants.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: Do not bypass a browser security warning to finish the test.

Host, affected resource or redirect and browser evidence. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Consolidate duplicate URLs

Measure experience and validate markup

Performance and markup checks need the right evidence. Separate real-user measurements, diagnostic tests and eligibility for a search feature.

Record real-user Core Web Vitals where available

Use field evidence for the experience visitors actually have.

Steps, evidence & next actionMedium · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Review available field data for the relevant page or origin and device group.
  2. Record LCP, INP and CLS with the measurement period and scope.
PassAll three meet the good thresholds at the 75th percentile: LCP ≤2.5 s, INP ≤200 ms and CLS ≤0.1.
FailAn available metric misses its threshold; missing field data remains untested or blocked, not a pass.

If it fails: Investigate the affected metric with a reproducible diagnostic test.

Retest: Compare new field data when enough post-change observations are available.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: A good result does not guarantee rankings. A lab score cannot substitute for this field-data check.

URL/origin scope, device, period and all three values. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Web Vitals

Reproduce a performance bottleneck

Turn a field symptom into a fixable development task.

Steps, evidence & next actionMedium · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Run a repeatable laboratory test with documented device and network settings.
  2. Identify a resource, long task or layout movement that explains the observed symptom.
PassThe suspected bottleneck can be reproduced and has a scoped fix.
FailA single overall score is reported without an actionable cause or test conditions.

If it fails: Change the identified cause and avoid unrelated optimizations in the same test.

Retest: Repeat comparable runs and verify the visitor interaction.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: Laboratory results diagnose controlled conditions; they do not prove real-user outcomes.

Tool, settings, URL, trace or affected resource. Keep confidential data out of shared exports.

No result recorded yet.
Reference: Web Vitals

Validate applicable structured data

Keep markup truthful and appropriate to the page.

Steps, evidence & next actionMedium · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Compare the markup with visible content and the current feature documentation.
  2. Use a vocabulary validator and, for Google-supported features, the Rich Results Test.
PassThe markup matches visible facts and satisfies requirements for the chosen applicable type.
FailIt invents reviews, entities or attributes, or has errors affecting the intended feature.

If it fails: Remove misleading properties and correct applicable requirements.

Retest: Validate the deployed output and check the visible page again.

Not applicable: Not applicable when the page has no relevant structured-data implementation.

Keep in mind: Valid schema does not guarantee a rich result. Not every Schema.org type has a Google search feature.

Type, page, validator findings and visible supporting content. Keep confidential data out of shared exports.

No result recorded yet.
Reference: General structured data guidelines · Supported search feature gallery

Retest the production output after a fix

Verify the delivered page rather than the editor setting.

Steps, evidence & next actionHigh · Developer

Applies to: Public website pages within your authorized scope.
Before you begin: An authorized URL or page sample and a place to keep evidence.

  1. Reopen the affected production URLs after deployment.
  2. Repeat the original response, rendering and directive checks and compare with a control page.
PassThe original defect is resolved without a new conflicting output.
FailOnly the CMS or code change was inspected, or cached production output still has the defect.

If it fails: Correct deployment or cache issues and reopen the failed test.

Retest: Check later crawler/index evidence separately when the issue depends on recrawling.

Not applicable: Use Not applicable only when this task does not apply, and record why.

Keep in mind: A technical fix and a search-engine processing update are separate events.

Release, URL, before/after evidence and retest date. Keep confidential data out of shared exports.

No result recorded yet.
Reference: JavaScript SEO basics · URL Inspection tool

Reset this checklist?

This removes saved statuses, evidence and result dates for the checks on this page. Other checklists keep their records. Export a CSV first if you need a copy.

A useful result, every time

Check. Record. Fix. Retest.

This is a manual SEO workflow. It helps you decide what to investigate and keep a usable record. It does not crawl your website or verify your answers automatically.

  1. Choose your scope. Pick the relevant task group and representative pages you are authorized to inspect.
  2. Run the stated check. Read the pass and fail conditions, then record evidence or a reason before choosing a result.
  3. Assign the next action. Add an owner, issue and follow-up date to your notes. Retest after a fix.

What your progress means

Review progress counts passes and failures against applicable checks. Failed work still counts as reviewed. Blocked and untested checks remain unfinished. This is not an SEO score.

Untested
No adequate test has been recorded.
Pass
The stated acceptance condition was observed.
Fail
The acceptance condition was not met.
Blocked
You need access, information or a dependency.
Not applicable
The check does not apply; record your reason.

Export CSV downloads the checks currently shown and your recorded evidence. Print expands the instructions for that view. Saved results stay in this browser; there is no account sync.

A visual working guide

Test each technical condition independently

Four distinct technical checks: URL discovery, fetching, rendering, and indexing signals. Passing a check does not guarantee indexing.
The diagram organizes separate checks; it is not proof that a search engine follows one fixed path or will index a page. Original instructional illustration.
Apply the workflow

How should you adapt these technical checks to your site?

Use the same tests for diagnosis and implementation, but adjust the sample and advanced scope to the site you actually have.

How do you use this as a technical SEO audit checklist?

Begin with a representative URL sample and the site’s intended indexing policy. For each failed test, record an affected URL, expected behavior, actual output, severity, owner and acceptance test. Do not turn an intentional exclusion into a defect simply because a crawler reports it.

What should a developer receive before making a fix?

A developer needs a reproducible URL, response or rendering evidence, the approved intended behavior, and a test that proves the correction. Include the template or route involved when known; label suspected causes until reproduced.

Which technical checks matter for a small website?

Run the access, indexing, canonical, linking, mobile and basic delivery checks on the actual pages you have. Advanced faceted-navigation, international and large-scale crawl work belongs in scope only when those features exist. Small sites can still have shared-template defects.

What does a canonical mismatch look like?

Illustrative example: a service page declares the homepage as canonical even though it contains a distinct service offering. Record both URLs, compare the intended page ownership, and correct the template if the declaration is unintended. Retest the live output; later Google selection remains a separate observation.

Consolidate duplicate URLs

Go deeper where it matters.

Choose the workflow that matches the job in front of you.

SEO Checklist

Choose a first-pass workflow, record results and see what needs attention next.

Open checklist

SEO Audit Checklist

Diagnose an existing site. Separate observations from possible causes and prioritize the evidence.

Open checklist

On-Page SEO Checklist

Review one page’s intent, title, structure, links and useful content before changing it.

Open checklist

Built around verifiable checks.

Primary-source guidance is linked beside the tasks it supports. Sources checked . Content version 1.1.0. A passed check does not guarantee crawling, indexing, traffic or rankings. Read our methodology.