Three checks that resolve most problems
Loopback requests
Open Tools → Site Health and look for a loopback failure. If the server cannot reach its own hostname, most markup checks cannot run and you will see “the site could not be crawled”.
Caching
If a fix looks like it did nothing, clear your page cache and CDN and check again in a private window. Caching layers serve stored HTML that predates the change.
Stale report
A finding that persists after a fix usually means the report predates it. Re-run the audit - the cached copy of your markup is discarded whenever a fix is applied.
What to include
The more of this you provide, the faster a problem can be reproduced. All of it is visible from inside your own admin.
Environment
- WordPress version, PHP version and plugin version
- Active theme, and whether it is a block theme
- Whether WooCommerce is active, and its version
- Your host, and whether the site is local, staging or live
- Any caching, firewall or security plugin in use
Most of this is on one screen under Tools → Site Health → Info, which has a Copy site info to clipboard button.
The problem
- Which category or fix is involved, by its exact name
- What you expected, and what happened instead
- The exact wording of any error or notice
- Whether it happens every time or intermittently
- A screenshot of the finding, expanded
Never include passwords, API keys or database credentials in a support request.
Capturing a debug log safely
Log to a file rather than the screen, so nothing leaks to visitors. Add this
to wp-config.php above the
/* That's all, stop editing! */ line:
define( 'WP_DEBUG', true );
define( 'WP_DEBUG_LOG', true );
define( 'WP_DEBUG_DISPLAY', false ); // Keep errors off the front end.
@ini_set( 'display_errors', 0 );
Reproduce the problem, then collect
wp-content/debug.log. Remove these lines when you are finished -
the security category will flag debug exposure if you leave them enabled.
Debug logs frequently contain file paths and occasionally query contents. Skim before sharing, and redact anything site-specific.
What support can and cannot cover
In scope
- A check reporting something demonstrably incorrect
- A fix that does not do what its description says
- PHP errors, warnings or fatals from the plugin
- Audits that never complete, or complete with missing categories
- Questions about what a finding means or how a fix behaves
Out of scope
- Implementing the recommendations for you - the plugin tells you what to change; making theme or server changes is your call
- Malware removal or incident response - this is not a malware scanner
- Recovering data after a one-off action; restore from your backup
- Server, host or CDN configuration
- Ranking outcomes. The plugin fixes technical faults; it does not promise positions
Support forum
Questions and bug reports go to the support forum on WordPress.org: wordpress.org/support/plugin/klydexa-website-audit. Search the existing threads first - a problem reported once is often already answered there. Posting requires a free WordPress.org account.
Check the FAQ first
Fourteen of the most common questions - privacy, whether fixes can break a site, batching, staging sites - are already answered there.