Choosing what to check

What is scanned by default

Posts and pages. That is the whole list.

Why not templates, patterns and custom post types

Because none of them is a page a visitor can open.

A pattern’s problems are already found on the pages the pattern appears in. Scanning it separately means finding the same fault twice, counting it twice, and asking you to fix it twice. The same goes for page-builder template libraries, which are full of markup nobody will ever serve.

Earlier versions did offer them, and the result was inflated totals and a lot of noise. Scanning covers posts and pages, and the numbers mean more for it.

Adding your own post types

If you have a custom post type that genuinely is a public page — a product, a case study, a documentation entry — add it with a filter:

add_filter( 'wsak_post_types', function ( array $types ): array {
    $types[] = 'product';
    $types[] = 'docs';

    return $types;
} );

Two related filters exist for narrower control:

Filter	What it controls
wsak_post_types	The post types the plugin knows about
wsak_scannable_post_types	Which of those may be scanned
wsak_column_post_types	Which list screens get the Accessibility column

Only types the current user is allowed to edit are ever offered, including from the command line. Adding a type with a filter does not grant anybody access to it.

The Accessibility column

Posts and Pages list screens gain an Accessibility column showing what is already known about each entry, so you can see at a glance which pages have been checked and which have outstanding findings.

Page builders

Elementor and similar builders store a stripped text copy of the page in post_content that bears little resemblance to what is rendered. On one real Elementor page, the stored copy was 3,808 bytes of bare headings against 69,503 bytes of actual page.

The plugin asks the builder for the real output rather than trusting post_content. If you have a builder that needs special handling, the wsak_builder_content filter is where to do it.