PlugUpp Search & Social Appearance Audit: SERP Preview, OG Preview and AI Readiness

No. The plugin audits what your site actually outputs – whichever SEO plugin, theme or page builder produces it. It does not manage or change your metadata.

No. It audits only your known WordPress content. It never follows links or discovers URLs like a crawler.

Yes, in every plan. After a scan, a “Site: AI access and robots.txt” row shows which AI crawlers the major providers document – OpenAI, Anthropic, Perplexity and Google – with whether your robots.txt allows or blocks each one, the matching robots.txt lines as evidence, and what the provider documents that rule as controlling. It reports documented vendor policy, never a guarantee about behaviour, and there are no AI visibility scores. The free plugin also warns you when robots.txt is served with a status that makes its rules ineffective; the findings that interpret crawler rules and page directives are a paid feature.

Free audits all your pages and posts on demand, with the Search, Social and Findings views, the AI access panel and no scan limits. Paid plans add automation – scheduled scans and email reports – plus AI readiness findings, Enhanced scan, custom post type and WooCommerce auditing, pre-publish auditing, filtering and CSV export, author flagging, and multi-site licensing. See the full plan comparison and pricing .

Because the directive is being sent as an X-Robots-Tag HTTP response header instead of a tag in the page. A header is exactly as binding as a tag – search engines obey it either way – but you cannot see it by viewing source. From version 1.6.0 the audit reads both, shows the header line as the evidence, and, when the directive is only in the header, says so on the finding. Look in your server or host configuration, your CDN rules, or a security or SEO plugin that sets headers.

Usually because the featured image is in a format social platforms do not display, such as an SVG, and the SEO plugin left og:image out rather than publish an image the platforms would reject. The page looks correct in the editor and shares with no image at all. The audit names the attachment and its format on the finding and tells you what to use instead: a JPEG, PNG, GIF or WebP featured image, or a social image set explicitly. If the page does share an image but it is not your featured one, because something else supplied it – a generated share image, or your SEO plugin’s site-wide default – the audit says that too, as a notice: the page shares correctly, it just does not share your image.

No, and the plugin never says it does. Google states that the number and order of headings on a page are not something to focus on, and that a page can rank perfectly well with no H1 or with several. What the audit reports is structural: the HTML standard says a document with headings should have one at level 1 and requires each heading to be at most one level deeper than the one before it, Google lists H1 elements among the things it uses to build the title link it shows in a search result, and screen reader users move around a page by its headings. That is why a missing H1 is a warning and the other two are notices. None of them is an accessibility compliance failure either: no accessibility success criterion requires an H1 or forbids a skipped level, and the accessibility tools that check headings treat both as best practice rather than as violations.

Because heading problems usually live in a template, not in the pages built from it. When the same finding covers at least three pages and most of one content type, a notice above the results names it, for example “No H1 heading on 30 of 30 Venues”. Fixing the template clears every one of those pages at once, so that line is usually the shortest route through a long list. The counts are worked out fresh each time you look, so they always match the rows underneath.

Because a page set to noindex cannot appear in a search result, so a point about how it would look there describes something that will never be shown. Findings like meta description length, a missing canonical or a hidden search thumbnail are listed as notices on those pages, with a line on each one saying why. They are still listed and still counted in the page’s finding total, so nothing is hidden – they just stop being counted as problems, and a page whose only remaining points are notices reads as OK. Social findings are not affected: a noindexed page shared in a chat still shows a link preview, so its Open Graph findings keep their full severity.

Because “Discourage search engines from indexing this site” is switched on under Settings > Reading. WordPress then adds a noindex tag to every page, so no page on the site can appear in search results. That is intentional on a staging or holding site. If the site is live, clear the setting under Settings > Reading and re-scan. Social sharing is unaffected either way – link previews still work.

No. Private and password-protected content is excluded automatically. Search engines and social platforms can never see it – a crawler or a social share preview only ever reaches a login screen, a password form, or a not-found response. Auditing how such pages appear would be meaningless, so they are left out of every scan, count and report. Make a page public (or remove its password) and it is picked up on the next scan.