Client: 9th Street Pub, a bar and grill in La Salle, Illinois, serving the Illinois Valley since 1977: “the Cheers of the Illinois Valley”
Scope: Full rebuild of an aging WordPress + Elementor site onto Mainfolk, Champlin Enterprises' own website platform, including menu, events, blog, and a live-domain cutover
Outcome: A site a competing agency's report scored at 19% now grades 96/A, with every old URL redirected, an events calendar and automated blog the old site never had, and analytics where there had been none at all
The situation
9th Street Pub had the website most long-running local businesses have: WordPress with a page builder, assembled years ago and patched since. Under the hood, the builder had left the pages hollow. The homepage had no headline a search engine could read (it lived inside a JavaScript slider), the page content was locked inside builder markup, there was no SEO tooling, and no analytics tag of any kind: the business had never once been able to see whether the website was working.
Then a competing agency cold-pitched the owner with an automated “snapshot report” scoring the site 19%. The score was designed to open a sales pitch, but the underlying point was not wrong: the site needed to be rebuilt, not patched again.
What made it hard
- The content was trapped in the page builder. Elementor pages carry their real content in builder data, not in the post content WordPress exposes, and every page started with the same header chrome. A naive import saw six real pages as duplicates of each other and threw them away.
- The domain could not move. The registrar account was not ours and could not be transferred on any useful timeline, so the standard cutover playbook did not apply. The new site had to go live on a domain whose registration we could not touch, without breaking email, SSL renewal, or sixteen years of inbound links.
- The old site would not sit still. A scheduled blog engine on the old install kept publishing posts three times a week, including into the window after the new site went live. Anything published there existed nowhere else.
The approach
Import measured against the source, not eyeballed
The WordPress importer read all 23 pages, 9 posts, and 82 media files, and every import run was scored page-by-page against the source rather than skimmed. That discipline caught what a visual once-over missed: an entire reviews page (all 7 customer reviews) and most of one article had been silently dropped, and were restored from the source before anyone else noticed they were gone. The result shipped as 13 engineered pages plus the 9 posts, with per-page titles and descriptions and 16 seeded redirects.
A real menu, events, and an automated blog
The pub's 57-item food menu came across as structured data in 9 sections rather than a picture of a menu, laid out in two columns and editable without a developer. The new site added what the old one never had: a full events calendar with month, week, and day views plus a “this week at a glance” strip, and the old site's scheduled blog engine was rebuilt natively on the new platform, posting on the exact same weekly cadence it always had.
A cutover engineered around a locked registrar
With the registrar off-limits, we inverted the usual pattern: the www hostname became the canonical site on the new platform while the bare domain answers with a permanent redirect from the old server, and the platform's edge learned a new www-canonical mode built for exactly this case. Every legacy menu sub-page and all 14 old blog URLs were 301-mapped to their new homes, mail was left strictly untouched, and a full backup of the old site was held so that rollback was a single DNS edit. The five orphan posts the old blog engine had published mid-migration were recovered before the old server went dark, and its schedulers were retired.
Measured after, not just promised
After cutover, the live site was scored with the same class of automated grader that produced the 19%, our own Website Snapshot tool, which is harsher than the agency reports on security and email trust: 96, an A. And for the first time the business can see its own traffic: GA4 and Pulse local-SEO monitoring now run where no analytics tag existed at all.
Results
| Metric | Before | After |
|---|---|---|
| Website grade (CE Website Snapshot) | 19% on a competing agency's report | 96 / A, measured live after cutover |
| Platform | WordPress + Elementor, page-builder markup | Mainfolk: engineered pages, no plugins to patch |
| Homepage heading for search engines | No h1 at all (headline lived in a JS slider) | Real semantic headings on every page |
| Menu | Static builder pages | 57 items in 9 sections, structured and editable |
| Events | None | Full calendar (month/week/day) + "this week" block |
| Analytics | No tag at all; the business was flying blind | GA4 + Pulse local-SEO monitoring |
| Old URLs after cutover | n/a | Every old page and post 301-redirected; zero link equity abandoned |
| Blog posts lost in the move | n/a | 0 (including 5 published mid-migration by a forgotten cron) |
| Downtime during cutover | n/a | 0, with a one-DNS-edit rollback held in reserve |
What we'd tell anyone attempting this
- Diff the content, don't trust your eyes. The dropped reviews page looked fine to a reviewer skimming the new site, because you cannot see what is not there. Scoring every page against the source is the only honest QA for a migration.
- A locked registrar is a constraint, not a blocker. Canonical-host inversion plus server-level redirects delivered a full platform move without touching the registration.
- Hunt for anything still writing to the old site. Cron jobs, form handlers, and scheduled publishers keep running after you stop looking. The five orphan blog posts existed only because we checked the old install one more time after go-live.
- Redirect everything, then verify the loops. Old canonical redirects and new ones can collide into an infinite loop for visitors on stale DNS. Test the cutover from the old path, not just the new one.
- Ship the measurement with the site. A business that has never had analytics does not know what “working” looks like. Monitoring is part of the rebuild, not an add-on.