SEO Checklist for Web Developers: Every Check, in the Order That Matters

This SEO checklist for web developers is 24 checks in seven stages, in the order they block each other: a page that cannot be crawled cannot be indexed, a page that is not indexed cannot rank, and a page that ranks for nothing needs aim before it needs a better title. Every check ends with how to verify it, using a command you can run against your own site or a report in Google Search Console, so you are never ticking a box on trust.

Work top to bottom. If a check in stage 1 fails, fix it before anything below it, because nothing further down can make up for it.

TL;DR:

• Stages 1 to 3 (crawl, render, index) are bugs you fix in code. They decide whether Google can see the page at all.
• Stages 4 and 5 (aim and the click) are copy in your templates. They decide which search the page can win.
• Stage 6 (links) is the one ranking signal entirely inside your repo.
• Stage 7 (measure) is what makes the rest worth doing: judge each change from the day Google recrawls the page, one change per page at a time.

Why each check matters is covered in depth in SEO for developers. This page is the list.

Stage 1: Can Google crawl it?

1. Every page that should exist returns 200. Verify: curl -s -o /dev/null -w "%{http_code}\n" https://example.com/pricing. Run it over every URL in your sitemap, not one.
2. A missing page returns 404, not 200 with a "not found" message. That second shape is a soft 404, and Search Console reports it under that name. Verify: curl -s -o /dev/null -w "%{http_code}\n" https://example.com/this-does-not-exist prints 404.
3. Deploys never serve 5xx for long. Google: "5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling." Verify: your uptime monitor's history around deploy times, and the server errors listed in Search Console's Pages report.
4. robots.txt blocks only what you mean to block. It controls crawling, not indexing: "A robots.txt is not a mechanism for keeping a web page out of Google." Verify: curl https://example.com/robots.txt and read every Disallow line against your route list.
5. No page you want ranked carries noindex. Staging configs leak into production more often than anyone admits. Verify: curl -s https://example.com/pricing | grep -i noindex prints nothing, and check the X-Robots-Tag header with curl -sI.

Stage 2: Can Google render it?

6. The main content is in the initial HTML. Google can render JavaScript, but content that only appears after scripts run arrives later and depends on rendering succeeding. Google's own advice: "server-side or pre-rendering is still a great idea because it makes your website faster for users." Verify: curl -s https://example.com/pricing | grep "a sentence from the page". If it is missing, so is your content until rendering runs.
7. Links are real <a href> elements. "Google can only discover your links if they are <a> HTML elements with an href attribute." A <div> with a click handler is not a link to a crawler. Verify: grep your components for onClick handlers that navigate, and use URL Inspection's rendered HTML for a page that relies on them.
8. Every screen of a single-page app has its own URL. Google's developer guide asks you to give each screen or piece of content its own URL. Verify: reload each view from its address bar and confirm you land on the same content.
9. Text is text. Copy inside images, canvas or the CSS content property is not read as page text. Verify: URL Inspection, "View crawled page", and search the HTML for the words you expect to rank on.

Stage 3: Will Google index the right URL?

10. Every page declares its canonical, and it points at itself. When one page answers at several URLs (trailing slash, query strings, http and https), Google picks one, and your rel="canonical" is "a hint, not a rule". Verify: curl -s https://example.com/pricing | grep -i canonical.
11. Redirects, the sitemap and canonicals agree. A sitemap that lists a URL whose canonical points elsewhere sends Google two answers. Verify: each sitemap URL returns 200 (check 1) and its canonical equals itself (check 10).
12. Removed pages get a server-side permanent redirect to their replacement. "For the quickest effect, use HTTP (also known as server-side) redirects." Verify: curl -sI https://example.com/old-page shows 301 or 308 and a Location header.
13. The sitemap is generated from the routes you serve. A sitemap "doesn't guarantee that all the items in your sitemap will be crawled and indexed", but a stale one wastes the help it does give. Verify: Search Console, Sitemaps report, shows it read successfully with no errors.
14. Pages that should be indexed are. Verify: Search Console's Pages report for the site, and URL Inspection for one page. If a page was crawled and not indexed, read the reason before changing code: it needs a different fix from a page Google could not fetch.

Stage 4: Is each page aimed at one search?

15. Each page has one search it is meant to win. Two pages aimed at the same search compete with each other. Verify: list every page with its search. Any search that appears twice is a merge or a re-aim, and keyword cannibalization in Search Console shows how to confirm it.
16. That search's words are in the <title>, the <h1> and the first paragraph. Google cannot match a page to a phrase the page never uses, and developer sites tend to name pages after features nobody searches for. Verify: curl -s https://example.com/page | grep -io "<title>.*</title>", then read the heading and opening.
17. The words come from searchers, not from your product's vocabulary. Verify: Search Console's queries report, filtered to the page, shows the phrases it already appears for. Which keywords you rank for covers reading it.

Stage 5: Will a searcher click it?

18. Every page has a descriptive title and meta description. Google's developer guide: "Make sure that every page has a descriptive title and meta description." Verify: crawl your sitemap and flag empty, duplicate or default titles.
19. Pages on page 1 with a low click rate get a title rewrite, not more content. Verify: Search Console, Performance, sorted by impressions, comparing click rate with position. Before rewriting, check the results page: an AI answer above the results can take the click, and no title wins that back. Low click rate at a good position covers telling the two apart.
20. Structured data matches what the page shows. It is how a page qualifies for rich results. Verify: Google's Rich Results Test on each page type, not one page.

Stage 6: Do your own pages link to the ones that earn?

21. Every page is reachable from a link on another page. "Ensure that all pages on the site can be reached by a link from another findable page." Verify: crawl the site from the homepage and diff the URLs found against the sitemap. Anything in the sitemap and not in the crawl is an orphan.
22. Money pages get contextual links with descriptive anchor text. Google uses links "as a signal when determining the relevancy of pages", and "the better your anchor text, the easier it is for people to navigate your site and for Google to understand what the page you're linking to is about." Header and footer links to everything say little about any one page. Verify: for each pricing, product or comparison page, count the in-content links pointing at it from related guides.
23. No internal link points at a redirect or a 404. Verify: run a link checker over the built site and require zero broken links in CI.

Stage 7: Did the change work?

24. Every change is dated and judged from Google's recrawl, one change per page at a time. This is the check most checklists stop before. Rankings drift on their own: across about 46,000 page-days on six sites, searches nobody touched moved a median of 1.9 places over a month (the measurement). A two-place climb after an edit can be the edit or the drift. Verify: keep a log of page, search, change and date; read the search's position in Search Console from the recrawl date (URL Inspection shows the last crawl); and do not edit that page again until the reading is in, because a second edit overwrites the baseline the first is judged against. A title change needs a few weeks after the recrawl to read, a content change longer.

Where page speed and backlinks fit

Both are separate work with their own tools. Page speed is measured with PageSpeed Insights and Lighthouse, and links from other sites live outside your code, so neither can be verified from your repo's HTML or Search Console's query data the way the 24 checks above can.

Running stages 4 to 7 from your editor

Stages 1 to 3 are a one-time sweep plus a CI check. Stages 4 to 7 never end: which search each page is aimed at, what changed on what date, and when each change is ready to judge. That bookkeeping is what slips first.

QueryScope keeps it for you inside the IDE you already code in. Your agent reads the repo and proposes the searches your buyers make, QueryScope sizes each one against your own Search Console and holds the plan, then hands back one change at a time. Anything that changes what a visitor reads waits for your commit, each change is measured from Google's recrawl, and a page is not handed back while that measurement runs. It stops at the click: it shows whether a page moved, not whether the visitors bought.

Sources

• Google Search Central, Get started with Search: a developer's guide ("Ensure that all pages on the site can be reached by a link from another findable page"; "Make sure that every page has a descriptive title and meta description"; "A robots.txt is not a mechanism for keeping a web page out of Google").
• Google Search Central, How HTTP status codes, and network and DNS errors affect Google Search ("5xx and 429 server errors prompt Google's crawlers to temporarily slow down with crawling").
• Google Search Central, What is URL canonicalization ("indicating a canonical preference is a hint, not a rule").
• Google Search Central, How to specify a canonical URL with rel="canonical" and other methods ("For the quickest effect, use HTTP (also known as server-side) redirects").
• Google Search Central, Understand the JavaScript SEO basics ("server-side or pre-rendering is still a great idea because it makes your website faster for users"; "Google can only discover your links if they are <a> HTML elements with an href attribute").
• Google Search Central, Learn about sitemaps ("it doesn't guarantee that all the items in your sitemap will be crawled and indexed").
• Google Search Central, SEO link best practices ("Google uses links as a signal when determining the relevancy of pages and to find new pages to crawl"; "The better your anchor text, the easier it is for people to navigate your site and for Google to understand what the page you're linking to is about").
• QueryScope, Why Google rankings fluctuate (about 46,000 page-days across six sites; untouched searches moved a median of 1.9 places over a month).