Summary
Lugg is an on-demand moving and delivery platform. I'm the sole owner of its organic growth and the main developer of its marketing site, working directly with the founders, design, sales and paid acquisition. The site is a Next.js app with 250+ city and service landing pages: furniture delivery in Boston, storage moves in New York, junk removal, store pickups and so on. I rebuilt how those pages are generated, so one set of templates now produces city-aware copy, FAQs and page sections for every service, instead of each page being written and maintained by hand.
The problem
- Copy/paste at scale. City and service pages were built with a brittle copy/paste workflow, so a change to shared copy meant editing page by page.
- Redundant CMS fields. The page schema had eight separate
local_*meta fields that editors had to keep in sync for every page. - Repetitive page sections. Service pages ended in a wall of 200+ "Additional Services" links, and four separate brand-logo components did nearly the same job.
The approach
I treated the site as a programmatic SEO surface rather than a set of hand-authored brochure pages.
- Three meta primitives. Every page is described by an
action, acategoryand aserviceKeyword. Templates combine those with the city to write the page copy, so "Storage movers" becomes "Storage movers in Boston" on the Boston page without anyone typing it. - One template set, many pages. Headings, hero copy, FAQs and section text all read from the same primitives, so a change to the template reaches every page at once.
- Reusable sections. I replaced one-off blocks with shared components that adapt to the service: hero brand logos, How It Works, Items We Take, We Move It All, Trust & Support, a service category accordion, pricing tables and related blog posts.
What shipped
One template for 250+ pages
Templated copy for 250+ landing pages, driven by action × category × serviceKeyword and the city. Headings, hero copy, FAQs and section text all read from the same primitives, so a change to the template reaches every page at once.


Fewer fields, less code
Eight redundant local_* meta fields came out of the CMS schema, and about 120 lines came out of the services landing-page renderer.
Service-page render logic is about 40% smaller (400 to 250 lines). Four brand-logo components became one, driven by a category field that also unlocked hardware- and furniture-specific filtering.


One block instead of 200+ links
Service pages used to end in a wall of 200+ "Additional Services" links. I replaced it with a single combined block of core and additional services, grouped in an accordion.

Prices on every page
Pricing tables on every service landing page, so the page answers the first question searchers ask: what does it cost?
Customer price stories break real Lugg costs into base price, mileage, labor and booking fee across regions and service types. Pricing transparency was the main friction point in customer feedback and in an LLM-search audit.


Also shipped:
- Competitor comparison pages such as Lugg vs. Dolly and Lugg vs. TaskRabbit, with competitor-specific FAQs, built as landing pages rather than blog posts so they can carry comparison schema and serve as paid-search targets for high-intent queries.
- CSV import and export for FAQs, so non-engineers can manage FAQ content at scale.
Results
This work shipped from November 2025 onward, alongside the structured data and site migration work. Over that period the marketing site saw, as tracked in Semrush:
- +28% year-over-year organic clicks and +53% year-over-year impressions in the peak month.
- Average ranking position from 36 to 15.4 in five months across the full keyword footprint, from page four to page two.
Inside the codebase, the same pages now come from one template set: about 40% less service-page render code, eight fewer CMS fields to maintain, and FAQ content that non-engineers can update in bulk.
What I'd point to
- Architecture beats volume. The gains came from composing pages out of structured primitives, not from writing more pages.
- Pricing is content. Putting real prices and cost breakdowns on landing pages answers the question searchers and AI answer engines are actually asked.
- Self-serve tooling. CSV import and export means the content team can scale FAQs without an engineer in the loop.