Picture a language school website. A couple of dozen courses, each with its own page, and on each page a teacher block: photo, name, a few lines on qualifications. Pages were built the usual way—copy a good one, duplicate, change the course title. Everything works until one teacher changes her surname.
Someone has to remember how many pages mention her, open each one, and fix it. Missing one is easy, and the site will know her under two surnames at once. Not a disaster, but a telling symptom. The site has been storing entities—courses, people, schedules—for a while. It just stores them as copies of pages.
How a page copy differs from a Feed entry
A page copy glues layout and content together. To change how all course pages look, you walk each page. To change a shared fact, you hunt every copy. More pages mean costlier edits and a higher chance something gets missed.
A content model splits the two. A template owns the look; records with the same field set own the content. Tilda’s July 7, 2026 Feeds 2.0 CMS announcement describes exactly that: define post structure and fields, style the post page in Zero Block, build a custom publication tile, and output Feeds with a new block.
Per the docs, you can start a feed empty or from a preset like “Blog” or “FAQ”, then adapt fields. Field types include text, images, gallery, video, date, link, number, dropdown, and more. A field can be required, so a post without it will not save. Small detail, but it disciplines content entry in practice.
What reference fields add
The interesting part for our school came later. From September 21, 2026, custom Feeds can use reference fields—link one feed to another. Tilda’s example is webinars and speakers: you do not retype the host for every webinar.
Reference field docs say a link can be single (one record from another feed) or multiple. You can show linked data in the tile, on the post page template, and in blocks from “Feeds and CMS”.
For the school that means: teachers in one feed, courses in another, each course points at its teacher. Change the surname once; all course pages show the new one. Twenty edits become one, and you cannot forget a page.
When a site should think about a content model
To me the honest sign is repeating edits. If you change the same information in several places on a schedule, the site already has an entity without its own home. A second sign is relationships—course and teacher, service and specialist, project and industry. When objects reference each other, copies drift faster than you can realign them.
A third sign is growth. With five pages, copying can be fine; a content model takes design time too. With dozens and a plan to add more, each copy raises the future cost of change. Design fields and links before the site sprawls, because moving content from copies into records later is manual work or CSV import.
Tilda offers CSV import and export between feeds, but fields in the new feed must exist first—they do not appear from the file alone. Deleted fields are kept 30 days and can be restored with values. Good safety net, not an excuse to design structure on the fly.
A site that grows without copies
If services, specialists, and projects on a company site still live as duplicated pages, you can plan a corporate site around a content model: entities and links first, then templates and design.
What Feeds do not replace
It is easy to confuse a content model with a business-process database. Feeds store and display records—courses, people, articles, events. Booking with seat limits, payments, schedules driven from an accounting system—they do not handle that on their own. You need other tools and integrations, sometimes a separate app.
Another caveat is design. Post page templates and custom tiles in Feeds 2.0 are set up in Zero Block, though you can output posts with a standard block. For a site the owner will edit, that matters: Zero Block gives design freedom but needs more care when editing. I would decide where the template lives together with who maintains it.
Lastly, Tilda’s September release announced a public API for Feeds CMS to show them on external sites. That widens options but does not turn Feeds into a general-purpose database. Records remain site content; they do not become your ERP.
A content model starts before Tilda
The useful work with Feeds happens before you turn them on in project settings. You need to know which entities the business has, which fields each requires, what links to what, and which pages should exist. That is structure design at the data level. I have written that I build SEO before design; a content model, to me, continues the same logic.
When entities are described, Feeds are a handy way to store and show them. When they are not, Feeds become another place to paste pages—now as posts. New tool, same mess.
The language school from the opening does not have to redo everything at once. Sometimes moving only teachers into their own feed is enough. Surnames change rarely, but one edit is better than twenty.