Website Launch SEO QA Checklist for Custom Websites

Why launch QA fails when it is only visual

Visual QA answers one question: does the page look right?

Launch QA has to answer better questions:

• Can search engines crawl the pages that matter?
• Are duplicate or low-value pages excluded from the index?
• Do old URLs resolve cleanly to the best new URL?
• Are forms, conversion paths, and analytics events working?
• Do headers support performance, security, and caching without blocking updates?
• Can the internal team maintain the site after handoff?

When those checks happen late, the team gets trapped. Designers are polishing pages while developers are untangling redirects. Marketing is changing metadata while analytics is still untested. Leadership sees the site as done because the homepage looks done.

It is not done until the launch system works.

The short version: what to verify before launch

Use this as the release gate for any custom website build or major redesign.

Step 1: remove staging crawl blocks carefully

Staging sites are often blocked from search with one or more of these:

• Disallow: / in robots.txt
• page-level noindex
• X-Robots-Tag: noindex headers
• password protection
• environment-specific middleware

That is fine before launch. It is a problem when those rules ship to production.

Check production directly, not your local build. Fetch the final live domain and verify:

• robots.txt does not block the whole site
• important templates do not carry noindex
• PDF or asset headers are not accidentally noindexed
• canonical URLs point to the production domain
• staging, preview, and temporary domains are not referenced in metadata

Google is clear that robots.txt controls crawler access. It is not an indexing strategy by itself, and it is definitely not privacy. If something should never appear publicly, protect it with authentication or remove it.

Step 2: validate the XML sitemap like a product artifact

The sitemap should not be a dump of every route the CMS can produce. It should be a clean list of canonical, indexable production URLs.

Before launch, check that the sitemap excludes:

• staging URLs
• redirected URLs
• noindex pages
• duplicate filtered pages
• internal search results
• thin tag or archive pages
• gated assets that should not be indexed

Then check that it includes:

• core service pages
• use-case pages
• product or solution pages
• high-intent blog posts
• case studies
• legal and trust pages where appropriate

For a custom site, sitemap QA is also a maintainability test. If the sitemap only works because one developer manually patched it the night before launch, it is fragile. The CMS and routing layer should generate the right URLs by default.

Step 3: map redirects before the final content freeze

Redirects are not cleanup. They are part of the information architecture.

For redesigns and migrations, build a redirect map before launch. Each important old URL needs a target that matches the user intent as closely as possible.

Avoid lazy redirect patterns:

• sending every old blog post to the blog index
• sending every old service page to the homepage
• chaining old URL → temporary URL → final URL
• using 302 redirects for permanent moves
• preserving URLs that should have been consolidated

The clean version is boring: old URL, final URL, status code, owner, test result.

Google’s site move guidance emphasizes preparing URL mapping and keeping redirects in place long enough for search engines and users to process the move. For business purposes, the same rule applies to buyers. If someone clicks an old proposal link, partner link, or bookmarked case study, they should land somewhere useful.

Step 4: check canonical tags against real page intent

Canonical tags are easy to generate and easy to get wrong.

Every indexable page should point to the preferred production URL for that content. That sounds obvious until a redesign introduces:

• pagination
• filtered resource libraries
• duplicate blog category paths
• campaign landing pages
• CMS preview routes
• uppercase and lowercase URL variants
• trailing slash differences

Do not only check whether a canonical tag exists. Check whether it tells the truth.

A practical rule: if a page is strong enough to include in the sitemap, it should have a self-referencing canonical unless there is a deliberate consolidation reason.

Step 5: review title tags and descriptions in context

Metadata QA should happen page by page, not as a spreadsheet exercise divorced from the actual site.

For each priority page, check:

• title tag is specific and not duplicated
• meta description reflects the page, not a generic brand line
• H1 and title tag support the same intent
• Open Graph title and description work for social previews
• featured image or OG image is appropriate
• no staging or placeholder copy remains

This is where many premium sites start to sound cheap. The design is sharp, but the metadata says “Home” or “Services | Company Name.” Search results are the front door too.

Step 6: test HTTP headers on key templates

Headers are invisible until they cause pain.

Check the homepage, core landing pages, blog posts, case studies, and form pages for:

• final status code
• redirect behavior
• cache-control rules
• content type
• compression
• security headers
• X-Robots-Tag

Cache rules deserve special attention. MDN describes Cache-Control as the mechanism for controlling browser and shared-cache behavior. In plain terms: it affects how quickly visitors see updates and how efficiently the site loads.

The goal is not to paste in every header from a security checklist. It is to choose defaults that fit the site. A marketing site, a logged-in product, and a documentation portal have different constraints.

Step 7: confirm analytics before traffic arrives

Analytics should be tested before launch, not the next morning when the numbers look suspicious.

For most B2B sites, verify:

• GA4 is installed once, not twice
• Google Search Console is verified for the right property
• form submissions fire the expected events
• scheduling clicks are tracked
• newsletter or content downloads are tracked
• internal traffic is understood
• consent behavior is working where required
• thank-you pages are not indexed accidentally

Do not stop at “the tag is present.” Submit a real test form, click the real CTA, and confirm the event shows up in the right reporting surface.

If the site supports sales, analytics QA is revenue QA.

Step 8: run the conversion paths like a buyer

A custom website can pass technical QA and still fail commercially.

Walk through the site as the buyer:

1. Arrive on the homepage from search.
2. Navigate to a service or use-case page.
3. Read proof or a case study.
4. Click the primary CTA.
5. Submit the form or book a call.
6. Confirm the routing and notification path.

Then repeat on mobile.

The QA question is not “does the form submit?” It is “does the right person get the right information quickly enough to act?”

Check hidden fields, CRM routing, confirmation emails, calendar rules, spam protection, and error states. These are small details until they block a qualified lead.

Step 9: verify schema only where it adds clarity

Structured data should describe what is genuinely on the page.

Useful schema candidates include:

• Article schema for editorial posts
• FAQ schema when the page has a real FAQ section
• Organization schema
• Breadcrumb schema
• Product or software schema when it accurately applies

Do not add FAQ schema to a page without visible FAQ content. Do not mark marketing claims as reviews. Do not stretch schema because a plugin made it easy.

Schema is not a costume. It is a label.

Step 10: make maintainability part of QA

The launch is not the finish line. It is when the site leaves the controlled build environment and enters daily use.

Before launch, verify the internal team can safely update:

• page titles and descriptions
• hero copy
• CTA labels and links
• blog content
• case studies
• team or author details
• schema-supported FAQ sections
• redirects where appropriate
• navigation labels

Also check what they should not be able to break. If one CMS edit can destroy spacing across an entire page, the system is too brittle.

A good custom site gives the team useful control without handing them a box of wires.

A practical launch QA order

Do the checks in this order to reduce rework:

1. Freeze URL structure and priority pages.
2. Finalize redirect map.
3. Validate crawl and index rules.
4. Generate and test sitemap.
5. Review metadata and canonical tags.
6. Test headers and page status codes.
7. Validate analytics and conversion events.
8. Run mobile conversion-path QA.
9. Confirm schema matches visible page content.
10. Document post-launch monitoring owners.

The order matters. If URLs are still changing, metadata and sitemap QA will churn. If forms are not final, analytics events will be wrong. If ownership is unclear, nobody will watch the launch after it ships.

Post-launch checks for the first week

After launch, monitor the site daily for the first week.

Check:

• Search Console indexing issues
• sitemap processing
• 404s and unexpected redirects
• form submissions and CRM delivery
• analytics event volume
• key page speed regressions
• branded search results
• social preview rendering
• support or sales reports of broken links

This does not need to become theater. A short daily pass is enough if someone owns it.

What Virdis looks for before a launch

For Virdis, launch QA is not a separate technical chore. It is part of building a site that can be trusted after handoff.

The standard is simple:

• the strategy is reflected in the URL structure
• the design survives real content
• the development work supports search and measurement
• the CMS gives the team controlled flexibility
• the conversion paths work before paid or sales traffic hits the site

That is the difference between a custom website and a custom-looking website.

One is a system. The other is a screenshot with invoices attached.

Frequently asked questions

When should SEO QA start during a website launch?

Start SEO QA before development is finished. URL structure, redirects, sitemap rules, metadata patterns, and analytics events should be planned before final content entry, then verified again on production before launch.

Should robots.txt block pages we do not want indexed?

Not by itself. Robots.txt controls crawler access, but it does not guarantee a URL will stay out of search results. Use noindex where appropriate, authentication for private content, or remove the page entirely.

What pages should be in the XML sitemap?

Include canonical, indexable production URLs that matter to users and search engines. Exclude redirected URLs, duplicate pages, staging URLs, noindex pages, thin archives, and internal search results.

Do all custom websites need structured data?

Most benefit from some structured data, but only where it accurately describes visible content. Article, Organization, Breadcrumb, and genuine FAQ schema are common fits. Avoid schema that exaggerates what is on the page.

How soon should Search Console be checked after launch?

Check it on launch day after the production sitemap is submitted, then review indexing, crawl, and sitemap signals daily for the first week. Larger migrations may need longer monitoring.