A technical SEO checklist should tell you what to test, what a failed test means, and what to do next. Start with the pages that matter most to your business: can Google reach them, render their main content, and select the intended URL for indexing? Then check how people and crawlers discover those pages, whether the mobile version works, and whether performance or markup creates avoidable problems.
This guide follows that order. It separates crawl access from indexability because a page can pass one test and fail the other. Each step includes a practical check and a decision rule. Use Screpy's website audit to spot sitewide patterns, then use Google Search Console's Page indexing and URL Inspection reports to see what Google actually observed. An audit finding is a lead to investigate, not proof that Google will or will not index a page.
Start with a crawl-and-index triage
Choose a small set of important URLs before opening a sitewide issue report: the homepage, a category or service page, a recent article, and any page that recently lost search traffic. Record each URL's intended status. A checkout confirmation page, for example, should not be judged by the same indexability test as a product page.
| What you observe | First check | Next decision |
|---|---|---|
| An important page is absent from Search | Inspect the exact URL in Google Search Console | Is the page undiscovered, blocked, excluded, or indexed under another canonical? |
| A crawler reports an error | Fetch the URL and inspect its final HTTP status | Is this an intentional removal, a temporary failure, or a broken internal link? |
| The wrong URL appears in Search | Compare redirects, canonical hints, sitemap entries, and internal links | Which URL should be the preferred version, and are the signals consistent? |
| The page is indexed but its main text is missing | Compare source HTML with Google's rendered view | Does critical content depend on a blocked or failing script? |
| Many similar URLs appear in the crawl | Group them by template, parameters, and canonical target | Is this a sitewide rule problem rather than many independent page problems? |
Keep discovery, crawling, rendering, indexing, and ranking separate. A successful HTTP response proves that one client fetched a page; it does not prove that Google indexed it. A URL listed in a sitemap is a discovery hint, not an indexing request. The Search Console URL Inspection tool is where you check Google's reported crawl, index, and canonical information for a specific URL. If you need a narrower page-by-page method, use Screpy's URL audit guide.
Check whether important URLs can be reached
Run a crawl of the URL set and inspect the final response, not just the URL you entered. For every important page, confirm that the final destination returns a usable 200 response, the content is accessible without a login or challenge, and the path is allowed for Googlebot in robots.txt. Review redirects for loops and chains. Screpy's SEO Crawler can help surface status codes, redirect paths, and internal routes; a Googlebot-specific access problem still needs verification in Search Console or server-side evidence.
Treat HTTP results according to the page's purpose:
| Result | Appropriate response |
|---|---|
200 on a page intended for Search |
Continue with indexability and rendered-content checks. A 200 alone is not enough. |
301 or 308 after a permanent move |
Link internally to the final destination and check that the destination is relevant and indexable. |
302 or 307 for a temporary move |
Confirm the temporary behavior is deliberate; revisit if it persists. |
404 or 410 for content with no equivalent replacement |
Keep the honest error status and fix internal links that still point there. |
404 for a page that moved to a close equivalent |
Redirect to that equivalent page, then update internal links. |
5xx, timeout, or an unexpected 403 |
Investigate server, security, or access rules before changing SEO metadata. |
Do not redirect every deleted URL to the homepage. Google recommends a 404 or 410 when removed content has no similar replacement; irrelevant redirects can confuse users and may be treated as soft 404s. Google's crawl-error guidance explains the distinction.
Finally, inspect robots.txt for rules that block important pages or their critical assets. The file controls crawling; it is not a reliable way to keep a URL out of search results. Use the robots.txt guide when a rule needs changing, and test the exact path and user agent before deployment.
Check whether the right URLs can be indexed
For each page you want in Search, check the rendered meta robots tag and any X-Robots-Tag HTTP header for noindex. A noindex directive must be visible to the crawler: if robots.txt blocks the URL, Google cannot fetch the page to read it. Conversely, an intentionally private or staging page should have an appropriate access or indexing control and should not appear among your production sitemap URLs. See Google's noindex documentation and Screpy's noindex and nofollow guide for the implementation details.
Next, distinguish your declared canonical from Google's selected canonical in URL Inspection. A canonical annotation is a strong hint, not a command. If a filtered, parameterized, or duplicate URL keeps appearing instead of the page you prefer, compare four signals: the canonical annotation, permanent redirects, sitemap inclusion, and the URLs used in internal links. Pick one intended destination and make these signals coherent. Do not point a canonical at a different page merely because the first page performs poorly; the pages should be duplicate or very similar alternatives. Google's canonicalization guide explains the signals, and the Screpy canonical guide covers common implementation errors.
Check templates, not only isolated pages. If thousands of faceted or tracking-parameter URLs inherit the same mistake, a template or routing fix matters more than editing individual tags. If pages are genuinely distinct and useful, avoid collapsing them into one canonical. Record the intended index state of each URL pattern so the next crawl can distinguish a deliberate exclusion from a regression.
Make important pages discoverable
An indexable page is still hard to find if nothing useful links to it. Start from the homepage and key navigation pages, then follow normal links to each important destination. Check for orphan pages, links hidden behind forms or click handlers, and internal links that point through unnecessary redirects. Google generally discovers crawlable links through HTML <a> elements with an href; its link guidance also recommends concise, descriptive anchor text. Screpy's orphan-page guide shows how to investigate pages missing from the site's link structure.
Use your XML sitemap as a list of canonical URLs you want discovered. Remove obsolete, redirected, non-indexable, or wrong-host entries. Check that meaningful changes are reflected accurately in lastmod where your platform supports it. A sitemap can help Google discover URLs, especially on a large or complex site, but Google does not guarantee crawling or indexing because a URL is listed there. It also does not replace internal navigation. The XML sitemap guide covers the file-level checks.
Before adding links, ask whether the destination helps the reader complete the current task. A technical SEO checklist should point to detailed robots, canonical, and rendering instructions when those checks fail. A paragraph filled with repeated keyword anchors gives the reader less guidance than one relevant next step.
Verify what Google can render on mobile
Fetch a representative page and compare three views: its initial HTML, the page in a normal mobile browser, and the rendered HTML shown by URL Inspection. If the title, main text, product details, canonical annotation, or important links only appear after a script that fails or requires user interaction, investigate the rendering path. Google can render JavaScript, but blocked resources, errors, and timing-dependent behavior can still make essential content hard to process. Google's JavaScript SEO guide describes the crawl-render-index sequence; Screpy's JavaScript crawlability guide provides focused checks.
Compare mobile and desktop versions for meaningful content and navigation, not pixel-perfect appearance. Important text, images, metadata, and internal links should remain available on mobile. Check whether lazy-loaded content appears without requiring a user to scroll or click in a way the crawler cannot reproduce. If your site serves separate mobile URLs, verify redirects and canonical/alternate relationships rather than assuming the desktop page covers both.
The fix depends on the failure. Repair a broken API response or blocked resource when it is the cause. If essential content only exists after client-side rendering, consider serving that content in the initial HTML or a reliably rendered version. Do not recommend server-side rendering as a universal migration: confirm the actual missing content first, then test the revised page in URL Inspection.
Measure page experience and markup without chasing scores
After access and indexing problems are understood, review user experience. Google's current Core Web Vitals cover loading performance (LCP), responsiveness (INP), and visual stability (CLS). Use the Core Web Vitals report for affected URL groups and a page-level diagnostic tool to identify what causes a problem. Prioritize a shared template issue affecting important pages over a minor score change on one low-value URL. Google's Core Web Vitals documentation describes the metrics and their role in page experience; none is a promise of higher rankings by itself. For a step-by-step diagnosis and fix sequence, use our page speed optimization checklist.
Check that the site consistently serves HTTPS with a valid certificate, without mixed critical resources or accidental HTTPS-to-HTTP redirects. This is a baseline reliability and security check, not a reason to predict a particular ranking increase.
If a page is eligible for a Google rich-result feature, validate the relevant structured data against visible page content and the feature's current requirements. Fix invalid or misleading markup, but do not add schema types simply to fill a checklist. A valid test result means the markup meets technical requirements; it does not guarantee that a rich result will appear. The Rich Results Test is a useful validation step.
International pages need an additional conditional check: if you maintain language or regional alternatives, validate the hreflang relationships and canonical choices across that set. A single-language site does not need an invented international SEO task.
Prioritize fixes and verify the result
Turn the checklist into a short issue register. For each finding, record the affected template or URL group, evidence, expected behavior, proposed fix, owner, and a retest method. This prevents a long list of crawler warnings from becoming an unordered backlog.
| Priority | Example | Why it comes first |
|---|---|---|
| Fix now | Important pages return 5xx, are blocked, or carry accidental noindex |
The page may be unavailable to users or excluded from indexing. |
| Fix next | A shared canonical or internal-link rule selects the wrong URL across a template | One change can correct many important URLs. |
| Schedule | A small number of relevant pages have broken links or suboptimal performance | Useful work, but the scope and impact need comparison with other issues. |
| Leave intentional | Deleted content without a replacement returns 404; private pages are excluded |
The observed status matches the desired behavior. |
After a fix, crawl the affected URL set again and compare it with the baseline. Open representative URLs in Search Console's URL Inspection tool and check the live test, rendered content, declared and Google-selected canonicals, and indexing status where available. Allow time for Google to recrawl; a successful live test is not an immediate indexing guarantee. Monitor the Page indexing report and relevant search queries over subsequent weeks. If a change affected only a few URLs, a sitewide average may hide the result, so compare the exact page group.
Use Screpy's website audit for repeatable sitewide checks and Search Console for Google's own observations. The practical goal is not to make every warning disappear. It is to make important pages reliably reachable, understandable, and eligible for the intended search experience.
You can turn crawl findings into an SEO plan with MCP by asking a Screpy-connected assistant to list the affected URLs, explain the recorded issue and suggest a retest. Review the plan against the intended behavior of each page before approving a fix; deliberate exclusions should stay deliberate.
Technical SEO checklist FAQ
Is a page indexed as soon as I add it to an XML sitemap?
No. A sitemap helps search engines discover URLs. It does not guarantee a crawl or an index entry. Check the URL in Search Console and investigate access, indexability, canonical, and content signals if it remains excluded.
Should I redirect every 404 page?
No. Redirect a moved page to a close, useful replacement. If content is gone and no equivalent exists, return 404 or 410 and remove obsolete internal links. A generic homepage redirect is rarely a useful substitute.
Does robots.txt remove a page from Google Search?
Not reliably. A blocked URL may still be known through links, while Google cannot fetch it to see a noindex directive. Use an appropriate indexing or access control for pages you do not want indexed.
How often should I repeat the checklist?
Run it after migrations, template changes, major releases, or an unexpected indexing change. For ongoing maintenance, monitor representative pages and affected URL groups on a schedule that matches how often your site changes. Keep the baseline so you can tell a new regression from an intentional exclusion.