Toolkit: Booking Readiness

Booking Readiness watches the pages and settings guests need to complete a booking and warns you in wp-admin the moment the checkout page is unpublished or a required setting goes missing, so a broken booking flow never sits unnoticed.

What it does #

A checkout page can break without anyone on your team noticing. Picture a checkout page left in Draft for weeks: logged-in admins open it fine, because WordPress shows drafts to editors, but every guest who clicks Instant Booking lands on a 404. Nothing in wp-admin says anything is wrong, and the site quietly stops taking bookings.

Booking Readiness closes that gap. It runs a set of checks every time an administrator opens a wp-admin screen, and once an hour it fetches your real checkout URL the way a logged-out guest would. The result shows up in three places:

• A notice on every wp-admin screen. A red notice reading Guests cannot complete a booking on this site right now. appears while a blocking check fails. A yellow notice reading Bookings work, but part of the booking flow needs attention. appears for warnings. The notice cannot be dismissed; it clears on its own the moment the underlying problem is fixed. Each item names the problem, offers an Open it link to the right editor or settings screen, and, where a page just needs publishing, a Publish it now button. Administrators see the notice; editors and other roles do not.
• The Toolkit Hub. The module’s section card on the Hub overview shows a red Guests cannot book or yellow Booking flow needs attention pill that jumps to the module. The Booking Readiness panel itself shows an Overall line, a table of every check (with status OK, Needs attention, or Not checked), a Re-check now button with the time and result of the last checkout probe, and a Recent actions list.
• Your site’s regular heartbeat to HomeRunner. The verdict rides along with it, so the HomeRunner team can see a blocked site without opening your wp-admin.

What it checks #

Three checks block bookings when they fail:

• Checkout page. A checkout page is selected in HomeRunner settings, the page still exists, it is published, it is not password protected, and it contains the [homerunner-checkout] shortcode.
• Checkout reachable. Once an hour the site requests its own checkout URL with no login and a throwaway quote, exactly as a guest would. Anything other than a normal response (HTTP 200) fails, because that is the page guests see after Instant Booking. Post status alone misses a security plugin, a cache layer, or a redirect that turns the page into a 404 for visitors while admins see it fine. If the server cannot fetch its own URL at all (a blocked loopback request, for example), the check shows Not checked with the reason, and never counts as a failure, because that says nothing about what guests see.
• HomeRunner connection. The API endpoint, API key, and platform are filled in on the HomeRunner API settings screen, and the plugin has not recorded a credentials error. Without these, no prices or availability can load.

Three more raise a warning. Bookings still work, but part of the flow is off:

• Confirmation page. The same page checks as the checkout page, with the [homerunner-confirmation] shortcode. By the time a guest reaches this page the booking already exists; they just see a 404 instead of their confirmation.
• Guest dashboard page. The same page checks, with the [homerunner-user-dashboard] shortcode. Only checked when a guest dashboard page is selected.
• Properties page. The page your search bar sends guests to (the properties page URL in HomeRunner settings, /properties by default). Checked only when that URL is a WordPress page; it must be published, or searches land on a page guests cannot open. An archive or custom route is skipped.

When the Guesty Hosted Checkout module is on, or when you have marked the site as booking through a PMS-hosted checkout (see Settings), the checkout page, checkout reachable, and confirmation page checks show Not checked with the reason, and the hourly probe does not run.

Publish it now #

The Publish it now button appears in the notice and on the panel row whenever the checkout, confirmation, or guest dashboard page HomeRunner is configured to use exists but sits in any status other than Published (Draft, Pending, Private, or Scheduled). It appears only for users who can both manage the site and publish pages.

One click sets that page to Published, records who did it and what the previous status was in Recent actions on the panel (the last 20 actions are kept), and re-runs the checkout probe right away. The confirmation message repeats the previous status, so if the click was a mistake you can set the page back in the editor.

The button is deliberately narrow. It refuses any page that is not one of the pages HomeRunner is configured to use, a page that no longer exists, and a page that is already published. If WordPress reports a save error, or something on the site overrides the new status, the panel reports that instead of claiming success.

How to turn it on #

Booking Readiness is on by default. New installs ship with it enabled, and sites that already had the Toolkit installed had it switched on once automatically during an update. If you turn it off, it stays off. On a multisite network it is not switched on automatically; enable it from the Hub.

1. Confirm it is on in the Hub #

In the HomeRunner Toolkit Hub, check that Booking Readiness is switched on. If you turned it off earlier, switch it back on; the hourly checkout probe starts a couple of minutes later.

2. Read the panel #

Open the Booking Readiness panel and look at the Overall line. Everything guests need to book is in place. means you are done. Otherwise the table below it shows which check needs attention and why.

3. Fix what is flagged #

Click Publish it now to publish an unpublished HomeRunner page, or Open it to jump to the page editor or the settings screen the check points at. Then click Re-check now to confirm the fix; the notice also clears on its own once the checks pass.

4. Mark a PMS-hosted checkout, if that applies #

If guests never use the WordPress checkout page because your PMS hosts the payment step (a Hostfully or Hospitable hosted checkout, for example), switch on Bookings go through a PMS-hosted checkout and click Save. The Guesty Hosted Checkout module is detected on its own, so Guesty sites do not need this.

Settings #

Tips #

• A guest reports a 404 after Instant Booking. Open the Booking Readiness panel first. If Checkout page says Needs attention with a status like “draft”, click Publish it now. If Checkout page is OK but Checkout reachable failed, something between WordPress and the visitor (a security plugin, a cache, or a redirect) is hiding the page from guests while admins see it fine; open the checkout URL in a private browser window to see what guests see. If Checkout reachable says Not checked because the site could not fetch its own URL, the probe cannot tell you either way, so test in a private window yourself. After any fix, click Re-check now.
• The Checkout page check confirms the page carries the checkout shortcode. What that page shows guests, and how the guest details step works, is covered in Checkout Guest Step.
• Sites that send every booking to Guesty’s payment page do not need an on-site checkout page. See Guesty Hosted Checkout; when that module is on, Booking Readiness skips the checkout checks by itself.
• Only administrators see the notice and the Publish it now button. If a colleague with an editor account says everything looks fine, ask an administrator to open wp-admin.
• Turning the module off stops the hourly probe and clears its stored result. Turning it back on starts a fresh probe.
• For the full list of Toolkit modules, see Toolkit: Overview.