How to migrate your content into a new website template
Migrate content with a full audit first, then map every old page to a new one, set up redirects for anything that moves or disappears, and rewrite only what genuinely needs it — reusing the rest as-is.
At some point, most sites outgrow their original template, or the business behind them changes enough that a straight redesign makes more sense than another patch job. The tricky part is rarely picking the new template — it's moving everything you already have into it without quietly losing content, breaking links, or tanking the search rankings you've already earned.
Content migration feels like it should be simple: copy the text, paste it into the new pages, done. Treated that way, it usually goes wrong. Here's a workflow that keeps it controlled.
Step 1: audit everything you currently have
Before touching the new template, get a complete list of every page on the current site, including ones you might have forgotten about — old landing pages, a blog you stopped updating, a resources page from a campaign two years ago. For each one, note its URL, its purpose, and roughly how much traffic or inbound links it gets if you have that data. This audit is tedious but it's the step that prevents the two most common migration mistakes: losing a page that was quietly still earning traffic, and carrying forward a page nobody needed anymore just because it existed.
Step 2: map every old page to a new one
With the audit done, decide what happens to each page in the new structure. Most pages map cleanly — your services page becomes the new services page. Some will merge (three thin blog posts on related topics might become one solid page). Some will genuinely no longer be needed. Write this mapping down explicitly, old URL to new URL, before you migrate a single word of content. This single document becomes your source of truth for the rest of the process, and it's also exactly what you'll need for the redirect step.
| Old URL | New URL | Decision |
|---|---|---|
| /services.html | /services | Direct carryover, minor rewrite |
| /blog/tip-1, /blog/tip-2, /blog/tip-3 | /guide | Merge into one comprehensive page |
| /2019-promo | — | Retire, redirect to homepage |
| /about-us.html | /about | Direct carryover, reuse as-is |
Step 3: set up redirects before you launch, not after
Any URL that changes or disappears needs a redirect pointing the old address to its new equivalent. Skip this and you lose whatever search ranking and inbound links pointed at the old URLs, and visitors who bookmarked or shared the old link land on a dead page. This is one of the most common and most avoidable migration mistakes — it happens because redirects feel like a launch-day afterthought instead of a core part of the migration plan. Build your redirect list directly from the page-mapping document in step 2.
Step 4: decide what to rewrite vs. reuse as-is
Not everything needs a rewrite just because it's moving to a new template. If a paragraph works, reuse it. Rewrite only where the new structure genuinely demands it: a page that's merging with others, content written for a section the new template doesn't have, or copy that's noticeably stale (an old promotion, outdated pricing, a team member who's left). Treating migration as an excuse to rewrite everything turns a moving job into a full content overhaul and multiplies the work for no real benefit.
- 1Audit the existing site completelyList every page, its URL, and its purpose — including easily forgotten ones.
- 2Map each old page to its new destinationDecide what carries over directly, what merges, and what gets retired.
- 3Build the redirect list from that mappingEvery moved or removed URL needs a destination before launch.
- 4Migrate content, rewriting only where neededReuse what already works; rewrite what's stale or restructured.
- 5Test every redirect and internal link after launchClick through the site as a visitor would before calling it done.
Step 5: test before and after launch, not just once
Once the new site is live, click through it the way a visitor would — follow navigation links, test old bookmarked URLs to confirm redirects fire correctly, and check that nothing from the mapping document got missed. It's worth doing this a second time about a week after launch, since it's easy to catch obvious breaks immediately but miss a redirect for a page that only gets occasional traffic from an old external link.
- ✓Audit every existing page before deciding anything about the new structure.
- ✓Map old URLs to new ones explicitly — this becomes your source of truth.
- ✓Set up redirects for every moved or removed page before launch, not after.
- ✓Reuse content that still works; rewrite only what's stale or restructured.
- ✓Test the live site as a visitor would, and check again about a week later.