Just Enough to Be Dangerous

TECHNICAL REFERENCE

CMS for Car Dealerships: A Technical Reference

How a CMS builds a page

Content in the CMS

Template / theme the design

CMS assembles combines both

Page shoppers see the finished page

Content and design stay separate, then get combined.

1. What a CMS actually does, technically

A CMS is a content repository plus a presentation layer plus an authoring experience. The three concerns:

  • Content modeling. What kinds of things exist? For a dealer: Vehicle, Incentive, Special Offer, Team Member, Testimonial, Blog Post, Landing Page, Hours, Service Menu, etc. Each has fields (year, make, model, MSRP, photos) and relationships.
  • Storage. Where the content lives. A relational database (MySQL, PostgreSQL) for most. Sometimes a mix of database + object storage (for media).
  • Presentation. How the content becomes a webpage. Templates (themes) in traditional CMSs; a separate frontend in headless.

The authoring experience is the part the marketing team sees. The modeling and presentation are the part the technical team owns.

2. The dealership CMS landscape

Dealer-specific platforms (proprietary). Dealer Inspire, Dealer.com, DealerOn, Sincro, DealerFire. Closed source. The vendor controls the schema, the templates, the integrations, the hosting. Migration off is a full rebuild. Pro: features are dealer-specific out of the box. Con: lock-in, slow vendor support, opaque pricing.

WordPress + dealer theme/plugins. WordPress core + a dealer-specific theme (DealerTrend themes, custom themes from agencies) + plugins for inventory feeds, credit applications, forms, etc. Pro: open, well-understood, large ecosystem. Con: maintenance burden, plugin quality variance.

Headless CMS + custom frontend. Contentful, Sanity, Strapi, or a similar headless CMS, with a Next.js / Astro / similar frontend. Pro: fast, flexible, modern. Con: requires more technical skill to operate, more vendors to coordinate.

Drupal. Open source, powerful, complex. Used by large dealer groups with sophisticated content needs. Heavier than WordPress to operate.

Custom-built. Rare. Almost always a legacy from an original vendor that has since moved on.

3. Content modeling for a dealership

The minimum viable content model for a dealer site:

  • Vehicle. VIN, stock number, year, make, model, trim, body style, exterior color, interior color, mileage, MSRP, sale price, photos, features, certified pre-owned flag, availability status, dealer-specific fields (location, in-transit flag, etc.).
  • Incentive / Special. Offer type, applicable models, start/end dates, disclaimer text, fine print, eligibility.
  • Team Member. Name, role, photo, bio, contact info, languages spoken, certifications.
  • Location / Hours. Address, phone, sales hours, service hours, parts hours, holiday hours, map coordinates.
  • Service. Service category, description, pricing model, common questions, related FAQs.
  • Testimonial / Review. Source, date, content, attribution.
  • Blog Post / Article. Title, body, author, publish date, related vehicles, related services.
  • Landing Page. URL slug, hero, sections, form, conversion goal.
  • Credit Application. Form fields, integration to financing provider, status tracking.

Each of these has fields, validation rules, relationships, and workflow states. The CMS either supports this natively, supports it via configuration, or doesn’t.

4. Workflow and permissions

A real dealership has multiple people creating content:

  • Marketing coordinator — updates special offers, posts to the blog, uploads photos.
  • BDC manager — updates lead form copy, may tweak landing pages.
  • General sales manager — approves pricing changes, vehicle descriptions.
  • Service manager — updates service descriptions, hours, advisor bios.
  • General manager — approves anything that affects brand or legal.

The CMS should support:

  • Roles with specific permissions. Not just “admin” vs “editor.” Granular: “can edit specials but not publish.”
  • Workflow states. Draft → in review → approved → published → archived.
  • Scheduling. A special offer that should appear next Monday can be scheduled.
  • Audit log. Who changed what, when, with what the previous value was.
  • Preview / staging. Review before publishing.

If your CMS doesn’t have these, the team is doing them with email, Slack, and a “promise not to break the site” honor system.

5. Headless CMS architecture

When the CMS and the frontend are separate:

[Authoring UI: Contentful, Sanity, Strapi]
            ↓
       [Content API: REST or GraphQL]
            ↓
       [Frontend: Next.js, Astro, etc.]
            ↓
       [CDN / Edge]
            ↓
       [User]

The benefits:

  • Performance. The frontend can be optimized independently. Static generation, edge caching, image optimization.
  • Multi-channel. The same content powers the website, a mobile app, a voice assistant, a chatbot, an in-dealership kiosk.
  • Developer experience. Modern frameworks, version control, CI/CD.

The costs:

  • Operational complexity. Two systems, not one. A content schema change requires a frontend change too.
  • Preview complexity. Showing draft content on the live site requires explicit preview infrastructure.
  • Vendor coordination. Two vendors, two contracts, two support channels.

For most single-dealer or small-group sites, headless is overkill. For multi-brand groups with 10+ rooftops and a shared content team, headless is often worth it.

6. Multi-site, multi-brand, multi-locale

Multi-site. A dealer group with 5 rooftops can either have 5 separate WordPress installations, 1 WordPress Multisite, 1 headless CMS with locale/channel targeting, or 5 separate headless deployments. Each has trade-offs. The technical question is “how much do these sites share — content, design, code, infrastructure?”

Multi-brand. A dealer group representing multiple OEMs (Ford and Toyota) usually has different sites, sometimes different vendors, often different OEM-mandated requirements. The CMS strategy needs to handle both.

Multi-locale. Spanish-language versions, regional offers, state-specific compliance. Most CMSs support this; few dealers use it.

7. The integration surface

A modern dealership CMS is rarely standalone. It integrates with:

  • Inventory feed. Often the most complex integration. VIN-level data, photos, pricing, options. May be DMS-sourced, third-party-sourced, or vendor-aggregated.
  • CRM. Lead form submissions to the CRM; CRM data back to the CMS for personalization (“Welcome back, here’s what you looked at”).
  • DMS. Deal jackets, service history, customer master.
  • Marketing platforms. Email service provider, ad platforms, CDP.
  • Analytics. GA4, GTM, server-side tracking, conversion APIs.
  • OEM portals. Required for co-op eligibility, dealer locator feeds, incentive display.
  • Financing partners. Credit application submission, status, decisions.
  • Trade-in tools. Vehicle valuation APIs.
  • Chat / messaging. Live chat, SMS, Messenger.
  • Phone systems. Call tracking numbers, dynamic number insertion, call analytics.

The CMS is the integration hub. The vendor or in-house team that owns the CMS is also the team that owns the integration map.

8. The CMS selection criteria

For a new site:

  • Dealer-specific features. Inventory, credit apps, OEM integrations, special offers — built in or assembled from plugins?
  • Time to launch. How long from contract to live site? Dealer-specific platforms are typically 60-120 days. WordPress with a dealer theme is typically 30-90 days. Custom builds are 6-12 months.
  • Time to change. After launch, how long does a content change take? A feature change?
  • Total cost of ownership. License + hosting + maintenance + integrations + agency fees, over 3-5 years.
  • Exit cost. How hard is it to leave? Vendor lock-in is a real cost, even if you don’t plan to leave today.
  • The team’s skills. What can the marketing team do? What requires the vendor? What requires a developer?

9. The CMS handoff checklist

When taking over a CMS:

  1. The schema — what content types exist, what fields they have, what’s required.
  2. The templates — which templates render which content types, where the code lives.
  3. The integrations — what talks to what, where the API keys are, who owns each vendor.
  4. The users — who has access, at what role, with what 2FA.
  5. The workflow — how content moves from draft to published, who approves, who schedules.
  6. The backup — how the content is backed up, how it’s restored, when it was last tested.
  7. The exit — how to export all content in a portable format.

10. References

  • Contentful, Sanity, Strapi, WordPress, and Drupal’s official documentation.
  • “Content Design” by Rachel Lovinger.
  • “Design Systems” by Alla Kholmatova.
  • The CMS Critical Path project’s vendor evaluations.
  • IETF HTTP API design guidance (RFC 7807, RFC 8594).
  • Gatsby, Next.js, and Astro’s content integration guides.

Part of the Just Enough to Be Dangerous infrastructure series from VCTRS. Prefer the plain-English version? Read What a CMS Actually Means for Your Dealership (And Why Marketing Should Be Able to Use It Without Filing a Ticket).

Agreement