1. The hosting stack behind a typical dealership site
A modern dealership website is rarely “one host.” It’s a stack:
- Origin hosting — where the application and database run. The server (or container, or serverless function) that generates each page.
- Edge / CDN — a network of POPs that cache and serve static assets and sometimes full pages close to the user. Often the same vendor as origin (Kinsta + Kinsta CDN) or a separate one (Cloudflare in front of AWS).
- Object storage — for media: photos, videos, PDFs. S3, Google Cloud Storage, or vendor-managed.
- Image optimization — a layer that resizes, formats (WebP, AVIF), and lazy-loads images on the fly.
- DNS — separate concern, covered in the DNS article. Often on Cloudflare, the registrar, or the website vendor.
- Email — almost never on the same host as the website. Microsoft 365 or Google Workspace.
- WAF / DDoS protection — Cloudflare, Akamai, AWS Shield, vendor-managed.
Knowing which layer does what is half the battle when something breaks.
2. Hosting categories in practice
Shared hosting (GoDaddy shared, Bluehost, HostGator)
– Dozens to hundreds of sites per server.
– “Unlimited” marketing claims hide CPU, RAM, and I/O caps.
– Noisy neighbor problem: another site on the box gets a traffic spike, your site slows down.
– Suitable for: brochure sites, low-traffic blogs, test environments.
– Not suitable for: a dealership site that drives real leads.
VPS (DigitalOcean, Linode, Vultr, AWS EC2, Azure VM)
– Guaranteed slice of physical hardware, hypervisor-isolated.
– Root access; you manage the OS.
– Suitable for: a custom application or a tuned WordPress site run by a competent sysadmin.
– Not suitable for: a marketing team that wants to click a button and have a site.
Managed WordPress (WP Engine, Kinsta, Pressable, GoDaddy Managed WordPress, Pantheon)
– VPS or dedicated hardware, pre-tuned for WordPress.
– Automatic core, theme, and plugin updates (with staging environments).
– Built-in caching, CDN, image optimization.
– Backups and one-click restores.
– Support teams that actually know WordPress.
– Suitable for: most dealer WordPress sites that aren’t on a proprietary platform.
Proprietary dealer platforms (Dealer Inspire, Dealer.com, DealerOn, etc.)
– Closed source. You don’t get root access, usually don’t even get FTP.
– The vendor controls everything: hosting, code, updates, security.
– Migration off is a rebuild, not a move.
– Suitable for: dealers who want a vendor relationship, not a technology relationship.
Cloud-native / PaaS (Vercel, Netlify, AWS Lightsail, Google App Engine, Azure App Service)
– Serverless or container-based. Scales automatically.
– Best for: headless CMS deployments, custom frontends, Jamstack sites.
– Rare at the dealership level unless the site is a custom build.
On-prem (rare) — a server in the dealership’s IT closet. Almost never appropriate for a public website. Mention it only to be told “we don’t do that anymore.”
3. The metrics that actually matter
Don’t pay attention to “unlimited bandwidth.” Pay attention to:
- Time to First Byte (TTFB) — the delay between the request and the first byte of response. Under 200ms is good. Over 800ms is a problem.
- Largest Contentful Paint (LCP) — when the main content visibly loads. Under 2.5s is Google’s “good” threshold.
- First Input Delay (FID) / Interaction to Next Paint (INP) — how quickly the site responds to clicks. Under 200ms is good.
- Uptime — usually expressed as a percentage. 99.9% (“three nines”) allows ~8.7 hours of downtime per year. 99.99% (“four nines”) allows ~52 minutes per year. Most managed hosts commit to three nines. The difference between three and four nines is significant cost.
- Requests per second the origin can handle — the practical capacity of the application stack, not the marketing number.
- Cache hit ratio — at the CDN, what percentage of requests are served from edge without hitting origin. 80%+ is healthy; 95%+ is excellent.
- P95 and P99 latency — not just averages. Averages hide the slow requests that customers notice.
4. Migration: how to do it without breaking the site
A typical host-to-host migration:
- Set up the destination. Provision the new environment, install the same PHP/Node version, the same database engine, the same WordPress version (if applicable).
- Migrate files and database. Use the host’s migration tool, or a manual
rsync+mysqldump. Verify checksums. - Test on a hosts file override. Point
yourdealership.comto the new server’s IP from your laptop. Click through every page template, every form, every search. - Lower DNS TTL 48-72 hours before the cutover. Set the relevant records to 300 seconds.
- Cut over DNS. Change the A/CNAME records to point to the new host.
- Keep the old host warm for 7-14 days. Don’t cancel immediately. Some customers will have cached the old IP.
- Monitor. Watch TTFB, error rates, and 404s from multiple geographies.
- Restore TTL. Once the move is stable.
A reverse proxy or load balancer in front of both environments can make the cutover zero-downtime, but adds complexity most dealership sites don’t need.
5. Security at the hosting layer
- Patch cadence. PHP, the web server, the database, the CMS, the plugins — all of it. Most compromises are unpatched known vulnerabilities.
- Isolation between sites. On shared and VPS, a misconfigured neighbor is your problem. Managed hosts isolate at the container or account level.
- WAF (Web Application Firewall). Blocks common attacks (SQL injection, XSS, bad bots). Cloudflare, AWS WAF, Sucuri, or vendor-managed.
- DDoS protection. Layer 3/4 (network) and Layer 7 (application). Most CDNs include this.
- Backups. Daily, retained for at least 30 days, stored off-host, tested for restore.
- SSH/SFTP access. Disable password auth. Use SSH keys. Restrict source IPs.
- File integrity monitoring. Alerts when core files change unexpectedly.
- Least privilege. The
www-datauser shouldn’t be able to write to directories it doesn’t need to write to.
6. Capacity planning
Dealership traffic is spiky. A typical dealer site sees most of its traffic during business hours, with peaks on weekends and around sales events. A few rules of thumb:
- Plan for 3-5x normal traffic during a major sale or marketing campaign.
- Test under load before a big event. Use k6, Locust, or Loader.io to simulate.
- Database is usually the bottleneck, not the web server. Read replicas, query caching, and proper indexing matter more than adding CPUs.
- Static asset caching at the CDN absorbs most of the traffic. If your cache hit ratio is below 80%, fix the cache headers before adding capacity.
7. Monitoring and alerting
- External synthetic checks from multiple geographies (Pingdom, UptimeRobot, Catchpoint, ThousandEyes). Check homepage, key VDP templates, the lead form submission endpoint.
- Real User Monitoring (RUM) for actual user-side performance. Built into GA4 if you have web-vitals events configured, or via Datadog, New Relic, Sentry.
- Origin health checks for CPU, RAM, disk I/O, database connections, queue depth.
- Error rate monitoring (5xx responses, PHP fatals, database connection failures).
- Certificate expiration monitoring. Most managed hosts handle this, but verify.
- DNS resolution checks at the apex and key subdomains.
8. Common failure modes
The slow-LAMP site. Legacy WordPress on a $9.95 shared plan, no object cache, image uploads at 4MB each. Symptoms: TTFB of 2-5 seconds, timeouts during traffic spikes, Google PageSpeed in the 30s. Fix: managed WordPress host + image optimization + caching plugin + reduce plugin count.
The over-provisioned custom build. A dealer’s marketing team hired an agency to build a custom React site on AWS, the agency left, and now nobody understands the stack. Symptoms: every change costs $5,000 from a new agency, deployment failures, mystery outages. Fix: decide whether to maintain the custom stack (and budget for it) or rebuild on a platform the team can run.
The vendor lock-in. Dealer Inspire or Dealer.com hosts the site, and the contract is up. Symptoms: 90-day migration timeline, full rebuild required, content has to be re-entered manually. Fix: this is preventable — keep a content export from any proprietary CMS quarterly.
The “we got hacked” recovery. Outdated WordPress core, an abandoned plugin with a known CVE, a brute-forced admin password. Symptoms: site redirects to spam, Google search results show “this site may be hacked,” host suspends the account. Fix: see the security checklist below. Recovery: clean from a known-good backup, rotate every credential, patch everything, and re-submit to Google.
9. Handoff and exit planning
When you take over hosting for a dealership, or hand it off:
- Document the stack. PHP version, web server, database engine, caching layers, CDN, DNS, SSL.
- Document the deployments. How does code get from a developer to production? Is there a staging environment?
- Document the credentials. Who has access? Where are they stored? Who can add or remove people?
- Document the recovery plan. How do you restore from backup? How long does it take? When was the last restore test?
- Document the exit. How do you get all the content and code out if you leave? Have you tested it?
- Document the cost. Hosting, CDN, WAF, backups, monitoring. The dealer should know what they’re paying and what each line buys.
10. The hosting checklist for a new dealership site
- [ ] Managed WordPress host or established dealer platform with documented uptime SLA.
- [ ] PHP 8.x, current LTS; MySQL 8 or MariaDB 10.6+; current WordPress core.
- [ ] CDN with global POPs, 80%+ cache hit ratio target.
- [ ] Image optimization pipeline (WebP/AVIF, lazy loading, responsive
srcset). - [ ] Object cache (Redis or Memcached) for database-backed pages.
- [ ] Page cache (full-page, not just object) with intelligent invalidation.
- [ ] WAF in front of origin.
- [ ] Daily backups, 30+ day retention, off-host storage, restore tested.
- [ ] SSL/TLS via Let’s Encrypt or commercial CA, auto-renewal verified.
- [ ] DNS with low TTL, registrar lock enabled, DNSSEC if supported.
- [ ] External uptime monitoring from at least 3 geographies.
- [ ] Real user monitoring for Core Web Vitals.
- [ ] Documented deployment, rollback, and exit procedures.
- [ ] Quarterly review of every plugin, theme, and dependency for active maintenance.
11. References
- Google’s Core Web Vitals documentation.
- Kinsta, WP Engine, and Pressable’s published architecture posts.
- Cloudflare’s learning center on caching, WAF, and DDoS.
- NIST SP 800-44 — Guidelines for Securing Public Web Servers.
- OWASP Top 10 and the Web Security Testing Guide.
- HTTP Archive’s Web Almanac for industry benchmarks.
Part of the Just Enough to Be Dangerous infrastructure series from VCTRS. Prefer the plain-English version? Read What Web Hosting Actually Means for Your Dealership (And Why “Who Hosts Our Site?” Is a Question You Should Be Able to Answer).
