Built by STS

WordPress Project Launch Checklist

Don’t just launch it. Verify it.

Launching a WordPress site is more than making it public. A successful launch means confirming that the site visitors—and search engines—actually receive is the site you intended to deploy.

This checklist is designed for freelancers, agencies, developers, and site owners who want a practical process for moving a WordPress project from development to production with confidence.

Built by STS principle: Configured isn’t the same as verified.

Prefer a printable copy?

Download the PDF edition of the WordPress Project Launch Checklist to use during your next site launch.

Download the PDF Checklist

1. Before You Begin

Before making launch-day changes:

  1. Confirm the production domain and canonical URL
  2. Confirm access to WordPress administration
  3. Confirm access to hosting/server controls
  4. Confirm access to DNS/CDN services
  5. Record the current WordPress, theme, and important plugin versions
  6. Confirm a recent backup exists
  7. Identify how the site can be restored if deployment fails
  8. Establish which version/build is intended for production
  9. Record any known issues intentionally being accepted at launch

Built by STS Note: A backup existing does not prove recovery works. Know the difference between backup configured, backup created, and restore tested.

2. Content & Site Structure

  1. Homepage is correct and complete
  2. Required pages are published
  3. Placeholder/sample content has been removed
  4. Draft/private content isn’t unintentionally public
  5. Page titles are correct
  6. Heading hierarchy is logical
  7. Each primary page has an appropriate H1
  8. Images and media display correctly
  9. Important images have appropriate alternative text
  10. Contact/business information is accurate
  11. Copyright/date information is appropriate
  12. Privacy/legal pages required for the site’s functionality are available

3. Navigation & Link Integrity

  1. Desktop navigation works
  2. Mobile navigation opens and closes correctly
  3. Header links reach their intended destinations
  4. Footer links reach their intended destinations
  5. CTA buttons reach their intended destinations
  6. In-content links work
  7. External links point to the intended websites
  8. Anchor links reach the correct sections
  9. Logo/home links behave correctly
  10. No important broken links remain

Built by STS Note: A 200 response doesn’t prove a link is correct. A link can successfully load the wrong page. Verify the intended destination, not merely the HTTP response.

4. Responsive & Visual QA

Test representative pages at several viewport sizes.

Suggested baseline: 1440px · 820px · 390px · 320px

  1. No horizontal overflow
  2. Header remains usable
  3. Navigation remains usable
  4. Text doesn’t clip or overlap
  5. Images scale correctly
  6. Buttons remain readable and tappable
  7. Cards/grids stack appropriately
  8. Footer remains readable
  9. Important controls remain visible
  10. Landscape orientation doesn’t expose obvious problems
  11. Browser zoom/reflow doesn’t break essential functionality

Test on at least one physical phone when possible.

5. Forms & Communication

If the site contains forms:

  1. Required fields behave correctly
  2. Validation messages are understandable
  3. Successful submissions are confirmed to the visitor
  4. Submission is stored where expected
  5. Notification email actually arrives
  6. Reply-to/from behavior is correct
  7. Spam protection works
  8. Test submissions are clearly labeled and removed if appropriate
  9. SMTP/mail delivery is verified where applicable

If the site has no public forms, record that explicitly rather than marking form testing as passed.

6. SEO & Metadata

For representative pages and posts:

  1. Document title is appropriate
  2. Meta description is present where intended
  3. Exactly one appropriate canonical URL is emitted
  4. Canonical uses the intended HTTPS hostname
  5. Open Graph metadata is correct
  6. X/Twitter metadata is correct
  7. Social images are appropriate
  8. No duplicate SEO fields are being generated
  9. Structured data, if intentionally implemented, is valid
  10. Important archive metadata is reviewed

7. Search Visibility — Pre-Launch

Before enabling indexing:

  1. Confirm whether WordPress currently discourages search engines
  2. Verify rendered robots directives
  3. Check for X-Robots-Tag restrictions
  4. Inspect robots.txt
  5. Check sitemap behavior
  6. Confirm staging/development URLs aren’t leaking into metadata
  7. Confirm canonical URLs point to production
  8. Identify which archives should eventually be indexable

Built by STS Note: Do not assume changing one WordPress setting removes every possible indexing restriction.

8. Social Sharing

  1. Homepage sharing preview is appropriate
  2. Representative page preview is appropriate
  3. Representative post preview is appropriate
  4. Social title is correct
  5. Social description is correct
  6. Social image is correct
  7. Default/fallback image behaves as intended
  8. Explicit article images override the fallback where expected

9. Accessibility Basics

This is an accessibility review, not a claim of WCAG compliance.

  1. Keyboard navigation works
  2. Focus states are visible
  3. Mobile menu can be operated by keyboard
  4. Escape closes overlays/menus where expected
  5. Focus returns appropriately after dialogs/navigation close
  6. Controls have understandable accessible names
  7. Important text/background contrast is reasonable
  8. Heading structure is logical
  9. Images have appropriate alt behavior
  10. Zoom/reflow doesn’t make essential content unusable
  11. Forms have understandable labels and errors

Built by STS Note: Test controls in their active state. A button that looks fine while a menu is closed may become invisible against the menu background after it opens.

10. Performance

  1. Important pages load without obvious delays
  2. Images are reasonably optimized
  3. No unnecessarily huge assets are being delivered
  4. CSS/JS assets return successfully
  5. Browser console doesn’t reveal obvious production errors
  6. Caching/CDN behavior is working as intended
  7. Fonts don’t create unnecessary loading problems
  8. Third-party scripts are intentional
  9. Real-user performance monitoring is configured if used

Built by STS Note: Treat performance scores as measurements—not permanent grades. Test the actual user experience too.

11. WordPress & Technical Health

  1. WordPress core is current for the intended launch
  2. Active theme version is correct
  3. Important plugin versions are correct
  4. Database updates are complete
  5. REST functionality required by the site works
  6. WP-Cron has no obvious overdue failures
  7. Production debugging is appropriately configured
  8. PHP errors aren’t being exposed publicly
  9. Site Health has been reviewed
  10. Genuine nonexistent URLs return HTTP 404
  11. No unexpected development/staging configuration remains

12. Security & Updates

  1. Check for WordPress security updates immediately before launch
  2. Check active plugins for available security updates
  3. Check active themes for relevant updates
  4. Review known vulnerability warnings
  5. Remove unnecessary/inactive components when appropriate
  6. HTTPS is working
  7. Origin certificate is valid where applicable
  8. CDN/proxy SSL mode is appropriate
  9. HTTP requests redirect to HTTPS
  10. Alternate hostname behavior is intentional
  11. Security tooling is functioning as intended

Built by STS Note: A site can be fully updated when the launch audit begins and have a security release arrive before the audit ends. Check again immediately before launch.

13. Privacy & Data Flow

Document what the site actually does, not what a generic privacy-policy template assumes it does.

  1. Identify public forms
  2. Identify analytics services
  3. Identify cookies/browser storage
  4. Identify hosting/security logs
  5. Identify third-party embeds
  6. Identify user accounts/registration
  7. Identify checkout/payment processing
  8. Identify newsletter/signup systems
  9. Identify uploads or gated downloads
  10. Confirm comments/pingbacks are intentionally configured
  11. Privacy Policy reflects the actual site
  12. Privacy/contact method works
  13. Privacy Policy is publicly reachable and linked appropriately

14. Backups & Recovery

Record separately:

  1. Backup system is configured
  2. Recent backup exists
  3. Website files are represented
  4. Database is represented
  5. Recurring backup evidence exists
  6. Retention policy is known, if applicable
  7. Storage location is known, if applicable
  8. Offsite status is known, if applicable
  9. Restoration procedure is documented
  10. Successful restoration has actually been tested, if claimed

Built by STS Note: Never report “recovery proven” merely because a backup exists.

15. Final Human Review

Put the developer brain away for a few minutes.

  1. Browse the site in a private/logged-out window
  2. Browse it on a physical phone
  3. Navigate as a first-time visitor
  4. Read important copy instead of merely checking layout
  5. Try every major CTA
  6. Look for unfinished language or placeholders
  7. Confirm visitors can understand what the site is and what to do next
  8. Check footer/legal information
  9. Review the overall experience without developer/admin privileges

Ask:

Does this feel finished to someone who didn’t build it?

16. Deployment Verification

  1. Intended release was actually deployed
  2. Production version matches the intended release
  3. Expected changed files/content are present
  4. No duplicate/nested deployment exists
  5. Production—not staging—was tested
  6. Deployment didn’t overwrite site-specific configuration
  7. Critical functionality was retested after deployment
  8. CDN/server caches aren’t serving an older release

Built by STS Note: Preparing a release isn’t deploying a release. Verify what’s actually running in production.

17. Indexing Transition

Only after pre-launch blockers are resolved:

  1. Create/confirm final backup
  2. Enable WordPress search-engine visibility
  3. Confirm the setting actually changed
  4. Immediately request fresh anonymous pages
  5. Verify unintended noindex/nofollow is gone
  6. Verify HTTP indexing headers
  7. Recheck robots.txt
  8. Recheck sitemap availability

Built by STS Note: Enabling indexing isn’t the end of launch. It’s the beginning of post-launch verification.

18. Post-Launch Verification & Monitoring

  1. robots.txt permits intended crawling
  2. XML sitemap returns successfully
  3. Sitemap contains intended published content
  4. Draft/private/trash content isn’t exposed
  5. Canonicals remain correct
  6. HTTP → HTTPS works on multiple paths
  7. www/non-www behavior is correct
  8. Redirects preserve paths and necessary query strings
  9. Category archives are intentionally indexable or restricted
  10. Author archives are intentionally indexable or restricted
  11. Date archives are intentionally indexable or restricted
  12. Feeds behave intentionally
  13. Attachment pages behave intentionally
  14. Real 404s remain real 404s
  15. Analytics/monitoring receives production traffic
  16. Fresh and cached responses are checked where relevant
  17. Search-engine webmaster tools are connected if part of the project
  18. Sitemap is submitted where appropriate
  19. Site is monitored after launch for errors or regressions

Final Launch Record

Project: __________________________

Domain: __________________________

Launch Date: _____________________

WordPress Version: _______________

Theme/Build Version: ______________

Backup Verified: ☐

Indexing Verified: ☐

Post-Launch Verification: ☐

Reviewed By: _____________________

Create with purpose.

Built by STS

Digital products crafted by Spears Tech Solutions.