The last hour before launch is where small misses become public. This is the checklist I run on every WordPress build, from search visibility to the forgotten staging URL.
Launch day has a way of exposing every shortcut. The site looks perfect on your monitor and then a client opens it on an old iPhone, or Google indexes the staging domain, or the contact form quietly sends replies to nobody. My WordPress launch checklist is the same ten checks on every build before I hand over the keys. None of them take long. All of them have saved me at least once.
1. Search engines are allowed in
Settings → Reading → “Discourage search engines” must be unticked on the live site. It is ticked on every staging site I build, which is exactly why it gets forgotten. I also check robots.txt is not blocking everything and that an XML sitemap exists and loads.
2. Every URL points at the live domain
After moving from staging, I search the database for the old domain and replace it, including inside serialised data. Then I click through the site looking for images or links that still load from staging. One missed URL means a broken image the moment staging is deleted.
3. Forms actually deliver
I submit every form and confirm the email arrives at the right inbox, not just that the success message shows. Shared hosting often cannot send mail reliably, so I set up SMTP through a transactional provider rather than hoping. I also check where submissions are stored, so nothing is lost if an email bounces.
4. Titles, descriptions and social previews
Each page gets a proper title and meta description, the home page has an Open Graph image, and I paste the URL into a social preview tool to see what actually appears when someone shares it. Default “Home – Site Name” titles are the quickest way to look unfinished in search results.
5. Speed on a real phone connection
I test on a mid-range Android over mobile data, not just Lighthouse on a desktop. Images are served in WebP at sensible sizes, fonts are limited to the weights actually used, and anything loading below the fold is lazy. If the largest image on the home page is over 200KB I have missed something.
6. Redirects from the old site
If there was a previous site, every old URL that had traffic or backlinks gets a 301 to its new equivalent. I export the old URL list from Search Console before the switch, because after it is gone it is gone. A relaunch that drops rankings is usually a relaunch that dropped redirects.
7. The essentials of security
Admin username is not “admin”. Two-factor authentication is on for every administrator. File editing from the dashboard is disabled. Unused themes and plugins are deleted rather than deactivated. Automatic updates are set for minor core releases and, on care-plan sites, monitored for everything else.
8. Backups exist and restore
A backup you have never restored is a hope, not a backup. Before launch I take a full backup, restore it to a throwaway environment, and confirm it works. Then the schedule is set: daily for sites that change often, weekly for brochure sites.
9. The 404 page, favicon and other small things
A designed 404 page with a way back. A favicon that is not the WordPress logo. A privacy policy that mentions the tools actually in use. The correct timezone in Settings → General so scheduled posts go out when expected. Small, but every one of them is noticed by someone.
10. The client can actually use it
Finally, I record a walkthrough on the client’s own site: how to edit the pages they will touch most, how to add a post, where the form submissions live, who to contact if something breaks. Then I watch them make one change themselves while I am still on the call. If they cannot, the handover is not done, whatever the checklist says.
None of this is glamorous. It is also the difference between a launch and a launch that becomes a support ticket by Monday.
