Skip to main contentLoren Couse
Menu

Case study · Lugg

Programmatic SEO for 250+ Landing Pages at Lugg

How I replaced a copy/paste workflow for 250+ Lugg city and service landing pages with a programmatic SEO system in Next.js, and the search results that followed.

Role
SEO & AEO Growth Engineer
When
July 2025 – present
Company
Lugg
Written

What itchanged

  1. 36 → 15.4average Google position in five months, page four to page two
  2. +28%year-over-year organic clicks in the peak month
  3. +53%year-over-year impressions in the peak month
  4. 250+local landing pages on one template system
  5. ~40%less service-page render code (400 to 250 lines)
  6. 8redundant CMS fields removed

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.

  1. Three meta primitives. Every page is described by an action, a category and a serviceKeyword. 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.
  2. 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.
  3. 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.

Lugg landing page header for general moving: track your movers in real time, movers on your scheduleThe same header on the couch removal page: track your couch removal in real time, couch removals on your schedule
The same header component on two pages. The service keyword rewrites every heading, so the couch removal page talks about couch removal without a hand-written variant.

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.

Bassett Furniture same-day delivery landing page with ratings and a row of furniture retailer logosPODS moving help landing page with a row of storage company logos
One hero component, two categories. The logo row is chosen by the page category, so furniture pages show furniture retailers and storage pages show storage brands.

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.

Service category accordion: a truck and movers for any occasion, with junk removal expanded into related services
Core and additional services, grouped in one 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.

Lugg pricing in Salt Lake City: base fare, per-mile rate and average cost for each truck sizeLugg pricing in New York City: base fare, per-mile rate and average cost for each truck size
City pricing on service landing pages, here for Salt Lake City and New York City.

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.

What ittook

  1. 33merged pull requests, November 2025 to April 2026
  2. 400 → 250lines of service-page render code
  3. CVSS 10.0Next.js vulnerability patched with the 15.2.6 upgrade

Next: Lugg schema and AI search

A dynamic FAQ engine, Service and FAQ JSON-LD, and a help center rebuild that made Lugg content readable for both Google and LLM answer engines.

Want this on your site? Write to me.

contact@lorencouse.com