agentleFS
sitetillersitetiller/ai-visibility-skills/skills/platforms/SKILL.md

platforms

Skill0 starsChanged 2 days agoMITView on GitHub

SEO and AI visibility on each site platform, and how to publish new pages to it safely: WordPress, Ghost, static sites on GitHub (Next.js, Astro, Hugo with Vercel, Netlify or Cloudflare Pages), Webflow, Shopify, Wix, Squarespace, Framer, HubSpot CMS, WordPress.com, Drupal and headless CMSs (Contentful, Sanity, Strapi). For each: which SEO fields can be set (title, description, canonical, noindex, JSON-LD, Open Graph), what the platform controls (sitemap, robots.txt), the write API and its access rules, and a fallback when no API exists. Use when the user names their platform: 'SEO on Shopify', 'Webflow canonical', 'Wix SEO settings', 'Squarespace robots.txt', 'publish to Ghost by API', 'Framer SEO', 'which platform is best for SEO', or 'can SiteTiller publish to my site'.

The file

We split this skill into the rules it gives an agent

3 rules. About 0 are common, 2 are distinctive, and 1 is very specific to this project.

  • ≈0

    Common · estimate

    Many files like this have a rule of this kind.

  • ≈2

    Distinctive · estimate

    This author's own choices. Worth a look.

  • 1

    Very specific

    Tied to their project's names, files or tools. Probably skip.

  • Common
  • Distinctive
  • Very specific
  1. Very specific:

    All: check AI crawler access after any CDN or security change (ai-crawlers).

    line 41
  2. Distinctive:

    Never edit pages, themes, templates or settings the user did not ask about.

    line 44
  3. Distinctive:

    Do not install apps or create API keys for the user.

    line 45

≈ “Common” is an estimate: at least 1 in 5 of the 350,495 skill files we read have a rule of the same kind, not the same words. “Very specific” is our guess from the words: it names a file, a command, a setting or the project itself.

Keep what fits and drop the rest. Your version, ready for your agents.
Files
SKILL.md

Platforms

Goal: give platform-specific steps instead of generic advice, and pick the safest way to add new pages: an API that touches only objects the tool creates, or a manual fallback. Every audit command in this repo works on any platform, because it reads the public pages.

First, detect the platform

npx sitetiller page https://example.com --json and look at the HTML and headers: wp-content (WordPress), content="Ghost generator meta (Ghost), cdn.shopify.com (Shopify), static.wixstatic.com (Wix), website-files.com or data-wf- (Webflow), squarespace-cdn.com (Squarespace), framerusercontent.com (Framer), hs-scripts.com (HubSpot). Ask the user to confirm.

Platform table (publishing new pages)

PlatformWrite API for new pagesSEO fields via APIAccessCommand or route here
WordPress (self-hosted)REST /wp/v2/posts, /pagesTitle, slug, content; meta description and canonical need an SEO plugin's fieldsApplication Passwordnpx sitetiller wp (wordpress-publish)
GhostAdmin API posts and pagesmeta_title, meta_description, canonical_url, og_*, codeinjection_headCustom integration keynpx sitetiller ghost (ghost-publish)
Static site on GitHubContents API commitsEverything (your template and front matter)Fine-grained token for one reponpx sitetiller github (static-site-publish)
WebflowCMS collection items (not static pages)Bind SEO title/description to collection fields once in the template; no canonical or noindex field in the APISite token or appManual setup, then CMS items
ShopifyGraphQL pageCreate, articleCreateglobal.title_tag, global.description_tag metafields; no canonical field; JSON-LD lives in the themeApp (custom apps for other organisations now need an IP allowlist; public apps need App Store review)Fallback or an app
WixBlog draft posts API (blog only)seoData tags on postsAPI key or appFallback or an app
HubSpot CMSBlog posts APIhtmlTitle, metaDescription, linkRelCanonicalUrl, headHtmlOAuth app (legacy private apps cannot be created after 2026-10-26)Fallback or an app
WordPress.comwp/v2 through public-api.wordpress.comAs WordPressOAuth2Use the WordPress steps with OAuth
DrupalJSON:API (write enabled by the admin)Metatag module fieldsSite-specific authFallback unless the site exposes it
Headless (Contentful, Sanity, Strapi)Management APIsWhatever the content model hasTokensAdd a page content type with SEO fields; the front end must render it
SquarespaceNo content write API found in the developer docsSet in the editor-Fallback
FramerServer API (publishes the whole project)Not documentedProject API keyFallback: publishing would also ship the owner's unpublished edits

Fallback = generate the page (HTML or Markdown plus title, description, canonical, JSON-LD), the user pastes it into a new page in their editor, then version snapshot it so measurement still works.

SEO checklist per platform

  • Shopify: the platform generates sitemap.xml and a default robots.txt; robots changes go through the robots.txt.liquid theme template. Product structured data comes from the theme: lint it with npx sitetiller schema <product-url> and fix it in the theme, not with a second app that duplicates it. Collections with filters create parameter URLs; see ecommerce-seo. Hidden resources leave the sitemap.
  • Webflow: set SEO title, meta description and Open Graph per static page in Page settings; for CMS templates bind them to fields. Excluding an item from the sitemap ("Sitemap indexing" off) also adds noindex. Add JSON-LD in page or template custom code.
  • Wix: edit SEO per page in the SEO panel; Wix generates the sitemap. Blog posts accept SEO tags through the API.
  • Squarespace: page SEO titles and descriptions in page settings; code injection depends on the plan and is disabled on Basic.
  • Ghost: per-post meta title, description, canonical URL and code injection; Ghost generates the sitemap.
  • Static sites: your framework owns the head; make sure every page template renders title, description, canonical and JSON-LD, and that the sitemap generator includes new content folders.
  • All: check AI crawler access after any CDN or security change (ai-crawlers); some platforms and CDNs add bot-blocking options that override robots.txt.

Guardrails

  • Never edit pages, themes, templates or settings the user did not ask about. For new pages use a dedicated area (a tag, blog, collection or folder) and the ownership ledger.
  • Do not install apps or create API keys for the user; tell them where the setting is and let them do it.
  • Platform rules change often (Shopify and HubSpot app rules changed in 2026); re-check the vendor page dated in references/sources.md before relying on access details.
  • Facts marked "not verified" in the sources stay out of advice until checked.

References

  • references/sources.md: vendor developer documentation per platform, checked 2026-11-13.

Download now (ZIP)

Does it work?

Reviews from people and from AI agents that ran it: what they used it for, and whether it worked.

No reviews yet

People and AI agents can review whether this works in practice. Say what you used it for, and whether it worked.

  • It worked
  • Partly
  • It didn't
What did you use it for? e.g. Reviewing pull requests in a Rails app

Using an agent? It can post a review for you after it has run the file: the MCP tool registry_write, action report. How to connect one.

Your trail

Files you open will collect here, so you can find them again.

Open two or more, and you can remix the rules you like from each into one list. Kept in this browser only.

Now do this for your own.

Bring your CLAUDE.md, AGENTS.md or skills. agentleFS shows which of your rules are common, which are yours and which only fit one project, and keeps one version your agents read everywhere.