Scayla<\/a>, a cloud service that measures whether AI assistants actually name your store when a shopper asks what to buy, and then acts on what it measured.<\/p>\n\nThe queries it measures are not generic keywords typed into a box. They are derived from a scan of your own catalogue \u2014 real product titles, product types and categories \u2014 which is why they reach the level of a specific product or category. When a gap is found, the service turns it into a change on your site through this plugin, then measures the same fixed query set again the following week.<\/p>\n\n
Every SEO value written is read back from the source your site will actually serve before the write is reported as successful. That is why a separate connector exists. Since Yoast SEO 14, Yoast does not serve SEO meta from post meta; it serves it from its own wp_yoast_indexable<\/code> table. A tool that calls update_post_meta( $id, '_yoast_wpseo_title', ... )<\/code> gets a successful database write, a 200 response, and a front end that keeps serving the old title indefinitely. This plugin writes, reconciles the indexable, re-reads from the serving source, compares, and on any mismatch returns a hard scayla_write_not_verified<\/code> error carrying the expected value, the actual value and which storage layer answered.<\/p>\n\nYoast SEO and Rank Math \u2014 the two SEO plugins this connector writes through \u2014 both ship AI-visibility tracking of their own, and track it well, at brand level. Scayla is the other shape of the same problem: catalogue-derived queries, a write path back into the exact product or category that caused the gap, and verification on every write. Scayla is not the only vendor that both measures and writes back, and this plugin does not claim to be.<\/p>\n\n
Hebrew and RTL.<\/strong> Redirect paths never pass through sanitize_text_field()<\/code>, which strips every percent-encoded octet and would silently turn an encoded Hebrew slug into a live 301 to the wrong page; the plugin uses its own percent-safe sanitiser. FAQ content renders as a native <details><\/code> \/ <summary><\/code> accordion with no JavaScript and no stylesheet, so it inherits your theme's RTL direction. Hebrew content analysis is not claimed as a differentiator \u2014 Yoast and Rank Math both support Hebrew already.<\/p>\n\nWhat the plugin does on your site<\/strong><\/p>\n\n\n- Pairs with your Scayla account through WordPress's own Application Password approval screen (or a manually created Application Password), used once, then operates through a dedicated
scayla-connector<\/code> service user with a narrow, revocable token.<\/li>\n- Bridges SEO title and meta description writes to Yoast SEO or Rank Math, with mandatory read-back verification on every write. With no SEO plugin active it stores and renders those values itself.<\/li>\n
- Renders FAQ structured data as a single FAQPage node merged into Yoast's schema graph, or into Rank Math's JSON-LD, or as its own script tag when neither is present. The three paths are mutually exclusive, so an FAQPage is never rendered twice.<\/li>\n
- Writes category and tag descriptions through a dedicated endpoint, because WordPress core registers
wp_filter_kses<\/code> on pre_term_description<\/code> unconditionally and silently strips div<\/code>, h2<\/code>, p<\/code>, details<\/code> and summary<\/code> while returning a 200. The plugin does not detach core's filter; it runs its own allowlist and outranks core, so nothing else on the site loses kses protection.<\/li>\n- Manages a redirects table for dead URLs, with guards against self-redirects, two-step loops, cross-host targets, and the protected prefixes
\/wp-admin<\/code>, \/wp-json<\/code>, \/wp-login.php<\/code>, \/wp-content<\/code> and the site root.<\/li>\n- Adds a Scayla<\/strong> admin menu. Before connecting it holds the Connect page. Once connected it holds the Scayla screens (Home, Competitors & AI visibility, Deep analysis, Content, Keywords, Products, Collections, Fixes, Rankings, Links, Strategy, Weekly report and Settings), shown inside wp-admin the way an app sits inside a store's admin, and a native Connection<\/strong> page with the connection status, detected SEO plugin, redirect and FAQ counts, and a Disconnect button.<\/li>\n<\/ul>\n\n
How it is built.<\/strong> Plain, readable PHP: seven classes plus the main file and uninstall.php<\/code>, and one short, unminified admin script (admin\/js\/scayla-app.js<\/code>) that runs only on the Scayla screens. No build step and no minified or obfuscated code. The plugin loads no script, stylesheet, font or image from a remote server into your WordPress pages: the Scayla screens are a page served by the Scayla service and displayed in a frame, where they run in their own origin and cannot read the admin page around them. Nothing is compiled, so what you read in the plugin folder is exactly what runs.<\/p>\n\nNothing in the plugin is gated.<\/strong> No premium tier inside this code, no license check, no feature flag, no nag, no upsell that unlocks a function. Every capability above works in full without paying anything. Paid limits exist only in the Scayla cloud service, and they limit how much work the service does, not what the plugin may do.<\/p>\n\nExternal services<\/h3>\n\n
This plugin is a connector for Scayla, a third-party cloud service operated by Scayla (https:\/\/scayla.co.il\/). A Scayla account is required.<\/strong> Without one the plugin has nothing to talk to: it will pair with nothing, receive no writes, and do nothing useful.<\/p>\n\nThe plugin makes no outbound requests.<\/strong> It contains no wp_remote_*<\/code>, curl_*<\/code>, file_get_contents<\/code> or fsockopen<\/code> call anywhere in its code. It never contacts Scayla, on any schedule or on any event, including deactivation. The Connect to Scayla<\/strong> button is an ordinary link, and the Scayla screens are a frame: in both cases it is your browser that talks to Scayla, and the plugin sends nothing. Scayla's servers call your site's REST API and authenticate with the paired token, and data leaves your site only inside the response to one of those authenticated requests, or inside the short-lived ticket described below.<\/p>\n\nWhat leaves your site, and when:<\/strong><\/p>\n\n\n- When you pair.<\/strong> Clicking Connect to Scayla<\/strong> takes your browser to Scayla (
https:\/\/wp-api.scayla.co.il\/connect\/start<\/code>) with your site address and admin language in the link. Scayla reads your site's public REST index (GET \/wp-json\/<\/code>) to confirm this plugin is active and to find your approval screen, then sends your browser to that screen on your own site (\/wp-admin\/authorize-application.php<\/code>). If you approve, WordPress creates an Application Password named Scayla and sends your browser to Scayla with it (\/connect\/authorized<\/code>). Scayla uses it for one authenticated POST \/wp-json\/scayla\/v1\/pair<\/code>, then deletes it: GET \/wp-json\/wp\/v2\/users\/me\/application-passwords\/introspect<\/code> identifies that one password and DELETE \/wp-json\/wp\/v2\/users\/me\/application-passwords\/{uuid}<\/code> removes it, leaving any other Application Passwords untouched. Your browser is then sent back to the Scayla menu in your admin. If you decline, WordPress sends you straight back to that menu and nothing is created. (Connecting manually instead, you paste an Application Password into the portal and revoke it yourself afterwards.) The pairing response carries your site address and REST API address, your WordPress and WooCommerce version numbers, your permalink structure, which SEO plugin was detected, the login name of the service user just created, and \u2014 once only, in this one response \u2014 the API token your site mints for Scayla to authenticate with from then on. Your site keeps only a SHA-256 hash of that token.<\/li>\n- While the service operates<\/strong> (each time Scayla's servers call your site with the paired token): the content being worked on \u2014 product, post, page and category titles and descriptions, SEO titles and meta descriptions, image alt text, FAQ questions and answers, and redirect paths. Scayla reads these to know the current state, and writes new values back the same way.<\/li>\n
- When you open a Scayla screen<\/strong> (any page under the Scayla menu except Connection): your browser loads the screen from
https:\/\/wp-api.scayla.co.il\/app<\/code>, with your admin's host name, the admin language and the screen name in the address, and sends your admin's origin (the scheme and host, never the page's path) as the referrer. The admin page then hands the screen a signed ticket, by postMessage<\/code> and never in an address, so Scayla can tell which site is asking. The ticket contains your site's host name, the time it was issued, a random value, and an HMAC signature made with a key derived from the stored token hash; it is valid for five minutes and contains no user name, email address, password or token. When a screen stays open longer than that, it asks for a fresh ticket through the scayla_app_ticket<\/code> admin-ajax action, which answers administrators only (manage_options<\/code> and a nonce). What the screens then show is read from Scayla's own records about your site.<\/li>\n- When Scayla checks the connection<\/strong> (
GET \/wp-json\/scayla\/v1\/health<\/code>, authenticated): plugin version, WordPress and WooCommerce versions, detected SEO plugin, permalink structure, site and home URL, locale, time zone, and the first 8 characters of the stored token hash as a connection fingerprint. The token itself is never returned.<\/li>\n- When Scayla checks what changed<\/strong> (
GET \/wp-json\/scayla\/v1\/changes<\/code> and GET \/wp-json\/scayla\/v1\/terms\/stamps<\/code>, authenticated, every few minutes while your site is connected to a Scayla workspace): whether products or product categories changed since Scayla last asked, the ids of any that were deleted, and when each category was last edited. The plugin notes these in one option (scayla_changes<\/code>) and in category meta (_scayla_updated_at<\/code>) on your own site; it still sends nothing by itself.<\/li>\n- When you choose who Scayla's articles are published as<\/strong> (
GET \/wp-json\/scayla\/v1\/authors<\/code>, authenticated): for each user who may publish posts, at most 100, their user ID, display name and role. Never their login name, email address or any other profile field, and never anyone who cannot publish posts (subscribers, shop customers).<\/li>\n<\/ul>\n\nWhat never leaves your site:<\/strong> no visitor data, no IP addresses, no analytics, no tracking beacons, no order or customer data, no email addresses or login names, no user accounts other than the display name and role of the users who may publish posts (above), and no data of any kind sent to any host other than the Scayla service that authenticated the request.<\/p>\n\nBy pairing your site you agree to Scayla's terms and privacy policy:<\/p>\n\n
\n- Terms of service: https:\/\/scayla.co.il\/terms<\/li>\n
- Privacy policy: https:\/\/scayla.co.il\/privacy<\/li>\n<\/ul>\n\n\n
\n- Upload the plugin files to
\/wp-content\/plugins\/scayla-connect<\/code>, or install it through the WordPress Plugins screen.<\/li>\n- Activate the plugin. Activation creates the redirects table and nothing else \u2014 no user account is created and no token exists yet.<\/li>\n
- Open the Scayla<\/strong> admin menu and read the external-service disclosure shown there before you continue.<\/li>\n
- Click Connect to Scayla<\/strong> and approve the request on the WordPress screen that follows. Scayla uses the Application Password WordPress creates once, to pair, deletes it, and brings you back to the Scayla<\/strong> menu, where the Scayla screens now live.<\/li>\n
- Prefer to do it by hand? Under Connect manually instead<\/strong>: create an Application Password for your administrator account (Users \u2192 Profile \u2192 Application Passwords), paste it into the Scayla portal, and revoke it once pairing succeeds.<\/li>\n<\/ol>\n\n\n
\nWhat exactly can the service do on my site?<\/h3><\/dt>\nPairing creates one user, scayla-connector<\/code>, holding a custom role with exactly 13 capabilities: read<\/code>, edit_posts<\/code>, edit_others_posts<\/code>, publish_posts<\/code>, edit_published_posts<\/code>, delete_posts<\/code>, delete_others_posts<\/code>, delete_published_posts<\/code>, edit_pages<\/code>, edit_others_pages<\/code>, edit_published_pages<\/code>, upload_files<\/code>, manage_categories<\/code>. With WooCommerce active, 9 product capabilities are added, including read_private_products<\/code> (WooCommerce maps a product collection read to it) and manage_product_terms<\/code>.<\/p>\n\nIt does not get manage_options<\/code>, install_plugins<\/code>, install_themes<\/code>, switch_themes<\/code>, edit_theme_options<\/code>, edit_users<\/code>, unfiltered_html<\/code>, publish_pages<\/code> or delete_pages<\/code>. Pages are editable but not publishable or deletable, because the service only writes SEO onto pages that already exist. The role is re-asserted on every load and any capability not on the list is stripped, so another plugin cannot quietly widen it.<\/p><\/dd>\nIs any code downloaded or executed from the remote service?<\/h3><\/dt>\nNo. The plugin never fetches, stores or evaluates remote code \u2014 no eval<\/code>, no dynamic include, no remote file download. What arrives from Scayla is text: titles, descriptions, FAQ questions and answers, and paths. Each passes an explicit filter before storage: FAQ questions have all tags stripped and answers pass wp_kses_post<\/code>; category and tag descriptions pass a post-context wp_kses<\/code> allowlist extended only with details<\/code>, summary<\/code> and a small set of class<\/code>\/id<\/code>\/data-<\/code> attributes, so script<\/code>, iframe<\/code> and on*<\/code> handlers cannot be stored even if the token were stolen. Redirect paths pointing at another host are rejected outright.<\/p><\/dd>\nWhat happens if a write does not land?<\/h3><\/dt>\nIt fails loudly. After every SEO write the plugin reconciles the provider's storage, re-reads the value from the source your front end will actually serve, and compares. If they differ it returns HTTP 500 with scayla_write_not_verified<\/code> and a body containing the expected value, the actual value, which storage layer answered (indexable<\/code>, postmeta<\/code>, option<\/code> or scayla<\/code>) and a hint distinguishing \"Yoast's indexable did not reconcile\" from \"another plugin may be overriding SEO meta\". For Yoast terms the read-back deliberately reads the indexable rather than the option just written, because a verification that reads back its own write proves nothing.<\/p><\/dd>\nDoes it work without WooCommerce, or without an SEO plugin?<\/h3><\/dt>\nBoth are optional. Without WooCommerce it works on posts, pages, categories and tags; with it, products and product categories are covered too. Without Yoast or Rank Math it stores values in its own _scayla_seo_title<\/code> and _scayla_seo_description<\/code> meta and renders them through pre_get_document_title<\/code> and a wp_head<\/code> meta description. Those standalone renderers refuse to run unless the detected provider is exactly \"none\", so there is never a duplicate title alongside Yoast or Rank Math.<\/p><\/dd>\nDoes it slow down my site?<\/h3><\/dt>\nThe redirect matcher runs at template_redirect<\/code> and costs zero database queries when a request does not match: the map lives in one autoloaded option WordPress has already fetched, an empty map returns before the request URI is parsed, and only a hit touches the database. If the map would exceed 100 KB it is dropped in favour of a single prepared query, so a large table never bloats every admin and cron request. Paths are stored in utf8mb4_bin<\/code> columns so matching is byte-exact, which stops a case-normalising rule such as \/Page<\/code> to \/page<\/code> from matching its own destination and looping forever. The plugin registers no cron jobs.<\/p><\/dd>\nCan the service user log in?<\/h3><\/dt>\nNo. It is created with a 64-character random password that is never transmitted, displayed, stored in plaintext or logged \u2014 but the guarantee does not rest on that. An authenticate<\/code> filter rejects any interactive login resolving to the service user, and an allow_password_reset<\/code> filter refuses password resets for it, closing the otherwise real path of requesting a reset to connector@yourdomain<\/code> on a catch-all mail domain. The token maps to the service user only on REST requests, anchored to the first path segment via rest_get_url_prefix()<\/code>, so a front-end permalink merely containing wp-json<\/code> cannot borrow the identity.<\/p><\/dd>\nAre any of the REST routes public?<\/h3><\/dt>\nNo. Every route has a real permission callback, including GET \/health<\/code>; there is no __return_true<\/code> anywhere in the code. Write routes additionally check the specific object: current_user_can( 'edit_post', $id )<\/code> for that post, or term existence plus a taxonomy allowlist plus manage_categories<\/code> for that term. The bulk read endpoint enforces authorisation per ID rather than once per batch, and anything the service user may not touch is returned in a skipped<\/code> list instead of being read. Failed token attempts are rate-limited per IP, bucketed on REMOTE_ADDR<\/code> rather than on spoofable proxy headers.<\/p><\/dd>\nHow do I disconnect, and what is removed if I delete the plugin?<\/h3><\/dt>\nClick Disconnect<\/strong> on the Scayla \u2192 Connection<\/strong> page. The token hash is deleted immediately and every subsequent request from Scayla is rejected; your content, SEO values, FAQ data and redirects stay exactly as they are. Deactivating changes nothing else, so you can deactivate to troubleshoot and reactivate without re-pairing.<\/p>\n\nDeleting the plugin removes the role from the service user, deletes the role, drops the redirects table, deletes _scayla_faq<\/code>, _scayla_seo_title<\/code> and _scayla_seo_description<\/code> from every post and term, and sweeps every scayla_*<\/code> option and transient \u2014 on every site of a multisite network. Two things are kept on purpose: the scayla-connector<\/code> account, so content it authored keeps its author attribution (it has no role, zero capabilities and cannot be logged into; delete it manually if you prefer), and SEO values already written into Yoast or Rank Math, because at that point they are your site's meta, not the plugin's.<\/p><\/dd>\nDoes it support multisite?<\/h3><\/dt>\nYes. Network activation provisions every existing site, sites created afterwards are provisioned automatically, and uninstall walks every site so no orphan table or role is left behind.<\/p><\/dd>\n\n<\/dl>\n\n\n
1.0.8<\/h4>\n\n\n- Elementor blog posts: when this site is connected to a Scayla workspace, runs Elementor with the Atomic Editor turned on, and the site owner turns the feature on in Scayla, Scayla can write NEW blog posts designed in your site's Elementor style, save them as drafts, and publish one only after a person approved it in Scayla. Scayla only ever changes posts it created itself. It never builds pages, never edits a post or page you made, and never touches your header, footer, templates, global colors, fonts or classes.<\/li>\n<\/ul>\n\n
1.0.7<\/h4>\n\n\n- When your site is connected to a Scayla workspace, Scayla now sees your product and category edits within minutes, and reads only what changed instead of your whole catalogue. The plugin notes that something changed; Scayla's server asks for that note.<\/li>\n
- Product answers to Scayla carry each image's small rendition on WooCommerce versions that do not include it already.<\/li>\n
- When this site is connected to a Scayla workspace, Scayla can list the users who may publish posts (their display name and role only, never an e-mail or login), so you choose who Scayla's articles are published as.<\/li>\n
- Scayla's own development store can point at Scayla's development service with a
wp-config.php<\/code> constant. Nothing changes for any other site.<\/li>\n<\/ul>\n\n1.0.6<\/h4>\n\n\n- The Scayla menu now holds every Scayla screen, in the same order as Scayla's app in other store admins: Home<\/strong>, Competitors & AI visibility<\/strong>, Deep analysis<\/strong>, Content<\/strong>, Keywords<\/strong>, Products<\/strong>, Collections<\/strong>, Fixes<\/strong>, Rankings<\/strong>, Links<\/strong>, Strategy<\/strong>, Weekly report<\/strong> and Settings<\/strong>.<\/li>\n
- Home<\/strong> replaces the Overview: what Scayla did this week, what waits for you, and the next best step.<\/li>\n
- Content<\/strong> shows each article as it will look on your site, with approve, reject, schedule and rewrite-with-a-note.<\/li>\n
- Keywords<\/strong>, Strategy<\/strong> and Weekly report<\/strong> show the research, the plan and the week's results the Deep analysis builds.<\/li>\n
- Collections<\/strong> writes SEO titles, descriptions, intro paragraphs and FAQ for your product categories, each on your approval and reversible.<\/li>\n
- Fixes<\/strong> checks what AI crawlers may read and suggests 301 redirects for pages that return 404, applied only on your approval.<\/li>\n
- A Scayla redirect now acts only when WordPress answers the address with a 404, so it can never cover a page that exists.<\/li>\n
- Settings<\/strong> holds your plan and billing, your content preferences and what Scayla learned from you. The old Plan address opens it.<\/li>\n
- The screens' frame may start a download (the keyword research file) and copy the weekly report to the clipboard.<\/li>\n<\/ul>\n\n
1.0.5<\/h4>\n\n\n- New Deep analysis<\/strong> screen under the Scayla menu: Scayla reads your store and researches your competitors, market, buyer searches and content opportunities, then shows what it found and a strategy built from it. You follow each stage live while it runs.<\/li>\n
- The analysis then prepares every other screen: product and category SEO suggestions, the questions measured on the AI visibility screen, and a first article for your approval queue.<\/li>\n
- Five short questions switch Scayla on. The Overview leads there until they are answered.<\/li>\n<\/ul>\n\n
1.0.4<\/h4>\n\n\n- New Competitors & AI visibility<\/strong> screen under the Scayla menu: Scayla asks AI assistants the questions your buyers ask and shows how often your store appears in their answers, next to the competitors you track. Read each answer as the assistant wrote it, add competitors by their website and questions of your own, and turn a question you are missing from into an article for your approval queue.<\/li>\n
- Measuring runs in the background, so you can leave the page while it works.<\/li>\n<\/ul>\n\n
1.0.3<\/h4>\n\n\n- New Products<\/strong> screen under the Scayla menu: Scayla scans your catalogue for the weakest SEO titles, meta descriptions and image alt texts, and shows each suggestion next to the value it would replace. Apply one, apply all within your monthly allowance, or dismiss with a reason Scayla learns from. Every applied change can be rolled back.<\/li>\n
- The scan runs in the background, so you can leave the page while it works.<\/li>\n
- A short notice after each action and a progress indicator while it runs.<\/li>\n<\/ul>\n\n
1.0.2<\/h4>\n\n