There is a slightly awkward point in a website launch where staging is no longer enough.
You can test a theme locally. You can test WordPress in an isolated staging install. You can check templates, mobile layouts and error pages. But eventually you need to know what the real production site does when a normal browser reaches it through the public internet.
I wanted that test without turning the site into a real launch.
The problem
Jenski was already on its production domain, with WordPress, HTTPS, the real theme and the recovered archive in place. But I still had two useful safety gates:
- maintenance mode was hiding the real site;
- search indexing was disabled.
The archive posts were also still drafts. That meant the production database could contain the recovered material without any of it appearing publicly.
At some point, though, maintenance mode itself becomes the thing preventing useful testing. A maintenance page cannot tell you whether the real homepage renders correctly on a phone, whether the Archive route works, whether category pages use the right theme, or whether your 404 page is actually the one you built.
Keep the search-engine gate separate from the visibility gate
The useful trick was to treat public visibility and search indexing as two different controls.
I temporarily removed only the maintenance marker. I did not enable search indexing.
So a browser could reach the real Jenski theme, but the site still told crawlers not to index it. WordPress REST responses continued to carry a noindex header and the rendered pages still contained noindex instructions.
I also kept every recovered historical post as a draft. Public WordPress REST still returned zero public posts.
Use exact preconditions before changing production
I did not just delete a maintenance file because it looked like the right file.
First I identified exactly what was controlling maintenance mode and recorded the file hash. The public-QA switch would only remove that file if the bytes still matched what had been inspected.
If the state had changed underneath the process, the switch would refuse to run rather than guessing.
The custom maintenance page itself stayed on the server, so the previous state remained easy to restore.
Test the production routes before opening a browser
Once the maintenance marker was removed, I checked the boring things first:
- the homepage returned HTTP 200;
- Archive returned HTTP 200;
- Search returned HTTP 200;
- all six category routes returned HTTP 200;
- an unknown route returned HTTP 404;
- the www hostname redirected permanently to the canonical apex domain;
- search indexing was still blocked;
- the public post count was still zero.
That gave me a clean boundary before spending time on visual testing.
Then render the real site like a user
The next pass used a real headless browser against the live production domain.
I rendered the homepage at desktop and mobile sizes, the Archive on mobile, Places on desktop and the custom 404 on mobile. The test also dumped the rendered DOM and checked for the pieces that should actually be visible.
That matters because a simple HTTP request can tell you that a page exists, but it cannot prove that the browser successfully rendered the experience you intended.
Do not confuse public QA with launch
This was still not a launch.
No recovered post was published. Search indexing stayed disabled. There was no announcement and no reason for search engines to treat the site as ready.
The only thing that changed was that the real production shell became visible long enough to test it properly.
What I would repeat
- Separate maintenance from indexing. They solve different problems.
- Keep unfinished content as drafts. The site shell can be tested without publishing the content queue.
- Use exact preconditions for production changes. Refuse to guess when state has drifted.
- Test HTTP state before visual state. Routes, redirects and indexing are cheaper to prove first.
- Render the actual production domain. Staging cannot prove every edge condition.
- Keep the QA switch reversible. Public QA should be a controlled state, not a one-way launch button.
The result was a production site I could inspect like any other visitor while it was still deliberately invisible to search engines and still contained zero published posts.
That is a much more useful definition of “not launched yet” than simply hiding everything behind a maintenance page.