Technical SEO Checklist for a New Site (Indexing First)

A technical SEO checklist is only useful if it is ordered by what actually stops a page from ranking. For a new site, that order is almost always the same: a page that cannot be crawled or indexed will never rank, no matter how fast it loads or how clean its heading structure is. So this checklist starts at indexing and works outward, not the other way around.

The short version: a technical SEO checklist for a new site has eight checks, and the first three — crawlability, indexability, and a correct sitemap — decide whether the rest even matter. Run them before you publish a topic cluster, not after.

Think of it as the technical-base check that has to pass before the B2B keyword research workflow pays off. It pairs with SEO for a new website, which covers the publishing order once the base is solid.

The quick answer: the 8 checks in order

#	Check	What “pass” looks like	Why it ranks this high
1	Crawl access	No noindex, no robots.txt block on real pages, no auth wall	A blocked page has zero ranking potential
2	Rendering	Your text is in the served HTML, not only injected by JS	JS-only content can index late or not at all
3	Sitemap	sitemap.xml lists canonical 200 URLs you actually want indexed	Tells Google what to prioritize
4	Canonicals	Each page points to itself unless intentionally consolidated	Prevents split or duplicate indexing
5	Status codes	No redirect chains, soft 404s, accidental 500s, HTTP/HTTPS duplicates	Wastes crawl budget and confuses indexing
6	Mobile	Same content and nav on a real mobile viewport	Google indexes the mobile version
7	Core Web Vitals	LCP, INP, CLS in the “needs improvement” range or better	A weak signal, but a bad template hurts
8	Monitoring	Search Console + uptime + basic analytics live	Your early-warning system

Checks 1–5 are pass/fail and come first. Checks 6–8 are improve-over-time.

Why indexing comes before everything else

It is tempting to start with speed scores and schema because tools give you a number to chase. But on a new site, the failure that quietly kills traffic is indexing, not performance. Two common versions:

• The JS-render trap. If the page text only appears after JavaScript runs, Google may index a near-empty shell or index it weeks late. A static or server-rendered build avoids this; a client-only single-page app is where I most often see new sites stall. Check by viewing the served HTML (curl or “View Source”), not the rendered DOM.
• The accidental noindex. Staging templates, draft flags, or a CMS toggle left on will keep a perfectly good page out of the index. Confirm none of your real pages carry it.

If checks 1–3 fail, fixing Core Web Vitals is rearranging furniture in a house with no door.

How to run each check (practically)

1. Crawl access — Fetch the page as a bot would and confirm a 200. Open robots.txt and confirm no important path is disallowed. Search the HTML for noindex.
2. Rendering — Compare “View Source” against what you see on screen. If the body text is missing from source, that is a rendering risk to fix before scaling content.
3. Sitemap — Open sitemap.xml (or sitemap-index.xml) and spot-check that the URLs return 200 and are the canonical versions. Remove anything that 404s, redirects, or you do not want indexed.
4. Canonicals — Each important page should have a self-referencing canonical. Watch for pages canonicalizing to the homepage by mistake.
5. Status codes — Crawl the site and look for redirect chains, soft 404s (a “not found” page returning 200), and duplicate HTTP and non-www variants that should 301 to one canonical host.
6. Mobile — Load the site on a real phone width. Confirm the same content, the same internal links, and no hidden navigation.
7. Core Web Vitals — Check LCP, INP, and CLS. A new site does not need perfection; it needs to avoid a slow, layout-shifting template.
8. Monitoring — Verify Search Console, submit the sitemap, and add lightweight analytics so you see impressions and errors early. The stage-by-stage way to read those reports is in Google Search Console for SEO.

The copy-and-keep checklist

Keep it simple enough that you will actually maintain it. One row per page, or one pass per site before a publishing wave:

• Page returns 200 to a bot, no noindex, not blocked in robots.txt
• Body text present in served HTML (not JS-only)
• In sitemap.xml, canonical URL, returns 200
• Self-referencing canonical
• No redirect chain / soft 404 / HTTP duplicate
• Same content and links on mobile
• LCP / INP / CLS not in “poor”
• Search Console receiving the page

Common mistakes (and what they cost)

• Writing 20 posts before checking indexability. You find out the whole template was noindex after a month of work. Check the base on page one.
• A sitemap full of redirects and 404s. It tells Google your URLs are unreliable and wastes crawl budget on a site that has little to spare.
• Assuming JavaScript content is always rendered. It often is — until it is not. Verify against served HTML rather than trusting the rendered view.
• Treating Core Web Vitals as the headline metric. On a new site, CWV is a tie-breaker. Indexing and intent matching decide far more.

How this connects to the rest of the workflow

Once the base passes, the work moves to content decisions: which pages to build, in what order, and how to link them. Internal links are part technical, part editorial — every important page should be reachable from another, which is also how you avoid orphan content (see internal linking strategy). To see the whole method run on a real cluster, read the B2B topic cluster example. If you would rather not formalize all of this yet, start with a lightweight SEO process.

FAQ

What is technical SEO?

Technical SEO is the work that lets search engines crawl, render, index, and understand a site without avoidable blockers. It does not write your content; it makes sure your content can be found.

Do small or new sites really need technical SEO?

Yes, but fewer checks. A small site can skip advanced log analysis, but crawlability, indexing, canonicals, mobile parity, and clean status codes still decide whether pages rank.

What is the single most important technical SEO check?

Indexability. A page that cannot be indexed cannot rank, so confirm crawl access and a missing noindex before anything else.

How often should I run this checklist?

Once before each publishing wave, and again whenever you change templates, hosting, or your CMS. Template-level mistakes affect every page at once.

Conclusion

A technical SEO checklist works when it is ordered by impact: indexing first, clean status and canonicals next, then mobile, speed, and monitoring. Run checks 1–5 before you publish, keep 6–8 improving, and you remove the invisible blockers that stop new-site content from ranking.

Next, decide what to publish first with SEO for a new website, or map your keywords to pages with keyword mapping.

Written by Taylor Yang. More on the method and the author on the about page.

Free template: the technical-base checklist above as a reusable file, plus the keyword map and content brief templates.

Get the next lessons by email — new B2B SEO breakdowns and the monthly “watch this blog rank” report: subscribe.