The challenge
Premier Auto Repair's website lived on WordPress.com "Atomic" hosting as a heavy Elementor build — about 58 Elementor pages, 470 media files, and plugins the shop never touched. A marketing agency held the keys, the content was effectively frozen, the site was slow, and the sitewide "appointments" call-to-action pointed at a broken draft page. The shop was paying for a platform it could not change and getting nothing new out of it.
The obvious answer — rebuild it in a modern framework — meant re-creating dozens of pages by hand. The shop needed the site fast, cheap, and theirs, and then it needed the site to start working for them.
What we built
1. Capture, don't rebuild (May 2026). We exported everything through the authenticated
WordPress REST API — 15 pages, 21 services, 22 vehicle pages, 3 posts, 470 media items, the
nav menu, taxonomies, and SEO metadata — then captured the rendered site and ran it through a
build step that localizes every URL, heals lazy-loaded images, rewrites ?p=ID shortlinks
to clean URLs, and strips dead WordPress cruft. Pages that were drafts or orphaned on the
old site (appointments, contact, financing, privacy policy, thank-you) were rebuilt into
the captured shell. The WordPress forms became Cloudflare Pages Functions that validate,
trap spam, and deliver leads to the shop's inbox with the customer set as reply-to. Result:
70 pages, fully self-contained, zero broken internal links, forms verified delivering,
deployed on the shop's own domain with automatic TLS.
2. Search and AI-search foundation. Short, clean titles and descriptions on every page;
AutoRepair / LocalBusiness and FAQ structured data; image alt text; real 404s instead
of soft ones; a corrected heading outline; a sitemap with per-post last-modified dates; an
llms.txt map of the site; and explicit access for AI crawlers. A technical SEO audit
drove a fixes round plus long-cache fingerprinted assets and edge caching.
3. A weekly blog that publishes itself. Posts are Markdown in the repo, dated for Tuesdays, written for the shop's customers (tire tread, timing belts, Georgia emissions readiness, check-engine lights) and fact-checked against what the shop actually does — no prices, warranties, or procedures the shop has not confirmed. A scheduled job on AIQSO infrastructure pulls the repo every Tuesday morning, runs a gate (dates, links, tests), builds, deploys the site and its functions, purges the edge cache, and live-verifies each newly released post. The first unattended release passed on 2026-10-27, and 31 articles are written and scheduled through 2027-04-27. Merging a post is the shop's approval; nothing else is manual.
4. Measurement, not promises. Google Search Console, daily rank tracking on 15 target searches, a listings audit with an owner checklist for the shop's business profiles, and a monthly rankings report. We measure positions; we do not promise them.
5. Online booking (November 2026). When the owner asked for online booking, we ported AIQSO's own booking system to Pages Functions with a shop capacity model — drop-off slots every 30 minutes in the morning, wait-while-we-work slots hourly, two-hour notice, a 30-day horizon, holidays blocked, Google Calendar as the booking of record, confirmation and cancel emails with calendar invites. It shipped off by default behind a kill switch, so the merge was customer-invisible until the shop's calendar and credentials were in place. The shop's existing management software has no API, so the owner chose this calendar with eyes open about keying bookings into it.
6. Cameras and network (on site). The same engagement covered the shop floor, not just the website. We installed cloud-based security cameras with analytics-driven alert automation — motion and event analytics that notify the owner instead of leaving footage to be reviewed after the fact — and replaced the shop's networking with a TP-Link Omada stack (router, access points, and switches).
How it works
The architecture is deliberately boring: a static site on a CDN, a handful of serverless functions, a transactional email provider, and a cron job that treats every release as a gated deploy with a live check. There is no CMS to patch, no database to back up, and nothing for an attacker to log in to. Every change goes through a pull request with an automated reviewer, and a merge is the client's sign-off.
Where this pattern fits
This is a Run engagement for a business whose website was a liability it had no time to manage: capture what works, fix what is broken, replace the moving parts with serverless pieces, then keep it alive with content and measurement on a schedule nobody has to remember — and, because we were already on site, the cameras and the network too. It transfers directly to any small business stuck on an agency-managed WordPress site that has stopped earning its keep.