The Technical SEO Checklist We Use on Every Launch

Most SEO problems we are asked to fix after a launch were created on launch day. A staging site's "noindex" tag that was never removed. A redesign that changed every URL without a single redirect. A beautiful single-page app that serves Google an empty page. None of these are hard to prevent, but they are easy to miss when everyone is focused on design sign-off and the go-live deadline.

That is why we run the same technical SEO checklist on every project, whether it is a five-page brochure site or a large e-commerce catalog. Technical SEO does not make your content good; it makes sure search engines can find, render, understand, and index the good content you already have.

Below is that checklist, grouped into the order we actually work through it, with the reasoning behind each item and a summary table at the end you can copy into your own launch plan.

1. Crawlability: can search engines reach your pages?

robots.txt

Your robots.txt file lives at the root of your domain and tells crawlers which paths they may request. On launch, check three things:

• It does not contain Disallow: / left over from staging. This is the single most common launch-day mistake we see.
• It does not block CSS, JavaScript, or image folders that Google needs to render the page properly.
• It includes a Sitemap: line pointing to your XML sitemap's full URL.

Remember that robots.txt controls crawling, not indexing. A blocked URL can still appear in search results if other sites link to it. To keep a page out of the index, allow it to be crawled and use a noindex meta tag instead.

XML sitemaps

A sitemap lists the canonical, indexable URLs you want search engines to discover. It should contain only pages that return a 200 status, are not noindexed, and are not canonicalized to another URL. Include accurate lastmod dates if you can keep them honest; Google has said it uses lastmod when it is consistently accurate. Large sites should split sitemaps by type (pages, posts, products) under a sitemap index, which also makes indexing problems easier to diagnose in Search Console.

HTTP status codes

Crawl the staging or production site with a tool such as Screaming Frog or Sitebulb and review every status code:

• 200 for live pages.
• 301 for permanent moves. Avoid chains (A to B to C) and loops.
• 404 or 410 for pages that are truly gone. A proper 404 page with helpful navigation is fine and expected.
• No "soft 404s," where a missing page returns 200 with a "not found" message. Google treats these as low-quality pages.
• No 5xx errors under normal load.

Canonical tags

Every indexable page should have a self-referencing rel="canonical" tag with an absolute URL. Duplicates, such as filtered product listings, tracking-parameter URLs, or print versions, should point their canonical to the main version. Make sure canonicals agree with your other signals: the canonical URL should be in the sitemap, use your preferred protocol and hostname, and not redirect anywhere.

2. Indexability: are the right pages allowed in?

Crawlable is not the same as indexable. Before launch, we check:

• No stray noindex meta tags or X-Robots-Tag headers on pages that should rank. CMS platforms often have a site-wide "discourage search engines" setting that is easy to forget.
• Thin or utility pages that should not rank, like internal search results, cart, account, and thank-you pages, are deliberately noindexed.
• One preferred hostname. Choose either www or non-www and 301 redirect the other, along with all HTTP traffic to HTTPS.
• Trailing slash behavior is consistent, so /about and /about/ do not both return 200.

3. Site architecture and internal linking

Search engines use links to discover pages and to judge which pages matter most. A clean structure helps both crawlers and visitors.

• Keep important pages within about three clicks of the homepage.
• Use descriptive, human-readable URLs, such as /services/web-development rather than /page?id=482.
• Link related content together using descriptive anchor text rather than "click here."
• Avoid orphan pages, meaning pages that exist in the sitemap but receive no internal links.
• Use real anchor elements with an href for navigation. Links that only work through JavaScript click handlers may not be followed.
• Add breadcrumbs on deeper sites; they help users and can be marked up with BreadcrumbList structured data.

4. Titles, meta descriptions, and headings

These elements are simple, but they are also where duplicates and placeholders slip through.

• Title tags: unique per page, describing the page's main topic, with your brand at the end. There is no hard character limit, but titles around 50 to 60 characters are less likely to be truncated.
• Meta descriptions: unique, written to earn the click, roughly 140 to 160 characters. Google may rewrite them, but a good one is often used as is.
• One clear H1 per page that matches the page's intent, followed by a logical H2 and H3 hierarchy.
• Open Graph and social tags so shared links show the right title, description, and image.
• Language and locale: a correct lang attribute on the html element, and hreflang annotations if you serve multiple languages or regions.

5. Structured data (JSON-LD)

Structured data helps search engines understand what a page is about and can make it eligible for rich results. Google recommends the JSON-LD format, placed in a script tag in the page. On a typical launch we add:

• Organization (or LocalBusiness for businesses with a physical location) on the homepage: name, logo, URL, contact details, and sameAs links to official social profiles.
• WebSite on the homepage to clarify the site name.
• Article or BlogPosting on blog posts, with headline, author, datePublished, dateModified, and image.
• BreadcrumbList on pages with breadcrumbs.
• Product with offers and reviews on e-commerce product pages, where the data is genuinely shown on the page.

A caveat about FAQ and HowTo markup

FAQ structured data used to be a popular way to take up more space in results. Since 2023, Google shows FAQ rich results only for a limited set of well-known, authoritative government and health websites, and it has stopped showing HowTo rich results. FAQPage markup is still valid schema and harmless when it matches visible content, but do not expect it to produce rich results for a typical business site. More broadly: structured data makes you eligible for rich results, it never guarantees them, and markup that describes content not visible on the page violates Google's guidelines.

Validate everything with Google's Rich Results Test and the Schema Markup Validator before launch.

6. JavaScript SEO and rendering

Google can render JavaScript, but rendering may be delayed, and other search engines and social preview bots are less capable. If your site is a client-side single-page app, the initial HTML may contain little more than an empty container.

How to check

1. View the raw page source (not the inspected DOM) and confirm that the main content, title, meta description, and canonical tag are present.
2. Use the URL Inspection tool in Search Console and view the rendered HTML and screenshot.
3. Confirm each route returns the correct status code. Many SPAs return 200 for every URL, including ones that should be 404.

How to fix

• Server-side rendering (SSR) or static site generation (SSG) with a framework like Next.js is our default for content that needs to rank.
• Prerendering at build time works well for SPAs with a known set of routes, such as marketing pages and blog posts.
• Make sure metadata is set per route on the server, not only updated in the browser after load.
• Do not hide important content behind interactions like tabs that fetch content only on click.

7. HTTPS, mobile, and Core Web Vitals

• HTTPS everywhere: a valid certificate, HTTP redirected to HTTPS with a single 301, and no mixed-content warnings from images or scripts loaded over HTTP.
• Mobile-friendly: Google uses mobile-first indexing, so the mobile version is what gets evaluated. Content, structured data, and metadata must be the same on mobile as on desktop. Check viewport settings, tap target sizes, and readable font sizes.
• Core Web Vitals: test key templates for LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Our Core Web Vitals guide explains how to diagnose and prioritize fixes.
• Accessibility basics: alt text, semantic headings, and labeled forms help users and give search engines clearer signals. See our guide to web accessibility for small businesses.

8. Redirects when migrating or redesigning

Site migrations are where the most organic traffic gets lost. If any URLs are changing, this is the highest-priority section of the checklist.

1. Export every URL from the old site: crawl it, and also pull URLs from your sitemap, analytics, and Search Console performance report so you catch pages with traffic or backlinks.
2. Map each old URL to its closest new equivalent in a spreadsheet. Avoid redirecting everything to the homepage; Google often treats that as a soft 404.
3. Implement 301 redirects at the server or edge level, one hop each.
4. Update internal links to point directly at new URLs rather than relying on redirects.
5. After launch, crawl the old URL list and confirm each one returns a 301 to a 200 page.
6. If the domain itself changes, use the Change of Address tool in Search Console and keep redirects in place for at least a year, ideally permanently.

9. Search Console and monitoring

• Verify the site as a Domain property using a DNS record, so it covers all protocols and subdomains.
• Submit your XML sitemap.
• Use URL Inspection to request indexing for the homepage and key pages.
• Check the Pages (indexing) report over the following weeks for unexpected exclusions.
• Set up analytics and confirm conversions are tracking before traffic arrives.
• Register with Bing Webmaster Tools too; it can import your Search Console setup.

The launch checklist at a glance

Area	Check	Tool
Crawlability	robots.txt allows crawling and lists the sitemap	Browser, Search Console robots.txt report
Crawlability	XML sitemap contains only 200, indexable, canonical URLs	Crawler, Search Console
Crawlability	No broken links, redirect chains, or soft 404s	Screaming Frog, Sitebulb
Indexability	No stray noindex; utility pages deliberately noindexed	Crawler, URL Inspection
Indexability	Self-referencing canonicals; one hostname and protocol	Crawler
Architecture	Key pages within three clicks; no orphan pages	Crawler
On-page	Unique titles, descriptions, and one H1 per page	Crawler
Structured data	Organization, Article, Breadcrumb, Product as relevant, all valid	Rich Results Test
JavaScript	Content and metadata present in server HTML	View source, URL Inspection
Security	HTTPS with no mixed content	Browser console
Mobile and speed	Mobile parity; Core Web Vitals within thresholds	PageSpeed Insights
Migration	Every old URL 301s to its new equivalent	Redirect map, crawler
Monitoring	Search Console verified, sitemap submitted, analytics live	Search Console, analytics

FAQ

How long after launch should we expect pages to be indexed?

It varies widely, from a few days to several weeks for a new domain. Submitting a sitemap and earning a few quality links helps, but there is no way to force indexing.

Is technical SEO a one-time task?

The launch checklist is, but sites drift. New plugins, content, and redesigns introduce problems, so we recommend a lighter crawl every quarter and a check of Search Console reports monthly.

Do we need a plugin like Yoast or Rank Math?

On WordPress, a reputable SEO plugin handles titles, sitemaps, and basic schema well. It does not replace checking redirects, rendering, or performance.

Need help before your launch?

If you would rather not discover a stray noindex tag three weeks after go-live, our technical SEO service runs this checklist and fixes what it finds. For new builds, we bake it into every web development project, or you can start with a free audit of your current site.