We’ve been carrying around an issue for quite some time regarding how we manage SEO fallback data. Because the same fields used for internal previews—Title and Image Preview—are also used for SEO fallback data, it’s been causing confusion and often results in less-than-ideal search engine metadata.

To address this, we’re splitting the two settings and creating a dedicated “SEO Fallback” tab!

What’s new?
We’re removing the overlap between “Presentation” fields and “SEO” fields. Now you can explicitly choose which fields feed into your SEO Title, Image, and Description. These are separate from the fields used for internal previews, giving you more granular control over how your content appears in search results.

Why does it matter?
With dedicated SEO fields, you can optimize exactly how content appears on search engines—without affecting the quick, at-a-glance previews in the CMS. This ensures your internal workflow remains clear and uncluttered, while your SEO metadata stays fine-tuned for external audiences.

How do I enable it?
Simply head over to any Model’s settings, locate the new “SEO” tab, and select the fields you want to use for SEO Title, Image, and Description.

If you want to experiment with all the new presentation fields available, explore the head over the Presentation Tab!

⚠️ API Changes

We've introduced two new relationships on the item_type entity: presentation_title_field and presentation_image_field. These relationships are exclusively used for DatoCMS’s internal interface and preview functionality:

• presentation_title_field supports fields of type: string, date, date_time, link, text, structured_text, color, lat_lon, integer, and float.

• presentation_image_field supports fields of type: file, gallery, link, color, date, date_time, and lat_lon.

At the same time, the existing relationships — title_field, image_preview_field, and excerpt_field — are now dedicated solely to configuring SEO fallback settings. As a result:

• title_field no longer accepts fields of type date, date_time, link, text, structured_text, or color. It now only supports string fields.

• image_preview_field no longer accepts fields of type link or color. It now only supports file and gallery fields.

These changes only refine the accepted field types and do not affect functionality, as the previously accepted field types were already ignored for SEO purposes and if ie. a model had a date field set as title_field that field is now set as presentation_title_field.

We’ve heard from many of you that it’s tough to quickly grasp what’s inside each record or block at a glance when shown in preview mode —especially when those blocks or records lack text fields.

To address this, we’ve introduced a new approach to displaying previews across the entire CMS: inline blocks, link fields, and even the item index, all benefit from clearer at-a-glance content!

What's new?

First, we’ve aligned how the “Presentation” tab works for both models and blocks, letting you pick a Title preview field and an Image preview.
And second, we introduced new field types that can be selected as title and/or preview fields:

• Color fields show a handy swatch (with optional opacity);

• Date/DateTime fields use a quick calendar icon and display the date itself;

• Geolocation fields bring in a map preview;

• Number fields can be used as title and show their integer or floating-point value.

How do I enable it?
Just head to the “Presentation” tab in your model or block settings to choose your Title and Image preview fields. No extra steps required!

See it in action 👇

Color, Geolocation, and Date fields will also provide a much cleaner interface when set as Preview Fields.

Why does it matter?

This update makes it faster and clearer to see what’s inside each record or block at a glance. If you’ve ever found yourself repeatedly opening blocks just to check their contents, you’ll love these new previews!

By default, all GraphQL queries on paginated items to our Content Delivery API return a response of 20 items.

While we'll still retain this as the default behaviour, we've increased the maximum number of items to 500.

You can manage this behaviour when making your queries using the first parameter like this:

1
{
2
# Fetch the first 500 posts
3
  allPosts(first: 500) {
4
    id
5
    slug
6
    title
7
    description
8
    publishedAt
9
    content
10
  }
11
}

For more info on working with Pagination in DatoCMS check out the docs.

Handling complex user roles and permissions is complicated enough as it is, so we thought we'd try and simplify things on our end as much as possible!

Firstly, when creating highly specific and granular roles that are inherited from others, you'll see a cleaner and clearer indication of which permissions are inherited from parent roles.

While you're in the process of making any modifications or edits to them, we're also showing a new pill that explicitly highlights what's changing, so you can make sure everything's good before hitting save.

On the cosmetic side, we're also making it way easier to just understand the roles you're working with. Inside Content Permissions, all the rules are now shown as actual readable sentences instead of "disabled form fields" which are just so much more readable!

As one of the most used and installed plugins in the DatoCMS Marketplace, this update was long overdue.

You can now update this plugin to V1.0.24 which introduces custom breakpoints for desktop, mobile, and tablet, allowing your editors to preview Draft and Published content within the CMS for each device.

Install the plugin via the Marketplace. If you already have it installed, you can head on to Configurations > Plugins and click to Update the plugin to the latest version.

A new enhancement has just been released that should allow for easier investigation of any issues encountered with the indexing of pages by our Site Search functionality.

By opening the details of events labeled "Site spidering completed with success", it is now possible to access a detailed log of the operations performed by our crawler, including analysis of the robots.txt and any sitemaps.

At the end of the log, you will also find a handy list of pages that encountered indexing problems.

Another one for content best practices! We're rolling out an option to stop CMS users from publishing invalid records.

How can published records be invalid you ask? Imagine records where title fields were required, and everything was published correctly. No sweat. You now extend that model to add in a new subtitle field which is also required. At this point, all the records in that model will require you to update them by filling in the subtitle field before their next publish.

While we'll enable this flag to TRUE for all new projects, you can easily enable it in your existing project under Configuration > Available Updates.

We’ve made a small but significant change to the way new models are created.

To enforce editorial best practices and provide better flexibility for your content workflows, draft mode will now be enabled for all new projects. While this is the new default, you are able to override this when creating new models, under the model's validation settings.

Additionally, for existing projects, we’ve added an option to enable this setting. You can find it in Configuration > Available Updates.

It is now possible to save invalid records in their draft state, and postpone validation enforcements to publication time. The feature can be enabled and/or disabled on models with the draft/published stages active.

The feature affects the CMS and, of course, the CMA (Content Management API). When draft saving is active, it's possible to POST/PUT invalid records to CMA and have them saved: the endpoints respond with a 200, and the record is just saved as a payload.

Validations will take effect when the record is published. If the record is not valid, publication fails, and editors need to fix the content to ensure all rules are handled before proceeding to move the record into the Published stage.

Starting March 10th, 2025, our legacy batch operation endpoints — which have been deprecated for years — will be discontinued and will return error responses. Documentation for these endpoints can be found here:

• https://www.datocms.com/docs/content-management-api/resources/item/batch_destroy

• https://www.datocms.com/docs/content-management-api/resources/item/batch_publish

• https://www.datocms.com/docs/content-management-api/resources/item/batch_unpublish

Required action

If you're using any of these endpoints, please update your integration to use their replacements. Documentation for the current endpoints can be found here:

• https://www.datocms.com/docs/content-management-api/resources/item/bulk_destroy

• https://www.datocms.com/docs/content-management-api/resources/item/bulk_publish

• https://www.datocms.com/docs/content-management-api/resources/item/bulk_unpublish

Impact assessment

Based on our monitoring over the past two months, only four projects are actively using these deprecated endpoints. If your project is affected, you will receive a direct email from our team in the coming days.