(<severity>). Change: <robots.txt rule>. Where: /robots.txt 2. Markup - Finding: <title> (<severity>). Change: Organization JSON-LD. Where: home page head 3. Content - Finding: <title> (<severity>). Change: <draft edit>. Where: <page> Not measured: <anything the result marks as unavailable or partial> ``` After the user publishes the changes, offer to re-run the same audits with the same arguments and compare the results by `findingKey`, as in the `fix-and-retest` skill. Report what changed and what is still open or not measured. 22:o9,26:T17ce,22:o17ce,--- name: domain-verification description: Explain and help complete Sitelemetry ownership verification when an audit returns action_required because the target is not verified, the proof has expired, the target spelling differs from the verified one, or the proof does not cover host-wide checks. Covers the DNS TXT record, HTTP file and Google Search Console methods, then retries the same audit. Use when an audit asks for verification or the user asks how to verify their site. --- # Domain verification ## Ground rules - Reply in the user's language. - Verification shows that the user controls the site. Help only with sites the user owns or administers, and never suggest ways around verification. - Verification is completed in the user's Sitelemetry web workspace, not through the audit tools. Give the user the `nextAction.url` the tool returned; do not guess other account URLs. - When a tool asks for verification, no audit ran and no audit allowance was used. - Never ask for passwords, API tokens or DNS, hosting or Google account credentials. The user makes the change, or you edit project files with their approval. ## 1. Read the reason | `reason` | `nextAction.type` | Meaning | What to do | |---|---|---|---| | `target_verification_required` | `verify_target` | No current proof for this exact target | Choose a method (section 2) | | `target_reverification_required` | `renew_verification` | The proof expired: it was last checked more than 30 days ago | Keep the DNS record or file in place and run the check again in the workspace, or sync Google Search Console again | | `verified_target_required` | `review_verified_target` | The target spelling differs from the verified one; `registeredTarget` shows the verified spelling | Show both spellings and ask the user which one to audit. Use `registeredTarget` only after they confirm, or verify the other spelling | | `verification_scope_required` | `verify_host` | A URL-prefix proof cannot authorize host-wide security checks | Verify the domain, the hostname or the root URL, or run only checks that the verified prefix covers | Targets are matched exactly. `https://example.com/` and `https://www.example.com/` are different targets, and so are different ports and paths. Verify the spelling the user wants to audit. ## 2. Verification methods The workspace issues a token that starts with `sitelemetry-` and shows the exact record name and file URL for the target. Always use the values it shows. ### DNS TXT record - Name: `_sitelemetry-challenge.<hostname>`, for example `_sitelemetry-challenge.example.com`, or `_sitelemetry-challenge.www.example.com` for the `www` host. - Value: the token, exactly. - Many DNS panels add the domain automatically; then enter only `_sitelemetry-challenge` (or `_sitelemetry-challenge.www`) in the name field. - New records can take from minutes to hours to become visible, depending on TTL. Check with `nslookup -type=TXT _sitelemetry-challenge.example.com` or `dig +short TXT _sitelemetry-challenge.example.com`. ### HTTP file - URL: `https://<host>/.well-known/sitelemetry-verification.txt` - Content: only the token, as plain text. Surrounding whitespace is ignored. The file must be smaller than 2 KB. - The URL must answer with a success status over HTTPS with a valid certificate. A redirect to another host, protocol or port fails the check. - Where the file usually goes: - Next.js, Vercel and most static site generators: `public/.well-known/sitelemetry-verification.txt` - Netlify: `.well-known/sitelemetry-verification.txt` inside the publish directory - nginx or Apache: the `.well-known` folder in the document root. Make sure rules that hide dot-folders do not block it; in nginx, a `location ^~ /.well-known/ { }` block takes precedence over regex rules that deny dot-folders. - WordPress: the `.well-known` folder in the site's root directory, uploaded with the host's file manager or SFTP - Check it with `curl -s https://example.com/.well-known/sitelemetry-verification.txt`; the output must be the token. ### Google Search Console Available when the workspace offers a Google connection and the user is a verified owner of the property. - A Domain property (`sc-domain:example.com`) covers the whole host, including host-wide checks. - A URL-prefix property covers only that prefix. It authorizes host-wide checks only when it is the root URL of the hostname, such as `https://example.com/`. ## 3. What verification covers - Host-wide security checks need proof for the domain, the hostname or the root URL. A proof for a path prefix such as `https://example.com/shop/` covers only checks that work within that prefix. - On an account with security-only access, a default `audit_security` call (or a default `audit_full`, which on such an account runs security only) runs seven public checks without verification: DNS, email DNS, RDAP, TLS, HTTP headers, MITM posture and technology fingerprint. Verification adds checks for HTTP methods, exposed files and paths, and API exposure. An explicit `modules` list runs without verification only if every module is one of those seven public checks (`dns`, `dns-email`, `rdap`, `tls`, `http-headers`, `mitm-posture`, `tech-fingerprint`). Any other module needs current verification, and host-wide modules need host proof. - On other accounts, every audit needs current verification of the exact target, including the public checks. - Verification does not create a monitoring project. The first accepted audit creates one automatically. - A proof stays current for 30 days after it was last checked. Keep the DNS record or file in place so it can be checked again. ## 4. Retry Retry only after the user confirms that the workspace shows the target as verified. - Call the same tool with the same `target` spelling and the same arguments as the rejected call. - If the result is again a verification reason, compare the target spelling with the verified one and check whether the proof is current. Do not retry in a loop. - Then continue with the `website-audit` skill to present the results. 22:o9,27:T135d,22:o135d,--- name: fix-and-retest description: Turn Sitelemetry audit findings into concrete fixes for the user's stack (nginx, Apache, Cloudflare, Vercel or Next.js, Netlify, WordPress), apply them with the user's approval or hand them over ready to use, then re-run the same audit on the same target and report honestly what is resolved, still open or not measured. Use after an audit when the user asks how to fix the findings, wants the changes made, or wants to confirm that a fix worked. --- # Fix and re-test ## Ground rules - Reply in the user's language. For the audit tools, set `lang` as described in the `website-audit` skill. - Only change and re-test sites the user owns or is authorized to test. - Base every fix on a returned finding: its evidence, impact and `remediation`. If you suggest something the audit did not report, label it as an extra suggestion. - Never say a fix worked until a re-test has measured it. ## 1. Start from real findings Use the findings of an audit from this conversation. If there are none, run one first with the `website-audit` skill. For every finding, note its `findingKey`, severity, title and `location`, and note the exact tool, `target` and options of that run. The re-test must repeat them. ## 2. Identify the stack Ask the user, or infer it from the project when you can read its files. | Signal | Stack | |---|---| | `nginx.conf`, `sites-available/`, `conf.d/` | nginx | | `.htaccess`, `httpd.conf`, `apache2.conf` | Apache | | Site proxied through Cloudflare, rules in the Cloudflare dashboard | Cloudflare | | `vercel.json`, `next.config.js`, `next.config.mjs`, `next.config.ts` | Vercel or Next.js | | `netlify.toml`, `_headers`, `_redirects` | Netlify | | `wp-config.php`, `wp-content/` | WordPress | When a CDN or proxy sits in front of the origin, it can add, replace or cache headers. Decide which layer owns each header and set it in one place. ## 3. Write the fixes Work from critical to info. For each finding give: - what changes and where (file path or dashboard location); - the change for the user's stack, adapted to the site; - the risk and how to roll it back; - how to check it before re-testing, for example `curl -sI https://example.com/` for response headers. Starting points for common findings (security headers, HTTPS redirect, HSTS, server version disclosure, caching, compression and email DNS records) are in [stack snippets](references/stack-snippets.md). Adapt them to the site; do not paste them blindly. Safety rules: - **Content-Security-Policy**: start with `Content-Security-Policy-Report-Only`, check the browser console for violations, then enforce. A strict policy copied without testing breaks sites. - **HSTS**: start with a short `max-age`. Add `includeSubDomains` only when every subdomain serves HTTPS, and `preload` only when the owner decides to submit the domain to browser preload lists. - **DNS and email records** (SPF, DKIM, DMARC, CAA): the user changes these at their DNS provider. Start DMARC at `p=none` with reports before moving to `quarantine` or `reject`. - Never ask for or handle passwords, API tokens or hosting and DNS credentials. ## 4. Apply or hand over - With access to the project files (for example in Claude Code): show the diff and apply it only after the user agrees. Do not deploy, restart services or change production settings on your own. - Without file access: give complete, copy-ready changes and the order to apply them in. - Ask the user to tell you when the changes are live. If the site uses a CDN or page cache, ask them to purge it so the re-test sees the new responses. ## 5. Re-test the same way - Tell the user that the re-test is a new audit run and uses the account's audit allowance. - Call the same tool with the same `target` spelling and the same options as the first run (`profile`, `modules`, `maxPages`, `strategy` and so on). A different scope makes the comparison invalid. - Handle `running`, `action_required` and errors as in the `website-audit` skill: poll with `pollArguments` unchanged and never start a duplicate audit. ## 6. Report before and after Match findings across the two runs by `findingKey`. | Result | Rule | |---|---| | Resolved | In the first run, absent from the re-test, and the check was measured in the re-test | | Still open | Present in both runs | | New | Present only in the re-test | | Not measured | The check was unmeasured, unavailable or partial in the re-test (see `coverageStatus`, `auditDetails` and `failedPillars`). Do not count it as resolved. | Show a table with the finding, severity, before, after and result. Report a score change only when both runs have a non-null score, and mention that scores can move for other reasons too, such as lab variance in performance measurements. If `findingsTruncated` was true in either run, say that the comparison covers only the returned findings. End with what is still open and the next step for each item. 22:o9,28:T1235,22:o1235,--- name: pre-launch-check description: Run a pre-release check of a website the user owns with Sitelemetry security, performance and accessibility audits, plus technical SEO when the site is meant to be indexed, then summarise launch blockers versus warnings using only measured results. Use when the user is about to launch, deploy, go live, migrate or redesign a site and wants to know what must be fixed first. --- # Pre-launch check ## Ground rules - Reply in the user's language. For the audit tools, set `lang` as described in the `website-audit` skill. - Only check sites the user owns or is authorized to test. If that is not clear, ask first. - The security audit sends test requests to the site. Depending on the account, these can include active, non-destructive probes such as port and injection checks, which may show up in server logs or firewall alerts. Tell the user before running it on a site that has not been audited before. - Use only the scores, severities and findings the tools return. Never invent a score, a pass or a measurement. ## 1. Confirm the scope - **Target**: the exact public `https://` URL, spelled as verified in the user's Sitelemetry workspace. A staging site must be reachable over public HTTPS; localhost, private addresses and hosts behind a VPN cannot be audited. A staging hostname is a separate target and needs its own verification. - **Indexing**: ask whether the site should be indexed by search engines at launch. Include `audit_seo` only if it should. On a staging site that is deliberately `noindex`, indexation findings are expected; say so rather than listing them as blockers. - **Runs**: tell the user which audits you will run and that each one is a separate audit that uses the account's audit allowance. If they prefer a single run, `audit_full` covers every audit area included in the connected account in one call. ## 2. Run the audits one at a time Default order: 1. `audit_security` 2. `audit_performance` with `strategy: "mobile"` (add a `desktop` run only if the user asks) 3. `audit_accessibility` 4. `audit_seo`, if indexing is in scope For each audit: - Wait for the final status before starting the next. On `running`, wait about `retryAfterMs` and call the same tool with `pollArguments` exactly as returned. Never start a duplicate audit. - Keep the same `target` spelling on every call. - On `action_required`, no audit ran and no allowance was used. - Access or allowance reasons: note it, relay the next step neutrally with the returned link, and continue with the other audits. - `target_verification_required`, `target_reverification_required` or `verified_target_required`: stop, because the other audits need the same proof for the same target, and follow the `domain-verification` skill. - `verification_scope_required`: only the host-wide security checks need broader proof. Record security as not measured, continue with the other audits, and point to the `domain-verification` skill for domain, hostname or root URL proof. - On an error, note it and continue with the next audit. ## 3. Classify the results Keep the severities the tools assign; do not re-grade them. - **Blockers**: critical and high findings. - **Warnings**: medium findings. - **Notes**: low and info findings. - **Not measured**: checks, areas or metrics that the results mark as unavailable, partial, failed or outside the connected account's access, and any audit that did not run. These are unknowns, not passes. When the same issue appears in two audits, list it once and name both. ## 4. Report Use this structure: ```text Pre-launch check for https://example.com/ (date) Audits: security completed, performance (mobile) partial, accessibility completed, SEO not run (site not indexed yet) Blockers (2) 1. [security, high] <title> at <location>: <fix> 2. [accessibility, high] <title> at <location>: <fix> Warnings (3) ... Notes (4): one line each, or a count if there are many Not measured - performance: <what was unavailable, from the result> Scores returned: security <score> (<grade>), accessibility <score> ``` Only list scores that the tools returned as numbers. A null score means the area was not measured. Verdict: - With blockers: "Not ready yet: fix these N blockers first", followed by the blockers in order of severity. - Without blockers: "No blockers were found in the measured checks", followed by the Not measured list. Never state that the site is secure, fully accessible or compliant; the audits cover specific automated checks. Offer the `fix-and-retest` skill for the blockers and, after fixes, a re-run of the same audits with the same arguments. 22:o9,29:T1d6c,22:o1d6c,--- name: website-audit description: Run a Sitelemetry audit on a website the user owns or is authorized to test, wait correctly for long-running audits, and present the findings ranked by severity with the top fixes. Use when the user asks to audit, scan, check or score their own site for security, technical SEO, AI visibility, analytics and tracking, accessibility (WCAG) or performance (Core Web Vitals), or asks for an overall site health check. --- # Website audit Use the Sitelemetry audit tools to measure a website and explain what to fix first. ## Ground rules - Reply in the user's language. Set `lang` to the user's language when it is one of `en`, `tr`, `es`, `de`, `fr`, `pt`, `it`, `ja` or `zh`; otherwise leave `lang` out and translate your summary yourself. `lang` changes the wording of the result, not what is measured. - Only audit sites the user owns or is authorized to test. If that is not clear, ask before calling any tool. Do not audit competitors or other third-party sites. - The audits run from Sitelemetry's servers and do not change the site. Starting an audit uses the connected account's audit allowance (it is released again if the audit fails). Polling a running audit and `action_required` results use none. - Security and full audits send test requests to the site. Depending on the account, these can include active, non-destructive probes such as port and injection checks, which may show up in the site's server logs or firewall alerts. Mention this when the user has not audited the site before. - Never invent scores, grades, findings, measurements or report links. ## 1. Get the exact target If the user started this skill with arguments, the first one is the target URL and an optional second word names the area: `security` (`audit_security`), `seo` (`audit_seo`), `ai` (`audit_ai_visibility`), `integrations` (`audit_integrations`), `accessibility` (`audit_accessibility`), `performance` (`audit_performance`) or `full` (`audit_full`). Confirm ownership or authorization as usual before calling. If only a URL was given and the conversation does not say which area, ask, or use `audit_full` if the user wants everything. `target` must be an absolute `https://` URL spelled exactly as it is verified in the user's Sitelemetry workspace. - Scheme, `www` or no `www`, port, path, path casing and query all count. Only hostname case, an explicit `:443` and a trailing slash are ignored. - Only public hosts are accepted: no localhost, private addresses, credentials in the URL or `#fragment`. - If the user gives a bare domain such as `example.com`, confirm the exact URL (for example `https://example.com/` or `https://www.example.com/`) before calling. - Keep the same spelling on every retry and every poll. ## 2. Pick the narrowest tool | The user asks about | Tool | Options worth knowing | |---|---|---| | Security headers, TLS, DNS, email authentication, exposed files, ports | `audit_security` | `profile`, `modules`, `ports`, only when the user asks | | Crawlability, indexation, metadata, structured data, internal links | `audit_seo` | `maxPages` (1-30), `includeSearchConsole`, `searchConsoleDays` (7, 28 or 90) | | AI visibility, GEO, AEO, AI crawler policy | `audit_ai_visibility` | `brand`, `prompts`, `competitors`, `maxPages`, `promptLimit` | | Analytics, tags, marketing pixels, consent, site verification tags | `audit_integrations` | none | | Accessibility, WCAG | `audit_accessibility` | none | | Speed, PageSpeed, Core Web Vitals | `audit_performance` | `strategy`: `mobile` (default) or `desktop` | | Everything, overall health, one combined score | `audit_full` | any of the above | - Leave options out unless the user asked for them; defaults follow the connected account's access. Unknown options are rejected, so send only options the chosen tool lists. - `profile` and `modules` exist only on `audit_security` and `audit_full`. Leaving both out requests every security module included in the connected account. - `includeSearchConsole` uses the Google connection already set up in the workspace; missing access does not stop the audit. When it is left out, `audit_seo` and `audit_full` (when it includes SEO) still add Search Console data if the workspace has that connection. Search Console data is metered separately from the audit allowance. Set `includeSearchConsole` to `false` if the user does not want it. - `audit_accessibility` is a static WCAG 2.2 check, not a full manual accessibility review. Say so when it matters. - Run one audit at a time. Do not start another audit while one is running. ## 3. Handle the result status Read `status` first. Every reason and error is described in [result handling](references/result-handling.md). - `completed` or `partial`: present the result (section 4). `partial` means some requested measurements were unavailable. - `running`: the audit is still in progress. Tell the user in one line, wait about `retryAfterMs`, then call the **same tool** with `pollArguments` exactly as returned. Do not add scan options. Repeat until the status is final. Polling resumes the same audit; it does not start a new one or use more allowance. Full and security audits can take several minutes. Never present `running` as a result and never start a replacement audit. - `action_required`: no audit ran and no allowance was used. Explain the `reason` and pass on `nextAction.url` exactly as returned. Do not retry until the prerequisite has changed. For verification reasons, follow the `domain-verification` skill. - Error (`isError` with text starting `Error:`): relay the message plainly and suggest the correction it points to, such as the exact verified target spelling or a narrower scope. ## 4. Present the findings 1. **Summary line**: target, audit type, status, and `score` and `grade` (or `blended` for `audit_full`) only when they are not null. A null score means the area was not measured; it is not zero. 2. **Coverage**: what was not measured and why, from `coverageStatus`, `executionComplete`, `auditDetails` and, for `audit_full`, `failedPillars` and areas outside the connected account's access. A completed run does not prove every check was measured, and unmeasured checks are not passes. 3. **Findings by severity**: critical, high, medium, low, then info. For each give the title, `location` if present, the evidence, the impact and the fix (`remediation`). For `audit_full`, also name the `pillar`. If `findingsTruncated` is true, say that `returnedFindings` of `total` findings were returned. 4. **Top fixes**: the three to five changes that remove the most severe risk first, in order, each tied to the findings it resolves. 5. **Passing checks**: one line with `passingChecks` or the main passing items. Keep each finding's `findingKey`, the tool and the exact arguments you used, so a later re-test can be compared like for like. Offer the `fix-and-retest` skill as the next step. Results normally come without a report link. If the result text includes one, you may pass it on; it opens in the user's signed-in Sitelemetry workspace. ## Access and limit messages When a result says that an audit, profile or module is not included in the connected account, or that the audit allowance is used up, repeat that fact neutrally together with the link the tool returned. Do not add sales wording, plan recommendations or prices. If the result offers a security-only alternative for the same target, you may mention it, and say that it does not complete the audit that was requested. 22:oeb5,11:[["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"SoftwareApplication\",\"name\":\"Sitelemetry\",\"description\":\"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn the findings into prioritized fixes and re-test them.\",\"applicationCategory\":\"IT & security\",\"operatingSystem\":\"Claude\",\"url\":\"https://agentready.co/connectors/sitelemetry\",\"sameAs\":[],\"publisher\":{\"@type\":\"Organization\",\"name\":\"egenil\",\"url\":\"https://github.com\"}}"}}],["$","div",null,{"className":"wrap","children":[["$","div",null,{"className":"pp-head","children":[["$","$L23",null,{"name":"Sitelemetry","url":null,"size":56}],["$","div",null,{"children":[["$","div",null,{"className":"crumbs","children":[["$","$L5",null,{"href":"/","children":"Connectors"}],[" / ",["$","$L5",null,{"href":"/categories/security-it","children":"IT & security"}]]]}],["$","h1",null,{"children":["Sitelemetry",null]}]]}]]}],["$","div",null,{"className":"pp","children":[["$","div",null,{"className":"ca","children":[["$","p",null,{"className":"tag","children":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn the findings into prioritized fixes and re-test them."}],null,["$","$L24",null,{"examples":[],"tools":[],"prefix":"","server":{"url":"https://claude-mcp.sitelemetry.com/mcp","login":"OAuth","protocol":null,"extras":[]},"instructions":[],"skills":[{"name":"ai-visibility","label":"Ai visibility","gist":"Use the Sitelemetry AI visibility (GEO/AEO) and technical SEO audits on a site the user owns to propose evidence-backed changes such as robots.txt rules for AI crawlers, schema.org JSON-LD structured","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/ai-visibility/SKILL.md","raw":"$25"},{"name":"domain-verification","label":"Domain verification","gist":"Explain and help complete Sitelemetry ownership verification when an audit returns action_required because the target is not verified, the proof has expired, the target spelling differs from the verif","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/domain-verification/SKILL.md","raw":"$26"},{"name":"fix-and-retest","label":"Fix and retest","gist":"Turn Sitelemetry audit findings into concrete fixes for the user's stack (nginx, Apache, Cloudflare, Vercel or Next.js, Netlify, WordPress), apply them with the user's approval or hand them over ready","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/fix-and-retest/SKILL.md","raw":"$27"},{"name":"pre-launch-check","label":"Pre launch check","gist":"Run a pre-release check of a website the user owns with Sitelemetry security, performance and accessibility audits, plus technical SEO when the site is meant to be indexed, then summarise launch block","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/pre-launch-check/SKILL.md","raw":"$28"},{"name":"website-audit","label":"Website audit","gist":"Run a Sitelemetry audit on a website the user owns or is authorized to test, wait correctly for long-running audits, and present the findings ranked by severity with the top fixes.","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/website-audit/SKILL.md","raw":"$29"}],"skillNote":"5 in the Claude listing"}],null]}],"$L2a"]}]]}]] 22:oa4a,1b:[["$","title","0",{"children":"Sitelemetry by egenil: AI connector · Agent Ready"}],["$","meta","1",{"name":"description","content":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn…"}],["$","link","2",{"rel":"manifest","href":"/manifest.webmanifest","crossOrigin":"$undefined"}],["$","link","3",{"rel":"canonical","href":"https://agentready.co/connectors/sitelemetry"}],["$","meta","4",{"property":"og:title","content":"Sitelemetry by egenil: AI connector"}],["$","meta","5",{"property":"og:description","content":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn…"}],["$","meta","6",{"property":"og:url","content":"https://agentready.co/connectors/sitelemetry"}],["$","meta","7",{"property":"og:site_name","content":"Agent Ready"}],["$","meta","8",{"property":"og:image","content":"https://agentready.co/connectors/sitelemetry/opengraph-image?3b61e23efdbb5225"}],["$","meta","9",{"property":"og:image:type","content":"image/png"}],["$","meta","10",{"property":"og:image:width","content":"1200"}],["$","meta","11",{"property":"og:image:height","content":"630"}],["$","meta","12",{"property":"og:image:alt","content":"AI connector on Agent Ready"}],["$","meta","13",{"property":"og:type","content":"website"}],["$","meta","14",{"name":"twitter:card","content":"summary_large_image"}],["$","meta","15",{"name":"twitter:title","content":"Sitelemetry by egenil: AI connector"}],["$","meta","16",{"name":"twitter:description","content":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn…"}],["$","meta","17",{"name":"twitter:image","content":"https://agentready.co/connectors/sitelemetry/opengraph-image?3b61e23efdbb5225"}],["$","meta","18",{"name":"twitter:image:alt","content":"AI connector on Agent Ready"}],["$","meta","19",{"name":"twitter:image:type","content":"image/png"}],["$","meta","20",{"name":"twitter:image:width","content":"1200"}],["$","meta","21",{"name":"twitter:image:height","content":"630"}],["$","link","22",{"rel":"icon","href":"/favicon.ico?favicon.3iymezf4ycw3e.ico","sizes":"64x64","type":"image/x-icon"}],["$","link","23",{"rel":"icon","href":"/icon.svg?icon.1m07wgr9jqhm5.svg","sizes":"any","type":"image/svg+xml"}],["$","link","24",{"rel":"apple-touch-icon","href":"/apple-icon.png?apple-icon.3q8qrgufoflqu.png","sizes":"180x180","type":"image/png"}],["$","$L2b","25",{}]] 22:o10,1c:null 22:null 22:o22,:HL["/stores/claude.png","image"] 22:o1290,2a:["$","aside",null,{"className":"side","children":[["$","div",null,{"className":"card","children":[["$","h2",null,{"children":"Stores"}],["$","div",null,{"className":"st","children":[["$","div","claude",{"style":{"display":"contents"},"children":[["$","span",null,{"className":"s","children":[["$","img",null,{"className":"sm","src":"/stores/claude.png","alt":"","width":16,"height":16}],["$","b",null,{"children":"Claude"}],["$","a",null,{"className":"src","href":"https://github.com/egenil/sitelemetry-claude-plugin","target":"_blank","rel":"noopener nofollow","children":"Source ↗"}]]}],["$","span",null,{"className":"rk2","children":[["$","small",null,{"children":"Listed, not ranked"}],null]}]]}]]}]]}],["$","div",null,{"className":"card","children":[["$","h2",null,{"children":"Details"}],["$","dl",null,{"className":"kv","children":[[["$","dt",null,{"children":"Company"}],["$","dd",null,{"children":"egenil"}]],[["$","dt",null,{"children":"Publisher"}],["$","dd",null,{"children":"Community"}]],["$","dt",null,{"children":"Category"}],["$","dd",null,{"children":["$","$L5",null,{"href":"/categories/security-it","children":"IT & security"}]}],[["$","dt",null,{"children":"Audience"}],["$","dd",null,{"children":"For developers"}]],null,["$","dt",null,{"children":"Sign-in"}],["$","dd",null,{"children":"None needed"}],["$","dt",null,{"children":"Interactive UI"}],["$","dd",null,{"children":"No"}],[["$","dt",null,{"children":"Checked"}],["$","dd",null,{"children":"Oct 27, 2026"}]],null]}]]}],["$","div",null,{"className":"card","children":[["$","h2",null,{"children":["More in ","IT & security"]}],["$","ul",null,{"className":"sim","children":[["$","li","14778",{"children":["$","$L5",null,{"href":"/connectors/remote-desktop-commander","prefetch":false,"children":[["$","$L23",null,{"name":"Remote Desktop Commander","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/b5/b5a9082663d57b64df78838701ea5ae096cf89afc03ebffa0f7a46cedff03231-64.webp","size":24}],["$","b",null,{"children":"Remote Desktop Commander"}],["$","small",null,{"children":"#357"}]]}]}],["$","li","4663",{"children":["$","$L5",null,{"href":"/connectors/freshservice","prefetch":false,"children":[["$","$L23",null,{"name":"Freshservice","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/0a/0a8072b376751e49e35758ccbc379dd5899695b9891dfc0ca4d65fc04ec7f0c9-64.webp","size":24}],["$","b",null,{"children":"Freshservice"}],["$","small",null,{"children":"#176"}]]}]}],["$","li","15096",{"children":["$","$L5",null,{"href":"/connectors/codex-security","prefetch":false,"children":[["$","$L23",null,{"name":"Codex Security","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/9b/9b9c2b09b2fa064611fb62307d321d5c2ea70cf0789f7ce34cdb0fc0d9190b3a-64.webp","size":24}],["$","b",null,{"children":"Codex Security"}],["$","small",null,{"children":"#410"}]]}]}],["$","li","4449",{"children":["$","$L5",null,{"href":"/connectors/malwarebytes","prefetch":false,"children":[["$","$L23",null,{"name":"Malwarebytes","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/6b/6b0d1f4fdc751c893519ae7edf22539020f70a4447410ac0c8586b501661b336-64.webp","size":24}],["$","b",null,{"children":"Malwarebytes"}],["$","small",null,{"children":"#337"}]]}]}],["$","li","15486",{"children":["$","$L5",null,{"href":"/connectors/chatgpt-admin","prefetch":false,"children":[["$","$L23",null,{"name":"ChatGPT Admin","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/13/1396309d23a53fd780c162b74ddd8fc23f67ce0ec59d8339d1e4ec13f9d7843b-64.webp","size":24}],["$","b",null,{"children":"ChatGPT Admin"}],["$","small",null,{"children":"#459"}]]}]}],["$","li","15254",{"children":["$","$L5",null,{"href":"/connectors/triggercmd","prefetch":false,"children":[["$","$L23",null,{"name":"TRIGGERcmd","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/ec/eca7ecf7fdc2986ac69916cf4f2849de76bd6664f0cf69e7a3a8786e6d392949-64.webp","size":24}],["$","b",null,{"children":"TRIGGERcmd"}],["$","small",null,{"children":"#467"}]]}]}],["$","li","4530",{"children":["$","$L5",null,{"href":"/connectors/have-i-been-pwned","prefetch":false,"children":[["$","$L23",null,{"name":"Have I Been Pwned","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/44/440498ff84a20b2de35e39fa2bfa9695ac2bc2fd87fd754756b9bbbe01441bf5-64.webp","size":24}],["$","b",null,{"children":"Have I Been Pwned"}],["$","small",null,{"children":"#426"}]]}]}],["$","li","4545",{"children":["$","$L5",null,{"href":"/connectors/workos","prefetch":false,"children":["$L2c","$L2d","$L2e"]}]}]]}]]}]]}] 22:o129,2c:["$","$L23",null,{"name":"WorkOS","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/fa/fab3112ca9f1751bb6eb573c7e18021fc70035e461c3a07847797f023f84b2c7-64.webp","size":24}] 2d:["$","b",null,{"children":"WorkOS"}] 2e:["$","small",null,{"children":"#447"}] 22:o11,20:false 1f:7031 22:o17,1e:C 1d:C 1:C 15:C b:C 22:C </article></body></html>

22:o1,#22:o647,2:"$Sreact.fragment" 3:"/_next/static/immutable/chunks/12yk9g49l7-7r.js" 4:"/_next/static/immutable/chunks/2jrhxdtf12-uf.js" 5:I[7575,["$3","$4"],""] 6:I[10291,["$3"],"default"] 7:I[2968,["$3"],"default"] 8:I[4098,["$3"],"WebMCP"] 9:I[57507,["$3"],"ExternalLinks"] a:I[93137,["$3"],"Analytics"] 10:"$Sreact.suspense" 16:"ViewportBoundary" 17:I[82520,["$3"],"$16"] 19:"MetadataBoundary" 1a:I[82520,["$3"],"$19"] :HL["/_next/static/immutable/chunks/3g2_9hnyt6p64.css","style"] 1:X b:X d:X 15:X f:[["children",{"s":"__PAGE__","h":49314,"d":{"r":["$","$2","c",{"children":[["$","$10",null,{"fallback":["$","div",null,{"className":"wrap","style":{"minHeight":"60vh"}}],"children":"$L11"}],["$L12","$L13"],"$L14"]}],"p":false,"v":"$15"}}]] e:[["children",{"s":{"n":"slug","t":"d","k":"sitelemetry","s":[]},"h":49250,"d":{"r":["$","$2","c",{"children":[null,["$","$L6",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L7",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}],"p":false,"v":"$d"},"c":"$Qf"}]] c:[["children",{"s":"connectors","h":49250,"d":{"r":["$","$2","c",{"children":[null,["$","$L6",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L7",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":"$undefined","forbidden":"$undefined","unauthorized":"$undefined"}]]}],"p":false,"v":"$d"},"c":"$Qe"}]] 1d:X 1e:X 22:o1232,0:{"q":"","i":false,"S":true,"r":"$1","t":{"t":{"s":"","h":49234,"d":{"r":["$","$2","c",{"children":[[["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/3g2_9hnyt6p64.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}],["$","script","script-0",{"src":"/_next/static/immutable/chunks/12yk9g49l7-7r.js","async":true,"nonce":"$undefined"}]],["$","html",null,{"lang":"en","className":"ec5Qua_variable","children":["$","body",null,{"children":[["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@graph\":[{\"@type\":\"Organization\",\"@id\":\"https://agentready.co/#org\",\"name\":\"Agent Ready\",\"url\":\"https://agentready.co/\",\"logo\":\"https://agentready.co/icon-512.png\"},{\"@type\":\"WebSite\",\"@id\":\"https://agentready.co/#site\",\"name\":\"Agent Ready\",\"url\":\"https://agentready.co/\",\"publisher\":{\"@id\":\"https://agentready.co/#org\"}}]}"}}],["$","header",null,{"className":"site","children":["$","div",null,{"className":"wrap","children":[["$","$L5",null,{"href":"/","className":"brand","children":[["$","svg",null,{"className":"brand-mark","viewBox":"0 0 64 64","aria-hidden":"true","children":[["$","defs",null,{"children":["$","linearGradient",null,{"id":"arg","x1":"0","y1":"1","x2":"1","y2":"0","children":[["$","stop",null,{"offset":"0","stopColor":"#2563EB"}],["$","stop",null,{"offset":"1","stopColor":"#06B6D4"}]]}]}],["$","path",null,{"d":"M9 55 L32 9 L55 55","fill":"none","stroke":"url(#arg)","strokeWidth":"11","strokeLinecap":"round","strokeLinejoin":"round"}],["$","circle",null,{"cx":"32","cy":"45","r":"7","fill":"#FACC15"}]]}],"Agent Ready"]}],["$","nav",null,{"aria-label":"Main","children":[["$","$L5",null,{"href":"/","children":"Connectors"}],["$","$L5",null,{"href":"/categories","className":"nv-x","children":"Categories"}],["$","$L5",null,{"href":"/blog","children":"Blog"}],["$","$L5",null,{"href":"/mcp-plugin-usage","className":"nv-x","children":"Usage"}],["$","$L5",null,{"href":"/methodology","className":"nv-x","children":"Methodology"}],["$","$L5",null,{"href":"/work-with-us","className":"nv-cta","children":"Work with us"}]]}]]}]}],["$","main",null,{"children":["$","$L6",null,{"parallelRouterKey":"children","error":"$undefined","errorStyles":"$undefined","errorScripts":"$undefined","template":["$","$L7",null,{}],"templateStyles":"$undefined","templateScripts":"$undefined","notFound":[[["$","title",null,{"children":"404: This page could not be found."}],["$","div",null,{"style":{"fontFamily":"system-ui,\"Segoe UI\",Roboto,Helvetica,Arial,sans-serif,\"Apple Color Emoji\",\"Segoe UI Emoji\"","height":"100vh","textAlign":"center","display":"flex","flexDirection":"column","alignItems":"center","justifyContent":"center"},"children":["$","div",null,{"children":[["$","style",null,{"dangerouslySetInnerHTML":{"__html":"body{color:#000;background:#fff;margin:0}.next-error-h1{border-right:1px solid rgba(0,0,0,.3)}@media (prefers-color-scheme:dark){body{color:#fff;background:#000}.next-error-h1{border-right:1px solid rgba(255,255,255,.3)}}"}}],["$","h1",null,{"className":"next-error-h1","style":{"display":"inline-block","margin":"0 20px 0 0","padding":"0 23px 0 0","fontSize":24,"fontWeight":500,"verticalAlign":"top","lineHeight":"49px"},"children":404}],["$","div",null,{"style":{"display":"inline-block"},"children":["$","h2",null,{"style":{"fontSize":14,"fontWeight":400,"lineHeight":"49px","margin":0},"children":"This page could not be found."}]}]]}]}]],[]],"forbidden":"$undefined","unauthorized":"$undefined"}]}],["$","$L8",null,{}],["$","$L9",null,{}],["$","$La",null,{}],["$","footer",null,{"className":"foot","children":["$","div",null,{"className":"wrap","children":[["$","span",null,{"children":"Agent Ready"}],["$","nav",null,{"aria-label":"Footer","children":[["$","$L5",null,{"href":"/blog","children":"Blog"}],["$","$L5",null,{"href":"/mcp-plugin-usage","children":"Usage"}],["$","$L5",null,{"href":"/methodology","children":"Methodology"}],["$","$L5",null,{"href":"/categories","children":"Categories"}],["$","a",null,{"href":"/llms.txt","children":"llms.txt"}],["$","a",null,{"href":"/sitemap.xml","children":"Sitemap"}],["$","$L5",null,{"href":"/work-with-us","children":"Work with us"}]]}]]}]}]]}]}]]}],"p":false,"v":"$b"},"c":"$Qc"},"h":{"r":["$","$2","h",{"children":[null,["$","$L17","GgKuzjZ-lFwBKlkMhghKwv",{"children":"$L18"}],["$","$L1a","GgKuzjZ-lFwBKlkMhghKwm",{"children":[["$","div",null,{"hidden":true,"children":["$","$10",null,{"name":"Next.Metadata","children":"$L1b"}]}],"$L1c"]}]]}],"p":false,"v":"$1d"}},"s":"$1e","a":"$@1f","w":"$@20"} 22:o1b1,21:I[82520,["$3"],"OutletBoundary"] :HL["/_next/static/immutable/chunks/2lo4itc7piqdu.css","style"] d:C 12:["$","link","0",{"rel":"stylesheet","href":"/_next/static/immutable/chunks/2lo4itc7piqdu.css","precedence":"next","crossOrigin":"$undefined","nonce":"$undefined"}] 13:["$","script","script-0",{"src":"/_next/static/immutable/chunks/2jrhxdtf12-uf.js","async":true,"nonce":"$undefined"}] 14:["$","$L21",null,{"children":"$@22"}] 22:o14d,1e:300 18:[["$","meta","0",{"charSet":"utf-8"}],["$","meta","1",{"name":"viewport","content":"width=device-width, initial-scale=1"}],["$","meta","2",{"name":"theme-color","content":"#ffffff","media":"(prefers-color-scheme: light)"}],["$","meta","3",{"name":"theme-color","content":"#0d0d0f","media":"(prefers-color-scheme: dark)"}]] 22:o25,1d:0 15:0 15:T4,slug1d:T4,slug1e:300 22:o68,23:I[37521,["$3","$4"],"Logo"] 24:I[53913,["$3","$4"],"Explore"] 2b:I[60329,["$3"],"IconMark"] 25:T144f,22:o144f,--- name: ai-visibility description: Use the Sitelemetry AI visibility (GEO/AEO) and technical SEO audits on a site the user owns to propose evidence-backed changes such as robots.txt rules for AI crawlers, schema.org JSON-LD structured data, an llms.txt file and content edits, each only where the findings support it. Use when the user asks how AI assistants and AI search can crawl, understand or cite their site, or wants to improve GEO, AEO or structured data. --- # AI visibility ## Ground rules - Reply in the user's language. For the audit tools, set `lang` as described in the `website-audit` skill. `lang` changes the report wording, not the measurement criteria. - Only audit sites the user owns or is authorized to test. If that is not clear, ask first. - Be precise about what is measured. `audit_ai_visibility` checks entity clarity, answerability, source signals and AI-crawler policy on the site's own pages. The `prompts` option runs content-readiness checks against the site; it does not query any AI provider. `competitors` are names used to assess comparison content; competitor sites are not audited. Nothing here measures or guarantees whether an AI assistant mentions or cites the site. Say this when you present results. ## 1. Run the audits 1. `audit_ai_visibility` on the target. - `brand`: pass it if the user gives one or the site name is ambiguous; otherwise it is inferred from the site. - `prompts`: real questions the site's audience asks, supplied by the user (up to 24, each up to 500 characters). Only as many prompts as the connected account's prompt limit are checked, and any beyond it are left out. If the result shows fewer prompts than were supplied, say so. - `competitors`: names only, if the user supplies them (up to 8). - `maxPages` and `promptLimit`: leave them out unless the user asks; defaults follow the connected account. 2. `audit_seo` on the same target when structured data, crawlability, indexation or metadata matter to the request. Start it only after the first audit has a final status. Handle `running`, `action_required` and errors as in the `website-audit` skill: poll with `pollArguments` exactly as returned, never start a duplicate audit, and relay access or limit messages neutrally. ## 2. Map findings to changes Propose a change only when a returned finding, or its evidence, supports it. Cite the finding next to each proposal. | Finding area | Change to propose | |---|---| | AI-crawler policy: crawlers blocked, rules unclear or inconsistent | robots.txt rules per crawler | | Structured data missing, invalid or not describing the main entity | schema.org JSON-LD for the real organization, site and page types | | Entity clarity | clear statements of who the organization is, what it offers and where, on the home and about pages | | Answerability | answer-first sections and FAQs based on real customer questions | | Source signals | author and date information, about and contact pages, references, consistent names | | No machine-readable site summary, when reported or when the user asks | an llms.txt file | Crawler names, robots.txt patterns and JSON-LD and llms.txt templates: [AI crawlers, JSON-LD and llms.txt](references/ai-crawlers-and-schema.md). ## 3. Rules for each change - **robots.txt**: the site owner decides which crawlers may access the site. Explain the difference between crawlers that collect training data and those that fetch pages for search or for a user's request. Keep the existing rules and the `Sitemap` line, and never block general search crawlers such as `Googlebot` or `Bingbot` by accident. - **JSON-LD**: describe only facts that are true and visible on the page. Ask the user for facts you do not have (legal name, logo URL, official profiles). Never invent ratings, reviews, prices, addresses, opening hours or FAQs. Use one stable `@id` per entity across pages, and check the markup with a structured-data validator before publishing. - **llms.txt**: present it as an optional, low-effort convention that not every AI provider reads. Link only to real, public pages. - **Content**: write edits in the site's voice and mark them as drafts for the user to review. Do not add claims the user has not confirmed. ## 4. Present and re-test Group the proposals by effort: configuration first (robots.txt, llms.txt), then markup (JSON-LD), then content. For each, name the finding it addresses, the change and where it goes. ```text AI visibility for https://example.com/ (score if returned) What this measures: content-readiness signals on your pages, not live AI answers. 1. Configuration - Finding: (<severity>). Change: <robots.txt rule>. Where: /robots.txt 2. Markup - Finding: <title> (<severity>). Change: Organization JSON-LD. Where: home page head 3. Content - Finding: <title> (<severity>). Change: <draft edit>. Where: <page> Not measured: <anything the result marks as unavailable or partial> ``` After the user publishes the changes, offer to re-run the same audits with the same arguments and compare the results by `findingKey`, as in the `fix-and-retest` skill. Report what changed and what is still open or not measured. 22:o9,26:T17ce,22:o17ce,--- name: domain-verification description: Explain and help complete Sitelemetry ownership verification when an audit returns action_required because the target is not verified, the proof has expired, the target spelling differs from the verified one, or the proof does not cover host-wide checks. Covers the DNS TXT record, HTTP file and Google Search Console methods, then retries the same audit. Use when an audit asks for verification or the user asks how to verify their site. --- # Domain verification ## Ground rules - Reply in the user's language. - Verification shows that the user controls the site. Help only with sites the user owns or administers, and never suggest ways around verification. - Verification is completed in the user's Sitelemetry web workspace, not through the audit tools. Give the user the `nextAction.url` the tool returned; do not guess other account URLs. - When a tool asks for verification, no audit ran and no audit allowance was used. - Never ask for passwords, API tokens or DNS, hosting or Google account credentials. The user makes the change, or you edit project files with their approval. ## 1. Read the reason | `reason` | `nextAction.type` | Meaning | What to do | |---|---|---|---| | `target_verification_required` | `verify_target` | No current proof for this exact target | Choose a method (section 2) | | `target_reverification_required` | `renew_verification` | The proof expired: it was last checked more than 30 days ago | Keep the DNS record or file in place and run the check again in the workspace, or sync Google Search Console again | | `verified_target_required` | `review_verified_target` | The target spelling differs from the verified one; `registeredTarget` shows the verified spelling | Show both spellings and ask the user which one to audit. Use `registeredTarget` only after they confirm, or verify the other spelling | | `verification_scope_required` | `verify_host` | A URL-prefix proof cannot authorize host-wide security checks | Verify the domain, the hostname or the root URL, or run only checks that the verified prefix covers | Targets are matched exactly. `https://example.com/` and `https://www.example.com/` are different targets, and so are different ports and paths. Verify the spelling the user wants to audit. ## 2. Verification methods The workspace issues a token that starts with `sitelemetry-` and shows the exact record name and file URL for the target. Always use the values it shows. ### DNS TXT record - Name: `_sitelemetry-challenge.<hostname>`, for example `_sitelemetry-challenge.example.com`, or `_sitelemetry-challenge.www.example.com` for the `www` host. - Value: the token, exactly. - Many DNS panels add the domain automatically; then enter only `_sitelemetry-challenge` (or `_sitelemetry-challenge.www`) in the name field. - New records can take from minutes to hours to become visible, depending on TTL. Check with `nslookup -type=TXT _sitelemetry-challenge.example.com` or `dig +short TXT _sitelemetry-challenge.example.com`. ### HTTP file - URL: `https://<host>/.well-known/sitelemetry-verification.txt` - Content: only the token, as plain text. Surrounding whitespace is ignored. The file must be smaller than 2 KB. - The URL must answer with a success status over HTTPS with a valid certificate. A redirect to another host, protocol or port fails the check. - Where the file usually goes: - Next.js, Vercel and most static site generators: `public/.well-known/sitelemetry-verification.txt` - Netlify: `.well-known/sitelemetry-verification.txt` inside the publish directory - nginx or Apache: the `.well-known` folder in the document root. Make sure rules that hide dot-folders do not block it; in nginx, a `location ^~ /.well-known/ { }` block takes precedence over regex rules that deny dot-folders. - WordPress: the `.well-known` folder in the site's root directory, uploaded with the host's file manager or SFTP - Check it with `curl -s https://example.com/.well-known/sitelemetry-verification.txt`; the output must be the token. ### Google Search Console Available when the workspace offers a Google connection and the user is a verified owner of the property. - A Domain property (`sc-domain:example.com`) covers the whole host, including host-wide checks. - A URL-prefix property covers only that prefix. It authorizes host-wide checks only when it is the root URL of the hostname, such as `https://example.com/`. ## 3. What verification covers - Host-wide security checks need proof for the domain, the hostname or the root URL. A proof for a path prefix such as `https://example.com/shop/` covers only checks that work within that prefix. - On an account with security-only access, a default `audit_security` call (or a default `audit_full`, which on such an account runs security only) runs seven public checks without verification: DNS, email DNS, RDAP, TLS, HTTP headers, MITM posture and technology fingerprint. Verification adds checks for HTTP methods, exposed files and paths, and API exposure. An explicit `modules` list runs without verification only if every module is one of those seven public checks (`dns`, `dns-email`, `rdap`, `tls`, `http-headers`, `mitm-posture`, `tech-fingerprint`). Any other module needs current verification, and host-wide modules need host proof. - On other accounts, every audit needs current verification of the exact target, including the public checks. - Verification does not create a monitoring project. The first accepted audit creates one automatically. - A proof stays current for 30 days after it was last checked. Keep the DNS record or file in place so it can be checked again. ## 4. Retry Retry only after the user confirms that the workspace shows the target as verified. - Call the same tool with the same `target` spelling and the same arguments as the rejected call. - If the result is again a verification reason, compare the target spelling with the verified one and check whether the proof is current. Do not retry in a loop. - Then continue with the `website-audit` skill to present the results. 22:o9,27:T135d,22:o135d,--- name: fix-and-retest description: Turn Sitelemetry audit findings into concrete fixes for the user's stack (nginx, Apache, Cloudflare, Vercel or Next.js, Netlify, WordPress), apply them with the user's approval or hand them over ready to use, then re-run the same audit on the same target and report honestly what is resolved, still open or not measured. Use after an audit when the user asks how to fix the findings, wants the changes made, or wants to confirm that a fix worked. --- # Fix and re-test ## Ground rules - Reply in the user's language. For the audit tools, set `lang` as described in the `website-audit` skill. - Only change and re-test sites the user owns or is authorized to test. - Base every fix on a returned finding: its evidence, impact and `remediation`. If you suggest something the audit did not report, label it as an extra suggestion. - Never say a fix worked until a re-test has measured it. ## 1. Start from real findings Use the findings of an audit from this conversation. If there are none, run one first with the `website-audit` skill. For every finding, note its `findingKey`, severity, title and `location`, and note the exact tool, `target` and options of that run. The re-test must repeat them. ## 2. Identify the stack Ask the user, or infer it from the project when you can read its files. | Signal | Stack | |---|---| | `nginx.conf`, `sites-available/`, `conf.d/` | nginx | | `.htaccess`, `httpd.conf`, `apache2.conf` | Apache | | Site proxied through Cloudflare, rules in the Cloudflare dashboard | Cloudflare | | `vercel.json`, `next.config.js`, `next.config.mjs`, `next.config.ts` | Vercel or Next.js | | `netlify.toml`, `_headers`, `_redirects` | Netlify | | `wp-config.php`, `wp-content/` | WordPress | When a CDN or proxy sits in front of the origin, it can add, replace or cache headers. Decide which layer owns each header and set it in one place. ## 3. Write the fixes Work from critical to info. For each finding give: - what changes and where (file path or dashboard location); - the change for the user's stack, adapted to the site; - the risk and how to roll it back; - how to check it before re-testing, for example `curl -sI https://example.com/` for response headers. Starting points for common findings (security headers, HTTPS redirect, HSTS, server version disclosure, caching, compression and email DNS records) are in [stack snippets](references/stack-snippets.md). Adapt them to the site; do not paste them blindly. Safety rules: - **Content-Security-Policy**: start with `Content-Security-Policy-Report-Only`, check the browser console for violations, then enforce. A strict policy copied without testing breaks sites. - **HSTS**: start with a short `max-age`. Add `includeSubDomains` only when every subdomain serves HTTPS, and `preload` only when the owner decides to submit the domain to browser preload lists. - **DNS and email records** (SPF, DKIM, DMARC, CAA): the user changes these at their DNS provider. Start DMARC at `p=none` with reports before moving to `quarantine` or `reject`. - Never ask for or handle passwords, API tokens or hosting and DNS credentials. ## 4. Apply or hand over - With access to the project files (for example in Claude Code): show the diff and apply it only after the user agrees. Do not deploy, restart services or change production settings on your own. - Without file access: give complete, copy-ready changes and the order to apply them in. - Ask the user to tell you when the changes are live. If the site uses a CDN or page cache, ask them to purge it so the re-test sees the new responses. ## 5. Re-test the same way - Tell the user that the re-test is a new audit run and uses the account's audit allowance. - Call the same tool with the same `target` spelling and the same options as the first run (`profile`, `modules`, `maxPages`, `strategy` and so on). A different scope makes the comparison invalid. - Handle `running`, `action_required` and errors as in the `website-audit` skill: poll with `pollArguments` unchanged and never start a duplicate audit. ## 6. Report before and after Match findings across the two runs by `findingKey`. | Result | Rule | |---|---| | Resolved | In the first run, absent from the re-test, and the check was measured in the re-test | | Still open | Present in both runs | | New | Present only in the re-test | | Not measured | The check was unmeasured, unavailable or partial in the re-test (see `coverageStatus`, `auditDetails` and `failedPillars`). Do not count it as resolved. | Show a table with the finding, severity, before, after and result. Report a score change only when both runs have a non-null score, and mention that scores can move for other reasons too, such as lab variance in performance measurements. If `findingsTruncated` was true in either run, say that the comparison covers only the returned findings. End with what is still open and the next step for each item. 22:o9,28:T1235,22:o1235,--- name: pre-launch-check description: Run a pre-release check of a website the user owns with Sitelemetry security, performance and accessibility audits, plus technical SEO when the site is meant to be indexed, then summarise launch blockers versus warnings using only measured results. Use when the user is about to launch, deploy, go live, migrate or redesign a site and wants to know what must be fixed first. --- # Pre-launch check ## Ground rules - Reply in the user's language. For the audit tools, set `lang` as described in the `website-audit` skill. - Only check sites the user owns or is authorized to test. If that is not clear, ask first. - The security audit sends test requests to the site. Depending on the account, these can include active, non-destructive probes such as port and injection checks, which may show up in server logs or firewall alerts. Tell the user before running it on a site that has not been audited before. - Use only the scores, severities and findings the tools return. Never invent a score, a pass or a measurement. ## 1. Confirm the scope - **Target**: the exact public `https://` URL, spelled as verified in the user's Sitelemetry workspace. A staging site must be reachable over public HTTPS; localhost, private addresses and hosts behind a VPN cannot be audited. A staging hostname is a separate target and needs its own verification. - **Indexing**: ask whether the site should be indexed by search engines at launch. Include `audit_seo` only if it should. On a staging site that is deliberately `noindex`, indexation findings are expected; say so rather than listing them as blockers. - **Runs**: tell the user which audits you will run and that each one is a separate audit that uses the account's audit allowance. If they prefer a single run, `audit_full` covers every audit area included in the connected account in one call. ## 2. Run the audits one at a time Default order: 1. `audit_security` 2. `audit_performance` with `strategy: "mobile"` (add a `desktop` run only if the user asks) 3. `audit_accessibility` 4. `audit_seo`, if indexing is in scope For each audit: - Wait for the final status before starting the next. On `running`, wait about `retryAfterMs` and call the same tool with `pollArguments` exactly as returned. Never start a duplicate audit. - Keep the same `target` spelling on every call. - On `action_required`, no audit ran and no allowance was used. - Access or allowance reasons: note it, relay the next step neutrally with the returned link, and continue with the other audits. - `target_verification_required`, `target_reverification_required` or `verified_target_required`: stop, because the other audits need the same proof for the same target, and follow the `domain-verification` skill. - `verification_scope_required`: only the host-wide security checks need broader proof. Record security as not measured, continue with the other audits, and point to the `domain-verification` skill for domain, hostname or root URL proof. - On an error, note it and continue with the next audit. ## 3. Classify the results Keep the severities the tools assign; do not re-grade them. - **Blockers**: critical and high findings. - **Warnings**: medium findings. - **Notes**: low and info findings. - **Not measured**: checks, areas or metrics that the results mark as unavailable, partial, failed or outside the connected account's access, and any audit that did not run. These are unknowns, not passes. When the same issue appears in two audits, list it once and name both. ## 4. Report Use this structure: ```text Pre-launch check for https://example.com/ (date) Audits: security completed, performance (mobile) partial, accessibility completed, SEO not run (site not indexed yet) Blockers (2) 1. [security, high] <title> at <location>: <fix> 2. [accessibility, high] <title> at <location>: <fix> Warnings (3) ... Notes (4): one line each, or a count if there are many Not measured - performance: <what was unavailable, from the result> Scores returned: security <score> (<grade>), accessibility <score> ``` Only list scores that the tools returned as numbers. A null score means the area was not measured. Verdict: - With blockers: "Not ready yet: fix these N blockers first", followed by the blockers in order of severity. - Without blockers: "No blockers were found in the measured checks", followed by the Not measured list. Never state that the site is secure, fully accessible or compliant; the audits cover specific automated checks. Offer the `fix-and-retest` skill for the blockers and, after fixes, a re-run of the same audits with the same arguments. 22:o9,29:T1d6c,22:o1d6c,--- name: website-audit description: Run a Sitelemetry audit on a website the user owns or is authorized to test, wait correctly for long-running audits, and present the findings ranked by severity with the top fixes. Use when the user asks to audit, scan, check or score their own site for security, technical SEO, AI visibility, analytics and tracking, accessibility (WCAG) or performance (Core Web Vitals), or asks for an overall site health check. --- # Website audit Use the Sitelemetry audit tools to measure a website and explain what to fix first. ## Ground rules - Reply in the user's language. Set `lang` to the user's language when it is one of `en`, `tr`, `es`, `de`, `fr`, `pt`, `it`, `ja` or `zh`; otherwise leave `lang` out and translate your summary yourself. `lang` changes the wording of the result, not what is measured. - Only audit sites the user owns or is authorized to test. If that is not clear, ask before calling any tool. Do not audit competitors or other third-party sites. - The audits run from Sitelemetry's servers and do not change the site. Starting an audit uses the connected account's audit allowance (it is released again if the audit fails). Polling a running audit and `action_required` results use none. - Security and full audits send test requests to the site. Depending on the account, these can include active, non-destructive probes such as port and injection checks, which may show up in the site's server logs or firewall alerts. Mention this when the user has not audited the site before. - Never invent scores, grades, findings, measurements or report links. ## 1. Get the exact target If the user started this skill with arguments, the first one is the target URL and an optional second word names the area: `security` (`audit_security`), `seo` (`audit_seo`), `ai` (`audit_ai_visibility`), `integrations` (`audit_integrations`), `accessibility` (`audit_accessibility`), `performance` (`audit_performance`) or `full` (`audit_full`). Confirm ownership or authorization as usual before calling. If only a URL was given and the conversation does not say which area, ask, or use `audit_full` if the user wants everything. `target` must be an absolute `https://` URL spelled exactly as it is verified in the user's Sitelemetry workspace. - Scheme, `www` or no `www`, port, path, path casing and query all count. Only hostname case, an explicit `:443` and a trailing slash are ignored. - Only public hosts are accepted: no localhost, private addresses, credentials in the URL or `#fragment`. - If the user gives a bare domain such as `example.com`, confirm the exact URL (for example `https://example.com/` or `https://www.example.com/`) before calling. - Keep the same spelling on every retry and every poll. ## 2. Pick the narrowest tool | The user asks about | Tool | Options worth knowing | |---|---|---| | Security headers, TLS, DNS, email authentication, exposed files, ports | `audit_security` | `profile`, `modules`, `ports`, only when the user asks | | Crawlability, indexation, metadata, structured data, internal links | `audit_seo` | `maxPages` (1-30), `includeSearchConsole`, `searchConsoleDays` (7, 28 or 90) | | AI visibility, GEO, AEO, AI crawler policy | `audit_ai_visibility` | `brand`, `prompts`, `competitors`, `maxPages`, `promptLimit` | | Analytics, tags, marketing pixels, consent, site verification tags | `audit_integrations` | none | | Accessibility, WCAG | `audit_accessibility` | none | | Speed, PageSpeed, Core Web Vitals | `audit_performance` | `strategy`: `mobile` (default) or `desktop` | | Everything, overall health, one combined score | `audit_full` | any of the above | - Leave options out unless the user asked for them; defaults follow the connected account's access. Unknown options are rejected, so send only options the chosen tool lists. - `profile` and `modules` exist only on `audit_security` and `audit_full`. Leaving both out requests every security module included in the connected account. - `includeSearchConsole` uses the Google connection already set up in the workspace; missing access does not stop the audit. When it is left out, `audit_seo` and `audit_full` (when it includes SEO) still add Search Console data if the workspace has that connection. Search Console data is metered separately from the audit allowance. Set `includeSearchConsole` to `false` if the user does not want it. - `audit_accessibility` is a static WCAG 2.2 check, not a full manual accessibility review. Say so when it matters. - Run one audit at a time. Do not start another audit while one is running. ## 3. Handle the result status Read `status` first. Every reason and error is described in [result handling](references/result-handling.md). - `completed` or `partial`: present the result (section 4). `partial` means some requested measurements were unavailable. - `running`: the audit is still in progress. Tell the user in one line, wait about `retryAfterMs`, then call the **same tool** with `pollArguments` exactly as returned. Do not add scan options. Repeat until the status is final. Polling resumes the same audit; it does not start a new one or use more allowance. Full and security audits can take several minutes. Never present `running` as a result and never start a replacement audit. - `action_required`: no audit ran and no allowance was used. Explain the `reason` and pass on `nextAction.url` exactly as returned. Do not retry until the prerequisite has changed. For verification reasons, follow the `domain-verification` skill. - Error (`isError` with text starting `Error:`): relay the message plainly and suggest the correction it points to, such as the exact verified target spelling or a narrower scope. ## 4. Present the findings 1. **Summary line**: target, audit type, status, and `score` and `grade` (or `blended` for `audit_full`) only when they are not null. A null score means the area was not measured; it is not zero. 2. **Coverage**: what was not measured and why, from `coverageStatus`, `executionComplete`, `auditDetails` and, for `audit_full`, `failedPillars` and areas outside the connected account's access. A completed run does not prove every check was measured, and unmeasured checks are not passes. 3. **Findings by severity**: critical, high, medium, low, then info. For each give the title, `location` if present, the evidence, the impact and the fix (`remediation`). For `audit_full`, also name the `pillar`. If `findingsTruncated` is true, say that `returnedFindings` of `total` findings were returned. 4. **Top fixes**: the three to five changes that remove the most severe risk first, in order, each tied to the findings it resolves. 5. **Passing checks**: one line with `passingChecks` or the main passing items. Keep each finding's `findingKey`, the tool and the exact arguments you used, so a later re-test can be compared like for like. Offer the `fix-and-retest` skill as the next step. Results normally come without a report link. If the result text includes one, you may pass it on; it opens in the user's signed-in Sitelemetry workspace. ## Access and limit messages When a result says that an audit, profile or module is not included in the connected account, or that the audit allowance is used up, repeat that fact neutrally together with the link the tool returned. Do not add sales wording, plan recommendations or prices. If the result offers a security-only alternative for the same target, you may mention it, and say that it does not complete the audit that was requested. 22:oeb5,11:[["$","script",null,{"type":"application/ld+json","dangerouslySetInnerHTML":{"__html":"{\"@context\":\"https://schema.org\",\"@type\":\"SoftwareApplication\",\"name\":\"Sitelemetry\",\"description\":\"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn the findings into prioritized fixes and re-test them.\",\"applicationCategory\":\"IT & security\",\"operatingSystem\":\"Claude\",\"url\":\"https://agentready.co/connectors/sitelemetry\",\"sameAs\":[],\"publisher\":{\"@type\":\"Organization\",\"name\":\"egenil\",\"url\":\"https://github.com\"}}"}}],["$","div",null,{"className":"wrap","children":[["$","div",null,{"className":"pp-head","children":[["$","$L23",null,{"name":"Sitelemetry","url":null,"size":56}],["$","div",null,{"children":[["$","div",null,{"className":"crumbs","children":[["$","$L5",null,{"href":"/","children":"Connectors"}],[" / ",["$","$L5",null,{"href":"/categories/security-it","children":"IT & security"}]]]}],["$","h1",null,{"children":["Sitelemetry",null]}]]}]]}],["$","div",null,{"className":"pp","children":[["$","div",null,{"className":"ca","children":[["$","p",null,{"className":"tag","children":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn the findings into prioritized fixes and re-test them."}],null,["$","$L24",null,{"examples":[],"tools":[],"prefix":"","server":{"url":"https://claude-mcp.sitelemetry.com/mcp","login":"OAuth","protocol":null,"extras":[]},"instructions":[],"skills":[{"name":"ai-visibility","label":"Ai visibility","gist":"Use the Sitelemetry AI visibility (GEO/AEO) and technical SEO audits on a site the user owns to propose evidence-backed changes such as robots.txt rules for AI crawlers, schema.org JSON-LD structured","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/ai-visibility/SKILL.md","raw":"$25"},{"name":"domain-verification","label":"Domain verification","gist":"Explain and help complete Sitelemetry ownership verification when an audit returns action_required because the target is not verified, the proof has expired, the target spelling differs from the verif","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/domain-verification/SKILL.md","raw":"$26"},{"name":"fix-and-retest","label":"Fix and retest","gist":"Turn Sitelemetry audit findings into concrete fixes for the user's stack (nginx, Apache, Cloudflare, Vercel or Next.js, Netlify, WordPress), apply them with the user's approval or hand them over ready","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/fix-and-retest/SKILL.md","raw":"$27"},{"name":"pre-launch-check","label":"Pre launch check","gist":"Run a pre-release check of a website the user owns with Sitelemetry security, performance and accessibility audits, plus technical SEO when the site is meant to be indexed, then summarise launch block","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/pre-launch-check/SKILL.md","raw":"$28"},{"name":"website-audit","label":"Website audit","gist":"Run a Sitelemetry audit on a website the user owns or is authorized to test, wait correctly for long-running audits, and present the findings ranked by severity with the top fixes.","source":"https://github.com/egenil/sitelemetry-claude-plugin/blob/b17862b30ee05ed173604715dfefd1acb68f17e8/skills/website-audit/SKILL.md","raw":"$29"}],"skillNote":"5 in the Claude listing"}],null]}],"$L2a"]}]]}]] 22:oa4a,1b:[["$","title","0",{"children":"Sitelemetry by egenil: AI connector · Agent Ready"}],["$","meta","1",{"name":"description","content":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn…"}],["$","link","2",{"rel":"manifest","href":"/manifest.webmanifest","crossOrigin":"$undefined"}],["$","link","3",{"rel":"canonical","href":"https://agentready.co/connectors/sitelemetry"}],["$","meta","4",{"property":"og:title","content":"Sitelemetry by egenil: AI connector"}],["$","meta","5",{"property":"og:description","content":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn…"}],["$","meta","6",{"property":"og:url","content":"https://agentready.co/connectors/sitelemetry"}],["$","meta","7",{"property":"og:site_name","content":"Agent Ready"}],["$","meta","8",{"property":"og:image","content":"https://agentready.co/connectors/sitelemetry/opengraph-image?3b61e23efdbb5225"}],["$","meta","9",{"property":"og:image:type","content":"image/png"}],["$","meta","10",{"property":"og:image:width","content":"1200"}],["$","meta","11",{"property":"og:image:height","content":"630"}],["$","meta","12",{"property":"og:image:alt","content":"AI connector on Agent Ready"}],["$","meta","13",{"property":"og:type","content":"website"}],["$","meta","14",{"name":"twitter:card","content":"summary_large_image"}],["$","meta","15",{"name":"twitter:title","content":"Sitelemetry by egenil: AI connector"}],["$","meta","16",{"name":"twitter:description","content":"Audit websites you own or are authorized to test for security, technical SEO, AI visibility, analytics and tracking, accessibility and performance, then turn…"}],["$","meta","17",{"name":"twitter:image","content":"https://agentready.co/connectors/sitelemetry/opengraph-image?3b61e23efdbb5225"}],["$","meta","18",{"name":"twitter:image:alt","content":"AI connector on Agent Ready"}],["$","meta","19",{"name":"twitter:image:type","content":"image/png"}],["$","meta","20",{"name":"twitter:image:width","content":"1200"}],["$","meta","21",{"name":"twitter:image:height","content":"630"}],["$","link","22",{"rel":"icon","href":"/favicon.ico?favicon.3iymezf4ycw3e.ico","sizes":"64x64","type":"image/x-icon"}],["$","link","23",{"rel":"icon","href":"/icon.svg?icon.1m07wgr9jqhm5.svg","sizes":"any","type":"image/svg+xml"}],["$","link","24",{"rel":"apple-touch-icon","href":"/apple-icon.png?apple-icon.3q8qrgufoflqu.png","sizes":"180x180","type":"image/png"}],["$","$L2b","25",{}]] 22:o10,1c:null 22:null 22:o22,:HL["/stores/claude.png","image"] 22:o1290,2a:["$","aside",null,{"className":"side","children":[["$","div",null,{"className":"card","children":[["$","h2",null,{"children":"Stores"}],["$","div",null,{"className":"st","children":[["$","div","claude",{"style":{"display":"contents"},"children":[["$","span",null,{"className":"s","children":[["$","img",null,{"className":"sm","src":"/stores/claude.png","alt":"","width":16,"height":16}],["$","b",null,{"children":"Claude"}],["$","a",null,{"className":"src","href":"https://github.com/egenil/sitelemetry-claude-plugin","target":"_blank","rel":"noopener nofollow","children":"Source ↗"}]]}],["$","span",null,{"className":"rk2","children":[["$","small",null,{"children":"Listed, not ranked"}],null]}]]}]]}]]}],["$","div",null,{"className":"card","children":[["$","h2",null,{"children":"Details"}],["$","dl",null,{"className":"kv","children":[[["$","dt",null,{"children":"Company"}],["$","dd",null,{"children":"egenil"}]],[["$","dt",null,{"children":"Publisher"}],["$","dd",null,{"children":"Community"}]],["$","dt",null,{"children":"Category"}],["$","dd",null,{"children":["$","$L5",null,{"href":"/categories/security-it","children":"IT & security"}]}],[["$","dt",null,{"children":"Audience"}],["$","dd",null,{"children":"For developers"}]],null,["$","dt",null,{"children":"Sign-in"}],["$","dd",null,{"children":"None needed"}],["$","dt",null,{"children":"Interactive UI"}],["$","dd",null,{"children":"No"}],[["$","dt",null,{"children":"Checked"}],["$","dd",null,{"children":"Oct 27, 2026"}]],null]}]]}],["$","div",null,{"className":"card","children":[["$","h2",null,{"children":["More in ","IT & security"]}],["$","ul",null,{"className":"sim","children":[["$","li","14778",{"children":["$","$L5",null,{"href":"/connectors/remote-desktop-commander","prefetch":false,"children":[["$","$L23",null,{"name":"Remote Desktop Commander","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/b5/b5a9082663d57b64df78838701ea5ae096cf89afc03ebffa0f7a46cedff03231-64.webp","size":24}],["$","b",null,{"children":"Remote Desktop Commander"}],["$","small",null,{"children":"#357"}]]}]}],["$","li","4663",{"children":["$","$L5",null,{"href":"/connectors/freshservice","prefetch":false,"children":[["$","$L23",null,{"name":"Freshservice","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/0a/0a8072b376751e49e35758ccbc379dd5899695b9891dfc0ca4d65fc04ec7f0c9-64.webp","size":24}],["$","b",null,{"children":"Freshservice"}],["$","small",null,{"children":"#176"}]]}]}],["$","li","15096",{"children":["$","$L5",null,{"href":"/connectors/codex-security","prefetch":false,"children":[["$","$L23",null,{"name":"Codex Security","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/9b/9b9c2b09b2fa064611fb62307d321d5c2ea70cf0789f7ce34cdb0fc0d9190b3a-64.webp","size":24}],["$","b",null,{"children":"Codex Security"}],["$","small",null,{"children":"#410"}]]}]}],["$","li","4449",{"children":["$","$L5",null,{"href":"/connectors/malwarebytes","prefetch":false,"children":[["$","$L23",null,{"name":"Malwarebytes","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/6b/6b0d1f4fdc751c893519ae7edf22539020f70a4447410ac0c8586b501661b336-64.webp","size":24}],["$","b",null,{"children":"Malwarebytes"}],["$","small",null,{"children":"#337"}]]}]}],["$","li","15486",{"children":["$","$L5",null,{"href":"/connectors/chatgpt-admin","prefetch":false,"children":[["$","$L23",null,{"name":"ChatGPT Admin","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/13/1396309d23a53fd780c162b74ddd8fc23f67ce0ec59d8339d1e4ec13f9d7843b-64.webp","size":24}],["$","b",null,{"children":"ChatGPT Admin"}],["$","small",null,{"children":"#459"}]]}]}],["$","li","15254",{"children":["$","$L5",null,{"href":"/connectors/triggercmd","prefetch":false,"children":[["$","$L23",null,{"name":"TRIGGERcmd","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/ec/eca7ecf7fdc2986ac69916cf4f2849de76bd6664f0cf69e7a3a8786e6d392949-64.webp","size":24}],["$","b",null,{"children":"TRIGGERcmd"}],["$","small",null,{"children":"#467"}]]}]}],["$","li","4530",{"children":["$","$L5",null,{"href":"/connectors/have-i-been-pwned","prefetch":false,"children":[["$","$L23",null,{"name":"Have I Been Pwned","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/44/440498ff84a20b2de35e39fa2bfa9695ac2bc2fd87fd754756b9bbbe01441bf5-64.webp","size":24}],["$","b",null,{"children":"Have I Been Pwned"}],["$","small",null,{"children":"#426"}]]}]}],["$","li","4545",{"children":["$","$L5",null,{"href":"/connectors/workos","prefetch":false,"children":["$L2c","$L2d","$L2e"]}]}]]}]]}]]}] 22:o129,2c:["$","$L23",null,{"name":"WorkOS","url":"https://bodgzvrssuydrdmsrqsh.supabase.co/storage/v1/object/public/listing-media/v/fa/fab3112ca9f1751bb6eb573c7e18021fc70035e461c3a07847797f023f84b2c7-64.webp","size":24}] 2d:["$","b",null,{"children":"WorkOS"}] 2e:["$","small",null,{"children":"#447"}] 22:o11,20:false 1f:7031 22:o17,1e:C 1d:C 1:C 15:C b:C 22:C </article></body></html>

Sitelemetry

MCP connector

Skills

Sitelemetry

MCP connector

Skills