Visibility – Lightweight SEO, AEO and GEO for Search and AI

FAQ

Is Visibility an alternative to Yoast, Rank Math, All in One SEO or SEOPress?

For most sites, yes. Visibility covers what 90% of sites actually need: titles, meta descriptions, canonical URLs, Open Graph, schema, robots directives, redirect management and sitemap control — and it imports your per-post data from those plugins in one click. It does not include keyword analysis or content scoring. If you don’t need those, Visibility is a much lighter alternative. If you do, stick with your current SEO plugin — Visibility isn’t meant to run alongside.

How do I migrate from another SEO plugin?

Install and activate Visibility. If data from Yoast SEO, Rank Math, All in One SEO, SEOPress, The SEO Framework, Slim SEO or SureRank exists in your database (the suite can be active or already deactivated), the Tools tab shows an import card with a per-field breakdown: titles, meta descriptions and robots overrides on posts and on taxonomy terms, plus canonical URLs, Open Graph images, social titles and descriptions, the default social image, the per-content-type schema type and the webmaster tools verification codes. Your existing 301, 302, 307 and 410 redirects come over too, from Rank Math, All in One SEO, SEOPress and the Redirection plugin. One click copies it all into Visibility without touching the source plugin, skipping anything you already set here and any value built from the suite’s template variables (%%title%%, %title%, #post_title, {{ title }}) — Visibility generates those from your real content. Each suite imports what it actually stores; the per-field breakdown always shows exactly what was found before you import, and the import is non-destructive and idempotent: your existing Visibility values win and re-running never duplicates. Review a few entries, then deactivate the suite. Old sitemap URLs (sitemap.xml, post-sitemap.xml…) keep working through a 301 redirect to the native /wp-sitemap.xml.

I used Native SEO Meta Tags, NoIndexer or Sitemap Customizer. How do I migrate?

Install and activate Visibility. If it finds data from any of those plugins, the Tools tab shows an import card with a per-plugin breakdown and an “Import now” button (and Overview points you there). The import is non-destructive (it copies, never deletes) and your existing Visibility values win on any conflict, so you can run it safely. Once you’ve imported and checked everything, deactivate the old plugins.

Is Visibility free? Is there a Pro version?

It is free, and there is no Pro version, no add-ons, no credit packs and no upsell banners in your admin. Everything described on this page is in the plugin you just downloaded, including the redirect manager, the one-click importers, the WooCommerce URL structures and the AI discovery files, which several SEO suites keep behind a paid tier. There is nothing to buy, no account to create and no key to paste. That is a deliberate product decision, not a launch promotion: the plugin has no premium tier to protect, so nothing in it is deliberately limited to sell you the next step.

Will Visibility slow down my site?

It is built not to. Visibility is about 277 KB, adds no database tables, schedules no cron jobs and makes no external HTTP calls, with one documented exception: a cached lookup that checks whether an author has a public Gravatar, the same one WordPress already performs for comment avatars. Settings live in a single autoloaded option and per-content values use native post, term and user meta, which WordPress already keeps in the object cache. Most of the actual work is done by core APIs (wp_robots, wp_sitemaps_*, register_post_meta, get_canonical_url), not by private reimplementations, so it is code the platform already runs and has already optimized. The “Performance and security” section above publishes the real numbers for each release, refreshed on every update.

Does Visibility track me or send my data anywhere?

No. There is no telemetry, no usage analytics, no “improve the plugin” opt-in, no account and no server of ours that your site talks to. Visibility never phones home, and deactivating it does not notify anyone. The single outbound request it can make is the cached Gravatar check described in “External services” above, which sends a hash of the author email and never the address itself, so an author avatar can be included in Open Graph and Person schema. Everything else happens inside your WordPress install.

Are there any database tables?

No. Visibility stores its settings in a single WordPress option and uses native post, term and user meta tables for per-content overrides. Deleting the plugin removes the option; per-content overrides remain so reinstalling does not lose your work.

Can I disable individual modules?

Yes. The Overview tab lets you toggle Discover (meta tags), Indexing (robots), Sitemaps and Redirects independently. You can run only what you need.

What are AEO and GEO, and does Visibility do them?

AEO (answer engine optimization) and GEO (generative engine optimization) are two names for the same goal: being findable, understandable and citable by AI assistants such as ChatGPT, Perplexity, Claude and Google’s AI answers, not only by a classic results page. In practice it is less exotic than the acronyms suggest. What the published evidence actually correlates with getting cited is content freshness (pages updated in the last month are cited noticeably more often), verifiable author expertise, and question-and-answer structure that is genuinely visible on the page. Visibility works on those three: a freshness filter and a sortable Last updated column on your content lists, author expertise fields that feed Person schema, and FAQPage built from Q&A you have actually published. What no plugin can do, including this one, is promise you a citation.

How does Visibility help with AI (AEO / GEO)?

It emits the signals AI search and assistants can read about your site: Site Identity JSON-LD (who is behind it), llms.txt and llms-full.txt (a Markdown index of your content, with taxonomy sections and WooCommerce-aware data), a clean Markdown version of every page at its .md URL, and a robots.txt editor to allow or block AI crawlers by name. No plugin can guarantee a citation, but Visibility makes your content easy for AI systems to find, read and attribute, and these are served on the fly with no extra files or cron. The companion plugin VigIA can then measure which AI crawlers actually visit.

Does Visibility generate llms.txt and a Markdown version of my pages?

Yes, both, and neither one writes a file to your server. /llms.txt is a Markdown index of your site for language models, with sections per content type and taxonomy and WooCommerce-aware entries, and /llms-full.txt is the long form. Every entry also answers at its own .md URL, so an agent following a link gets clean Markdown instead of a full HTML page. All of it is generated on the fly from your real content: no files written, no cron job, nothing to regenerate when you publish. An honest note on expectations, because this gets sold louder than the evidence supports: llms.txt is a proposed convention, not a standard. Adoption is still low, Google has said it ignores it, and no major AI vendor has confirmed support. Including it costs you nothing and positions you if that changes, but it is not what will get you cited. Freshness, author expertise and clear structure are.

Does Visibility add schema markup and structured data?

Yes, as a single JSON-LD graph rather than a pile of separate blocks: the Article family with a selectable type per content type (BlogPosting, NewsArticle and the rest), BreadcrumbList, Person including author expertise fields, FAQPage built from your Details and Accordion blocks, and Site Identity (Organization and WebSite) on the home page, with per-post and per-term overrides for all of it. What is deliberately missing is a visual builder for rich types such as Recipe, Product, Event or HowTo. Those need properties your content does not hold in structured form (ingredients, prices, dates, steps), and adding the type without its required properties generates errors in Search Console, which is worse than not adding it at all. The plugins that own that data already handle it: WooCommerce adds Product, recipe plugins add Recipe, event plugins add Event.

Does Visibility control the XML sitemap?

It customizes the sitemap WordPress already generates at /wp-sitemap.xml instead of building a second one alongside it, which is why there is no cache to clear and nothing to rebuild. You can exclude whole post types and taxonomies, individual posts and terms by ID or slug, and users by role; control lastmod dates; and set the maximum number of URLs per sitemap. Anything set to noindex stays out automatically, so the two modules can never contradict each other, and you can also exclude something from the sitemap while leaving it indexable. Arriving from another SEO plugin, its old sitemap URLs (sitemap.xml, post-sitemap.xml and the rest) are 301-redirected to the native one, so nothing search engines already know about breaks.

My sitemap looks fine in the browser but Google says it could not be read. Why?

Because it is answering with a 404 status while showing you the right file, and Google discards any sitemap that does not answer 200. It happens on any site with no published entries of the Posts type: a shop, a campus, a portfolio, a site of services and pages. WordPress decides the 404 before the sitemap is rendered, and on an ordinary blog what keeps it away is only that the query behind the page happened to find entries, which has nothing to do with the sitemap being served. Publish one post and it goes away; delete it and it comes back. Pages, products and courses make no difference. The suites never run into this because they serve their sitemap from their own address with their own header, leaving the native one broken. Visibility answers /wp-sitemap.xml with a 200, with a switch for it in the Sitemaps tab. Sitemaps that genuinely have nothing behind them still answer 404, which is the honest status for them, and so does every other address on the site.

My old sitemap URLs redirect to a page that does not exist. What is wrong?

Something on the site has switched off the sitemap WordPress generates, and that is what the old addresses point at. WordPress keeps those URLs routed even when the feature is off, so that /wp-sitemap.xml can answer a clean 404 instead of a broken page, and a redirect sent there lands on that 404. Two causes account for nearly all of it: a snippet filtering wp_sitemaps_enabled to false, left in a child theme or in Code Snippets by a migration tutorial and still running long after the plugin it was written for is gone, and another SEO plugin serving sitemaps of its own, which switches the native one off and redirects the native addresses to its own while Visibility redirects them back, so the two end up in a loop. Visibility checks before redirecting and leaves the old address alone, so it answers a plain 404 rather than a redirect to one. To get the sitemap itself back, look for that filter in functions.php and in your snippets plugin, and check that “Discourage search engines from indexing this site” is unticked in Settings > Reading, which switches the sitemap off as well.

Does Visibility manage redirects? Do I need .htaccess or a separate plugin?

Redirects are included and you need neither. The Redirects module handles 301, 302, 307 and 410 responses, resolved in PHP with no .htaccess editing, no server configuration and no custom database table. It imports and exports CSV, offers you a redirect for any post you delete so the URL does not become a 404, and lets you take over or remove the slug-change redirects WordPress creates silently on its own. One thing it does not do, on purpose: log every 404 your site receives. That needs a dedicated table and a scheduled cleanup job, which is the kind of weight this plugin exists to avoid. If you want that view, the companion plugin VigIA already records the 404s that crawlers run into.

Does Visibility work with Elementor, Divi and other page builders?

Yes. The Visibility panel appears in the Block Editor sidebar and, on any screen where a builder replaces the block editor, as a matching meta box on the classic editing screen, so you get the same title, description, social, schema and robots controls whichever editor your builder leaves in place. Elementor gets one extra piece of handling worth knowing about: it keeps its layout in post meta and substitutes the content at render time, so the stored post content is close to empty. Visibility renders the Elementor document when it builds the Markdown version of a page, which means AI agents reading your .md URL get the real text instead of a blank page.

Does Visibility work with WooCommerce?

Yes, and it treats a shop as a first-class case rather than an afterthought. Products, product categories, tags and attributes are covered like any other content for titles, descriptions, social tags, schema and robots rules; the product gallery image is part of the og:image fallback chain; and the llms.txt index is WooCommerce-aware. It also fixes product URLs in ways WooCommerce blocks on its own permalinks screen, which has its own answer below. What Visibility does not add is Product schema: WooCommerce already generates it with the price, stock and review data it owns, and a second copy would only contradict the first.

Does it work with custom post types and custom taxonomies?

Yes. All public post types and taxonomies are supported — including WooCommerce product categories, tags and attributes (the latter requires “Enable Archives?” in the WooCommerce attribute settings).

Can I preview how my page will look on Google, social networks and AI answers?

Yes. The Visibility panel — in the Block Editor sidebar and in the Classic Editor meta box — includes a live preview with three views: your Google result snippet, your shared social card and an AI Overview citing your page. It updates as you type, following the exact fallback chains the plugin emits (post title, excerpt, featured image, site fallbacks). It is an honest render of what goes into your HTML, not a score: the final appearance always depends on each platform.

How do I set noindex on a single post?

In the Block Editor, open the Visibility panel in the post sidebar and tick the noindex toggle. In the Classic Editor, the same toggle is in the Visibility meta box. You can also use Quick Edit or Bulk Actions from the post list.

Does my robots.txt always work, even on a subdirectory install?

Yes, and this is an SEO safeguard worth knowing about. WordPress only serves its virtual /robots.txt on root installs once the rewrite rules have been flushed; on a subdirectory install, or when the rules go stale, /robots.txt can return a 404 while the same directives still answer at /?robots=1 — so crawlers asking for the canonical /robots.txt get nothing. Visibility takes ownership of the endpoint: it serves /robots.txt itself when there is no physical file (independent of the rewrite rules, so it works on any install), and when another plugin writes a physical robots.txt that the web server would serve instead, it merges its own directives into that file in a BEGIN/END block, leaving every other block untouched, so its rules prevail there too. It also 301-redirects WordPress’s internal /?robots=1 to /robots.txt. The result is a single canonical /robots.txt that always loads your AI-crawler and indexing rules, even behind a static file.

Does Visibility work on WordPress Multisite?

Yes, and each site keeps its own rules. Every site in the network has its own Visibility settings, so on a subdomain or mapped-domain network each one serves its own /robots.txt and /llms.txt from its own directives, with nothing to wire up by hand — something WordPress does not do on its own and most SEO plugins leave as a single global file. This matters because a physical robots.txt or llms.txt in the site root is one file shared by the whole install: Visibility writes it only where it genuinely belongs — a single-site install, or the main site of a subdirectory network — so one site can never overwrite another’s rules, and everywhere else the always-served virtual endpoints answer per site. On a subdirectory network (every site under one domain) the robots.txt standard allows only one file at the domain root, owned by the main site, and the Discover tab makes that clear wherever the physical-file option does not apply. Activate Visibility per site or network-activate it; either way, no site clobbers another.

There is one case that used to have no way out: a physical robots.txt already sitting in the network root. The web server hands that one file to crawlers before WordPress runs, so every site in the network answers with the same rules and no plugin can override a static file the server sends first. The Discover tab offers a way past it on Apache and LiteSpeed: one button adds a single rewrite to the .htaccess, in its own BEGIN/END block, that routes /robots.txt into WordPress even though the file exists. Every host then answers with its own directives and its own Sitemap: line, and the physical file is left untouched on disk. Nothing is written without the click, removing it puts the .htaccess back exactly as it was, and only a network administrator sees the button, because the .htaccess belongs to the whole network. On nginx there is no equivalent a plugin can perform, so the screen says so plainly and hands you the directive for whoever administers the server.

Where does Visibility store per-post overrides?

In standard WordPress post meta (_native_aeo_pack_* keys). Term overrides go to term meta, user social URLs to user meta. Nothing leaves the standard WordPress tables.

Can I copy my configuration to another site?

Yes. The Tools tab exports every Visibility setting plus the per-entry and per-term values (meta titles and descriptions, canonical URLs, social overrides, schema types, robots flags) as a single JSON file, and imports it back on another site. Content is matched by slug, not by database ID, so it works between sites that were never clones: staging to production, or a starter configuration across several sites. On import you choose whether the file only fills in what is empty (the default, safe on a site that already has its own values) or replaces what is there. Everything goes through the same validation as the settings screen, only known keys are read, and nothing is ever created: values land on content that already exists, and the result tells you how many entries were not found. Redirects are not in the file because they have their own CSV export on the Redirects tab, and author profile fields stay out because they belong to each user account.

How do I know which content has gone stale?

Content freshness is the AEO signal with the strongest evidence behind it: pages updated in the last month get cited noticeably more often by AI assistants. With the threshold set in the Discover tab (90 days by default), your content lists get a “Not updated in 90 days” filter link with a count, and a sortable Last updated column. That is all it does: no score, no traffic light, no “SEO health” number, because which article deserves a rewrite is an editorial call. Set the threshold to 0 to leave your list tables untouched.

Can I clean up my WooCommerce URLs?

Yes, including the parts WooCommerce itself refuses to do. In the Indexing tab you can remove the base of each taxonomy independently, so a store can drop /product-category/, /product-tag/ and /brand/ while keeping /category/ on its blog, which the single toggle of earlier versions did not allow. And you can choose a product URL structure WooCommerce blocks on its own permalinks screen: the product slug alone (/my-product/), the category and the slug (/t-shirts/my-product/), or the full category path (/clothing/t-shirts/my-product/). WooCommerce puts the /product/ base back whenever you empty it and forces a base in front of a category structure, which is why those three need a plugin.

Old URLs are 301-redirected to the new ones, and so is any other combination that still resolves (a leftover base, a category the product no longer belongs to), so a product never ends up reachable at two URLs. The redirects are included: no premium tier for them. If you are running Premmerce Permalink Manager, Visibility detects it, tells you in the Indexing tab that both plugins are rewriting the same URLs, and takes precedence (its filters run last). Import its structure from the Tools tab first, check your product URLs, and then you can deactivate it, premium included. Two honest notes. Whatever already exists at a path wins, so a page or a term keeps its URL and the product stays on the one WooCommerce gave it. And a base-less taxonomy URL costs one rewrite rule per term, five counting feeds and pagination, so the settings screen tells you how many rules your selection adds before you commit to it: fine for a blog or a normal shop, worth a thought on a store with thousands of attribute terms.

Does Visibility generate FAQ structured data?

Yes, from the content you already have. Switch on JSON-LD: FAQPage in the Discover tab and Visibility reads the native Details and Accordion blocks in your entries, taking the question from the block heading and the answer from its content, and emits FAQPage in the same JSON-LD block as the rest of the schema. There is no separate builder or duplicate fields to fill in, so the markup can only ever describe Q&A that is genuinely visible on the page. It is off by default on purpose: a Details block is not always a question (“Show technical details”), and describing something that is not a FAQ is worse than not describing it. Honest expectation: this helps AI assistants pick up your Q&A structure. It does not bring back Google’s FAQ rich results, which were retired in 2023.

Is there an API for plugins and themes?

Yes, and it stays stable. Read the robots state Visibility resolved with Native_AEO_Pack_Frontend_Robots::is_noindex( $post_id ), is_nofollow( $post_id ), is_term_noindex( $term_id, $taxonomy ) and is_term_nofollow( $term_id, $taxonomy ); read any setting with Native_AEO_Pack_Settings::get( $group, $key, $default ); and check the AI-crawler rules with Native_AEO_Pack_Settings::is_robots_ai_blocking() and get_robots_ai_agents(), which is how the companion plugin VigIA reads them.

To change what is emitted, four filters:

• native_aeo_pack_schema_graph ($graph, $context, $object) — the JSON-LD nodes before they are printed. $context is article, person or identity. Add, edit or drop nodes; return an empty array to print nothing.
• native_aeo_pack_meta_description ($description) — the resolved description, after the whole fallback chain. It feeds the meta tag, og:description, the Twitter card, the Article node and the preview alike.
• native_aeo_pack_og_image ($image, $post) — the image chosen for a singular, after the per-post, featured, WooCommerce, inline and site-fallback chain.
• native_aeo_pack_schema_faq_pairs ($pairs, $post) — the question/answer pairs read from the blocks, before they become FAQPage. Return an empty array to skip it on a page where Details blocks are not questions.