A WordPress launch often ends with some variation of “Everything looks good—make it live.”
We understand the impulse. After working through layouts, content, navigation, and all the smaller decisions that make a website feel finished, publishing can seem like the last step.
But making a site public and verifying a production deployment are different things. Launching Built by STS gave us a practical reason to work through that distinction—and to write down a process we could use again.
That process became the WordPress Project Launch Checklist, our first published resource.
The Launch Became Part of the Project
BuiltBySTS.com has been a working test of the ideas behind Built by STS. We started with a native WordPress foundation, developed our own theme, and built STS SEO around specific gaps we could demonstrate. Getting the site ready for visitors gave us another problem to solve.
How would we know the production site was actually delivering what we intended?
Looking through settings was part of the answer. It could tell us which theme was active, whether search visibility was enabled, and which image an article should use when shared. But those answers needed to be checked against the site itself.
As we worked through the launch, the same principle kept coming back:
Configured isn’t the same as verified.
We began turning that principle into concrete checks. Each check needed to help someone establish what was true, recognize what remained uncertain, or decide what required a closer look.
Following a Setting Through to the Result
A canonical URL illustrates the distinction well. A value in a settings screen tells us what has been saved. Inspecting the rendered page tells us whether the correct canonical actually appears—and whether another system has added a second one.
HTTPS needs a similar follow-through. A secure homepage is useful evidence, but we also tested HTTP requests and the www hostname on deeper URLs. The destination mattered as much as the response code. A redirect that reaches the wrong page has not passed just because it ends with HTTP 200.
Some checks went beyond inspecting HTML. Our mobile navigation needed to open and close, respond to the keyboard, return focus appropriately, and remain readable on a small screen. That work included correcting the close control’s contrast against its actual background.
Deployment added another lesson. Preparing a corrected release did not prove that the live installation had received it. We needed to confirm the active version and the styling served by production before calling the fix complete.
These examples were not all failures. They were different kinds of evidence. A saved configuration, a rendered response, and a tested interaction each answer a different question.
Leaving Room for an Honest Answer
Backups made that especially clear. We established that backups containing site files and the database existed. That was valuable, but it did not establish that a successful restoration had been tested. It also did not settle every question about retention or offsite storage.
A checklist should preserve those distinctions. Otherwise, checking a box can quietly turn limited evidence into a much larger claim.
We used a small set of outcomes to make the limits visible:
- PASS — verified: the check has supporting evidence.
- NEEDS REVIEW — deserves attention: something needs a decision or further investigation.
- HUMAN CHECK — requires human judgment: technical checks cannot settle the question on their own.
- UNABLE TO VERIFY — insufficient evidence/access: we cannot responsibly confirm the result.
- N/A — does not apply: the check is outside this project’s requirements.
Those outcomes are more useful than treating every unanswered question as a pass or every uncertainty as a failure. They also give the next person reviewing a launch somewhere to begin.
Some things still need a person to read, navigate, and make a judgment. Is the copy accurate? Does a link reach the destination its label promises? Is the site ready for the people who will use it?
Accessibility checks do not amount to a blanket compliance claim. A performance score records a measurement under particular conditions. Neither should become a permanent stamp of approval. We wanted a process that encouraged careful review without pretending to automate every decision.
What WordPress Already Gave Us
Once the checklist was useful enough to share, we applied another familiar question:
Before we build something, we ask what WordPress already does well.
For this resource, a standard hierarchical Page was enough. WordPress gave us a draft workflow, a parent Resources page, a stable URL, and native blocks for headings, paragraphs, lists, and notes. The Media Library could hold the PDF. Our existing STS SEO fields could supply the description and social image.
We did not need a resource custom post type, a separate publishing system, or an interactive checklist application for the first release.
The work we added was the resource itself: the checklist, its explanatory notes, a printable edition, and a clear path between the Resources landing page and the full web version. Keeping that distinction clear helped us avoid turning a content project into unnecessary software development.
Using the Process on Resource 001
The finished resource contains 186 checklist items across 18 sections, with nine Built by STS Notes and a Final Launch Record. It is available as a complete web resource and an optional downloadable PDF.
The web page remains the main destination. Readers can use the material without downloading anything, while the PDF provides a printable copy for a project review.
Then we applied the same verification approach to the resource’s own release.
Before publication, we checked the approved content, parent and slug, PDF, social image, and responsive presentation. After publication, we checked the actual anonymous production URL rather than relying only on a draft preview.
That included confirming the content counts, following the download link, inspecting the rendered metadata, checking redirects, and finding the resource in the WordPress sitemap. We also checked the Resources page link and the layout at desktop and small-screen widths.
Search visibility received the same treatment. Enabling indexing begins another round of verification: checking for unintended robots directives or blocking headers and confirming sitemap availability. Public indexability still does not prove that a search engine has indexed a page.
A Process Worth Reusing
The checklist grew out of one site, but the questions are useful well beyond Built by STS. A freelancer handing over a project, a developer deploying a release, or a site owner preparing to launch can use it to organize the review and record what still needs attention.
Use the checks that apply to your project. Keep the evidence and the unanswered questions together. Give human review its own place in the process.
Explore Resource 001: WordPress Project Launch Checklist
Start with what WordPress does well. Build what’s actually needed. Create with purpose.