Indexability
Production pages use the intended robots directives, status codes, canonicals, and crawl rules. Staging restrictions do not follow the site into production.
A launch is a controlled change to a public business system. This checklist brings content, conversion, search, accessibility, security, analytics, domains, and recovery into one approval process so the site is not considered finished merely because it looks correct.
Name one person who can approve content and business claims, one who controls the domain and DNS, one who can deploy or roll back the website, and one who will verify leads and analytics. Record how the team will communicate during the change and who makes the decision to pause.
Freeze nonessential scope before launch. New preferences discovered during final review should enter a post-launch list unless they affect accuracy, accessibility, security, legal requirements, search continuity, or a primary customer action.
Production pages use the intended robots directives, status codes, canonicals, and crawl rules. Staging restrictions do not follow the site into production.
Each indexable page has a unique title, useful description, one clear H1, descriptive headings, meaningful internal links, and appropriate structured data.
Every changed or removed URL has an intentional direct redirect. Important linked, ranking, converted, and shared addresses are included in testing.
The XML sitemap contains canonical indexable URLs only, uses the correct host and protocol, and is referenced from robots.txt and submitted to Search Console.
Crawl the production candidate before DNS changes when possible. After launch, crawl the public site again because domains, redirects, headers, caching, and platform settings can behave differently in production.
Automated tools find only part of the problem set. Manual keyboard, zoom, screen-reader spot checks, and real task completion remain necessary.
| Area | Launch evidence |
|---|---|
| Accounts | Named administrators, MFA, least privilege, recovery contacts, and removed test users. |
| Transport | Valid TLS, HTTPS redirects, no mixed content, and secure cookie behaviour. |
| Software | Supported versions, reviewed dependencies, updates applied, and unnecessary components removed. |
| Forms | Input validation, spam protection, limited data collection, secure delivery, and retention ownership. |
| Backups | Current backup, separate storage, documented restore path, and an identified recovery owner. |
| Monitoring | Uptime, certificate, form, error, security, and performance alerts route to people who can act. |
| Rollback | Previous production state, deployment instructions, DNS values, decision authority, and communication plan. |
Record the pre-launch analytics property, consent settings, tag configuration, event names, form completions, calls, bookings, sales, and baseline traffic. Test in real time with consent declined and accepted where applicable. Exclude internal and test activity according to the measurement plan.
Immediately after launch, verify the homepage, important landing pages, forms, redirects, robots rules, sitemap, canonicals, analytics, and error monitoring. Repeat checks after caches and DNS changes settle. Review Search Console coverage, queries, crawl errors, and redirected URLs over the following weeks.
Use the companion website migration checklist when URLs, platforms, domains, or content are moving.
The accountable business owner should approve content and outcomes, while designated technical, search, analytics, accessibility, security, and operational owners approve their areas. One named launch lead should coordinate the final decision.
Test the redirect map before launch against the production candidate, immediately after launch on the public domain, and again after platform or caching changes settle. Include important historical, linked, ranking, and converted URLs.
Test every contact, quote, booking, payment, newsletter, login, search, download, and support form. Verify validation, consent, spam protection, confirmation, notifications, data routing, mobile use, keyboard use, and failure handling.
Monitor availability, certificates, errors, forms, security events, performance, analytics, conversions, crawl status, indexing, redirects, search queries, and customer feedback. Alerts must reach someone who can investigate and respond.
Yes. A rollback plan defines the previous working state, deployment and DNS restoration steps, backups, decision authority, communication, and the conditions that justify reversing the launch.
North Star designs, rebuilds, hosts, and supports business websites remotely across Canada. Bring the checklist or brief to a scope call and we will translate it into a clear proposal.
Request a Website ScopeExplore Web Design