Troubleshooting

“The server cannot reach itself”

The server pass fetches your page over HTTP, from your own server. Some hosts block that, which is called a loopback failure.

Symptoms. Scans return little or nothing, or the plugin tells you it fell back to stored content.

What to do. Ask your host to allow loopback requests. They are a standard WordPress requirement, used by the built-in cron and the site health screen too.

On staging with a self-signed certificate, the request may fail on the certificate rather than the connection:

add_filter( 'wsak_page_source_sslverify', '__return_false' );

Staging only.

To override the verdict entirely, if you know loopback works and the detection disagrees:

add_filter( 'wsak_loopback_works', '__return_true' );

A fix applied but nothing changed

Almost always specificity. Your theme or page builder styles the same element with a more specific rule, so the fix is present and losing.

The plugin re-measures after applying a style rule and tells you when this has happened, rather than reporting success. Suggested rules are weighted to outrank what is already there, but nothing can outrank a declaration marked !important, and in that case the plugin says so.

What to do. Fix it in the theme, or remove the !important that is blocking it.

A page builder’s content looks wrong

Builders like Elementor store a stripped text copy in post_content that is not what gets rendered. The plugin asks the builder for the real output.

If you use a builder it does not recognise, point it at the rendered output:

add_filter( 'wsak_builder_content', function ( string $html, int $post_id ): string {
    return my_builder_render( $post_id ) ?: $html;
}, 10, 2 );

The counts dropped after an update

Nothing was hidden. Earlier versions counted every scan of a page separately, so a page scanned ten times contributed ten copies of each finding. Only the most recent scan of each page is counted now.

Your dismissals are preserved through that change.

The score disagrees with the list

You are probably looking at a page where the server pass has finished and the browser pass has not. Let both complete.

On a site that cannot make requests to itself, this could previously show “0 issues” above a list of issues. That is fixed, but if you see anything like it, check loopback first.

A big scan never seems to finish

Whole-site scans run in the background through Action Scheduler. If they stall, the usual cause is WordPress cron not running — common on sites where DISABLE_WP_CRON is set without a real system cron replacing it.

Check Tools → Site Health for scheduled event failures.

Templates and patterns are missing from the list

Intentional. Scanning covers posts and pages, because nothing else is a page a visitor can open, and a pattern’s problems are already found on the pages it appears in. Add a genuinely public custom post type with wsak_post_types. See Choosing what to check.

Findings keep coming back after I dismissed them

This was a real bug in versions before 0.29.0, where a dismissal was stored against the scan record rather than the finding, so the next scan reinstated it. Update, and existing dismissals will be preserved as part of the upgrade.

Still stuck

Open an issue on GitHub with your WordPress and PHP versions, your theme, and what you expected to happen. Or tell us directly.