Let's Camp SEO strategy

This document was created through a combination of consultations with programmatic SEO experts, reverse-engineering HipCamp's strategy from their sitemaps, and Let's Camp's ICP docs, investment memo, and inventory.

1. What HipCamp is actually doing

There are five page archetypes stacked into one big permutation engine:

1a. The geographic backbone

These "shell" pages each show a hero, intro paragraph mentioning the place by name, listing cards, FAQ block, and internal-link rails ("Top cities", "Top regions", "Top national parks", "Nearby states").

1b. The filter dimension (48 single + 15 multi)

Stacked on top of every geo, they layer 48 single-filter pages and 15 selected multi-filter combinations. Grouped:

1c. Specific-property pages (the listing leaves)

1d. Long-tail question pages

10,748 question URLs (4,994 unique slugs after dedup). Counted by leading pattern:

1e. Collections (editorial)

52 evergreen + event-driven landing pages: e.g., /collections/camping/memorial-day, /collections/camping/overland-expo-west, /collections/camping/field-van, etc. Low volume, high seasonal intent.

1f. The math of the index

Single-filter discover pages: ~92,500 URLs.
Multi-filter: 2,615 URLs.
City "all" pages: tens of thousands of URLs.
Public-campground pages: tens of thousands of URLs.
Question pages: 10,748 URLs.

HipCamp's PSEO index is somewhere in the 200K-500K page range.

2. What changes for Let's Camp

Shift 1: Inventory is the bottleneck, not the keyword universe

HipCamp has tens of thousands of listings. Let's Camp has ~200 campgrounds right now.

Shift 2: There are two audiences, not one

• Operator SEO → drives B2B SaaS signups directly → grows the inventory → unblocks the consumer PSEO from the thin-inventory problem
• Consumer PSEO → drives camper bookings → makes the marketplace more valuable → makes our B2B pitch ("list with us and Google sends you free traffic") more credible → drives operator signups

Build both, but operator pages ship today regardless of inventory while consumer pages need inventory density + data first.

Shift 3: Canada-first taxonomy

A few of HipCamp's filters are Canada-irrelevant (redwoods, desert, surfing). The additions below are Canada-specific. They live on different axes of the permutation engine — calling out which is which because they're not all the same kind of thing:

3. Infrastructure

Let's Camp actually runs three separate web properties. The main site has structural SEO friction.

~1,000+ pages are indexed as of June 2026. But Google's crawler has to execute each page's JavaScript and index the rendered DOM. This is slow and expensive for Google; it's faster at indexing straight HTML. Indexing gets queued (days-to-weeks delay for new URLs), and pages can be invisible to non-Google crawlers (e.g., Bing, ChatGPT / Perplexity / Claude search, social cards).

The slowness is a real problem for a Programmatic SEO play that needs to ship hundreds of new pages quickly and earn AI-crawler citations.

The fix is adding Server-Side Rendering (SSR). There are common tools on the market to do this, such as Prerender.

Here are the benefits of SSR:

1. Speed of indexing new pages. Rendering Javascript-heavy pages can take days to weeks for a new URL to be indexed. For a PSEO corpus shipping tens of new pages per week, that drag compounds. SSR pre-renders pages so Google's first pass can pick up all our content on the first pass.
2. AI crawlers and non-Google search. ChatGPT, Perplexity, Claude search, and Bing don't typically render JS. AI search citations are a growing acquisition channel; SSR makes us visible to them.
3. Deterministic reliability. Pass 2 can be silently delayed or fail. SSR is straightforward to verify.

Infra recommendations:

1. Add Server-Side Rendering.
2. Operator-side competitor pages — start on join.letscamp.ca immediately. WordPress + Yoast is already there. Just add ~12 new pages. (No new infra required.) Subdirectories generally outrank subdomains by 15-40% in measured A/B migrations, so eventually we'll want operator content under letscamp.ca/software/..., but the existing subdomain has accumulated authority and backlinks, so we don't need to today. Plan a consolidation pass later, once the corpus is stable and someone can babysit the 301s + Search Console for ~90 days.
3. Consumer-side PSEO at scale → build at letscamp.ca/explore/... as a static-rendered subdirectory. Google's official position is that subdomains and subdirectories rank equivalently, but practitioner consensus (Rand Fishkin, Aleyda Solis, multiple documented migrations) is that subdirectories outperform subdomains by 15-40% in practice. The probable mechanism is authority consolidation + entity perception + denser internal linking — not crawl budget or domain authority literally. Since this is brand-new content with no migration risk, we get the upside for free by going subdirectory from day one.
4. Noindex the 416 /camps/<slug>/terms-conditions pages. They're templated legal boilerplate with no search intent and currently sit in the sitemap. Five-minute fix, modest domain-quality lift.

Subdirectory architecture for the new PSEO surface is the consequential choice — get it right at the start.

Implementation options for letscamp.ca/explore/* — to decide with Vivek / Mike

The strategy (build /explore/ as a static-rendered subdirectory of letscamp.ca) is settled. The technical path to get there has three viable shapes. This is the kind of decision worth making jointly with whoever owns the Let's Camp tech stack:

Option A: Cloudflare Worker as a reverse proxy

A Cloudflare Worker sits in front of letscamp.ca and routes traffic by URL prefix:

• /explore/* → a new static-rendered SEO site, hosted separately (Vercel, Cloudflare Pages, etc.)
• everything else → the existing Vite SPA, unchanged

Yes, this is a reverse proxy. The Worker accepts incoming requests and forwards them to different origins based on path rules. Workers run at the edge so the routing overhead is minimal (low milliseconds).

• Pros: Zero impact on the existing booking app. Independent deploy cycle for SEO content. Fast edge routing. Easy to roll back or A/B test. Two teams can work in parallel.
• Cons: Two codebases. Another moving piece in the system. Worker subrequest limits (50 per request) apply if a single page needs many origin fetches.
• Best when: We want to ship SEO content fast without touching the booking app. Cloudflare is already in the stack.

Option B: Build static rendering into the existing Vite app

Add SSR capability to the current Vite/React app, either by:

• Adopting Vite SSR via Vike (formerly vite-plugin-ssr)
• Migrating to a framework that does SSR natively (Next.js, Astro, Remix)

The /explore/* routes would then be pre-rendered at build time as static HTML, shipped from the same codebase as the booking app.

• Pros: Single codebase. No proxy layer. Future-proofs the whole app for SEO, not just /explore/.
• Cons: Bigger engineering lift up front. Any bug in the migration risks the booking conversion flow. Ties SEO release cycle to app release cycle.
• Best when: The team is already considering a framework migration for other reasons (performance, DX), OR there's appetite for a single-codebase architecture.

Option C: Add Prerender.io (or equivalent) to the existing site

A drop-in service caches a server-rendered version of every SPA page. Cloudflare detects search-bot user-agents and routes them to the cached HTML; human users get the SPA.

• Pros: No code changes. Works for the entire site, including the existing 1,000+ /camps/* pages. Fastest path to "Google sees pre-rendered HTML."
• Cons: External dependency. Costs scale with traffic ($90+/month at PSEO scale). Only helps SEO bots — humans still get the SPA, so no Core Web Vitals benefit. Doesn't make new PSEO content easier to author — we still need somewhere to build it.
• Best when: We want a quick fix for the existing SPA's indexing speed without building a separate static site.

4. Keyword storing — the explicit lists

The subsections below are the master taxonomy of keyword dimensions: geo, camp-style, amenity, activity, audience, and Canadian-specific niche. You generate a candidate page-set by combining one value from each relevant dimension — e.g., a province from the geo list plus a filter from the camp-style list produces a /camping/{province}/{filter} page. All values are picked with Canadian search behavior in mind, not US — that's why some of HipCamp's 48 filters from §1b don't appear here, and a few Canada-specific ones do.

3a. Geo

Country: Canada (1) · Provinces and territories (13): BC, AB, SK, MB, ON, QC, NB, NS, PE, NL, YT, NT, NU.

3b. Camp-style — grounded in real product taxonomy

Use Let's Camp's own bookable-inventory taxonomy for filters, because every filter page can then ladder directly into the booking funnel without a category mismatch. From the homepage "What are you booking?" dropdown, the actual product categories are:

Search-intent additions (keyword-driven, not product-driven):

3c. Amenity dimension

3d. Activity dimension

3e. Audience / use-case

3f. Canadian-specific niche

3g. B2B / operator-side (different intent, higher conversion)

5. Page templates

Three core templates. Each is a Mustache-ish template with slot fillers from inventory, scraped public data, and a small editor-curated per-province table.

URL:   /camping/<province-slug>/<filter-slug>     (province root)
       /camping/<province-slug>/<city-slug>/<filter-slug>   (city)
       /camping/<province-slug>/<region-slug>/<filter-slug>  (region)
H1:    "The best {filter} camping in {place}, {province}"
Meta:  "{filter} camping in {place}: {N}+ campgrounds | Let's Camp"

Above the fold:
- Hero image
- H1
- 2-3 sentence intro: sensory-specific opener about the place,
  then a one-line inventory summary ("{N}+ {filter} sites starting
  at $X/night"). NO em-dashes, NO dangling "the same".
- Filter chip rail (other available filters for this geo, with counts)

Body:
- Listing grid (cards): name, rating, # of sites, key amenity icons,
  starting price in CAD, "Book direct" CTA
- If <5 listings: pad with "Public {province} provincial parks near
  {place}" cards (info only — HipCamp's state-park trick)

Internal-link rails (this is where SEO compounds):
- "More {filter} camping in {province}" → 8 nearby cities/regions
- "Other ways to camp near {place}" → 6 other filter types
- "Top provincial parks near {place}" → 6 parks
- "Top campgrounds in {province}" → 6 most-booked listings
- Breadcrumb: Canada > {Province} > {Place} > {Filter}

Below the fold:
- FAQ (5-8 questions; LLM-generated against per-province fact sheet,
  human-edited)
- Recent reviews (pull from listings if available)
- App download / "Become a host" CTA

URL:   /camping/{province-slug}/parks/{park-slug}
H1:    "Camping at {Park Name}, {Province}"
Meta:  "{Park Name} camping: {N} campgrounds nearby, booking guide,
        and what to know before you go | Let's Camp"

Body:
- 4-paragraph guide:
  1. What the park is, in one line
  2. Best time to visit, peak/shoulder seasons
  3. How camping inside the park works (fees, booking window) —
     link OUT to the official source
  4. "Where to camp nearby" — Let's Camp's actual inventory surfaces

- Cards: official park campgrounds (info only) + Let's Camp customer
  listings within X km, sorted nearest
- "Things to do at {park}" — 6-10 activities with internal links
- FAQ block
- Map embed
- Internal-link rail: other top parks in this province

URL:   /software/<comparison>   e.g. /software/campspot-alternative
H1:    "The best Campspot alternative for Canadian campgrounds"
Meta:  "Campspot alternative: free marketplace, no monthly minimum,
        Canadian support | Let's Camp"

Body:
- Hero with one-line value prop
- Side-by-side comparison table (Let's Camp vs Campspot) — cells
  straight from the VoC bad-alternatives table
- "Why owners switched" — 3-4 named-customer quotes (Nancy G.,
  Kassandra C., Michael S. — public, Capterra-sourced)
- "How the switch works" (the 48-hour migration value prop)
- FAQ: pricing, migration, training time, existing reservations
- "Book a demo" CTA throughout

URL:   /camping/{province-slug}/parks/{park-slug}/sold-out-alternatives
       (also: /camping/alternatives-to-{park-slug})
H1:    "Where to camp when {Park Name} is sold out"
Meta:  "{Park Name} sold out? {N} nearby Canadian campgrounds with
        availability right now, plus walk-up options inside the park."

Above the fold:
- H1
- 2-sentence intro using real proprietary data, e.g.:
  "{Park} weekend sites sell out 47 days before check-in on average.
  Here are {N} Let's Camp partner campgrounds with availability
  within a 2-hour drive, plus walk-up options inside the park itself."
- "Available right now" badge or live count

Body — five blocks:
1. Live availability — nearby private campgrounds (Let's Camp inventory
   within ~2hr drive, sorted by drive time). Card per camp: name,
   distance, recent-booking ticker, starting price, "Book" CTA.
2. Walk-up campgrounds inside {Park} (info only, links to official
   park site). Same trick as HipCamp's state-park pages — capture
   intent we can't directly serve.
3. FAQ block (templated from Google's "People Also Ask" for this geo):
   - "Can you camp in {Park} without a reservation?"
   - "How far in advance does {Park} sell out?"
   - "What's the closest park with availability?"
   - "When does {Park} open for reservation?"
4. Closest similar parks — internal links to /camping/{province}/parks/{X}
   for 4-6 nearby parks with similar character (Killarney for Algonquin,
   Yoho for Banff, etc.).
5. Map: pins for nearby private campgrounds + the park itself.

Methodology block (mandatory): "Lead-time data based on {N} bookings
across {Y} Let's Camp campgrounds near {Park} between {date range}.
Refreshed weekly."

5b. The quality bar — what makes a PSEO page worth shipping

The hard part of PSEO isn't generating pages, it's generating pages Google rewards. Empty templated pages don't just fail to rank — they degrade the perceived quality of the whole domain. Ship only if most of these are present:

• Proprietary data the reader can't find elsewhere. Best moat. For Let's Camp: actual lead-time data, real-time availability, real price ranges in that geo, occupancy patterns.
• Sub-breakdowns and ranges, not point estimates. Glassdoor's analog: price by site type with a "what's typical" callout. Always a range, never a single number.
• A real map. Embedded, with pins for every listed campground and key landmarks.
• Methodology block. "How we picked these" — what data, how ranked, when updated. Two sentences, signed off.
• Top-X lists with reasons. Each listing has a one-line reason it's on the list. Differentiation per listing, not uniform cards.
• Real reviews surfaced inline. The proof-of-life signal. Verbatim, with name, date, length of stay, snippet.
• Auto-generated FAQs templated against actual entity data; FAQPage schema for rich snippets.
• Internal links to two scales of context — one zoom out (region/province), one sibling (other places at same level).
• Tools where applicable. Campground pricing calculator, "how many nights can we afford" — earns external links.
• No padding. Thin-yet-padded pages are worse than short-but-dense ones.

5c. The content quality rubric (every page passes this before ship)

§5b lays out the principles. This is the operational checklist that enforces them. A page can only ship if it passes this rubric. Run through it as a gate before publishing each batch.

6. Phased rollout

Each phase has a clear gate. Headline principle: quality first, scale second. First batch (20-50 great pages across operator + consumer + park templates) is the proof point. Don't ramp until those are ranking. Then 5-10/week, not 500. Google's quality classifier penalizes sudden floods of templated pages.

7. Content generation pipeline

None of these are exotic — table stakes for any PSEO play.

1. Master inventory table. Every campground, structured fields. Sourced from MongoDB camps + sites + sitetypes (see Appendix A).
2. Proprietary-data extract (nightly from MongoDB): aggregations of bookings, availabilities, pricemodels, waitlists, events, addons, attractions.
3. Per-province fact sheet (one short markdown each, edited twice a year): season dates, peak/shoulder, prices, top activities. Ground truth for the LLM.
4. Public-park dataset (quarterly): name, province, slug, official URL, geo, key features, lat/lng.
5. External data joins:
   • Weather: Environment and Climate Change Canada open API. Per camp by lat/lng → nearest station → monthly historical normals. Powers historical weather graphs and entire pages like "Best camping months in {region}", "Driest July destinations in {province}", "Year-round warm-weather campgrounds." Refresh annually.
   • Trails: OpenStreetMap. Per camp → trails within X km → name, length, difficulty. Powers "Trails near {camp}" and the parallel "Camping near the {trail name}" page set. AllTrails has the trails; Let's Camp can be the bridge.
   • Optional: tides (DFO), ferry schedules (BC Ferries, Marine Atlantic), aurora forecast, dark-sky preserves (RASC).
6. Templates (Mustache or Python f-strings): one per page type.
7. LLM generation step: only state facts present in fact sheet or proprietary-data extract. Strict prompts.
8. Human QA queue: 30-second human review before ship. 60-100 pages/hour at reasonable quality.
9. Renderer: Next.js or Astro ingesting JSON per page.
10. Sitemap generator: split by template (sitemap-cities.xml, sitemap-parks.xml, sitemap-software.xml), submitted via Search Console.

7b. Measurement and monitoring

PSEO is a domain-level reputation game. Dashboard should be Google Search Console (free, authoritative for what Google sees), not just Ahrefs/SEMrush.

Pre-launch / per-batch

• New pages return HTTP 200 with proper title + meta description
• Internal links resolve (no 404s in the new batch)
• Schema validates (FAQPage, LodgingBusiness, BreadcrumbList — Google Rich Results Test)
• Sitemap updated + re-submitted via Search Console

Weekly alarms

• "Discovered – currently not indexed" growing = Google saw the URL but chose not to crawl. Almost always quality. Fix before shipping more.
• "Crawled – currently not indexed" growing = Google crawled AND read AND chose not to index. Same fix.
• 404s / soft-404s climbing = renderer issue or dead sitemap URLs. Same-day triage.
• Site-wide average position dropping after a batch = new pages diluting domain quality. Pull, fix, redeploy.
• Index coverage rate = indexed / submitted. Target ≥80%. <50% = quality problem, stop ramping.

Monthly editorial

• Stale content audit. Pages >12 months untouched: refresh or de-index.
• Better to remove than to keep up. Pages with no impressions after 6 months: fix intent match or noindex.

Lead-attribution (GTM-engineer angle)

• Track demo bookings + signups per page. Operator-driving pages are worth 100× camper-bouncing pages. UTM correctly. Surface per-page conversion in the funnel monitor.

7c. Data freshness architecture (how often pages refresh)

A PSEO page is only useful if its data is current. But re-rendering thousands of pages on every database change is wasteful and breaks the static-rendering model. The standard pattern at SEO scale is Incremental Static Regeneration (ISR) layered with on-demand revalidation and client-side hydration — three layers, picked by how fast each kind of data changes.

Layer 1 — Static pages with time-based revalidation (the bulk of the corpus)

Pages are pre-rendered as static HTML at build time. Each page has a revalidate interval — when a request comes in after the interval has elapsed, the page is regenerated in the background and the requester gets the stale version instantly. Next.js calls this ISR; Astro does it via SSG + adapter; Vercel and Cloudflare support it natively.

Recommended intervals for Let's Camp:

• 24 hours for camp descriptions, attractions, named-park guides, FAQs, comparison pages — most of the corpus
• 1 hour for price ranges, lead-time stats, "X% availability for {month}" badges — anything tied to pricemodels or availabilities aggregates
• 5–15 min is overkill for static rendering; if you need this frequency, the block belongs in Layer 3

Layer 2 — Webhook revalidation for material data changes

When something important changes in MongoDB (new camp listed, significant price update, new attraction added), fire a webhook from the booking app's API to the PSEO renderer. The renderer calls revalidatePath() (Next.js) or the equivalent on the specific affected URLs. The page rebuilds within seconds.

This is how you avoid the "stale until next 24h interval" gap for changes that matter. It's also why this pattern beats a database listener — events fire at the application layer when they're semantically meaningful, not on every individual database write.

Triggers worth firing:

• Camp goes live / pauses
• Price model changes materially
• New add-on offering launched
• Event added / updated
• Camp closes for the season

Layer 3 — Client-side fetch for live blocks

Some data needs to be near-real-time for humans but isn't useful for Google to index. The recent-booking ticker ("Just booked 3 nights at Big Bend, 2h ago"), live waitlist counts, "open this weekend" widgets — all of these render client-side via /api/... endpoints that hit MongoDB directly.

The static page shell (Layers 1+2) is what Google indexes. The live blocks (Layer 3) layer over top after page load. Google sees the proof-of-life value via the static layers; humans get the freshness on top.

What companies actually do

• Airbnb / Vrbo: static listing pages, ISR with hours-to-day revalidation, client-side data for prices and availability
• Zillow: static for the bulk, on-demand revalidation when listings change, client-side for "estimate updates"
• HipCamp: likely a similar pattern — page bones pre-rendered, hot blocks hydrate after
• Stripe / Linear / Vercel docs: pure SSG, rebuilt on every git push (editor-managed, not data-driven)

Anti-patterns to avoid

• Database listeners that trigger rebuilds on every write. Too noisy, too tightly coupled to the write path. Use application-event webhooks at semantic boundaries instead.
• Re-rendering the whole corpus every N minutes on a cron. Wasteful. ISR re-renders a page only when someone visits it after the interval has elapsed.
• Putting all the data client-side. Then you've built another SPA, with all the indexing trade-offs. The point of the layered pattern is to use Google's static-HTML preference where it helps and reserve client-side for blocks where it doesn't hurt.

Appendix A — Proprietary data → page features

Per-collection mapping: what's in each high-value MongoDB collection, what concrete page block it powers, query shape. Engineering scoping reference.