Skip to main content

Troubleshooting

A page is missing from the audit​

The most common reasons:

  • It is private or password-protected. These are excluded on purpose - search engines and social platforms can never see them. Make the page public, or remove its password, and it is picked up on the next scan.
  • It is a custom post type or WooCommerce product. The free plugin audits pages and posts; custom post types and products are added by the paid plans.
  • It is excluded from the audit. Re-include it from the Exclusions screen (Manual Exclusions tab), or from the Posts / Pages screen. On paid plans, check whether an exclusion rule matches it.

An archive page is missing from the audit​

The audit covers the blog home / posts page, category, tag and custom taxonomy term archives, and monthly date archives, when the Audit archive pages setting is on. Three kinds are deliberately left out: custom post type archives, author archives, and pagination pages such as /page/2/ (page 1 carries the appearance metadata that matters).

A scan reports an error on some pages​

The plugin audits a page by requesting it on your own server. On some configurations behind aggressive Cloudflare bot protection this self-request can be challenged. The plugin retries and falls back to a direct local fetch; if that also fails it reports an actionable error for those items rather than silently skipping them. A temporary error (such as a timeout) is retried later in the same scan, which helps on shared hosting.

A scheduled scan ran later than the time I set (paid)​

On standard shared hosting, WordPress background tasks run on site visits, so a scan scheduled for 09:00 starts on the first visit after 09:00. On low-traffic sites this can be noticeably later. A server-side cron calling wp-cron.php removes the delay but is never required.

The email report didn't arrive (paid)​

Reports are sent with WordPress's standard mail function. On hosts without proper mail configuration, messages may be delayed, spam-foldered or dropped. An SMTP plugin is recommended for reliable delivery. Send failures are recorded in the plugin log (Settings > Logs).

The "Likely Fallback" image is wrong (paid)​

When a page has no Open Graph image, Enhanced scan predicts which image a platform might use. Social platforms choose fallback images by their own undocumented rules, so this is guidance, not a guarantee.

A search thumbnail looks different to what Google shows​

The Search Appearance thumbnail is indicative. On mobile results Google chooses its own image and may show a different one, or none. Pages with max-image-preview:none correctly show no thumbnail.

"Discourage search engines from indexing this site" is switched on under Settings > Reading. With it on, WordPress adds a noindex tag to every page, so none of them can appear in search results. This is right on a staging or holding site, and it is one of the most common things left behind when a live site is copied from one.

If the site is live: clear that checkbox under Settings > Reading, save, and re-scan. The finding clears on the next scan of the Site checks row. Social sharing is unaffected either way - link previews still work while the setting is on.

Because it affects everything, this finding also appears in the site-wide notice at the top of the dashboard.

My issue and warning counts dropped, and pages show notices instead​

This is expected from version 1.4.0 on pages that carry noindex. A page set to noindex cannot appear in a search result, so findings about how it would look in one - meta description length, a missing canonical, a hidden search thumbnail - are listed as notices rather than issues or warnings, each with a line saying why. Nothing is removed: they are all still listed and still counted in the page's finding total.

Two things to check if the drop surprises you:

  • Is the whole site noindexed? See the entry above - one setting can noindex every page at once.
  • Did you mean those pages to be noindexed? The Indexable / noindex flag on each card tells you. If a page should be in search results, remove the noindex (usually in your SEO plugin, sometimes in the theme) and re-scan: its search findings return to their normal severity.

Stored severities are rewritten when a page is scanned, so the change appears page by page as your next scan runs, not retrospectively across old results.

Every page of one type has the same heading finding​

That is the expected shape of a heading problem: it is in the template, not in the pages. When a heading finding covers at least three pages and most of one content type, a notice above the results says so, naming the finding and the type it covers with a link straight to those rows. Fix the heading level in that template and re-scan, and all of those rows clear together. Working through them page by page fixes nothing that the template will not undo on the next page you build.

A heading finding points at a heading I cannot see​

The audit reads the HTML your page produces; it cannot apply your stylesheet. A heading hidden with CSS, collapsed into an accordion, or positioned off screen for screen readers is still in the document, so it is counted like any other and can be what makes a level look like it jumps. Open the finding and read the heading outline it shows as evidence - the extra heading is usually recognisable straight away as menu, footer or hidden-panel text. This is why the hierarchy findings are notices rather than warnings.

A heading finding says it measured the whole page​

The heading order is normally read from the page's main content area, so that a header repeated on every page does not dominate the result. Some themes do not mark a main content area at all, and when none of them contains headings the audit reads the whole page instead and says so on the finding:

Measured across the whole page: this theme exposes no main-content landmark, so headings in the header and footer are included.

When you see that line, the jump being reported may be between a heading in your content and one in your header or footer. The H1 count is always taken across the whole page, deliberately: sliders, hero sections and similar plugins often render the page's headline outside the main content area, and an H1 there is still the page's H1.

I fixed a heading and the finding is still listed​

Findings are worked out while a page is scanned and stored with that page, so a row shows the state it was last scanned in. Use Re-scan on the row to re-audit it on the spot, or run a full scan after fixing a template. The same applies after an update that changes how something is classified: the new behaviour appears page by page as each page is next scanned.

The AI access panel says my robots.txt could not be read​

The panel is built from your robots.txt as it is served over your public URL, because that is the version an outside crawler sees - including any rules your CDN injects at the edge. If that request fails or the server answers with an error, the plugin says it could not read the file rather than guess from a view that might be wrong, and the paid AI findings are held back for that scan. Open https://your-site/robots.txt in a browser: if it errors there too, the problem is on the server or in front of it, and fixing that fixes the panel.

The Site row warns that my robots.txt rules are ineffective​

Your robots.txt is answering with HTTP 404 (or 410) while still returning rules in the body. Crawlers treat a missing robots.txt as no restrictions at all, so every rule delivered with a "not found" status does nothing - for search engines and AI crawlers alike. Anything you believe you have blocked is not blocked. The fix is on the server or in whatever generates the file: robots.txt should return HTTP 200.

This warning is in every plan, because a file that cannot work is a plain misconfiguration rather than an AI question.

The Site row warns about my favicon​

The audit reads your rendered homepage and looks for the icon links browsers and crawlers use (rel="icon" and its variants). "Missing favicon" means none were declared AND the classic /favicon.ico location answered nothing; "Favicon URL does not resolve" means an icon is declared but its address returns an error. Either way search results and link previews fall back to a generic placeholder. The fix is usually one setting: add a Site Icon under Appearance > Customize > Site Identity, then Re-scan the Site checks row.

"Favicon is not a crawlable file" is a third case, and a less obvious one. Some themes and plugins declare the icon inline, as a data: URI, instead of pointing at a file. Browsers display it, so the site looks fine to you, but Google states that Googlebot-Image must be able to crawl the favicon file and lists the formats it accepts (BMP, GIF, ICO, PNG, JPEG, PPM and TIFF). An inline icon is none of those, so Google falls back to the generic placeholder. You only see this warning when there is also no /favicon.ico to fall back on. The fix is the same Site Icon setting, which serves the icon as a real file.

AI results do not match what I set at my CDN or SEO plugin​

Four things sit outside what any audit run from inside your own site can see, or can tell apart:

  • Vendor compliance is documented policy, not proven behaviour. The panel and the findings say "documented to honor" for exactly that reason. One public dispute exists - Cloudflare reported undeclared Perplexity crawlers in 2025, which Perplexity disputes - and the plugin takes no side.
  • Google's Search Console opt-out for AI features leaves no on-page signal. A site can be opted out of AI Overviews with nothing in the HTML or robots.txt to show it.
  • CDN and firewall bot rules are upstream of robots.txt. A crawler can be turned away before your site is asked. When a known CDN is detected, the audit says so as an advisory (paid) rather than claiming to know that CDN's policy.
  • A robots directive aimed at one named crawler is not told apart from a site-wide one. From version 1.6.0 the per-page checks read X-Robots-Tag response headers as well as the page's meta tags, and a header that names a crawler (googlebot: noindex) is counted as a noindex, because the page is noindexed for that crawler. The audit does not report which crawler was named, but the whole header is on the evidence line so you can see it.

Crawler token lists change, and the providers revise them. The list the audit uses is re-checked against each vendor's documentation at every release that touches this feature.

A page is reported as noindex but there is no noindex in the page​

The directive is being sent as an X-Robots-Tag HTTP response header rather than as a tag in the page. Search engines obey a header exactly as they obey a tag, but a header does not appear when you view the page source, so this one is easy to miss and hard to find.

From version 1.6.0 the audit reads both. When the noindex comes only from a header, the finding says so ("The directive is sent as an X-Robots-Tag response header, not a meta tag, so it does not appear in the page HTML") and the headers themselves are on the evidence lines. To read it, go to the Search Appearance tab and click the Notices badge on that page's preview card - a noindex is a notice, so it is not behind the Issues badge, and the Robots flag beside it reports the directives as a fact rather than explaining them. The usual places to look are your server or host configuration, your CDN rules, and any security or SEO plugin that can set response headers.

If a page reported as indexable before this version and reports as noindex now, nothing changed on your site - the audit can now see a directive that was always being sent. Stored results are rewritten when a page is next scanned, so this appears page by page as your next scan runs. Use Re-scan on a row to see it immediately.

A page has a featured image but the social image is reported as missing​

The most likely cause is the format. Social platforms display JPEG, PNG, GIF and WebP; they do not display SVG or AVIF. When a page's featured image is one of those, some SEO plugins leave og:image out altogether rather than publish an image the platforms would reject, so the page looks correct in the editor and shares with no image at all.

The audit names it: the finding carries the attachment number, its format and its filename, and tells you to use a JPEG, PNG, GIF or WebP featured image or to set a social image explicitly. Replace the image and Re-scan the row to confirm.

Two cases where you will see the plain "No og:image is defined" message with no cause attached: the featured image is a perfectly good JPEG or PNG (so the tag is missing for some other reason), and your SEO plugin has its own social image chosen for that page. The audit reads the featured image, not another plugin's per-page choice, so it says nothing rather than guessing.

A related case gets its own finding rather than this one: the page shares, but not with your image. If the featured image is in one of those formats and something else supplied the social image - a share image generated for you, or your SEO plugin's site-wide default - you get the notice Featured image is not the shared image instead. Nothing is broken there, which is why it is only a notice; it tells you the page is sharing a stand-in, and on a site with a default social image that is the same picture as every other page in the same position. Swap the featured image for a JPEG, PNG, GIF or WebP and Re-scan the row to put the page's own image back on its shares.

A social image is declared but shares still show no image​

Check the finding OG image format not displayed by social platforms. It means the og:image URL answers with a real image, but in a format the platforms do not render - an SVG or an AVIF. The served content type is on the evidence line. Point og:image at a JPEG, PNG, GIF or WebP instead.

"Possible sources" lists a plugin or theme I'm not sure about​

Source identification is informational - it offers clues about what produced a piece of metadata (an SEO plugin, the theme, and so on), never a definitive attribution.