CMS Best Practices
Webflow CMS Naming Conventions
That Actually Scale
The naming system that keeps your CMS readable at 40 collections and 500 items. Rules, examples, and the mistakes everyone makes once.
Naming things is famously one of the two hard problems in computer science. In Webflow CMS, it is also one of the most consequential. Bad naming does not break your site — it breaks your team's ability to maintain it.
A collection called "Items" with fields named "Field 1," "Text," and "Img" technically works. Webflow will not complain. Your Designer bindings will function. But six months later, when a new developer picks up the project or a content editor needs to update a field, nobody knows what "Field 1" is supposed to contain. The site becomes a guessing game.
This guide covers a complete naming system for Webflow CMS — collections, fields, slugs, help text, and reference fields — that keeps your CMS readable and maintainable regardless of how large it grows. These are not preferences. They are conventions tested across hundreds of Webflow projects.
Why Naming Matters
Editor UX
Content editors interact with your CMS through Webflow's Editor interface. They see collection names in the sidebar, field names as form labels, and help text as guidance. If a field is named "CTA Copy" and the editor does not know what CTA stands for, they will either guess wrong or skip it. If a field is named "Primary Button Label" with help text that says "The text shown on the main call-to-action button (e.g., Learn More, Get Started)," they know exactly what to enter.
Good naming is a UX investment. Every field name is a micro-instruction. Every help text is inline documentation. The five seconds you spend writing a clear field name saves every editor five minutes of confusion — multiplied by every edit they ever make.
Developer sanity
Developers work with CMS data in the Designer (binding fields to elements), in custom code (accessing CMS data via Webflow's API), and in content migration scripts. Consistent naming means a developer can predict what a field is called without looking it up. If every image field follows the pattern "[Subject] Image" (Featured Image, Author Image, Sponsor Logo), you never have to guess whether it is called "img," "photo," "pic," or "image."
API readability
Webflow's CMS API returns field values keyed by slug. A field named "Featured Image" gets the slug "featured-image." A field named "img1" gets the slug "img1." When you are reading API responses at 11 PM debugging a sync issue, featured-image tells you what it is. img1 tells you nothing.
Collection Naming: Plural Nouns, No Abbreviations
Collections represent a type of content. Each item in the collection is one instance of that type. The collection name should be the plural noun form of what it contains.
| Do | Do Not | Why |
|---|---|---|
| Blog Posts | Blog | "Blog" is the section, not the content type |
| Team Members | Team | The collection contains members, not the team itself |
| Case Studies | Work | "Work" is vague — case studies, projects, portfolio pieces? |
| Testimonials | Testi | Abbreviations save two seconds and cost two minutes |
| Event Photos | Gallery | "Gallery" does not say what kind of gallery or what it belongs to |
| Job Openings | Careers | "Careers" is the page. The collection holds individual job openings. |
The rule: If you can say "Each item in this collection is one ___," the plural of that blank is your collection name. Each item in Blog Posts is one blog post. Each item in Team Members is one team member. Each item in Event Photos is one event photo.
No abbreviations. "Testi," "Prods," "Cats" — these save a few characters on screen and cost clarity every time someone reads them. Webflow's interface has room for full words. Use them.
Companion collection naming: Prefix companion collections with their parent's name. "Product Photos," "Event Sessions," "Project Documents." This groups them visually in the CMS panel and makes the relationship obvious without checking the reference field.
Field Naming: Sentence Case, Descriptive, Include Units
Field names are the form labels your editors see when creating or editing CMS items. They should read like clear, professional form labels — not database column names.
Use sentence case
Sentence case means capitalize the first word and proper nouns only: "Featured image," "Author name," "Registration URL." Webflow auto-capitalizes the first letter, so in practice you get: "Featured image," "Author name," "Registration url." Some teams prefer title case ("Featured Image") for consistency — either works, but pick one and stick with it across every collection.
Be descriptive, not clever
A field called "Hero Heading" tells the editor exactly where this text appears. A field called "H1" requires them to know HTML. A field called "Main Title" is ambiguous — main title of what? The page? The hero? The first section?
| Do | Do Not |
|---|---|
| Hero heading | H1 |
| Event start date | Date |
| Featured image | Img |
| Author name | Name |
| Registration URL | Link |
| Price (USD) | Price |
| Duration (minutes) | Duration |
| Square footage | Sqft |
Include units in number fields
If a Number field represents a measurement, include the unit in the field name: "Price (USD)," "Duration (minutes)," "Weight (kg)," "Square footage." Without the unit, an editor entering "90" into a "Duration" field does not know if you mean seconds, minutes, or hours. Including the unit in the field name eliminates ambiguity permanently.
Prefix section-specific fields
For collections that map to page sections (landing pages, service pages), prefix fields with their section: "Hero heading," "Hero subheading," "Hero background image," "Features heading," "Features body." This groups related fields together in the CMS editor and makes it obvious which section each field controls.
Slug Conventions
Webflow auto-generates slugs from the Name field. The default behavior produces reasonable slugs — "My Blog Post" becomes "my-blog-post" — but edge cases and manual overrides can create inconsistency. Establish these rules:
- Lowercase and hyphenated. This is Webflow's default and the web standard. Never use underscores, camelCase, or uppercase in slugs.
- No dates in slugs. "2026-03-15-our-spring-event" creates a URL that is longer than necessary and looks dated when someone visits the page in 2027. Let the slug be the title: "spring-conference-2026." The year goes at the end only if you run the same event annually.
- No stop words. Webflow does not strip "the," "and," "of" from slugs automatically. "The Complete Guide to Webflow CMS" becomes "the-complete-guide-to-webflow-cms." Manually shorten to "complete-guide-webflow-cms" or "webflow-cms-guide." Shorter slugs are easier to read, share, and type.
- Unique and stable. Once a slug is published and indexed by search engines, do not change it. If you must, set up a 301 redirect from the old slug. Slug changes without redirects create 404 errors and lose accumulated SEO value.
Read more about slug best practices in the slug field guide.
Help Text Best Practices
Every CMS field in Webflow has an optional Help Text property. This text appears below the field in the Editor, providing guidance to anyone entering content. Most Webflow projects leave help text empty. This is a missed opportunity.
Good help text answers three questions:
- What should I enter here?
- Where does this content appear on the site?
- Are there any constraints I should know about?
Examples:
- Meta description: "A 150-160 character summary for search engine results. Appears below the page title in Google. Should include the primary keyword and a reason to click."
- Featured image: "Displayed on the blog listing page and in social media shares. Recommended size: 1200x630px. Will be cropped to 16:9 on cards."
- Event start date: "The first day of the event. For single-day events, this is also the event date. Multi-day events should also set the End date field."
- Sort order: "Controls display position. Lower numbers appear first. Use increments of 10 (10, 20, 30) to leave room for reordering."
Writing help text for every field takes 15 to 20 minutes per collection. That investment pays back every time an editor publishes correct content without asking a developer what a field does.
Reference Field Naming
Reference fields connect collections. Their names should make the relationship direction and target obvious.
The rule: Name single-reference fields after the target collection (singular). Name multi-reference fields after the target collection (plural).
| Collection | Field Name | Type | Target |
|---|---|---|---|
| Blog Posts | Author | Reference | Team Members |
| Blog Posts | Categories | Multi-Reference | Categories |
| Sessions | Event | Reference | Events |
| Sessions | Speakers | Multi-Reference | Speakers |
| Product Photos | Product | Reference | Products |
| Case Studies | Services | Multi-Reference | Services |
Avoid generic names. A reference field called "Related" or "Link" tells the editor nothing about what it connects to. "Related Case Studies" or "Parent Event" is immediately clear. The field name should answer "What am I selecting?" without the editor needing to click into the dropdown to find out.
When the relationship is not obvious from the target name, add context: "Primary Author" (not just "Author" if there is also a "Contributing Authors" multi-reference), "Host Venue" (not just "Venue" if the event also has a "Reception Venue"), "Parent Category" (not just "Category" if there is also a sibling relationship). Read more in the CMS architecture planning guide.
How Trellis Enforces Consistent Naming
Naming conventions only work if they are enforced. On a solo project, discipline is enough. On a team — especially agencies managing multiple client sites — conventions drift. One developer uses "Blog Posts," another uses "Articles," a third uses "Posts." Fields get abbreviated. Help text gets skipped. Slugs get overridden.
Trellis enforces naming conventions automatically during CMS generation. When Trellis creates a collection, it follows the rules: plural nouns, no abbreviations, sentence case fields, units in number fields, descriptive reference names, and complete help text for every field.
This is not a linter that flags problems after the fact — it is a generator that produces correctly named collections and fields from the start. You describe your content model ("I need a blog with authors and categories"), and Trellis creates Blog Posts, Authors, and Categories with properly named fields, reference relationships, and help text. Every time. For every project.
For agencies, this means every client site follows the same naming system. A developer picking up a Trellis-generated project knows where to find the featured image field, how reference fields are named, and what the help text says — because it is always the same. Consistency across projects is the closest thing to a superpower in agency work.
Frequently Asked Questions
Should I use Title Case or Sentence case for field names?
Either works as long as you are consistent. Title Case ("Featured Image") looks more formal. Sentence case ("Featured image") reads more naturally. Webflow auto-capitalizes the first letter of field names, so both are viable. Pick one convention and apply it to every field in every collection. Mixing conventions within a project looks unprofessional and creates confusion about whether two differently-cased fields are the same thing.
Can I rename collections and fields after they are created?
Yes, but with caveats. Renaming a collection or field in Webflow updates the display name but does not change the API slug. A field originally named "Img" with slug "img" renamed to "Featured Image" still has the API slug "img." Any custom code or integrations using the old slug will continue to work, but new developers will be confused by the mismatch. When possible, get the names right the first time.
How should I name Option field choices?
Use plain language, not codes. "In Progress" instead of "IP." "Case Study" instead of "cs." Option choices appear in dropdown menus for editors — they should be immediately understandable. Keep them concise but not abbreviated.
Is there a character limit for field names?
Webflow does not enforce a strict character limit on field names, but excessively long names wrap awkwardly in the CMS editor and truncate in the Designer panel. Keep field names under 30 characters. If you need more context, use the help text.
Should I prefix fields with the collection name?
No. A field in the "Blog Posts" collection called "Blog Post Title" is redundant — you are already editing a blog post. Name it "Title" or more specifically "Post title." The collection context provides the namespace. The exception is companion collections, where prefixing with the parent name ("Product name" on a Product Photos companion) can add clarity.