Changelog

A navigation menu used to be a second copy of your site that somebody had to keep in step with the first one. Organise your pages into folders and the menu follows, so there is nothing left to keep in step.

What's new in v2.31.0

• Folders are the menu. A page can sit inside a folder, and the folder structure drives the navigation. Move a page and the menu moves with it, without anyone editing a list of links.

• A folder can have its own page. A folder renders an index of what is inside it, so a section of your site has a real landing page instead of a menu item that goes nowhere.

• One tree instead of two. Because the structure and the menu are the same thing, they cannot drift apart. A page you add is in the navigation because it is where it is.

• Hand built menus still work. If you want a menu that does not mirror the folders, you still have one. This is a way to stop maintaining navigation, not a rule that you must.

Read the navigation guide at https://publish.spideriq.ai/docs/building-your-site/navigation.

An agent that could set a field on update but not on create had to make two calls to do one job, and nothing said so. Create now accepts what update accepts, and reads come back bounded by default.

What's new in v2.30.0

• Create takes the fields update takes. A field you were only able to set by updating a record afterwards can now be set when you create it, so a create and an update stop being a required pair.

• Reads are bounded by default. List responses come back with a sensible limit rather than everything, so an agent asking a broad question gets an answer it can hold instead of a reply that fills its context.

• The asymmetry is gone, not documented around. This was fixed in the API rather than written up as a quirk to work around, so code written against either shape keeps working.

Read the content tools reference at https://publish.spideriq.ai/docs/mcp-reference/content-tools.

Posts, authors and tags were the content types you got. Now you can define your own: name the fields, fill in the records, and render them on the site, all in one sitting and all through the same API your agent already uses.

What's new in v2.29.0

• Define the content type yourself. Describe the fields a record should have and the collection exists. There is no migration to write and no separate CMS to configure.

• Fill it one record at a time or in bulk. Create records individually while you are figuring the shape out, then load the rest in a single bulk call once you know it works.

• Records can point at each other. A collection record can link to records in another collection, so a case study can reference the product it is about instead of repeating it.

• Render it like anything else. A custom collection reads from a template the same way posts do, so putting one on a page is the work you already know rather than a new mechanism.

Read the collections guide at https://publish.spideriq.ai/docs/ai-agents/custom-collections.

An embedded agent used to answer without knowing where it was standing. On a site you host yourself, it can now read the page around it, and only when you ask it to.

What's new in v2.28.0

• Off unless you turn it on. Page reading is opt in. Add the page context attribute to the mount element and the agent captures the page's main visible text. Leave it off and nothing is captured at all.

• Point it at one part of the page. Give the attribute a CSS selector and the agent reads only that subtree, so a support widget can see the article and not the pricing banner beside it.

• Your host does the wiring. The page reference comes from the mount code on your own site, which is why this applies to sites you host yourself. On a site published here the setting is present but nothing is captured.

• A hard privacy boundary. Private subtrees, password fields and every form value are stripped before anything leaves the browser, and the stripping happens on a copy, so your live page is untouched.

Read the agent embed guide at https://publish.spideriq.ai/docs/ai-agents/agent-embed.

The whole agent lifecycle now runs headless. Find one, hire it, put it on a page, without opening the dashboard at any point.

What's new in v2.27.0

• Discover, hire and embed as commands. The three steps are CLI commands and the matching agent tools, so the sequence can be scripted or run by another agent rather than clicked.

• The same lifecycle the dashboard uses. These are not a parallel path. A hire made from the terminal appears in the dashboard, and one made in the dashboard is visible to the CLI.

• Scriptable from the start. Because every step returns its identifiers, you can chain the whole thing in one script and repeat it for as many sites as you run.

Read the CLI reference at https://publish.spideriq.ai/docs/ai-agents/cli.

Your agent no longer has to live on a site we host. A small loader script and one element put it on a page you control, including a site built on something else entirely.

What's new in v2.26.0

• One script, one element. Add the loader and a mount element carrying your flow id. The agent renders in place, on your own domain, with no framework requirement and nothing to build.

• Configured from the markup. The card's title and subtitle, whether the header shows, and how it lays out are attributes on the element, so a change is an edit to a page rather than a redeploy.

• It does not fight your page. The agent mounts inside its own boundary and sizes itself to the space you give it, so your stylesheet and its stylesheet stay out of each other's way.

• It tells you when it fails. If the agent cannot mount, the element carries an error state you can see in the DOM and a warning in the console, rather than leaving a silent empty box.

Read the agent embed guide at https://publish.spideriq.ai/docs/ai-agents/agent-embed.

AI agents joined the component marketplace. They are browsable the same way every other component is, which means adding one to a page is a choice from a library rather than a build.

What's new in v2.25.0

• Browse agents like components. Agents sit in the marketplace in their own category, with a description and a preview, next to the heroes and pricing tables you already pick from.

• Add one to a page in the builder. Choosing an agent listing puts it on the page as a block. There is no separate embed step and nothing to paste into a template.

• Author your own listing. An agent you build can be published as a marketplace listing with its own metadata, so the rest of your team picks it from the library instead of copying a configuration.

Read the AI Agents guide at https://publish.spideriq.ai/docs/design/ai-agents.

An AI agent is now one of the kinds of flow you can build, which means embedding one on your site is the same job as embedding a form. No separate product and no separate place to configure it.

What's new in v2.24.0

• An agent is a flow. Build it in the same place you build forms and bookings, and it gets the same hosted address on your own domain and the same analytics as everything else.

• Embed it or link to it. Drop the agent into a page as a block, or send someone straight to its own URL. Both run the same agent with the same configuration behind them.

• Isolated from your page. The embedded agent renders inside its own boundary, so your site's styles cannot break it and it cannot break your site's layout.

• Configured, not coded. Which model, what it is allowed to say and what it can see are settings on the flow, so changing your agent's behaviour does not mean a deploy.

Read the agent embed guide at https://publish.spideriq.ai/docs/ai-agents/agent-embed.

A form, a booking page, a multi step funnel and a checkout used to be four different things to learn. They are now one thing with a setting on it, which means what you learn once applies to all of them.

What's new in v2.23.0

• Five kinds, one engine. A flow is a booking, a form, a funnel, a checkout or an embedded agent, and the rest of the machinery is shared. The same builder, the same hosted URL, the same analytics.

• Funnels are a real graph. A funnel is steps and the connections between them, so you can reorder, branch and archive without rebuilding, rather than a linear sequence you have to recreate to change.

• Checkout is a flow kind. An order carries its cart, its line items, its total and its currency, and it stays attached to the flow and the session it came from, so you can see what a visitor did before they paid.

• Card payments work with Stripe. Payments are handled through Stripe payment intents. Stripe is not affiliated with us; you connect your own account.

Read the flows guide at https://publish.spideriq.ai/docs/forms-and-booking/booking.

Some pages are not for everyone. You can now put a login wall in front of any part of your site, decide who gets through it, and let people sign in with an account they already have.

What's new in v2.22.0

• Gate a page behind a sign in. Choose which pages are public, which need an account, and which need a particular kind of member. A visitor without the right access sees the login wall instead of the content.

• Groups, defined by a rule. A member group can be a fixed list or a condition that decides membership on the fly, so access follows what is true about a person rather than a list somebody has to maintain.

• Sign in with an existing account. Connect a provider and your members sign in with credentials they already have, instead of inventing another password for your site.

• Restrict the data, not just the page. Access rules reach the content a page reads, so a gated page cannot leak through a component that fetched the data anyway.

This is set up from the dashboard. Read the guide at https://publish.spideriq.ai/docs/members/site-members.

Publish documentation and you get more than a website. Every published docs site is now an addressable endpoint an AI agent can connect to and query directly, with nothing to install and nothing to deploy.

What's new in v2.21.0

• An agent can point at your docs and read them. Your site exposes a JSON-RPC endpoint on your own domain. Any MCP capable client connects to it and works with your manual the way it works with any other tool.

• Four read only tools, scoped to you. Keyword search, semantic search, a question answering tool and a fetch by document. They only ever see your published docs, never drafts, and never another tenant's content.

• No sidecar, no SDK, no per site deploy. The endpoint exists because the docs site exists. There is no separate server to run and no build step to add.

• Rate limited where it costs. The expensive tools carry their own limits and return a clear retry signal, so an enthusiastic agent cannot run up your bill in a loop.

Read the documentation guide at https://publish.spideriq.ai/docs/building-your-site/documentation.

Getting an account used to mean asking someone for one. There is now a signup page anyone can use, it creates the workspace for you, and it is careful about who it tells what.

What's new in v2.20.0

• Sign up without an invitation. Anyone can create an account from the signup page, and a free workspace comes with it. There is nothing to request and nobody on our side to wait for.

• Verified by email before anything opens. No session is created until the link in the verification email is clicked, so an address nobody controls cannot be used to hold an account.

• The form will not tell a stranger who has an account. A brand new address and one that is already registered get exactly the same response. Somebody probing the page learns nothing about who your customers are.

Sign up at https://publish.spideriq.ai/signup, or read the docs first at https://publish.spideriq.ai/docs.

Your posts, authors, tags and other collections used to be reachable only from the templates built for them. Any component can now read them directly, which means a section can show real content instead of content someone pasted in.

What's new in v2.19.0

• Collections are available everywhere. A component on any page can read your published collections, so a homepage section listing your three newest posts stays right on its own instead of being edited every week.

• Filter and sort in the template. Narrow a collection by the fields you care about and order it how you want, inside the template, without a separate query step or a copy of the data.

• Server filtered widgets you can reuse. Define the filter once as a widget and drop it on several pages. The filtering happens on the server, so the visitor's browser is not downloading a collection to throw most of it away.

Read the live collections guide at https://publish.spideriq.ai/docs/building-your-site/live-collections.

Documentation stopped being a second class citizen on your site. Docs now carry the same SEO treatment as your pages, they are searchable, and an agent can build them for you from files you already have.

What's new in v2.18.0

• Docs get the same SEO treatment as pages. Titles, descriptions, canonical URLs and structured data on doc pages, so a support article can rank for the question it answers instead of being invisible.

• Full text search across your docs. Readers search the whole manual from inside it, and the same search is available to an agent through the API rather than only in the browser.

• Bring existing docs in. Point the importer at Markdown you already wrote, or at an OpenAPI file, and it becomes doc pages with the structure intact. No retyping and no copy and paste.

• Components inside a doc page. A doc body can hold the same components your marketing pages use, so a reference page can carry a live example rather than a screenshot of one.

Read the documentation guide at https://publish.spideriq.ai/docs/building-your-site/documentation.

Two audiences read your site now, and they need opposite things. Search engines need to be told what to skip. Models need the text without the page around it. Both are settings, not projects.

What's new in v2.17.0

• Decide page by page what gets indexed. Each page carries its own indexing setting and its own canonical URL, so a thank you page, a private proposal or a duplicate landing page stays out of search results without touching a robots file.

• An index for AI crawlers, and the full text behind it. Your site serves an index of itself at one address and the actual content of every published page at another, as a single file a model can read in one request. The full content file is a setting you switch on.

• Any page as clean Markdown. Add .md to a page or post URL and you get that page as Markdown, with the title, the metadata and the body, and none of the layout.

Pages built entirely from a marketplace component are not included in the full content file, and the crawler guide explains why.

Read the crawler guide at https://publish.spideriq.ai/docs/seo/ai-crawlers.

VayaPin™ Cards put the locations you already maintain onto your site as cards, and keep them right without anyone opening the page again.

What's new in v2.16.0

• Locations on any page. Drop the cards component onto a page and it renders your pins with their details, laid out to match the rest of the site rather than as a pasted map embed.

• Locations on a blog post. A post can show the pins it mentions, so an article about three towns carries the three places without a hand built list under it.

• It stays current on its own. Change an address or a detail in VayaPin and the cards follow on the next request. There is no page to re-edit and no export to re-run.

• It behaves like any other block. The cards are a component in the page builder, configured the same way as everything else, with no plugin to install.

Read how to place them at https://publish.spideriq.ai/docs/seo/vayapin-cards.

An agent that gets a well-formed answer has no way to tell a good one from a wrong one. Two changes give it that: responses that say what they are not for, and a check it can run against the page it just built.

What's new in v2.15.1

• Guidance rides along with the answer. Ask for ?format=llm and a success response carries a guidance block. It states what the resource is for, what it is not for, what to call next, the caveat that matters, the pitfalls people hit, and the hard limits. Six keys, and the vocabulary is frozen so it stays parseable.

• A visual check an agent can run itself. content_visual_check opens a published URL in a real browser and returns a screenshot, the page's DOM, console errors and failed requests. An agent can confirm the page it just built actually renders, instead of trusting the status code.

• The assertion rule ships inside the tool. Embedded forms render in a cross-origin frame, so their field labels never appear in the page text. Check dom.shadow_hosts for the element instead. That rule lives in the tool's own description, where it gets read.

• Guidance became automatic in June. From 16 June, callers authenticating with a token get the guidance block by default rather than having to ask for it. Add ?format=json to opt out. Browser sessions are unaffected.

Read the agent-facing reference at https://publish.spideriq.ai/docs/mcp-reference/form-tools.

Forms are generally available. Build one, put it on a page or give it its own address, branch it on what people answer, and send the answers somewhere useful.

What's new in v2.15.0

• Embed it or host it. A form can sit inside a page on your site, or live at its own canonical URL you can share directly. Both render from the same definition, so there is nothing to keep in sync.

• Logic that reacts to answers. Rules show, hide and branch fields based on what someone has already answered, and variables carry a value through the rest of the form.

• Prefill and recall. Hidden fields and URL parameters carry context into a form before anyone types, and recall puts an earlier answer back into the wording of a later question.

• Answers land where you work. Map a form's fields to your CRM so a submission arrives as a record rather than as another inbox you have to check.

Read the forms guide at https://publish.spideriq.ai/docs/forms-and-booking/forms.

A form and a booking are two kinds of the same thing, and until now they did not share an address. They do now, and the tools that hand you that address return the one that actually works.

What's new in v2.14.0

• One address, aware of what it is serving. Every flow lives at /f/<flow_id> on your own domain, and that route serves the right page for the kind of flow behind it rather than assuming a booking.

• The old address still resolves. /book/<flow_id> permanently redirects to the canonical route, so links already out in the world keep working and nothing you have shared has to be reissued.

• Preview returns the right URL. The preview tool used to hand back a booking address for a form. It now returns that flow's own canonical URL, and the tool descriptions match what the code does.

• An unknown kind fails loudly. A flow kind the renderer does not recognise returns a structured error naming what was sent and what was expected, instead of quietly rendering the wrong page.

Read the flow URL reference at https://publish.spideriq.ai/docs/forms-and-booking/building-a-form.

Three things a page needs once more than one person edits it: a way to see what changed, a way to stop someone changing it, and a way to take the whole thing away with you.

What's new in v2.13.0

• Every edit keeps a snapshot. A page keeps numbered version snapshots with the full block body, who changed it, and a summary of the change. List them, open any one of them, and restore the page to it.

• Lock a page you do not want touched. A locked page records who locked it, when, and why, and releasing it is a deliberate separate step. Useful for a campaign page that must not move while it is running.

• Export a page with everything it depends on. One call returns the page plus the full source of every component it references, your site settings and your domains, as JSON, as readable Markdown, or as a ZIP you can keep.

• The export audits itself. The same call runs ten checks over the page, including empty scroll sequence frames, a missing primary domain, and gaps in the page's SEO fields, so you see the problems before you redeploy.

Read the page lifecycle reference at https://publish.spideriq.ai/docs/mcp-reference/content-tools.

The component marketplace grew again. This round filled in the blocks a landing page usually needs after the hero, so fewer sections have to be written from scratch.

What's new in v2.12.0

• Social proof and trust blocks. Testimonial, logo wall, review and rating layouts, alongside badge, guarantee and credential blocks for the part of a page where a visitor decides whether to believe you.

• Urgency and scarcity blocks. Countdowns, stock and seat counters and deadline banners, as ready components rather than something to hand build for each campaign.

• Forms and order forms. Lead capture layouts and checkout style order forms, so a page that has to collect something does not need a separate tool bolted onto it.

• Video and location blocks. Video sections for pages that lead with a demo, and location aware blocks for sites that serve different towns or regions from the same template.

Browse the library at https://publish.spideriq.ai/docs/design/marketplace.

Renaming a page used to mean hunting for every link that pointed at the old slug. There is now one call that walks your whole site and tells you which internal links no longer resolve, before you deploy rather than after.

What's new in v2.11.0

• Every page and every menu, in one pass. The audit walks the blocks of every published page plus your navigation menus, and checks each internal link against the roster of pages that actually exist and the redirects you already have active.

• It tells you where the bad link lives. Each broken link comes back with its position in the tree, so you get the page and the block that holds it instead of just a list of dead paths.

• Suggested redirects, not just complaints. Alongside the broken links you get proposed redirects for the ones that look like renamed slugs, and a list of the redirects already in place.

• Safe to run whenever. The audit only reads. Run it as often as you like, and wire it into your push flow so broken links surface before a deploy instead of after one.

Read how to run it at https://publish.spideriq.ai/docs/mcp-reference/design-tools.

Version pinning gave you a safe way to push a component change to every page at once. This is the other half of it: a safe way to take that change back.

What's new in v2.10.0

• Restore an earlier version by name. Name the component and the version you want back. Its content is restored as a new published version, so the forward history stays intact and nothing is overwritten.

• Every consuming page follows. Pages pinned to the bad version are repointed to the restored one in the same call, and they render live on the next request with no site deploy.

• Preview before it happens. A dry run tells you exactly which pages would move and returns a token. Nothing changes until you spend that token, and a token issued for a rollback cannot be spent on an update.

• Roll back one page at a time if you want. Name a subset of pages and only those move, so you can prove the old version on one page before taking the rest with it.

Read how pinning and rollback fit together at https://publish.spideriq.ai/docs/design/components.

A scroll linked image sequence used to be a five step recipe. Now one call takes a video URL and a page slug and gives you a draft hero, and the pieces underneath it are available on their own if you want to drive them yourself.

What's new in v2.9.0

• One call from video to hero. Point the pipeline at a video URL and a page. It extracts numbered WebP frames, uploads them to your media bucket under a predictable name, and inserts the scroll sequence block into that page as a draft. It never publishes on its own.

• Pick how many frames you want. Ask for an exact frame count, sample at a set rate, or clip a section of the video and sample that. Canvas size, quality, background colour and scroll distance are all settings on the block.

• Frames from anywhere, not just a pattern. The sequence component now accepts a plain list of frame URLs as an alternative to the base URL and filename pattern, so frames that do not sit at predictable names still work.

• Upload from your own machine. An agent can push a single local file or walk a whole local directory into your media bucket in one request, with frame files optimised to WebP and their filenames preserved so the sequence can find them.

Read the full recipe at https://publish.spideriq.ai/docs/design/components.

A personalised landing page used to mean one page per prospect, each built and published by hand. Now you author one page, put the prospect's identifier in the URL, and the page fills itself in at the moment it is opened.

What's new in v2.8.1

• One page serves every prospect. A page whose template is dynamic_landing picks up a /lp/{page}/{identifier} route. The identifier resolves to a real business record at request time, so there is no second page row and nothing to keep in step.

• Address a prospect by the id you already hold. The resolver accepts ten identifier keys, selected per request with ?resolve_key=: a Google Place ID, a domain, four VayaPin pin keys, and four company registry keys including VAT and LEI.

• A rep can be bound to the same page. A second URL segment names one of your configured salespeople, and the page gains their name, title, photo and booking link without changing the page itself.

• A link that no longer resolves still works. When the identifier does not match, the page renders from your own fallback copy instead of failing, so a forwarded or expired link is still a usable page rather than an error.

Read the dynamic landing pages guide at https://publish.spideriq.ai/docs/building-your-site/dynamic-landing-pages.

You can now bring a component you already wrote. Submit React, Vue or Svelte source and it is compiled into a single self contained bundle that drops onto any page of your site as an ordinary block.

What's new in v2.8.0

• Bring your own framework. Source in React, Vue or Svelte is built with esbuild into one bundle that carries its own framework runtime. The page hosting it needs nothing installed, and there is no per site build step.

• Isolated by default. Each component mounts inside its own Shadow DOM with its styles attached to that root, so its CSS cannot leak onto your page and your page's CSS cannot leak into it.

• Configured like every other block. The component registers as a custom element and reads its settings from the block, so you edit its props in the page builder the same way you edit a static component.

• Tailwind included in the build. The builder ships a Tailwind toolchain, so a component written with utility classes compiles without you wiring up a bundler.

Read how to author and publish one at https://publish.spideriq.ai/docs/design/components.

Your blog now has the parts a real publication needs. Posts carry a named author, sit under nested categories, and pick up tags. Readers get full text search, a featured shelf, and related reading at the end of every article.

What's new in v2.7.0

• Author profiles, human or AI. Every post can carry a named author with a bio, an avatar, and a role. Each author is marked human or ai, so a reader can see who wrote a piece and whether a person or an agent wrote it.

• Categories that nest, tags that count. A category can sit under a parent category, so a blog that keeps growing still navigates. The tag list returns every tag with its post count, so you can see what you actually publish about.

• Search, featured posts, and related reading. Readers full text search every published post. You pin posts to a featured shelf, choose the related posts that close each article, and every post carries a running view count.

• The whole post lifecycle, from an agent or the dashboard. Create, update, preview, duplicate, publish, unpublish, and archive a post through the same API your agent already uses. Drafts and posts pending review stay private until you publish them.

Nothing here needs a plugin, a second tool, or a separate deploy. It is the same site, the same content API, and the same palette as your pages and docs.

Full setup guide in the docs at https://publish.spideriq.ai/docs/building-your-site/blog.

What's New

Your site can now run a full press room. Press releases live at /press alongside your blog and docs — same site, same deploy, same palette. It is a first-class content type, not a collection and not a component.

• Releases with their own URL space — a public index, and RSS, Atom and JSON feeds.

• Scheduling and embargoes — schedule a release and it goes live on time with nobody at a keyboard. Embargo one and named journalists get their own expiring preview link; the preview is noindex, and the release publishes itself at the lift time.

• Media kits — logos, headshots, fact sheets, packaged as one ZIP. Downloads are ungated by default, because a reporter on deadline should not hit a form wall to get your logo.

• Press contacts and boilerplates — named people with a region and a beat, and reusable "About us" blocks you write once.

• Journalist subscribers — double opt-in, one-click unsubscribe, notified automatically when you publish.

Six one-click templates

You do not have to lay the page out. Six newsroom templates are published in the marketplace — the original one-click Newsroom, plus Minimal, Startup (dark), Startup (light), Agency and Corporate. Every one adopts your own palette, typography and navigation; what differs is the composition.

A freshly applied template shows an empty media kit, and that is deliberate. Earlier versions shipped placeholder assets convincing enough that a live page could advertise files that did not exist. We removed them. A template will never publish an asset you did not upload — add your own under Content, Press, Media kits.

Built to be found, by search engines and by AI

• Correct NewsArticle structured data with a dateline on every release. There is no schema.org/PressRelease type, and only 4 of 30 live newsrooms I surveyed emit NewsArticle at all.

• Append .md to any release URL for clean Markdown — the format AI crawlers ingest best. Combined with llms.txt, your newsroom is machine-readable.

An agent can run the whole thing

This is the part no newsroom vendor offers. The incumbents are read-only — pr.co's API is explicitly read-only with no webhooks — so none of them can be driven by an agent. Here there are 27 press tools over MCP and a spideriq content press CLI group, so an agent can draft, schedule, embargo, publish and attach media end to end.

Documentation: https://publish.spideriq.ai/docs/building-your-site/newsroom

What's New

Atomically update + propagate component changes across all consuming pages.

What's New

Launch of the Directory module — a structured local business listing system built into every tenant.

• Create and manage listing categories

• Upsert listings with geo, contacts, hours

• Bulk import from IDAP verified data

• Full CRUD API for directories

What's New

All destructive operations now use a two-phase confirmation protocol.

• dry_run returns preview + confirm_token

• Token-based execution for safety

• Covers deploy, publish page/component/post

• Preview deploys via content_deploy_site_preview

What's New

Component Marketplace with automatic Shadow DOM isolation.

• 50+ components across hero, pricing, CTA, footer

• Theme tokens flow through Shadow DOM

• Scoped CSS with zero style leaks

• One-click insert with page_insert_section

What's New

Full custom domain support with automatic SSL provisioning.

• Add/verify custom domains

• Auto SSL certificates

• Primary domain for canonical URLs

• DNS health monitoring