Technical SEO Checklist for a Brand-New Website
· Written by Rankody · Reviewed by Çağtay Özbek, founder · 8 min read
In this article
- 1. Why a new site needs a different checklist than an established one
- 2. Step 1: Make sure Google can access the site at all
- 3. Step 2: Give Google a map — sitemaps and internal links
- 4. Step 3: Fix duplicate content before it exists
- 5. Step 4: Hit Core Web Vitals thresholds
- 6. Step 5: Titles, meta descriptions, and structured data
- 7. Step 6: Don't let content quality undo the technical work
- 8. The full checklist, in order
- 9. FAQ
A technical SEO checklist for a new website needs about 12-15 checks done before and right after launch: HTTPS, an XML sitemap, a working robots.txt, verified indexing in Search Console, Core Web Vitals within Google's "good" thresholds (LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1), unique titles and meta descriptions, canonical tags, and at least basic structured data, according to Google's own SEO Starter Guide and Core Web Vitals documentation. Skip any of these and you're not "doing SEO wrong" — you're making Google's crawlers guess, and they guess conservatively.

Why a new site needs a different checklist than an established one
An established domain has crawl history, backlinks, and accumulated trust. Google already knows where to find its pages and roughly how often they change. A brand-new site has none of that. Every technical decision you make in the first few weeks — how your sitemap is structured, whether your robots.txt accidentally blocks CSS, whether your canonical tags point where you think they do — either helps Google build an accurate model of your site fast, or forces it to re-crawl and re-evaluate later, which costs you months.
This is also why a long-tail keyword strategy matters more for new sites than broad head terms: technical SEO gets you found, but on a domain with no authority yet, you also need to target queries you can realistically win.
The checklist below is ordered the way a crawler actually encounters your site: access first, structure second, speed and quality third, then the on-page and structured-data layer that turns "indexed" into "ranking."
Step 1: Make sure Google can access the site at all
Before anything else, confirm the basics that block crawling entirely if they're wrong.
- HTTPS is live and consistent. Every URL should resolve to
https://, with HTTP versions 301-redirecting, not 302. Mixed HTTP/HTTPS versions of the same page create duplicate content that Google has to resolve on its own. - robots.txt exists and isn't blocking too much. Google's own guidance is blunt about the most common failure mode here: robots.txt "tells search engine crawlers which URLs the crawler can access on your site," and a frequent new-site mistake is blocking essential resources like CSS and JavaScript files, which can stop Google from rendering the page correctly even if the HTML itself is crawlable.
- robots.txt is not a privacy tool. Google explicitly warns that blocked pages can still get indexed if other sites link to them — the URL just shows up without a description. If a page genuinely needs to stay out of search, use a
noindexmeta tag, not a robots.txt disallow. - The site isn't accidentally set to noindex. This sounds obvious, but staging-to-production migrations regularly ship with a sitewide
noindextag left in place. Checkview-sourceon a handful of live pages, not just the homepage.
Step 2: Give Google a map — sitemaps and internal links
A new site usually has few or no external backlinks, which is exactly the situation a sitemap is built for. Google's sitemap documentation notes that submitting one is "particularly valuable... especially when your site lacks internal links or is newly launched." Google is also explicit that a sitemap is "merely a hint" — it doesn't guarantee crawling — but it dramatically improves the odds on a site with no other discovery signals.
Sitemap requirements that trip people up on new builds:
| Requirement | Google's rule | Common mistake |
|---|---|---|
| File size / URL count | 50MB uncompressed or 50,000 URLs per sitemap file | Auto-generated sitemaps exceeding the limit with no sitemap index |
| URL format | Fully-qualified, absolute URLs (https://example.com/page) | Relative paths or mixed trailing slashes |
| Content | Only canonical URLs you want indexed | Including redirected, noindexed, or duplicate URLs |
| Encoding | UTF-8 | Left at a CMS default that isn't UTF-8 |
| Submission | Search Console, or referenced in robots.txt | Generated but never actually submitted anywhere |
Once the sitemap is right, internal linking does the rest of the discovery work — every new page should be reachable in a click or two from a page Google already crawls regularly, not just listed in the sitemap and orphaned otherwise.
Step 3: Fix duplicate content before it exists
Duplicate content is rarely intentional on a new site — it's a side effect of URL parameters, www vs non-www, trailing slashes, or a staging subdomain that never got de-indexed. Google's canonicalization documentation describes the core problem plainly: "having the same content accessible through many different URLs can be a bad user experience" and makes it harder to track how a page actually performs in search, because clicks and impressions get split across duplicate URLs instead of consolidating on one.
The fix is a rel="canonical" tag on every page, pointing at the single preferred version — but Google is upfront that this is "a hint, not a rule": it may choose a different canonical if your signals conflict (for example, if your sitemap lists one URL but your internal links point to another). Consistency across sitemap, internal links, and canonical tags is what makes the hint reliable.
Step 4: Hit Core Web Vitals thresholds
Page experience is a ranking input, and it's one of the few technical SEO factors with hard published numbers. Per Google's Web Vitals documentation, the "good" thresholds are measured at the 75th percentile of real page loads, segmented by device:
| Metric | Measures | "Good" threshold | "Poor" threshold |
|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading speed | Under 2.5 seconds | Over 4.0 seconds |
| INP (Interaction to Next Paint) | Responsiveness | Under 200 milliseconds | Over 500 milliseconds |
| CLS (Cumulative Layout Shift) | Visual stability | Under 0.1 | Over 0.25 |
A page has to hit "good" on all three at the 75th percentile to pass. For a new site, the most common early culprits are unoptimized hero images (hurts LCP), render-blocking JavaScript on interactive elements (hurts INP), and ads or embeds that load without a reserved size (hurts CLS). Check real numbers in Search Console's Core Web Vitals report once you have traffic — lab tools like Lighthouse are useful pre-launch but don't reflect real user conditions.
Step 5: Titles, meta descriptions, and structured data
Once crawling and speed are handled, the remaining technical layer is what actually shows up in search results and helps Google (and AI answer engines) understand the page.
Titles and meta descriptions. Google's SEO Starter Guide recommends titles that are "unique to the page, clear and concise, and accurately describes the contents," and meta descriptions as short, page-specific summaries — typically one or two sentences highlighting the key point of the page. Every page needs both, written by hand; templated or duplicated titles across a category of pages is one of the most common new-site issues Search Console flags.
Structured data. It isn't required for indexing, but Google's own structured data documentation cites measurable results from sites that added it: Rotten Tomatoes saw a 25% higher click-through rate on pages with structured data, Food Network reported a 35% increase in visits after adding it across 80% of its pages, and Nestlé's rich-result pages had an 82% higher click-through rate than non-rich pages. For a new site, starting with Organization, Article, and BreadcrumbList schema covers most of the early benefit without much engineering effort.
This is also where technical SEO overlaps with being cited by AI tools. Search engines and AI assistants both rely on machine-readable signals to figure out what a page is actually about — the same structured, well-labeled content that gets a page cited by ChatGPT, Perplexity, and Google's AI Overviews is easier for a traditional crawler to parse correctly too.
Step 6: Don't let content quality undo the technical work
A technically perfect site with thin or AI-generated-and-unedited content still won't rank. Google has been explicit that it doesn't penalize content for being AI-assisted — it penalizes content that's low-quality or created purely to manipulate rankings, regardless of how it was produced. Technical SEO gets a page crawled, indexed, and correctly understood; it can't make a shallow page rank for a competitive query. Treat the checklist above as the floor, not the strategy.
The full checklist, in order
- HTTPS on every URL, with HTTP redirecting via 301
- robots.txt present, not blocking CSS/JS, not used as a privacy tool
- No accidental sitewide
noindexleft from staging - XML sitemap submitted in Search Console, under 50,000 URLs / 50MB per file
- Sitemap contains only canonical, indexable URLs with absolute paths
- Every new page internally linked from an already-crawled page
rel="canonical"on every page, consistent with sitemap and internal links- No duplicate content across
www/non-www, trailing slash, or parameter variants - LCP under 2.5s, INP under 200ms, CLS under 0.1 at the 75th percentile
- Unique, hand-written title tag on every page
- Unique, page-specific meta description on every page
- Mobile rendering matches desktop (Google indexes mobile-first)
OrganizationandArticlestructured data at minimumBreadcrumbListschema if the site has any category depth- Search Console verified and sitemap error report checked weekly for the first month
This is roughly the same technical pass we run automatically before Rankody publishes any article — full disclosure: we build one — because a well-written article on a technically broken site still won't get crawled correctly. If you'd rather have the research, writing, and technical basics handled and delivered for approval than run this checklist by hand every week, that's the problem we built the product around.
FAQ
Do I need to fix every item on this checklist before launch, or can some wait? HTTPS, robots.txt, and avoiding a sitewide noindex must be right before launch — they can block crawling entirely. Sitemaps, Core Web Vitals, and structured data can be improved in the weeks after launch without serious harm, as long as you're not actively blocking Google in the meantime.
Does technical SEO matter if I only have a handful of pages? Yes, arguably more. A small new site has little else — no backlink profile, no crawl history — so technical signals like a clean sitemap and correct canonical tags carry more relative weight in how quickly Google understands the site.
How do I check my current Core Web Vitals scores? Use the Core Web Vitals report in Google Search Console for real-user data once you have traffic, or Lighthouse/PageSpeed Insights for lab data before launch. Lab data is useful for catching obvious problems early but doesn't replace real 75th-percentile field data.
Will structured data guarantee rich results in search? No. Valid structured data makes a page eligible for rich results like star ratings or carousels, but Google decides whether to display them based on overall page quality and relevance. It's a prerequisite, not a guarantee.
Is a technical SEO checklist a one-time task? No. Redirect chains, broken canonical tags, and Core Web Vitals regressions creep in as a site grows and templates change. Re-check the crawlability and speed items at least monthly, and any time you ship a new page template.
A technically sound new site is table stakes, not a growth strategy — it just makes sure the content you publish actually gets a fair chance to be found.
Rankody researches your market, writes sourced long-form articles, and publishes on schedule — every piece waits for your approval first. Three articles free, no card. Analyze my site
Keep reading
- The Pre-Publish SEO Checklist for AI-Written Articles
A 17-point SEO checklist to run before publishing a blog post: title and meta length, Core Web Vitals, alt text, internal links, and verified sources.
- How Long Does It Take for a New Blog to Rank on Google?
A brand-new blog usually needs 6-12 months to rank on Google, and just 6.11% of new pages crack the top 10 within a year, per Ahrefs' 2025 ranking study.
- White-Label SEO Content Services: Options and Real Costs
A breakdown of white label SEO content services in 2026: the four supply models, what each costs per article, margin math, and how to vet vendors.