How long does an SEO-safe replatform actually take?

Six to twelve weeks of preparation before launch is normal for a port authority site with 800+ indexed URLs. Cutting that short is where the traffic loss happens.

Should we keep the old URLs or use this as a chance to clean them up?

Both. Map every old URL to a target on the new site (keep, redirect or sunset), and improve the structure for the kept ones where it makes sense. The cleanup is fine; the redirect map is non-negotiable.

How much organic traffic typically gets lost in a careless replatform?

30 to 50% within four weeks of launch is the pattern we see when the redirect map is incomplete or the metadata gets rewritten wholesale. Recovery typically takes six to nine months and is never quite complete. The work to prevent it is mechanical, not creative, and far cheaper than the lost traffic.

Replatforming a port authority website without losing a year of SEO

A port authority website often carries 500 to 2,000 indexed URLs accumulated over a decade: tariff schedules, port circulars, vessel notices, terminal information, statistics, regulatory updates, news, careers, public consultations. Most of those URLs are linked from somewhere on the open web (a shipping line tariff page, a regulator citation, an academic paper, a trade press article). The cumulative SEO equity is substantial, and far larger than most port operators realise.

Replatform that site carelessly and you lose a year of organic traffic. Replatform it carefully and you keep the equity, sometimes gain on it. The difference is mechanical, not creative.

Where replatforms go wrong

The classic failure pattern is depressingly consistent:

Old site has 1,200 indexed URLs.
New site is built around 80 cleanly designed pages.
The remaining 1,120 URLs return 404 at launch.
Within four weeks, organic sessions drop 30 to 50%.
The agency blames “Google fluctuations”.
Six months later, traffic still hasn’t recovered.

This isn’t a Google problem. It’s a redirect problem.

The work that has to happen before launch

Crawl the old site comprehensively

Run Screaming Frog or Sitebulb against the live site with no crawl limits. Export every URL with a 200 status code. Cross-reference with Search Console (Indexing report, last 16 months) and Google Analytics (every URL with at least one session in the last two years). Add anything from Google Search Console performance reports with non-zero impressions. The combined list is your starting universe.

For most port authorities this lands somewhere between 800 and 3,000 URLs. If your dev team has been told there are “around 200 pages”, they’re missing 80% of the indexed footprint.

Categorise every URL

Each URL needs a decision:

Keep. Same content, same intent, lives on the new site. Most likely a 1:1 redirect.
Consolidate. Multiple old pages on the same topic merge into one new page. Each old URL redirects to the consolidated target.
Migrate to new structure. Content stays but URL changes (e.g. port circulars moving from /news/circulars/2018/ to /operations/circulars/). Each old URL redirects to the new equivalent.
Sunset. Genuinely outdated content (a 2014 consultation that has long since closed). Either redirect to the most relevant parent page or 410.

The categorisation is content work, not engineering. It needs someone who knows the port authority’s audiences (shipping agents, port users, regulators, investors, public) to make the right calls.

Build the redirect map

A spreadsheet of every old URL paired with its new destination. 301 (permanent), with no chains and no loops. Every redirect tested before launch. The redirect map should ship as part of the launch, in nginx, Apache or Cloudflare worker form, not as WordPress plugin redirects (which add latency and break under load).

Sample redirect rows look like this in plain terms:

/tariffs/2019-tariff.html to /services/tariffs/
/news/2017/circular-12-2017/ to /operations/circulars/circular-12-2017/
/contact-old.html to /contact/

Aim for direct mappings. A redirect chain (A redirects to B redirects to C) loses link equity and slows page load.

Preserve internal linking and metadata

Pages that survive should keep their meta titles and descriptions where they’re working. Don’t rewrite every title to fit a new editorial system. If /services/pilotage/ ranks for “pilotage Felixstowe” with a specific title, keep that title or improve on it deliberately. A wholesale rewrite of metadata is a category of self-inflicted damage.

Internal links from kept pages should point to new URLs, not redirect through the old ones. Audit and rewrite internal links during content migration.

Launch and monitor

Submit a new sitemap to Search Console immediately. Verify the new property if the domain is staying. If you’re moving domains, use Change of Address tool.

Watch the crawl. Search Console will show a wave of 404s as Google rediscovers old URLs. Most should resolve via your redirects within four weeks. Anything still 404’ing is a redirect map gap; fix it.

Track rankings on a 200-keyword sample. Pick the top 200 organic queries by clicks and check rank position weekly for the first 90 days. Some volatility is normal. A consistent drop on a cluster of related queries is a content problem on those pages.

Don’t rebuild internal linking too soon. Let the redirects settle and the new site stabilise before you start adding new pages or restructuring.

The honest truth

Replatforming a port authority site is unglamorous work. The interesting part (the new design, the new IA, the new CMS) is maybe 40% of the project effort if you’re doing the SEO migration properly. The redirect map, the content audit, the metadata preservation and the launch monitoring are the other 60%. They’re what saves you from a year of recovering traffic you should never have lost.

Get this right once and you don’t have to do it again for a decade. Get it wrong and the next port authority CEO will be asking why digital traffic is half what it was in 2023.