What to Check Before Launching a Website

Before launching a website, it is worth running a structured review. The goal is not impossible perfection. It is to prevent predictable problems: broken pages, forms that do not submit, incorrect metadata, mobile issues, accidental indexing, or analytics that were never configured.

A checklist separates the launch into areas and reduces the chance of forgetting important tasks.

1. Domain and HTTPS

Check:

• Primary domain.
• `www` and non-`www` variants.
• HTTPS certificate.
• Redirects.
• Required subdomains.
• DNS.
• Old URLs that need redirects.

Choose one canonical domain and keep internal links, sitemap entries, and metadata consistent.

Also verify that HTTP redirects correctly to HTTPS when appropriate.

2. Environment variables

For deployed applications, confirm that production has its own variables.

Review:

• Public URLs.
• Database connection.
• Service keys.
• Webhooks.
• Email.
• Analytics.
• Storage.
• Payment environment.
• Feature flags.

Do not copy development values into production without checking them.

Private keys should never be exposed through variables intended for browser-side use.

3. Database

Before launch:

• Confirm production uses the correct database.
• Review required indexes.
• Verify backups.
• Test migrations.
• Make sure test seeds are not publicly visible.
• Review test accounts.
• Remove fake public data.

A site can work technically while still showing test content that reduces trust.

4. Navigation

Browse the site as a new user.

Test:

• Navbar.
• Footer.
• Breadcrumbs.
• Buttons.
• Calls to action.
• Internal links.
• External links.
• Logo-to-home behavior.
• Spanish/English routes when available.
• 404 page.

Broken links often appear after slug or route changes.

5. Responsive design

Do not rely only on resizing the browser window.

Test:

• Phone.
• Tablet.
• Desktop.
• Different widths.
• Orientation when relevant.

Review:

• Tables.
• Modals.
• Forms.
• Menus.
• Grids.
• Images.
• Buttons.
• Long text.
• Fixed elements.

A table that looks perfect on desktop may be unusable on mobile.

6. Forms

Test every form end to end.

Include:

• Required fields.
• Validation.
• Error states.
• Success message.
• Received email.
• Database record.
• Anti-spam.
• Duplicate submission.
• Special characters.
• Mobile behavior.

Do not assume a form works because the button responds.

7. Login and permissions

If the product has accounts, test:

• Registration.
• Login.
• Logout.
• Password recovery.
• Sessions.
• Protected routes.
• Roles.
• Administrator access.
• Token expiration.
• Error messages.

Also try opening restricted URLs manually as a normal user.

8. Payments

If the site accepts payments, verify:

• Correct environment.
• Currency.
• Price.
• Taxes.
• Coupons.
• Redirects.
• Webhooks.
• Order state.
• Rejected payment.
• Pending payment.
• Approved payment.
• Emails.
• Retries.

Do not test only the happy path.

Payment systems often contain intermediate states that the interface must handle correctly.

9. Metadata

Review per page:

• Title.
• Meta description.
• Canonical URL.
• Open Graph.
• Social image.
• Language.
• Language alternatives.
• Robots directives.

Dynamic pages should generate specific metadata from real content.

10. Sitemap

Open the production sitemap.

Check:

• Correct domain.
• Public URLs only.
• No localhost.
• No preview environments.
• No admin pages.
• No draft content.
• No records that should remain unindexed.
• Correct Spanish/English routes.

A URL in the sitemap signals that you want search engines to discover it.

11. robots.txt

Confirm that it:

• Does not accidentally block the entire site.
• Does not use robots rules as a security mechanism.
• Points to the correct sitemap.
• Matches your indexing strategy.

`robots.txt` is not an authentication system.

12. Search Console

After domain and sitemap setup, you can review:

• Correct property.
• Submitted sitemap.
• Indexing.
• Coverage.
• Errors.
• Inspection of important URLs.

Do not expect every page to appear immediately. Crawling takes time.

13. Analytics

Before launch, decide what matters.

In addition to pageviews, events may include:

• Registration.
• Form submission.
• Download.
• Purchase.
• Checkout start.
• Resource click.
• Tool use.
• Search.
• Subscription.

Exclude development and preview traffic when appropriate so the data remains useful.

14. Consent and privacy

If the site uses technologies that require consent under applicable rules, verify:

• Consent banner.
• Preferences.
• Default state.
• Updates after accept/reject.
• Privacy policy.
• Cookies.
• Analytics.
• Advertising.

Avoid a banner that is only visual and does not change tag behavior.

15. Performance

Review:

• Oversized images.
• Unnecessary scripts.
• Fonts.
• JavaScript.
• Slow APIs.
• Caching.
• Lazy loading.
• Console errors.

A site does not need a perfect score to launch, but it should avoid obvious issues that affect users.

16. Basic accessibility

Check:

• Contrast.
• Labels.
• Keyboard navigation.
• Alternative text.
• Heading hierarchy.
• Focus states.
• Identifiable buttons.
• Understandable forms.

Accessibility also improves overall clarity.

17. Security

Review:

• No exposed secrets.
• Dependencies.
• Server-side validation.
• Rate limiting where needed.
• Permissions.
• CORS.
• Headers.
• Private files.
• Logs without sensitive information.

Do not rely only on frontend validation.

18. Content

Before opening to the public:

• Remove placeholder text.
• Review spelling.
• Confirm prices.
• Verify contact information.
• Review images.
• Confirm dates.
• Remove test records.
• Review legal text.
• Check English versions.

An incomplete record can damage perception more than a small visual issue.

19. Emails and notifications

Test:

• Sender.
• Subject.
• Links.
• Language.
• Mobile template.
• Delivery.
• Errors.
• Duplicate notifications.

Email links should point to the production domain, not localhost.

20. Logs and monitoring

After publication, you need to detect failures.

Prepare:

• Application logs.
• Alerts when appropriate.
• Error tracking.
• Service status.
• Basic metrics.

A launch does not end when Vercel, Render, or another provider says “deployed.”

SG Hub launch checklist

You can use the SG Hub website launch checklist as a starting point and adapt it to your technology stack.

A simple company website does not need the same tests as a marketplace with accounts, payments, and webhooks.

Final review

Before announcing the launch:

1. Run the production build.

2. Test the real URL.

3. Review navigation.

4. Submit forms.

5. Verify sitemap and robots.

6. Test mobile.

7. Review analytics.

8. Check consent behavior.

9. Review browser and server errors.

10. Confirm no test data remains.

A strong launch does not depend on one test. It comes from reviewing the product as a user, an administrator, and a system before real traffic arrives.