Content Commands

Commands under spideriq content for pages, posts, blog metadata, docs, settings, links, and deploying. All respect the workspace bound by spideriq use.

Pages

spideriq content pages [--status draft|published|archived]
spideriq content pages:duplicate <page_id> [--slug <slug>]
spideriq content blocks:duplicate <page_id> <block_id> [--position start|end|before|after|<n>]
spideriq content export <page_id> [--format json|md|archive] [--output <path>]
spideriq content pages:insert-section <page_id> <component_slug> [--position …] [--props '<json>'] [--component-version <v>] [--yes | --confirm-token <token>]

Posts & blog metadata

spideriq content posts                              # list
spideriq content posts get <post_id>
spideriq content posts update <post_id> [--title …] [--slug …] [--excerpt …] [--author-id …] [--category-id …] [--featured] [--vayapin-pins "BB:TAPAS,BB:CHAMPERS"]
spideriq content posts delete <post_id>
spideriq content posts unpublish <post_id>
spideriq content posts status <post_id> <draft|published|archived>
spideriq content posts search --query <q> [--limit <n>]
spideriq content posts featured [--limit <n>]
spideriq content posts duplicate <post_id> [--slug <slug>]

spideriq content authors list|create|update|delete …   # --name --bio --email --role --agent-type
spideriq content tags list|create|update|delete …       # --name --slug --description
spideriq content categories list|create|update|delete … # --name --parent-id --sort-order

Custom collections

Define your own content types and fill them. Every record becomes a page at /<route_base>/<record-slug>.

spideriq content collections list
spideriq content collections get <slug>
spideriq content collections create --slug <slug> --label <label> [--route-base <base>] [--schema <json>|--schema-file <path>] [--public]
spideriq content collections update <slug> [--label …] [--route-base …] [--schema <json>|--schema-file <path>] [--public|--no-public]
spideriq content collections delete <slug> [--dry-run] [--confirm-token <token>]

Records live under a collection:

spideriq content collections records list <collection> [--limit <n>] [--offset <n>] [--sort <expr>]
spideriq content collections records get <collection> <record_slug>
spideriq content collections records create <collection> --slug <slug> [--data <json>|--data-file <path>] [--seo-title …] [--seo-description …] [--og-image-url …] [--sort <n>] [--publish-at <iso>]
spideriq content collections records bulk <collection> --file <path>
spideriq content collections records update <collection> <record_id> [--slug …] [--data <json>|--data-file <path>] [--status draft|published|archived] [--dry-run] [--confirm-token <token>]
spideriq content collections records delete <collection> <record_id> [--dry-run] [--confirm-token <token>]

records get takes a slug; records update and records delete take a record id. List first, keep the id, then write.

records bulk reads a JSON file — either a bare array of record objects or {"records": [...]} — and creates up to 100 in one transaction. Any invalid record rejects the whole batch.

Deleting a collection cascades to its records, so it previews by default. Publishing a record is the same two-step: --dry-run returns a confirm_token, then re-run with --confirm-token.

Example — define a content type, fill it, render it

spideriq content collections create \
  --slug case-studies --label "Case Studies" --route-base case-studies --public \
  --schema '{"fields":[{"id":"client_name","type":"text","required":true},
                       {"id":"industry","type":"select","options":["SaaS","Retail","Finance"]},
                       {"id":"body","type":"richtext"}]}'

spideriq content collections records bulk case-studies --file ./case-studies.json

spideriq content collections records update case-studies <record_id> --status published --dry-run
spideriq content collections records update case-studies <record_id> --status published --confirm-token <token>

spideriq content deploy
# → https://<your-domain>/case-studies/<record-slug>

Collection and record slugs allow lowercase letters, digits and hyphens — no underscores. Field ids inside the schema are snake_case and do allow underscores. A data key the schema does not declare is rejected, not dropped.

Directory

Programmatic-SEO directories: a category per vertical, listings underneath, one page per category, city and business.

spideriq directory categories list                        # page size 50 — pass --page for more
spideriq directory categories create --name "Plumbers"
spideriq directory categories get plumbers                # the category + the cities with listings
spideriq directory categories delete plumbers             # cascades to every listing in it

spideriq directory listings list --category plumbers --city Miami
spideriq directory listings import plumbers ./listings.json    # an array of {name, city, ...}
spideriq directory listings delete plumbers reliable-rooter

spideriq directory refresh-stats                          # rebuild the city rollup

Import from your own business data

One call, no export step and no sync pipeline. It reads the tenant's business corpus directly and carries every declared column through.

spideriq directory listings import-from-idap plumbers \
  --category-filter "Plumber" --country-code US --rating-min 4.0 --limit 5000 --prune

Flag	Meaning
`--category-filter`	matches the business's own category list, e.g. `"Plumber"`
`--country-code`	ISO-2, uppercase, exact
`--city`	substring match
`--rating-min`	inclusive lower bound
`--limit`	max rows, hard cap 5000 (default 5000)
`--prune`	archive listings this import did not produce — off by default

Without --prune an import never removes anything. A business deleted from the corpus, or renamed so it derives a different slug, keeps its listing published forever, and every re-run drifts the category further from its source. With --prune those listings are archived rather than deleted, and the change is reversible.

Prune refuses rather than guess when the result set is empty or was truncated at --limit, and says which. That refusal is an answer — re-running unchanged refuses identically, so change the filters instead of retrying.

Nothing here runs on a schedule. Re-running the import is a decision you make.

Docs

spideriq content docs:duplicate <doc_id> [--slug <slug>]

(Create and reorder docs through the API or the MCP tools.)

Query any published docs site (docs-as-MCP)

Read-only, domain-scoped queries against any published docs site — your own or anyone's. No auth or workspace binding; -w/--workspace only selects which API origin to use (staging / self-hosted). The CLI mirror of the hosted docs-as-MCP server.

spideriq content docs:search <domain> "<query>"      # full-text keyword search
spideriq content docs:semantic <domain> "<query>"    # semantic (vector) search
spideriq content docs:ask <domain> "<question>"      # grounded, cited answer (metered)
spideriq content docs:fetch <domain> <full-path>     # fetch one page (path after /docs/)

docs:ask is metered against the docs site owner's Docs-Pro plan and is rate-limited — use docs:search / docs:semantic for browsing.

Settings, links, deploy

spideriq content settings [--set '<json>']          # read, or update site settings
spideriq content audit-links [--json]               # check internal links across the site
spideriq content deploy-readiness                   # is the site ready to deploy?
spideriq content deploy-status                      # status of the last deploy

spideriq content deploy                             # interactive: preview → confirm → production
spideriq content deploy --json                      # emit the preview envelope (automation)
spideriq content deploy --confirm <token>           # consume a token from a prior preview
spideriq content deploy --yolo                      # skip preview (not recommended)

Example — publish a post and deploy

spideriq content posts update post_abc123 --title "Launch day" --featured
spideriq content posts status post_abc123 published
spideriq content deploy        # preview, review the diff, confirm

Next steps

CLI Overview — install, auth, and common flags.
Design & Form Commands — templates, themes, components, forms.
Content API — the endpoints these commands call.
Deploy — how deploying to the edge works.
Directory Tools — the same operations as MCP tools, with error tables.