Workflow

Customer Page SEO Controls

Follow the sequence below, then use API Reference for payload schema and response details.

Steps

  1. List the bounded page inventory for one selected locale, preserving the returned cursor:

    Operation IDs: sites.seoPages.list

  2. Load one page-locale detail projection with inherited, requested, preview, access, and served

    Operation IDs: sites.seoPages.get

  3. Save SEO/social metadata independently with `expectedRevision`. Omitted properties remain

    Operation IDs: sites.seoPages.metadata.patch

  4. Save `inherit | hidden` visibility independently with `expectedRevision`:

    Operation IDs: sites.seoPages.visibility.patch

  5. Keep localized-path edits on the existing collision-aware operation:

    Operation IDs: sites.slugs.set

  6. Load site-level requested/effective search readiness and crawler-visible blockers:

    Operation IDs: sites.seoReadiness.get

  7. Run validation only when a prepared candidate generation exists, then inspect bounded history:

    Operation IDs: sites.seoValidation.run, sites.seoValidation.history

  8. When readiness reports an available previous generation, use the generation-bound rollback

    Operation IDs: sites.seoRollback.create

Notes

These operations expose requested SEO intent separately from served generation state. A `202`

mutation response means the requested revision is stored and candidate activation is pending; it

must not be interpreted as crawler-visible success.

state:

unchanged and `null` resets to inheritance:

operation. The backend revalidates the current pointer, immutable target, route snapshots, and

subject access before committing; never infer or submit a target generation from client state:

The backend resolves current subject access for every mutation. Reset/removal and restrictive hide

operations remain available after commercial downgrade; demo scopes remain read-only.

Related Docs

All workflowsAPI reference