| 开发者 | rankth |
|---|---|
| 更新时间 | 2026年6月8日 17:32 |
| PHP版本: | 7.4 及以上 |
| WordPress版本: | 7.0 |
| 版权: | GPLv2 or later |
| 版权网址: | 版权信息 |
VIS-A7K9-XB).agentic-seo-visibility folder to the /wp-content/plugins/ directory, or install through the WordPress Plugins screen.No. Pairing produces a shared site token that the plugin uses — no WordPress user password is involved at any point, and you don't need to enable Application Passwords in your WP user profile.
Yes, when you allow it. Each Visibility agent has an "Allow publishing" toggle in the Visibility dashboard. With it on, the agent publishes posts directly. With it off (the default), every save is forced to draft so a human reviews and publishes manually.
Yes — that's the default behaviour. Without the "Allow publishing" toggle, every post the AI agent creates or updates is saved as a WordPress draft. You publish manually from wp-admin when you're satisfied with the content.
Through the plugin's REST surface (/wp-json/visibility/v1/*), AI agents can list, create, update, and delete posts; manage categories and tags; upload media and set featured images; and read site health info (post counts, WP version, timezone). Nothing outside that — no theme files, no user accounts, no general WordPress settings.
No. The plugin adds a small set of authenticated REST endpoints that only respond when called by Visibility, plus one cron heartbeat that runs once a day. There's no extra JavaScript or CSS on the public side of your site and no background polling.
Yes. Posts created by AI agents go through WordPress's standard post-save flow, so SEO-plugin meta boxes, structured-data / schema generation, and XML sitemap entries populate the same way they do for posts you write by hand. You can configure agents on the Visibility side to populate Yoast / Rank Math / AIOSEO fields directly via post meta.
Yes. Each subsite pairs independently with its own Visibility project. Network-activate the plugin or activate it per subsite; the pairing flow runs at the subsite level.
Each WordPress site pairs with one Visibility project at a time. Disconnect from Agentic SEO → Connection and re-pair when you need to move the site to a different project.
Pairing codes are valid for 10 minutes and are single-use. If yours times out, click Generate a new code in your Visibility project to mint another one — there's no penalty and the old code is discarded automatically.
On pairing and once a day for heartbeats, the plugin sends your site URL, site name, WordPress version, and the installed plugin version. Post content only travels when one of your AI agents creates or updates a post in WordPress — and that always originates from a Visibility project you control. See the External services section below for the precise endpoint list.
Deactivate it from the Plugins screen, then delete. On deactivation the daily heartbeat cron is unscheduled; on delete the pairing token (visibility_site_token) and cached company / project names are removed from wp_options. Your data in your Visibility project is untouched — disconnect from this plugin before deleting if you also want Visibility to forget about this site.
WordPress 6.0 or newer and PHP 7.4 or newer. Tested up to WordPress 7.0.
agentic-seo-visibility)
so translations load correctly and the WordPress.org plugin scanner
passes. The plugin's display name is unchanged./wp-json/visibility/v1/events/*. The Visibility server pushes
approved actions straight here (with their full payload), so
changes show up in WordPress within seconds of approval instead
of waiting on the 5-minute WP-Cron tick.events/action-approved -- executes a single approved action.events/drain-inbox -- bulk catch-up.events/site-config-changed -- mirrors the allow_publish /
disabled flags so admin banners stay accurate without polling.Plugin URI and Author URI headers — they were both
pointing at https://app.visibility.so which the WordPress.org
Plugin Checker flags (the two URIs must describe different things:
the plugin product vs. the publisher). Plugin URI stays at the
product page; Author URI now points at the publisher site at
https://visibility.so.Tags line with more specific search terms
(agentic seo, ai content, ai writer, content automation, seo).?visibility_status=...&visibility_msg=...)
are now nonce-protected, so a crafted URL can no longer inject a spoofed
admin notice into the Settings page.wp_die(__(...)) upgraded to wp_die(esc_html__(...)) on the
permission-denied paths.esc_url() (variables were already escape-on-assign — this is the
belt-and-braces "escape late" pattern WP coding standards prefer).parse_url() → wp_parse_url() and
@unlink($tmp) → wp_delete_file($tmp) (use the WordPress wrappers
so filter hooks run and the filesystem op doesn't silent-fail).readme.txt Tested up to: 6.9.agentic-seo-for-visibility), text domain, and Settings submenu
("Agentic SEO") updated to follow WordPress.org plugin-directory naming
guidance for plugins that integrate with a named external service.
Internal REST namespace, option keys, and cron action names are
unchanged so pre-release test installs continue to work after update.readme.txt now includes an External services section listing
every outbound network call the plugin makes (pair, heartbeat,
disconnect), what is sent, and explaining that a Visibility account is
required.Cache-Control: private, no-store, no-cache headers
on every /visibility/v1/* response so page caches (LiteSpeed, WP Rocket,
Cloudflare, etc.) can't serve a stale unauthenticated body to a different
caller. Earlier versions relied on WP's default headers, which LiteSpeed
was overriding.modified field returning a zero date ("-001-11-30T00:00:00+00:00")
for freshly created posts where post_modified_gmt hadn't been normalised
yet. Falls back to current GMT time when the stored value is empty/zero.editUrl (wp-admin link) so the
agent + user have something they can open even when the post is a draft
(drafts return 404 to anonymous visitors, which is normal WP behaviour).