SEO Preservation

185 linking root domains, 15 years accumulated, including press coverage (Washington Post, Smithsonian) that cannot be bought or recreated.

→ Every old URL that carries real backlink equity gets a 301 redirect to its new equivalent — no exceptions, verified individually, not assumed.

Every existing URL mapped to its new destination — core pages, all 30 blog posts, all 59 tag pages, plus explicit 410s for confirmed-discontinued content.

→ The complete core-page table is embedded directly below on this page. Category and date archive pages (noindex, no real backlinks) are confirmed to need no redirect — documented, not assumed.

Existing title tags and meta descriptions for every core page, captured verbatim before the rebuild touches anything.

→ Carried forward as the starting point for the new site’s metadata — refined, not replaced blind.

Existing TripAdvisor, Yelp, and Google reviews — real accumulated trust signals tied to the business, not the website.

→ Unaffected by the rebuild itself — these live on the platforms, not the site. Risk is only in broken outbound links to them.

30 real posts, 2013–2024, targeting real tourist search terms (wildlife on the river, what to wear, local events).

→ Every post preserved with its original slug moved under /blog/ — real titles and URLs already catalogued in Preservation Itemization.

Name, Address, Phone must match exactly across the website, GBP, TripAdvisor, Yelp, Viator, and Airbnb — currently doesn’t (two addresses, three phone numbers found).

→ Locking one canonical version everywhere is a real, open task — not yet resolved, pending client confirmation (see Client Questionnaire).

GA4 (G-6WXE90X597) and GTM tracking must keep working through the migration — losing historical data or breaking tracking mid-launch is a real, avoidable risk.

→ Same GA4 property and GTM container carried into the new site, verified firing correctly post-launch before the old site is fully retired.

The live site currently loads the FareHarbor script redundantly (4x per page) and has no re-bind logic for client-side navigation — a Next.js-specific risk that doesn’t exist on the old static site.

→ The `FareHarborScriptLoader` component (already built) re-runs autoLightframe() on every route change — confirmed necessary, now implemented, not just documented.

The actual cutover from the old host to the new one — the single highest-risk moment in the whole project if done carelessly.

→ Low TTL set in advance, staged rollback plan ready, done with the client present so any issue is caught immediately — not treated as a routine deploy.

The build lives on a staging server before launch — if Google indexes the staging URL, that creates duplicate-content risk against the real site.

→ noindex meta tag + robots.txt disallow on staging, confirmed before any content goes up there.

Real JSON-LD/microdata already lives on every one of the site’s 51 real pages — Organization, WebSite, BreadcrumbList, Article, BlogPosting. An earlier read of a Screaming Frog export said zero schema sitewide; that was a measurement gap (structured-data extraction wasn’t enabled on that crawl tier), not a real finding.

→ Diffed pre/post-launch and carried forward untouched. New commercial types — LocalBusiness, FAQPage, TouristTrip, Offer — get added on top, not built as if starting from nothing.

Every page shares one H1

All pages use the same H1 (the header phone number). Google can’t distinguish the SUP page from the kayak page from the homepage.