Axle Staging Guard

Yes, for plugins that send through WordPress's own wp_mail() function, which is most of them. A few plugins replace wp_mail() entirely. Axle Staging Guard detects this and shows a warning on its settings screen, because it cannot intercept those emails.

No. Blocked emails are reported to WordPress as sent, so forms and password resets behave normally. Use redirect mode if you need to receive them.

The production lock is still stored, and the live domain still matches it, so the live site stays unguarded. The search engine setting under Settings > Reading is never changed by this plugin.

Use the axle_staging_guard_environment filter. It receives an array with type (production, staging, development or local) and source.

Then the production lock no longer matches, and the live site would count as staging. Axle Staging Guard warns about this on every admin screen and in Site Health, so it does not go unnoticed. Lock the new domain from Tools > Staging Guard, or list every live domain in AXLE_STAGING_GUARD_PRODUCTION_HOSTS so a move never trips it. www. and the bare domain already count as the same.

The list of outgoing requests holds none: no query strings, bodies or headers, and parts of a path that look like email addresses, hashes or keys are hidden. The email log keeps who an email was for and its subject, and the message only if you turn that on. Entries are deleted after 7 days, and the email log is part of the WordPress export and erase personal data tools. The live site keeps no log.

It blocks hosts, not modes. api.stripe.com and api.paypal.com are the same host whether the key is a test key or a live one, so in "Block all except allowed hosts" both are blocked until you allow them. Allow the sandbox host you want to test against (for example sandbox.paypal.com), or allow api.stripe.com only when the copy has test keys. Not sure which hosts a plugin calls? Use "Log only" for a day and read the list.

Add it under Tools > Staging Guard > "Calls to other services" > Allowed hosts, one per line. api.example.com allows that host, and *.example.com allows every subdomain (but not example.com itself). You can also set AXLE_STAGING_GUARD_HTTP_ALLOWED_HOSTS in wp-config.php, or use the axle_staging_guard_http_allowed_hosts filter. "Test a URL" on the same screen shows whether an address would get through.

No. On the live site requests are never blocked, changed or recorded, whatever the settings say, and there is no list.

No. Sites that already use the plugin keep "Allow all" for outgoing requests, so nothing changes until you choose. A fresh install starts on "Log only", which lets everything through and records it, so you can see what the site calls before you start blocking. Site Health reminds you while a staging copy allows all calls.

A failed request, like a network error: the WordPress HTTP API returns a WP_Error with the code axle_staging_guard_http_blocked. It is never reported as a success.

Code that does not go through the WordPress HTTP API: a PHP SDK that opens its own cURL connection, file_get_contents() on a URL, and anything the visitor's browser sends (analytics scripts, embeds). Server-side requests from WordPress and from plugins that use wp_remote_get() and friends are covered.