Key takeaways
- Build SEO in while the site is made: one search topic per page, clean URLs, titles, structured data and tracking.
- The day before launch, remove staging noindex, fix robots.txt, check the sitemap, metadata and analytics.
- For 30 days after launch, submit the sitemap, inspect key pages and read Search Console's Page indexing report.
A new website needs SEO in three phases. Build it into the plan, check it the day before launch, then watch Google’s response for the first 30 days. This checklist covers each phase and ends with a pre-live vs post-live table you can hand to your developer.
SEO is built on simple fundamentals. A new site rarely fails because it missed an advanced tactic. It fails because someone skipped a basic step, so most of this list is basics, in the order they come up.
Why new websites stay invisible to Google
A website is invisible when Google cannot crawl it, will not index it, or cannot tell what it is about. Good design does not change that. A beautiful site with a leftover noindex tag still gets dropped from Google Search results.
Invisible is the normal state for pages on the web. An Ahrefs study of around 14 billion pages found that 96.55% of them get no traffic from Google. Being published is not the same as being found.
AI search raises the stakes. Google’s rule for AI Overviews and AI Mode is plain. A page must be indexed and eligible to be shown with a snippet before it can appear as a supporting link. If your site is not retrievable by Google, it is invisible to AI Overviews as well. I cover the rest in my guide to ranking in AI search results.
Phase 1: Plan and build search into the site
The cheapest time to get SEO right is before the first template is coded. Changing URLs, page structure and templates after launch means rework, redirects and lost weeks.
Plan pages around real searches
- Write down the site’s main goal: leads, sales, admissions or bookings. Every important page should serve it.
- List the searches you want to win and give each page one main topic, so your pages do not compete.
- Give each product, service or location its own page instead of one page that lists everything.
- Keep important pages a few clicks from the homepage, linked from the menu or from related pages.
- Fix a short, readable URL pattern (lowercase words separated by hyphens) and stick to it.
Start with specific searches you can realistically win. A 3PL warehousing company serving chemicals, paints and agro-chemicals launched its new site in July 2025 with no rankings. National players owned the broad terms, so my team at Adtric targeted niches such as “chemical warehousing” and “paints 3pl” first.
The industry pages gave the first rankings. Between August 2025 and September 2026, its target keywords in Google’s top 100 went from 0 to 15 out of 50 (case study). That work started after launch, but the lesson belongs in the plan.
Build the technical foundation
- Mobile first. Google uses the mobile version of a site for indexing and ranking. Keep the same content, structured data, titles and robots meta tags on mobile and desktop.
- HTTPS everywhere, with one preferred version (www or non-www) and every other version redirecting to it.
- Editable titles and meta descriptions on every template. Google asks for a distinct, descriptive title on each page and sets no length limit; long titles are simply cut off in results. Google sometimes uses the meta description when it describes the page better than the page text, so write one per page.
- Canonical tags on duplicate or near-duplicate pages, such as filtered or tracking URLs. Google calls
rel="canonical"a strong signal and says not to use robots.txt for canonicalization. - Structured data in JSON-LD, the format Google recommends. Use types that match what each page really is. Markup can make a page eligible for rich results; it does not guarantee them.
- A speed target. Aim for Google’s “good” Core Web Vitals. That means Largest Contentful Paint within 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. INP replaced First Input Delay in March 2024, so checklists that still say FID are out of date.
- A password on staging. Google says password protection keeps content out of Google Search. My team at Adtric protects staging sites with a password, so there is nothing to forget on launch day.
One piece of common advice I disagree with: “optimize for Google first and the user experience will follow.” It is backwards. Build for the visitor, then make sure Google can crawl and read what you built.
Set up tracking before launch
- Create the GA4 property and add the tag to every template.
- Decide what counts as a lead or sale, and mark those events as key events in GA4.
- Line up DNS access for Search Console. A Domain property covers every subdomain and protocol, and it is verified through a DNS record.
This is what setting up for search from launch looks like in practice. My team at Adtric built the website for an Indian manufacturer of transmission towers and line hardware that sells to utilities abroad. We set it up for search from day one: clean URLs, sitemaps, Search Console indexing checks and a page for every product line.
Monthly sessions from organic search went from 2 in June 2025, the launch month, to 594 in May 2026 (case study).
Phase 2: The day before launch
The day before launch is for checking, not building. I look at five things: noindex tags, robots.txt, the XML sitemap, on-page metadata, and analytics. The first two can hide a finished site from Google, so I start there.
Walk the site like a visitor first
Whenever I audit a site, I start by acting like a visitor. What is this site trying to tell me, sell me or explain, and does it manage that? Only then do I move to the technical side: titles, code, key meta tags. The same order works the day before launch.
For a full audit, I do a few minutes of manual checks, then run an AI-assisted audit built on my own checklist. I verify every critical finding by hand before anyone acts on it.
Indexing controls
- Remove staging noindex tags from every page meant to be public. Check the HTML and the HTTP headers, because noindex can be set in either. If your CMS has a site-wide “hide from search engines” option, make sure it is off.
- Configure robots.txt to let search bots into public directories and block private login and admin paths. Delete any
Disallow: /left over from staging. The file must sit at the root of the site host. - Know what robots.txt cannot do. It manages crawling and is not a mechanism for keeping a page out of Google. A blocked URL can still be indexed if other sites link to it. Use noindex or a password instead.
- Never block a noindexed page in robots.txt. If Google cannot crawl the page, it never sees the noindex rule.
- Do not treat robots.txt as security. Anyone can read it. Protect login pages properly; my WordPress security checklist covers how.
XML sitemap
- List only live, indexable, canonical URLs. No staging addresses, redirects or noindexed pages.
- Use fully qualified, absolute URLs. One sitemap holds up to 50,000 URLs or 50MB uncompressed.
- If you have several sitemaps, submit them together through a sitemap index file.
- Add a
Sitemap:line to robots.txt with the full sitemap URL. - Skip priority and changefreq, which Google ignores. Keep lastmod honest, because Google only uses it when it is consistently accurate.
On-page and metadata
- Every public page has a unique title, a meta description, one clear main heading and descriptive alt text on meaningful images.
- No placeholder text, test pages or dummy products remain.
- Canonical tags, internal links and menus point to the live domain, not staging.
- Structured data passes the Rich Results Test on each main template.
- A crawl with Screaming Frog shows no broken links and no missing or duplicate titles.
Analytics and technical tracking
- The GA4 tag fires on every template. Data can take up to 30 minutes to start, then your own visit should appear in the Realtime report.
- A test form submission records as a key event.
- HTTP and www variants redirect in one step to the preferred HTTPS version.
Phase 3: The first 30 days after launch
Launch is when Google starts looking, not when SEO ends. Crawling can take anywhere from a few days to a few weeks. Google’s SEO Starter Guide says some changes take hours and others take several months.
Use the first 30 days to confirm that Google can find, crawl and index the pages that matter. Most of my SEO toolkit is free Google tools: Search Console, GA4, PageSpeed Insights and the Rich Results Test. The one paid tool I keep is either Semrush or Ahrefs.
Week 1: get found
- Verify the Search Console Domain property and submit the sitemap. The Sitemaps report shows when Google read it and any processing errors.
- Run the homepage and main service or product pages through the URL Inspection tool. The live test shows what Google sees now. Request indexing for key pages, but requests have a daily limit and do not guarantee indexing.
- Do a
site:yourdomain.comsearch for a quick view. Google says the site: results are not always exhaustive, so trust URL Inspection over it. - Recheck robots.txt, redirects and forms on the live domain. Search Console’s robots.txt report shows whether Google could fetch and parse the file.
- Confirm GA4 is recording real visitors and key events.
- If you serve a local area, add the new website to your Google Business Profile.
Weeks 2 to 4: read what Google tells you
- Open the Page indexing report every week. “URL marked ‘noindex'” on a page you want in search means a tag was missed. Remove it and inspect the URL again.
- “Crawled – currently not indexed” needs no resubmission, according to Google. Check whether the page is thin, duplicated or poorly linked from the rest of the site.
- Check the live site in PageSpeed Insights. A new site often has no real-user data yet, so use the lab score for now; 90 or above counts as good.
- Watch the Performance report in Search Console for the first queries and pages earning impressions.
- Keep improving pages. On-page SEO is not a one-time job that ends at launch.
You do not need to publish three times a week to rank. A new site gains more from making its core pages the best answer for their searches than from a posting schedule. If pages stay out of the index, my explainer on how Google crawls, indexes and decides priority goes deeper.
Pre-live vs post-live SEO checklist table
Use this table to split the work between your developer, content team and whoever owns SEO. Pre-live rows happen on staging; post-live rows happen on the live domain.
| Task | When | How to check | Tool |
|---|---|---|---|
| Map one main search topic to each page | Pre-live: plan | Every key page has a target search; no two share one | Semrush or Ahrefs, Google Trends |
| Password-protect staging | Pre-live: build | Staging asks for a login in a private window | Browser |
| Unique titles and meta descriptions | Pre-live: build, recheck day before | No missing or duplicate titles in a crawl | Screaming Frog |
| Structured data on main templates | Pre-live: build | Valid items, no errors | Rich Results Test |
| Mobile layout and speed | Pre-live: build | Pages work on a phone; lab score 90 or above | PageSpeed Insights |
| Remove staging noindex | Pre-live: day before | No noindex in HTML or headers on public pages | Screaming Frog, view source |
| robots.txt allows public paths, blocks admin | Pre-live: day before | No Disallow: /; Sitemap line present | Browser |
| XML sitemap lists only live, indexable URLs | Pre-live: day before | Absolute URLs, no redirects or noindexed pages | Browser, Screaming Frog |
| GA4 and key events | Pre-live: day before | Your visit shows in Realtime; test form records | GA4 |
| HTTPS and one preferred version | Post-live: launch day | HTTP and www variants redirect in one step | Browser, Screaming Frog |
| Verify Search Console and submit sitemap | Post-live: launch day | Sitemap read with no errors | Search Console |
| Inspect key pages | Post-live: week 1 | Live test passes; indexing requested | URL Inspection |
| Spot-check what is indexed | Post-live: week 1 | Main pages appear | Google site: search |
| Review indexing reasons | Post-live: weekly, weeks 1 to 4 | Wanted pages are not excluded by noindex or robots.txt | Page indexing report |
| Recheck live speed | Post-live: weeks 2 to 4 | Lab score holds; field data once available | PageSpeed Insights, Core Web Vitals report |
| First queries and conversions | Post-live: day 30 | Impressions growing; key events recording | Search Console, GA4 |
What my own site taught me about this checklist
The checks do not stop at day 30. In October 2026, an audit of this site found that the sitemap index had stopped listing the book and essay sitemaps. Only 11 of 26 book pages and about half of the essays were indexed.
A sitemap is only a hint to Google, but it is the list you hand Google of pages you want found. Restoring the missing sitemaps and resubmitting them in Search Console fixed that route back. Google still has to recrawl and reassess each page, which can take weeks.
Speed tells the same story. After page caching was turned on in October 2026, along with a PHP upgrade, the homepage’s mobile PageSpeed score went from 61 to 91. Run the checklist at launch, then again every few months. A plugin update or theme change can quietly undo a step you checked once.
If this is a redesign or migration, not a new site
If the site already exists and the domain, platform or URLs are changing, you are running a migration. That needs its own plan, because the risk is losing rankings the old site already earned.
- List every old URL from crawls, sitemaps, Search Console and analytics, including PDFs and other files.
- Map each old URL to its closest new page and use permanent server-side redirects, one hop each.
- Avoid delayed “we have moved” pages. Google treats a delayed meta refresh as a temporary redirect.
- For a domain change, use Change of Address in Search Console. Keep redirects as long as possible, generally at least a year.
For a large Gurugram real estate developer, the relaunch changed every URL. In the first week of March 2025, visits from Google fell to 2,764, down from about 3,400 a week before the switch. My team at Adtric treated it as a migration: a redirect map, a fresh sitemap and daily index checks in Search Console. Organic sessions from April to September 2025 were 45% higher than in the same months of 2024 (case study).
A small finance bank moved to a .bank.in domain in a project my team at Adtric ran. Its old homepage showed a message, then forwarded visitors after a few seconds. Google began treating that old homepage as a live page again.
By mid-November 2025, weekly clicks to the new domain had fallen from about 5,200 to about 1,800 (migration guide). A server-side 301 on every old URL is safer. Explain the move with a banner on the new site and an email or SMS.
If you are planning a move, my website migration SEO page explains how I approach it.
What to do next
Copy the table, share it with your developer, and agree who owns each row before launch day. Then put the week 1 and day 30 checks in your calendar now, so they do not get skipped.
If you want someone to check the site against this list before it goes live, you can book a website SEO audit.

