A Drupal redesign often starts with visual ambition, but the project becomes expensive when the content model is left untouched. Old content types, overloaded fields, unclear view modes, and editor workarounds quietly shape every component.
Content model cleanup before redesign is a planning step, not a cosmetic task. It decides which content types still have editorial purpose, which fields carry meaning, which displays are real, and which cleanup choices need migration or rollback planning.
Map Each Content Type To An Editorial Job
Start by asking what each content type lets an editor publish that no other type can handle cleanly. If the answer is only a campaign name, an old department, or a one-time layout need, the redesign should not inherit it blindly.
Write the owner, audience, required fields, default workflow, and display contexts for each type. This gives designers and developers a shared map before they decide which components, templates, and preview states are worth building.
The Content Model Cleanup Worksheet
Use one row per content type. Record the editorial job, fields editors actually understand, fields that are empty or duplicated, view modes in use, migration risk, accessibility concern, cache or permissions concern, and the redesign decision.
The worksheet should produce decisions, not inventory theater. Keep, simplify, merge, migrate, document, or retire each item. If the team cannot choose one of those actions, the model is not ready to drive design work.
Check Fields Before Components
A field should describe content meaning rather than a one-off presentation preference. When a field exists only to force spacing, image placement, teaser length, or a special campaign variant, it may belong in component configuration instead.
Before removing or renaming a field, check existing content, revisions, migrations, feeds, API consumers, search displays, accessibility labels, and editor training notes. Cleanup is safer when the blast radius is explicit.
Use View Modes As A Design Reality Test
View modes show whether the same content needs different presentations in full pages, teasers, listings, search results, embedded cards, or editorial previews. If every mode has custom exceptions, the redesign is inheriting a content strategy problem.
For example, a case study teaser may need a short outcome, logo, industry tag, and image crop, while the full page needs challenge, approach, result, and proof. Naming that difference early prevents components from becoming vague all-purpose containers.
Sources Used For Drupal Behavior
Use the Drupal documentation as the boundary for platform concepts: Drupal User Guide: adding a content type (Use for content type structure context.); Drupal User Guide: view modes and formatters (Use for display-mode planning context.).
Official documentation explains the Drupal concepts, but the production site still needs local review. Exported configuration, custom modules, editorial habits, and migration history can change what is safe to edit.
What To Decide Before The Redesign Starts
Before visual design starts, decide which content types stay, which fields are renamed or retired, which view modes are required, what editors need to preview, and which changes require migration scripts or stakeholder approval.
The practical standard is simple: no component should be designed around a field nobody owns, a view mode nobody uses, or a content type nobody can explain. That is how Drupal cleanup turns redesign work from guesswork into implementation planning.
Migration And Editorial Risk Review
Every cleanup choice should be tested against migration risk. Removing a field sounds simple until older nodes, Views filters, paragraph references, feeds, or custom templates still expect it to exist. Before the redesign team deletes or merges anything, export a small inventory of affected content and write down what happens to each value.
The editorial risk is just as important as the technical risk. If editors used a field as a workaround because the old system gave them no better place for a note, removing it without a replacement will recreate the same workaround after launch. Cleanup should ask why the mess appeared, not only whether the database looks untidy today.
Preview, Access, And Cache Questions
Content model decisions also shape preview and access behavior. A field that changes a teaser, a landing page card, and a search result needs to be previewed in each of those contexts. A role that can edit the main body may not be allowed to change a taxonomy term or media reference. These details affect confidence on launch week.
Cache planning belongs in the same conversation. If one content item appears in several components, the redesign needs to know which updates should invalidate which pages. A clean field map gives developers a better chance of setting cache tags, contexts, and view modes deliberately instead of discovering display bugs after editors begin real work.
How To Run The Cleanup Meeting
Bring one editor, one designer, one developer, and one product owner into the cleanup meeting. Review a real node for each content type, then ask what the next version of that page must do. Mark fields as keep, rename, merge, migrate, archive, or investigate. Do not decide from the field list alone; decide from real editorial examples.
End the meeting with a short decision register. Each entry should name the content type, the field or display affected, the decision, the reason, the owner, and the follow-up test. This register becomes the bridge between discovery and implementation, and it reduces the risk that a redesign ships beautiful components on top of confused content.
Prototype With Real Content Before Locking Components
The cleanup should feed a prototype before the redesign locks its component set. Use real nodes with long titles, missing images, unusual taxonomy combinations, unpublished references, and older body copy. Real content shows whether a component is flexible enough for the site or whether the design only works for the perfect example.
This step often reveals the quiet decisions that matter most: whether a summary should be required, whether media needs focal point guidance, whether a card should hide empty metadata, and whether a view mode needs a separate editorial label. Those decisions are content model decisions as much as theme decisions.
After the prototype review, update the field map again. Mark which cleanup choices are launch blockers, which can be done after launch, and which should be left alone because the migration cost is higher than the editorial benefit. A good redesign does not need a perfect model; it needs a model the team understands and can maintain.
Keep one old, awkward page in the test set until the end. If that page can be edited, previewed, and displayed without special handling, the cleanup has probably improved the model in a way editors will feel after launch.
For related context on this site, keep these supporting guides close: Drupal Theme Accessibility Checks Before QA Gets Expensive Cache Contexts A Drupal Theme Team Should Discuss Early Drupal Component Library Planning Checklist For Theme Teams.