Directory / plugin

Scayla Connect

v1.0.8 · by liorzabari

Connector for Scayla: measures whether AI assistants name your store, then writes SEO, FAQ schema and redirects, verified by read-back.

About this plugin

Scayla Connect is not an SEO plugin. It is the site-side connector for Scayla, 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.

The queries it measures are not generic keywords typed into a box. They are derived from a scan of your own catalogue — real product titles, product types and categories — 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.

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 table. A tool that calls update_post_meta( $id, '_yoast_wpseo_title', ... ) 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 error carrying the expected value, the actual value and which storage layer answered.

Yoast SEO and Rank Math — the two SEO plugins this connector writes through — 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.

Hebrew and RTL. Redirect paths never pass through sanitize_text_field(), 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> / <summary> accordion with no JavaScript and no stylesheet, so it inherits your theme’s RTL direction. Hebrew content analysis is not claimed as a differentiator — Yoast and Rank Math both support Hebrew already.

What the plugin does on your site

  • 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 service user with a narrow, revocable token.
  • 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.
  • 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.
  • Writes category and tag descriptions through a dedicated endpoint, because WordPress core registers wp_filter_kses on pre_term_description unconditionally and silently strips div, h2, p, details and summary 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.
  • Manages a redirects table for dead URLs, with guards against self-redirects, two-step loops, cross-host targets, and the protected prefixes /wp-admin, /wp-json, /wp-login.php, /wp-content and the site root.
  • Adds a Scayla 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 page with the connection status, detected SEO plugin, redirect and FAQ counts, and a Disconnect button.

How it is built. Plain, readable PHP: seven classes plus the main file and uninstall.php, and one short, unminified admin script (admin/js/scayla-app.js) 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.

Nothing in the plugin is gated. 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.

External services

This plugin is a connector for Scayla, a third-party cloud service operated by Scayla (https://scayla.co.il/). A Scayla account is required. Without one the plugin has nothing to talk to: it will pair with nothing, receive no writes, and do nothing useful.

The plugin makes no outbound requests. It contains no wp_remote_*, curl_*, file_get_contents or fsockopen call anywhere in its code. It never contacts Scayla, on any schedule or on any event, including deactivation. The Connect to Scayla 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.

What leaves your site, and when:

  • When you pair. Clicking Connect to Scayla takes your browser to Scayla (https://wp-api.scayla.co.il/connect/start) with your site address and admin language in the link. Scayla reads your site’s public REST index (GET /wp-json/) 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). If you approve, WordPress creates an Application Password named Scayla and sends your browser to Scayla with it (/connect/authorized). Scayla uses it for one authenticated POST /wp-json/scayla/v1/pair, then deletes it: GET /wp-json/wp/v2/users/me/application-passwords/introspect identifies that one password and DELETE /wp-json/wp/v2/users/me/application-passwords/{uuid} 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 — once only, in this one response — 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.
  • While the service operates (each time Scayla’s servers call your site with the paired token): the content being worked on — 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.
  • When you open a Scayla screen (any page under the Scayla menu except Connection): your browser loads the screen from https://wp-api.scayla.co.il/app, 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 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 admin-ajax action, which answers administrators only (manage_options and a nonce). What the screens then show is read from Scayla’s own records about your site.
  • When Scayla checks the connection (GET /wp-json/scayla/v1/health, 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.
  • When Scayla checks what changed (GET /wp-json/scayla/v1/changes and GET /wp-json/scayla/v1/terms/stamps, 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) and in category meta (_scayla_updated_at) on your own site; it still sends nothing by itself.
  • When you choose who Scayla’s articles are published as (GET /wp-json/scayla/v1/authors, 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).

What never leaves your site: 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.

By pairing your site you agree to Scayla’s terms and privacy policy:

  • Terms of service: https://scayla.co.il/terms
  • Privacy policy: https://scayla.co.il/privacy

Plugin tags