Support / Royal MCP Pro / Site Launch Readiness

Site Launch Readiness

End-to-end walkthrough for the wp_prepare_for_launch composer. Runs 5 read-only health checks (backup + SEO + broken links + TTFB perf + security) in one MCP call and returns a rolled-up report. Named for the "am I ready to ship this?" moment, but used more often as a routine monthly / pre-campaign health check.

When to run this
  • About to flip a staging site to production for the first time
  • About to publish a large content push or start a marketing campaign
  • Monthly routine "is this site still healthy" check
  • Post-update sanity: after a plugin/theme update batch, confirm nothing regressed
  • Handing a client site over from build phase to their own team
  • Before a support conversation with hosting ("here's what's actually failing right now")

Prerequisites

  • Royal MCP Pro installed and licensed (see Getting Started)
  • MCP client connected to your site
  • Cap: manage_options (required for the composer to run at all)
  • Optional: SiteVault Pro (for the backup step to actually fire — skipped-with-note when absent)
  • Optional: SEObolt Pro (for the SEO step to return the full audit — falls back to basic native scan when absent)
  • Optional: GuardPress Pro (for the security step to return the full security overview — falls back to basic wp-config checks when absent)

The 5 checks, in order

backup_snapshot

Kicks off a SiteVault backup so you have a known-good restore point before shipping. Skips silently when SiteVault isn't active or when skip_backup: true is passed.

Skip condition

The step evaluates as skipped (status not run) when either: (a) skip_backup: true was passed, OR (b) SiteVault isn't installed / active. Neither condition is an error; both are surfaced with status: skipped.

When it fires

Calls SiteVault's backup entry function. Returns {via: 'sitevault_create_backup', id, result} on success. Whether the actual backup completes synchronously or runs in the background depends on SiteVault's own configuration — check SiteVault's backup log to confirm completion rather than assuming the tool response means done.

seo_audit

Confirms basic on-page SEO surfaces are present on the home page. Uses SEObolt Pro if installed; otherwise fetches home HTML and does a native scan.

SEObolt path

Returns {via: 'seobolt', note: 'SEObolt is active — run its Audit page for full report'}. The composer intentionally doesn't duplicate SEObolt's audit — it just confirms the plugin is available and hints at where the full report lives.

Native fallback

Fetches home_url('/') and checks the returned HTML for: has_title (a <title> tag with at least 5 chars), has_meta_description (a <meta name="description">), has_h1 (at least one <h1>). Returns all three booleans in the response.

If the home page can't be fetched at all, this step returns status: error, message: 'could not fetch home page' — usually a symptom of the site being genuinely broken (500 error, DNS issue, hosting-layer WAF blocking self-requests).

broken_link_scan_home

Extracts href and src attributes from the home page pointing at same-origin URLs, HEAD-checks the first 25 unique ones, reports any that return 400+ or fail to connect.

Scope + limits

  • Home page only. The scan is not site-wide — only URLs referenced on the home page get checked.
  • Same-origin only. External links (to social media, partner sites, CDNs on a different domain) are skipped.
  • Capped at 25 unique URLs. A home page with dozens of internal links gets its scan truncated to the first 25 after dedup.
  • 3-second HEAD timeout per URL. Slow-to-respond URLs count as broken (code: 0).

Response shape

Returns {sampled, broken_count, broken_urls: [{url, code}]}. code: 0 means the HEAD request itself failed (timeout, DNS, connection refused).

perf_check_ttfb

Times a single GET request to the home page. Returns time-to-first-byte in milliseconds and the HTTP status code.

How it measures

Records microtime(true), fires wp_safe_remote_get(home_url('/'), ['timeout' => 8]), records elapsed time on response. Returns {home_elapsed_ms, home_status}.

What to read from it

  • Under 400ms: healthy for most stacks. No action needed.
  • 400–1000ms: workable but a page-cache miss or first-visitor cold start could push it into user-perceptible territory.
  • 1000ms+: likely user-visible. Check page cache is working, image sizes, database query count.
  • Over 8000ms: exceeds the tool's timeout — step returns status: error. Genuine hosting-layer problem or the site is straight-up unreachable.

One measurement is noisy — run the composer 2-3 times and take a rough median. Sub-second differences between runs are normal.

security_status

Confirms basic security posture. Uses GuardPress Pro if installed; otherwise checks wp-config flags directly.

GuardPress path

Returns {via: 'guardpress', note: 'GuardPress active — see its Overview page'}. Like the SEO step, the composer defers to GuardPress's own security dashboard rather than duplicating it.

Native fallback

Returns {via: 'native_scan, wp_debug_enabled, wp_debug_display, disallow_file_edit, file_mods_allowed, is_ssl}. Each flag is a boolean read from constants and helpers:

  • wp_debug_enabled should be false in production
  • wp_debug_display should be false in production (never expose PHP errors)
  • disallow_file_edit should be true in production (locks down wp-admin theme/plugin editor)
  • file_mods_allowed should be true for auto-updates to work; can be false on managed hosts that push updates externally
  • is_ssl should be true for any modern production site

Running the check

Basic call

The tool takes no required arguments. Just ask your AI:

Run wp_prepare_for_launch on my site and summarize what's flagged.

Response shape (with all 5 steps returning ok):

{
  "isError": false,
  "content": [
    { "type": "text", "text": "Launch readiness (best_effort): 5 ok, 0 skipped, 0 error." }
  ],
  "structuredContent": {
    "compose_mode": "best_effort",
    "dependencies_probed": {
      "sitevault":  { "available": true },
      "seobolt":    { "available": false },
      "guardpress": { "available": false }
    },
    "steps": [
      { "name": "backup_snapshot",       "status": "ok", "reversible": false, "data": { "via": "sitevault_create_backup", "id": "bk_123" } },
      { "name": "seo_audit",             "status": "ok", "reversible": false, "data": { "via": "native_scan", "has_title": true, "has_meta_description": true, "has_h1": true } },
      { "name": "broken_link_scan_home", "status": "ok", "reversible": false, "data": { "sampled": 18, "broken_count": 0, "broken_urls": [] } },
      { "name": "perf_check_ttfb",       "status": "ok", "reversible": false, "data": { "home_elapsed_ms": 312, "home_status": 200 } },
      { "name": "security_status",       "status": "ok", "reversible": false, "data": { "via": "native_scan", "wp_debug_enabled": false, "wp_debug_display": false, "disallow_file_edit": true, "file_mods_allowed": true, "is_ssl": true } }
    ],
    "counts":  { "ok": 5, "skipped": 0, "error": 0 },
    "summary": { "…": "rolled-up launch_summary object" }
  }
}

Skip the backup step

If you just took a backup manually or don't need one for this check:

Run wp_prepare_for_launch with skip_backup=true.

The backup_snapshot step is evaluated as skipped in the response and counted separately.

Compose mode variants

Same three modes as every other composer (see Cross-plugin Composers):

  • best_effort (default): every step runs independently. A failing step is recorded and the composer moves on.
  • strict: first failing step aborts the composer. Useful if you want a hard-stop on any red flag.
  • report_only: lists which steps would run but doesn't execute them. Useful if you're piping the composer's plan into a runbook.

Acting on each failure type

backup_snapshot failed

SiteVault fired but the backup itself errored. Check SiteVault's backup log in wp-admin for the actual failure reason. Common causes: disk-space limit on cloud storage, credential rotation, cron not firing. If SiteVault isn't the problem, the composer step's error message tells you what the entry function returned.

seo_audit shows missing title / description / h1

Fix in whichever tool you use for SEO meta:

  • Missing title: check theme's <head> template or SEO plugin's home-page title setting
  • Missing meta description: set one in Yoast / Rank Math / SEOPress / AIOSEO / SEObolt home settings
  • Missing h1: check theme, or add a Section Heading module (Divi) / Heading widget (Elementor) at the top of the home page

broken_link_scan_home reports broken URLs

For each URL in broken_urls:

  • 404: the target post/page was deleted or renamed. Either restore it, redirect to a live equivalent (via the Redirection plugin + redirection_bulk_import), or edit the source home-page reference.
  • 500: the target renders but errors out. Fix the target's underlying error (WP_DEBUG_LOG will have specifics).
  • 0 (connection failed): DNS problem, hosting-layer WAF blocking self-requests, or a firewall between WP and its own site. Same class of issue as most Royal MCP host-layer problems — see Free Troubleshooting.

perf_check_ttfb over 1000ms

  • Verify page cache is working (ForgeCache, WP Rocket, LiteSpeed Cache, W3 Total Cache — whichever you use). If cache-status header says MISS on repeated requests, cache isn't warming.
  • Check image weight on home page (large images = large HTML response = higher TTFB even before rendering).
  • Check for slow DB queries (Query Monitor plugin will show them per request).
  • Check for outbound API calls in the home-page render path (weather widgets, currency converters, third-party embeds).
  • If none of the above: escalate to your host with the TTFB numbers. Might be shared-hosting neighbor-noise or server-config issues.

security_status shows a risky flag

  • wp_debug_enabled: true in production: set define('WP_DEBUG', false); in wp-config.php (leave WP_DEBUG_LOG on if you want log-only debugging).
  • wp_debug_display: true: set define('WP_DEBUG_DISPLAY', false); in wp-config.php. Never expose PHP errors to visitors.
  • disallow_file_edit: false: add define('DISALLOW_FILE_EDIT', true); to wp-config.php. Prevents in-admin theme/plugin file edits.
  • is_ssl: false: your site is on plain HTTP. Get an SSL cert (Let's Encrypt is free via most hosts), install it, update WP address settings to https://, add a permanent redirect.

Common scenarios

Staging-to-production flip

Run the composer on staging first to establish a healthy baseline, then run again immediately after flipping DNS or migrating to prod. Compare the two reports — any step that was ok on staging and now shows error on prod is your first diagnostic target.

Monthly agency health check across 20+ client sites

Same composer call on each site. Log the response to a shared spreadsheet (TTFB numbers over time are especially valuable — a slow-creeping upward TTFB trend catches degradation before customers complain).

Pre-content-push safety net

Big content push planned for tomorrow morning? Run this the night before. Any red flag caught now is easier to fix than firefighting during peak-traffic launch hour.

Post-plugin-update regression scan

Update WordPress core + a batch of plugins → run this composer. If TTFB spiked or a security flag flipped from safe to risky, you know which update batch caused it. Rollback is easier when you know what changed and when.

Still Stuck? Two-Step Support Path

If the composer isn't running the steps you expected, work through these two steps in order.

Step 1: Start with the Royal MCP Troubleshooting Guide

Royal MCP Troubleshooting — Start Here covers MCP-layer issues.

For Pro-specific patterns:

Step 2: Email priority support

If you've worked through Start Here and the relevant Pro-specific doc and the composer still isn't working, email priority support from your purchase email address at support@royalplugins.com. Priority email support is included with your license — typical response within 24 hours. Never include your license key in email; we look it up from your purchase address.

What to include in your email
  • Your hosting provider
  • Royal MCP Pro version
  • Which sibling Royal Plugins are active — SiteVault, ForgeCache, GuardPress, SEObolt + version numbers (the composer routes through these when available)
  • Which MCP client
  • The full steps array from the response including status, message, and data for each step
  • Whether re-running the composer produces the same result or if it's intermittent (TTFB and broken-link scans are especially variable)
  • Screenshot of the Pro tool row in Audit Log with View Details expanded
← Bulk Price Updates + Undo SEO Audit → Fix → Report →