We've just rolled major changes to the Site Search feature: settings for how to index websites now have a dedicated section in the Project settings, while build triggers have become leaner.

What's new

Until today, Site Search was buried deep within build triggers and tightly integrated with the build system: you could crawl a website only if you had a build trigger.

That wasn't always what you needed. Maybe on a non-static website, there's no build phase at all, but you rightly want to leverage the Site Search functions.

So we improved it to bring about a few major changes:

• Site Search is now independent of Build Triggers being used. to benefit from Site Search, you simply have to create a Search Index, and you're good to go. No more artificial coupling.

• Site Search logs split apart from Build Triggers logs. Build triggers and indexing logs are now two different sections in your Project settings.

• Independent control over indexing.  You can control when and how your sites are indexed for search purposes independently of their build process (even if you don't have one).

ℹ️ If you had Site Search enabled, your setup has been migrated to the new configuration: for each build trigger with indexing enabled, we created a search index and linked it to the build trigger.

How does it work?

Navigate to the Search Indexes section in Project settings to create or manage your search indexes:

Why the change? 

Decoupling search indexes from build triggers gives customers explicit control over when indexing happens and provides independent failure reporting and logging for indexing.

Plus, it opens up new possibilities: you can now add a custom suffix to the user-agent we use when crawling websites. With that, you can work on your robots.txt and sitemaps to get different search indexes for various sections of your website (for example, one for the blog, another for the documentation, and another for the FAQs).

We've just rolled out Smart Confirmation Guardrails to prevent accidental data loss while keeping your workflow smooth and efficient.

What's New?

Destructive actions now show clear consequences before you commit. No more "oops" moments.

In primary environments, high-risk changes affecting 10+ records require explicit confirmation by typing what you're destroying (e.g., "delete author_name field in 2k+ records"), while smaller changes use lighter confirmations to keep your workflow fast. Sandboxes remain unrestricted for rapid iteration.

How Does It Work?

When you attempt a destructive action in your primary environment, the system calculates potential impact.

If 10+ records will be affected, it shows a detailed confirmation dialog with exactly what will be deleted or modified, how many records will be impacted, and a confirmation phrase to type that reinforces the consequences.

If fewer than 10 records will be affected, a simpler dialog will be shown that doesn't require a confirmation phrase.

Why Does It Matter?

Accidentally deleting a model, converting a field type, or removing a locale can cause massive data loss, broken references, and hours of recovery work. These guardrails give you safety without friction — protection appears exactly when and where you need it most.

This is especially valuable for:

• Enterprise teams managing large-scale content operations with thousands of records

• Multi-locale projects where removing a language could affect hundreds of assets and records

• Complex schemas with interconnected models and references

You get enterprise-ready protection with smart defaults: your production environment stays safe, while development environments stay fast.

We've added a new path filter for uploads in the GraphQL API (CDA), allowing you to filter uploads based on their storage path.

The filter supports exact matching (eq), negation (neq), inclusion (in), and exclusion (notIn) operations. All path comparisons are case-insensitive.

1
{
2
  # Find a specific asset by path
3
  upload(filter: { path: { eq: "/123/1763384420-hero-image.jpg" } }) {
4
    id
5
    url
6
  }
7

8
  # Find multiple assets by paths
9
  allUploads(filter: { path: { in: ["/123/1763382120-logo.png", "/123/1763381111-banner.jpg"] } }) {
10
    id
11
    url
12
  }
13

14
  # Exclude specific paths
15
  allUploads(filter: { path: { notIn: ["/123/1763383331-preview.jpg"] } }) {
16
    id
17
    url
18
  }
19
}

You can also use this new filter when fetching uploads via the CMA or in your project Media Area

We're adding a new way to let users access the CDA Playground without requiring "Create/edit API tokens" permissions in their role.

This is especially useful for developers — including external contractors — who have been given an API token by someone else, and need to explore and test content queries but don't require full API token management capabilities.

What's New

For people with no permission to "Create/edit API tokens", we've added a "Force CDA playground visibility" toggle in the Editor preferences. When enabled, users can access the CDA Playground regardless of their role permissions.

How It Works

For users with this toggle enabled, the CDA Playground will prompt for an API token on first access.

Once a valid token is provided, the playground functions normally — the toolbar displays the custom token and allows updating it as needed.

This gives developers and technical users the access they need to work with the Content Delivery API, without granting broader API token management permissions.

We're introducing favorite locales to keep your workspace focused and your most-used languages instantly accessible.

What's New?

Mark up to 6 locales as favorites to prioritize them across the CMS, reducing clutter and eliminating the need to hunt through long language lists.

• Instant access: Favorite locales appear at the top of selectors throughout the CMS — no more hunting through lists.

• Cleaner workspace: While editing records, collapse non-favorite locales to keep your view focused on what matters.

How Does It Work?

Open Editor's Preferences from your avatar menu (upper right corner), enable "Favorite Locales," and select your most-used languages. You can choose up to 6 favorite locales.

Why Does It Matter?

Managing 10, 15, or 20+ locales means constant scrolling and visual noise. By surfacing only the languages you use regularly, this feature eliminates friction in your daily workflow — especially valuable when you work primarily in a consistent subset of locales. You get faster navigation and a cleaner interface without changing how localization works.

We recently removed the ability to add new Travis CI and CircleCI build triggers: these integrations have been practically unused for years. Maintaining them creates technical debt and maintenance burden without providing value to our users.

Existing Travis CI and CircleCI build triggers will be migrated to custom build triggers in the following weeks. After the migration is complete, the migrated CircleCI triggers will be fully functional — both outbound triggers and incoming webhooks continue to work seamlessly. For Travis CI triggers, that have not been used in the last 6 years, we'll continue to manage outbound triggers, which will still work, while incoming webhooks won't be recognised as valid.

We'll contact all paying customers with existing Travis CI and CircleCI build triggers via email to inform them about the incoming changes. 

We've added native LLM.txt support to make our documentation and blog instantly accessible to AI assistants like ChatGPT and Claude.

Every documentation and blog page now includes a "Copy page" dropdown that lets you:

• Copy the page as Markdown - Get clean, formatted Markdown optimized for LLMs

• Copy a shareable .md link - Direct link to the Markdown version

• Open in ChatGPT - Launch ChatGPT with the page pre-loaded

• Open in Claude - Launch Claude with the page pre-loaded

Why It Matters

When working with AI assistants, feeding them accurate documentation context is critical. Instead of copy-pasting HTML or having the AI scrape pages (which often loses structure), you can now give your AI assistant perfectly formatted documentation in one click.

Whether you're debugging an integration, exploring our APIs, or asking questions about DatoCMS features, your AI assistant now has direct access to our complete documentation in the format it works best with.

P.S. You can actually append .md to any page URL on our site to get its Markdown version — though we can't guarantee the quality of the conversion for all pages yet!

The DatoCMS JavaScript client is now fully type-safe. Records (the missing piece that wasn't) are also generated directly from your project’s schema.

This gives you real autocomplete and compile-time safety across your project.

The CLI bridges your schema and repo perfectly. Run a single command to generate types, and if your schema changes, rerun it to keep your code perfectly in sync.

$ npx datocms schema:generate schema.ts

The client also ships with new utilities to simplify record management, like duplicateBlockRecord(), inspectItem(), and mapBlocksInNonLocalizedFieldValue() to handle nested blocks, relations, and localized fields automatically.

Quick Links:

• CMA Client Package

• Configuring the CLI Docs

• Using the JS Client Docs

• Type-safe Development with TypeScript Docs

• Announcement post on the blog

You can now turn Structured Text fields back into Markdown with our new datocms/structured-text-to-markdown package. Perfect if you need clean Markdown output for your pipelines, exports, or tooling (or just a clean .md page for all the LLMs 🤭).

Just a lil

npm install datocms/structured-text-to-markdown

and you're set!

The renderer supports all DatoCMS Structured Text nodes and converts them to CommonMark-compatible Markdown:

Block Nodes

• Headings: # H1 through ###### H6

• Paragraphs: Plain text with double newlines

• Lists: Both unordered (-) and ordered (1.) lists with nested support

• Blockquotes: Lines prefixed with >

• Code blocks: Fenced code blocks with language support

• Thematic breaks: Horizontal rules (---)

Inline Formatting

• Strong: **bold**

• Emphasis: *italic*

• Code: `code`

• Strikethrough: ~~text~~

• Highlight: ==text== (extended Markdown)

• Underline: <u>text</u> (HTML fallback, no native Markdown)

Links

• Regular links: [text](url)

• Record links: Custom rendering via renderLinkToRecord

Full deets on the package and advanced usage are on the README.

We’ve fixed a long-standing issue with localized Link fields.

When editors used a Link field to reference entries, the dropdown showed records from all locales, even if those records were not available in the locale currently being edited. This often caused confusion in the UI, query errors and other unwanted production quirks.

Now, the Link field dropdown only shows records available in the current locale. This change should make managing localized content clearer and safer out of the box.