VigIA – AI Visibility, Analytics & Control vs Alpaca Bot

Alpaca Bot is a chat screen inside WordPress admin, talking to a model you host. Conversations stay on your site, in your own database, and only their author can open them. It runs against Ollama out of the box, or any OpenAI-compatible endpoint. Features A chat screen in wp-admin: replies stream in as they are written, with a copy button on every message and code block, “Edit and resend” on your own, and an image attached from the media library for a model that can see. Your conversations, stored privately on your site (or not at all: the Privacy tab decides) and listed in the screen’s history. Switch models per conversation; where the site allows it, your pick is remembered as your default. A system prompt, per-model overrides (temperature, context window, keep-alive) and a receipt under every reply: model, tokens, time. Monthly usage caps, per site and per user, with the meter behind them. A REST API under alpaca-bot/v1 (docs/api.md) and a WP-CLI command. Requirements PHP 8.4+, WordPress 6.9+, an Ollama instance (or any provider php-agents supports) Setup Install Ollama on your localhost or server. In your WordPress admin, open Alpaca Bot > Settings and, on the Provider tab, enter the endpoint’s base URL. For Ollama it ends in /v1: http://localhost:11434/v1. Click Save Changes. The Models tab then lists what the provider serves; pick a default. ⭐️ Become a Patreon and support Alpaca Bot development. ⭐️ Usage The chat screen Click Alpaca Bot in the admin menu, below Dashboard and above Posts. The screen is open to every user who can edit posts (filter alpaca_bot/admin/menu_capability to change that). The model select in the header picks the model for this conversation; where the site allows it, your pick is saved as your default. The history select opens one of your earlier conversations, and New chat starts a fresh one. Type in the box at the foot of the screen. Enter sends, Shift+Enter adds a line, Escape clears the box. The image button attaches a picture from the media library to your next message, for a model that can see. The largest image the screen takes is set by the site’s PHP post_max_size, not its upload limit: the image travels inside the message, not as an upload. Replies stream in as they are written. Every message has a Copy button, your own have Edit and resend, and a code block has its own copy button. Under a reply is its receipt: the model, the tokens it used and how long it took. The Help tab at the top right of the screen repeats this, and documents the shortcodes. Settings Alpaca Bot > Settings (administrators) is one page in six tabs: **Provider** (the endpoint, its key, the timeout), **Models** (the default, temperature, context window, keep-alive, and per-model overrides), **Chat** (system prompt, welcome text, what users may change), **Privacy** (whether conversations and the usage log are stored, and for how long), **Limits** (monthly token caps for the site and per user) and **Tools** (what the model may do besides answer — read the next section before you leave those as they come). Every field is also readable and writable over the REST API (`GET`/`PUT /settings`). Tools, and what they let the model reach Settings > Tools switches the model's tools on and off. Three ship, **all three on by default**: `web_fetch` reads one public web page as text, `summarize` condenses text through the model, and `draft_post` writes a draft. Read this section before you leave `web_fetch` on, and before you open the chat to a role. web_fetch makes the web server send a request, and hands the reply back. Every URL is checked twice before the fetch — WordPress’s own wp_http_validate_url(), then the plugin’s own check over every address the name resolves to, on the first URL and on every redirect — and http(s) only, ports 80/443/8080 only, no private, loopback, link-local or other special-purpose address. What no check of that shape can cover is a name whose answer changes between the check and the connection: each is a separate DNS lookup, so a host under someone else’s control, with a short TTL, can answer the checks with a public address and the connection with 127.0.0.1 or a cloud metadata address. The response body then comes back as text. Closing that means pinning the resolved address into the transport, which is a compatibility project and is planned for a later 0.x release. Who can reach it, today, with no model involved: anyone who can edit posts — a Contributor included, since core grants Contributors edit_posts — can put [alpacabot_agent name="get" url="…"] in their own draft and preview it. So treat web_fetch as a capability you are granting your authors, not as something only the model uses. An egress policy is the supported mitigation, and it is the one that holds for every plugin on the site at once: stop the web server’s host from opening outbound connections to your private ranges and to 169.254.169.254, at the network or the host firewall. On a cloud instance, require IMDSv2. If you cannot do that and do not need the tool, leave web_fetch off — the chat, the drafts and the summaries all work without it. Opening a route to a role opens the tools to that role too. alpaca_bot/capability/chat (and chat/stream) can name any capability, read and exist included, and that is deliberate — it is how a site builds a subscriber-facing or public chat. But the toolkits a turn may call are chosen by the toolkits.enabled setting alone: there is no second capability check between a role that may chat and the tools that are switched on. So a role you admit only to converse gets web_fetch with it. Only draft_post checks a capability of its own (edit_posts/edit_pages) and refuses a role that lacks it. Until a later 0.x release adds a floor of its own, use the alpaca_bot/toolkits filter to take web_fetch away from the users you are opening the chat to: add_filter( 'alpaca_bot/toolkits', function ( array $toolkits, int $user_id ): array { if ( ! user_can( $user_id, 'edit_posts' ) ) { unset( $toolkits['web_fetch'] ); } return $toolkits; }, 10, 2 ); REST API and WP-CLI Everything the screen does is a route under alpaca-bot/v1: a turn (POST /chat, then its stream as server-sent events), conversations, models, settings and usage. docs/api.md is the reference, with authentication, streaming and error examples. From the command line, wp alpaca-bot chat|models|usage|settings does the same. Shortcodes Both 0.4 shortcodes are back on the new pipeline. Both are for logged-in users who can edit posts (edit_posts); anyone else sees a notice. [alpacabot prompt="…"] Puts the model’s answer to the prompt in a post or page. prompt — The message sent to the model. Without it, the shortcode is the chat screen (below). model — the viewing editor’s model — The model, where the site lets users change it (Settings › Chat); it must be one the provider lists. Without it, the answer runs on the model the editor who first views the page would chat on (their own preference where the site lets users change it, else the site’s default), and the cache does not record which. system — the site’s system prompt — The system prompt for this answer. temperature — the model’s setting — The temperature for this answer, 0 to 2. format — markdown — markdown renders the answer (raw HTML stripped, links kept); text shows it as plain, escaped text. cache — 1h — How long the answer is kept: a number with a unit (45s, 30m, 1h, 2d), a year at most. off generates on every view. Anything else keeps the default. Generating an answer costs provider tokens and counts against the monthly cap of the user viewing the page, so it is cached (a transient, per shortcode, per post and per cache duration) and served from the cache until it expires. Two identical shortcodes on two pages are two answers; changing the site’s system prompt starts a new answer, changing its default model does not (the model is part of the answer’s identity only when the shortcode names one). When a turn fails, the page shows why in the words the chat uses (the cap, a model the provider does not list, or a fixed “could not complete” message: the provider’s own error, which quotes its endpoint, goes to the debug log under WP_DEBUG), and nothing is cached. The block editor and the REST API never generate. content.rendered carries the cached answer, or a notice when there is none; an answer is generated only when the page is viewed on the site. So a client listing a hundred posts over the API spends nothing, and the editor’s preview shows what the cache holds. A generation counts against the same per-minute limit as the chat. Thirty a minute per user, shared with the chat screen, the REST routes and the abilities, and moved everywhere at once by the alpaca_bot/rate_limit filter (bucket chat). A cached answer costs nothing; a page carrying more shortcodes than the minute allows shows the rest as a “Too many requests” notice, caches nothing for them, and fills them in on a view after the minute turns over. Anyone who can write a post can write a prompt. A Contributor can put a prompt, and a system prompt, in a draft; once it is published, the first user with edit_posts to view the page generates the answer, the tokens count against that viewer’s cap, and the answer is on the page for everyone without anyone having read it first. The markdown is sanitised (no scripts, no raw HTML), but links and images the model writes reach the public page. Review a page after its answer appears. A per-site capability setting for this belongs to the admin-wide panel of a later 0.x release. A visitor never triggers a generation. A visitor, or a logged-in user who cannot edit posts, sees a notice in place of the answer. A site that wants visitors to see the answer returns true from the alpaca_bot/shortcode/allow_guests filter ((bool $allow, int $postId, string $tag)); they then see the cached answer and nothing else. When the cache has expired, visitors see the notice again until someone who can edit posts opens the page. That is the point: a page nobody with the capability opens spends nothing, whatever the model costs. add_filter('alpaca_bot/shortcode/allow_guests', '__return_true'); [alpacabot] With no prompt, the chat screen on a page, for logged-in users who can edit posts, with the same bundle and stylesheet as in wp-admin (a front-end design of its own is a later 0.x release). A visitor sees a login notice and loads nothing. The REST API and the block editor show a notice in its place, as for a prompt. The screen’s markup carries the viewing user’s REST nonce, as it does in wp-admin; it is useless without their cookies, but a full-page cache set to cache pages for logged-in users would store one editor’s page and serve it to another, so leave a page carrying the shell out of such a cache. [alpacabot_agent name="get|summarize" url="…" length="…"] (deprecated) The 0.4 form still works, under the same rules and cache: get shows the page’s readable text, summarize fetches it and asks the model for a summary (length is free text, “2 sentences”; model and cache as above). The fetch is the chat’s web_fetch tool itself, so it runs only while that tool is on under Settings › Tools, and through the same address guard: a private, local or non-http(s) address is refused. It logs a deprecation notice once per request under WP_DEBUG and goes away in a later 0.x release. Put the text to summarize in a prompt instead, or open the URL in the chat, where the fetch and summarize tools read it for you: [alpacabot prompt="Summarize https://…"] would not work, since a shortcode’s turn runs no tools and the model cannot open the URL. Support Questions and bug reports go to the WordPress.org support forum. Say which plugin, WordPress and PHP versions you run. For premium support, book a call: video calls, help setting up your Ollama instance or provider, troubleshooting, and onsite setup assistance. If the plugin has been useful, star Alpaca Bot on GitHub; a star helps other site owners find it. Made Possible By Emma Delaney’s How to Create Your Own ChatGPT in HTML CSS and JavaScript Lucide Beautiful & consistent icons – ISC license htmx High power tools for HTML – 0BSD license league/commonmark Markdown parser for PHP – BSD-3-Clause license php-agents Provider-agnostic AI agents for PHP – MIT license Ollama Get up and running with large language models locally – MIT license

VigIA (Spanish for “lookout” or “watchman”, incorporating “IA” – Spanish for “AI”) is a complete AI visibility toolkit for WordPress. Monitor 60+ AI crawlers, control access to your content, and optimize how AI systems discover and understand your site. What does VigIA do? Scores your AI visibility with a 100-point analyzer covering 20 checks across 5 categories Tracks AI crawlers visiting your site (GPTBot, ClaudeBot, PerplexityBot, and 60+ others) Provides detailed analytics with advanced filters, server-side pagination, and exportable reports with metadata banner Blocks unwanted crawlers via PHP (403 response) Manages robots.txt rules for AI crawlers with compliance monitoring Sends email alerts about crawler activity (daily, weekly, or monthly) Generates llms.txt files to help AI systems understand your site Serves markdown endpoints for posts, pages, taxonomy archives (categories, tags, WooCommerce product categories, custom taxonomies) and WooCommerce products with schema-like data Generates JSON-LD structured data with Site Identity and AI Discovery signals Exposes abilities for AI agents and automation tools (WordPress 6.9+) Key Features AI Visibility Analyzer * 100-point scoring system with letter grades (A+ to F) * 20 individual checks across 5 categories * Access & AI Discovery (37 pts): robots.txt, AI bot directives, Content Signals, llms.txt, sitemap, RSS feed * Structured Data & Semantic Context (25 pts): JSON-LD schemas, Open Graph, Twitter Cards, meta description, canonical URL * Content Structure & Readability (20 pts): heading hierarchy, semantic HTML5, image alt text, content/HTML ratio * AI Interaction & Distribution (8 pts): markdown delivery, AI share buttons * Access Performance (10 pts): TTFB measurement * Smart recommendations with direct links to VigIA features and plugin suggestions * Analyze any page on your site with URL autocomplete selector * Results cached for 24 hours with manual re-analyze option Analytics Dashboard * Total visits, unique crawlers, and pages crawled statistics * Timeline chart with daily breakdown * Category distribution (AI Training, AI Search, AI Assistant, Data Scraper) * Top crawlers and most crawled pages tables with paginated navigation * Share Buttons & AI-powered Summaries integration: see share button clicks per page * Recent activity log with content type and HTTP status columns (color coded by status family) * Advanced filters: multi-select crawler picker, content type, HTTP status code, and configurable date range * Server-side pagination with four-button pager (first, previous, next, last) — operates over the full database, not just the latest 500 rows * Period comparison functionality * CSV export with a metadata banner (site name, site URL, export type, date range, export timestamp, applied filters) * “Export filtered CSV” button that downloads exactly what the active filters return, with vigia-filtered-YYYY-MM-DD.csv filename * Content type detection distinguishes Home, Post, Page, Product, custom CPTs, Category archive, Tag archive, Date/Author archive, Feed, Sitemap, REST API, File, Admin / login attempts (/wp-admin, /wp-login.php), WordPress system (admin-ajax, xmlrpc, wp-cron, wp-comments-post), 404 Not found, and Other Crawler Blocking * Block crawlers via PHP with 403 Forbidden response * Quick block dropdown in analytics dashboard * Manage blocks from Extras page * Works on any server (Apache, Nginx, LiteSpeed, etc.) Robots.txt Management * Add Disallow rules for AI crawlers * Visual preview of your robots.txt * Compliance monitoring: see which crawlers ignore your rules * One-click blocking for non-compliant crawlers * Works with both physical and virtual robots.txt Email Alerts * Daily, weekly, or monthly reports * Three detail levels: Minimal, Normal, Complete * Non-compliant crawler warnings * Activity comparison with previous period Markdown for Agents * Serve posts, pages and any public post type as optimized markdown for AI agents * Serve taxonomy archive pages (categories, tags, WooCommerce product categories, custom taxonomies) as markdown — disabled by default, opt in per taxonomy * Dedicated .md URL endpoints (e.g., /your-post.md, /category/news.md, /product-category/electronics.md) * Accept: text/markdown content negotiation on posts and taxonomy archive pages * Discoverability via Link HTTP headers and HTML tags * YAML frontmatter for posts: title, date, modified, author, image, categories, tags, post type, lang * YAML frontmatter for taxonomy terms: title, description, url, type, taxonomy, parent, count, image (term meta), lang * WooCommerce product frontmatter adds schema-like fields: sku, product_type, price, regular_price, sale_price, currency, availability, stock_quantity, rating, rating_count, review_count * Taxonomy term body includes the term description (rendered through the_content), the list of direct child terms in hierarchical taxonomies, and an excerpt of the latest posts/products assigned to the term * Product listings inside product_cat archives include an inline summary with formatted price, “was X” on sale items, star rating and out-of-stock flag * Respects blocking rules (blocked crawlers get 403) and LLMs.txt exclusion filters * Per-term noindex detection from Yoast SEO, Rank Math, All in One SEO and SEOPress * Analytics integration: tracks markdown requests per crawler * X-Markdown-Tokens response header * Filters: vigia_markdown_post_eligible, vigia_markdown_term_eligible, vigia_markdown_term_posts_limit * Follows the Cloudflare Markdown for Agents standard LLMs.txt Generator * Select content by post type with one click * Filter by taxonomies (categories, tags, custom) * Manual include/exclude with AJAX search * Exclude by URL patterns (wildcards supported) * SEO plugin integration (auto-exclude noindex content) * Auto-regeneration (daily, weekly, monthly) * Robots.txt integration (add llms.txt and llms-full.txt references) * Generate llms.txt and llms-full.txt files * Full content or excerpt mode * Compatible with Yoast SEO, Rank Math, All in One SEO, SEOPress, The SEO Framework, and Native SEO NoIndexer JSON-LD Structured Data * Generate WebSite and Organization/Person schema for site identity * AI Discovery: ReadAction pointers to llms.txt, llms-full.txt, and Markdown for Agents endpoints * Social profiles and sameAs links for brand identity across the web * SearchAction for Google sitelinks search box * Media library integration for logo selection * SEO plugin conflict detection (Yoast, Rank Math, AIOSEO, SEOPress, The SEO Framework) * Choose output page (front page or any published page) * Live JSON-LD preview with real-time updates * Smart integration with LLMs.txt and Markdown for Agents features Supported AI Crawlers VigIA monitors 60+ AI crawlers including: OpenAI: GPTBot, OAI-SearchBot, OAI-AdsBot, ChatGPT-User Anthropic: ClaudeBot, Claude-SearchBot, Claude-User, Claude-Code Google: Google-Extended, GoogleOther, Gemini-Deep-Research, Google-NotebookLM Perplexity: PerplexityBot, Perplexity-User Meta: Meta-ExternalAgent, FacebookBot, Meta-WebIndexer Amazon: Amazonbot, Amzn-SearchBot, bedrockbot Mistral: MistralAI-User, MistralAI-Index Microsoft: BingBot ByteDance: Bytespider Apple: Applebot-Extended And many more… Privacy Focused VigIA stores visitor data locally in your WordPress database. No data is sent to external servers. Abilities API VigIA is one of the first WordPress plugins to implement the Abilities API introduced in WordPress 6.9. This API allows AI agents, automation tools, and external systems to discover and interact with VigIA’s functionality in a standardized, secure way. What are Abilities? Abilities are self-contained units of functionality that VigIA exposes through WordPress’s central registry. Each ability has defined inputs, outputs, and permissions, making it easy for automation tools to understand and use them. Available Abilities VigIA registers the following abilities: Analytics vigia/get-crawler-stats – Get statistics about AI crawler visits (total visits, unique crawlers, pages crawled) vigia/get-top-crawlers – Get a ranked list of most active AI crawlers vigia/get-top-pages – Get the most crawled pages on your site Blocking vigia/get-blocked-items – List all blocked crawlers and IP addresses vigia/block-crawler – Block a crawler by User-Agent pattern vigia/unblock-crawler – Remove an existing block Robots.txt vigia/get-robots-rules – Get current AI crawler rules in robots.txt vigia/add-robots-disallow – Add a Disallow directive for a crawler vigia/remove-robots-rule – Remove a robots.txt rule Use Cases Automated monitoring: AI agents can query crawler statistics and alert you to anomalies Reactive blocking: Automation tools can block crawlers that repeatedly ignore robots.txt External dashboards: Aggregate data from multiple WordPress sites with VigIA installed WP-CLI integration: Future command-line access through the Abilities API n8n / Make workflows: Build custom automation flows using VigIA’s abilities Requirements The Abilities API ships with WordPress 6.9 and later. On older WordPress versions, VigIA works normally but abilities and MCP are not available. MCP Server (Model Context Protocol) VigIA exposes its 9 abilities as native MCP tools to any MCP-compatible client (Claude Code, Cursor, Claude Desktop, Codex CLI, Antigravity, Continue, Cline, Zed and similar) using the official WordPress MCP Adapter. The adapter ships bundled with the plugin, so the MCP endpoint is active right after installation — no Composer step or terminal access required. Requirements WordPress 6.9 or later (provides the Abilities API) Quick connect (recommended) Open VigIA > Extras > MCP and click “Generate password and connection commands”. The plugin creates a dedicated Application Password named VigIA MCP and renders ready-to-paste commands for Claude Code, Cursor, Claude Desktop and a generic block (URL + Authorization header) for any other MCP client. The plain password is shown only once. If you lose it, revoke the entry from the same panel and generate a new one. Endpoint https://your-site.example/wp-json/vigia/v1/mcp The endpoint uses HTTP Basic auth with the WordPress Application Password. The user must have the manage_options capability. Connecting Claude Code Quick Connect builds the full command for you. The shape is: claude mcp add --transport http vigia https://your-site.example/wp-json/vigia/v1/mcp --header "Authorization: Basic BASE64_OF_USER_AND_APP_PASSWORD" Claude Code merges the new entry into its config file automatically — no risk of breaking other servers. Connecting Cursor Save the JSON block from Quick Connect as ~/.cursor/mcp.json. You can also reach this file from inside Cursor at Settings → Cursor Settings → MCP. If the file already exists with other content, see the FAQ. Claude Desktop and other clients Claude Desktop does not speak HTTP MCP, so it needs a small bridge and a config file of its own. Any other client (Codex CLI, Continue, Cline, Antigravity, Zed, or your own) takes the two raw values Quick Connect exposes: the server URL and the Authorization header. Both cases are covered in the FAQ, together with how to merge VigIA into a config file that already exists without losing what is in it. Read-only mode If you only want your AI to consult VigIA (not change anything), enable “Read-only mode” in the MCP tab. While on, write actions (block, unblock, robots changes) return a permission denied error. Read actions (statistics, top crawlers, blocked items, robots rules) keep working. The toggle stores a vigia_mcp_read_only option that hooks into the vigia_can_write_via_abilities filter. Developers can still force read-only from a mu-plugin: add_filter( 'vigia_can_write_via_abilities', '__return_false' ); The mu-plugin filter at the default priority takes precedence over the toggle. Who can reach the endpoint The endpoint requires the capability to manage options, the same one every tool behind it already asked for. The vigia_mcp_transport_capability filter can lower that bar; each tool keeps its own permission check. After connecting Restart your MCP client after adding the server so it picks up the new tools. Then try a few prompts to confirm everything is wired up: “Show me VigIA crawler stats for the last 7 days.” “List the top 5 most crawled pages on this site.” “Add a robots.txt Disallow rule for TestBot and then list the current AI crawler rules.” The third example exercises a read + write + read round-trip, which is the most complete sanity check. Support Need private support or custom development? Do you need one-on-one help, priority troubleshooting, or a custom feature, integration, or tweak built specifically for your site? I offer private support and custom development. Just contact me and tell me what you need. Need help or have suggestions? Official website WordPress support forum YouTube channel Documentation and tutorials Love the plugin? Please leave us a 5-star review and help spread the word! About AyudaWP We are specialists in WordPress security, SEO, AI and performance optimization plugins. We create tools that solve real problems for WordPress site owners while maintaining the highest coding standards and accessibility requirements.