How to Switch Recruitment Website Platform

Agencies change website platform for good reasons. The old site is slow, the job board plugin breaks every other WordPress update, or the agency that built it has stopped answering emails. The new site is usually better. The move is where the damage happens.

Search engines rank URLs. When a URL that ranked on Monday returns a 404 on Tuesday, Google keeps the ranking for a short while, re-crawls, gets the 404 again and drops it. Every link another site pointed at that URL stops counting at the same moment. On a recruitment site the pages that carry that history are usually the sector pages, the salary guides and a handful of old blog posts that still pull traffic years after they were written.

The three failure points

Old URLs with no destination: the new platform uses a different URL pattern, nobody mapped old to new, and every indexed page on the old site becomes a 404 on cutover day.

Jobs that vanish: the job board on the old site was fed by a plugin or a feed from the CRM. The new site's feed is connected late, or connected but still importing, and the jobs page sits empty for the first few days. For a recruitment site that is the page candidates came for. In Redsun's 2026 audit, 66% of the 367 agency sites that responded had a live vacancies page (see /research/state-of-recruitment-marketing-2026). Those are the agencies with the most to lose here.

Search Console left on the old setup: the property was verified with an HTML tag or file on the old site, the old site is switched off, verification lapses, and the person who would have spotted the 404s in the Pages report can no longer get in.

All three are avoidable, and none of them needs a developer. They need a spreadsheet, the right order of work and two or three weeks of checking afterwards. The rest of this guide goes through each one, and says plainly what Redsun's tooling does for you and what it leaves to you.

You cannot redirect a URL you do not know exists. The first job is a complete list of the old site's URLs, and no single source gives you that.

The old sitemap: fetch /sitemap.xml on the current site and save every URL in it. This is the list the old platform wanted indexed. It often misses pages added by hand and always misses pages that were deleted but are still linked from elsewhere.

Search Console: export the Pages report (indexed and not indexed) and the Performance report's pages tab for the last twelve months. Anything with impressions is a URL Google knows about and will come back to check.

Analytics: export landing pages from GA4 for the last twelve months. This catches the URLs real visitors arrive on, including campaign landing pages that were never in a sitemap.

Backlinks: if you have access to a backlink tool, export the list of your pages other sites link to. These are the URLs whose redirects matter most, because a dead one throws away a link you cannot easily replace.

Sort the list into three piles

Put every URL in a spreadsheet with a column for where it should go. Then sort it into three groups.

Pages with a clear equivalent: the IT sector page, the about page, the contact page, the salary guide. Each one gets a row pointing at its new address.

Groups that share a pattern: every blog post under /news/, every old job URL under /vacancies/. These get one prefix rule each, covered in the next chapter.

Pages with no honest equivalent: a 2019 office party post, a page for a service you stopped offering. Leave these to 404. Pointing them all at the homepage looks tidy and helps nobody: Google treats a mass redirect to the homepage as a soft 404 anyway, and a visitor who clicked a link about a specific thing lands somewhere that has nothing to do with it.

Keep job URLs in their own tab. They behave differently from every other page on the site, and chapter 4 deals with them separately.

A redirect map is a two-column list: the old path and the new path. Every row becomes a permanent (301) redirect, which tells search engines the page has moved and passes most of its ranking signal to the new address.

Rules worth following

Map like for like: the old Accountancy sector page goes to the new Accountancy sector page, and the old blog post goes to the same post on the new site. The closer the match, the more of the ranking carries over.

One hop: if A redirects to B and B later redirects to C, point A straight at C. Chains slow the crawl, and every extra hop is another place for the map to break.

Never redirect into a 404: check every destination exists on the new site before cutover. A redirect into a missing page is worse than the 404 it replaced, because Search Console then reports the destination and the original fault gets harder to find.

Use prefix rules for whole sections: if the old blog lived at /news/ and the new one lives somewhere else, one rule for /news/* covers every post you did not map individually.

What Redsun does with the map

Redsun keeps your redirect map in its own table, tenant_legacy_redirects, separate from the site document. That matters more than it sounds. The site builder saves the whole document every time you edit, so a map stored inside it could be wiped by a stale browser tab. Kept apart, the map survives every edit you make afterwards.

The map is read only when a request arrives for a path your new site does not serve. A page that exists always wins, so a rule can never hide a live page. When a rule matches, the visitor gets a 301 to the new address.

Matching is forgiving about the things old platforms are inconsistent about. Paths are compared in lower case, with trailing slashes, query strings and anchors ignored, so /About-Us/ and /about-us?ref=footer both match a rule for /about-us. An exact rule beats a prefix rule, and among prefix rules the longest one wins, so a rule for one specific old post can sit underneath a /blog/* catch-all without being shadowed by it, whatever order they were written in.

Redsun also refuses the rules that would do harm. A rule whose destination is not a page the new site serves is ignored and the 404 stands. A rule that points at the path being requested is ignored. Destinations must be paths on your own site, so a map built from a scrape of the old site can never send your visitors to another domain.

There is no screen in the admin for typing redirect rules in. Send the spreadsheet and the map is loaded for you as part of the move. After launch, Redsun writes its own rules whenever a URL changes: rename or delete a sector or service page and a 301 from the old address goes into the same table, pointed at the new page, with any older rule that pointed at the retired address repointed so you never build a chain.

Moving the content as well as the URLs

Old blog posts and sector pages have to exist on the new site before anything can redirect to them. Redsun can stage the articles and sectors from your old site as an SEO Transfer Bundle. It appears on your Home hub as a card, and nothing reaches your site until you press Save it, which applies the bundle as your own edit. Articles you have already rewritten on the new site are kept as you wrote them, and only articles the new site lacks are added.

Changing domain at the same time

The redirect map works on paths within one domain. If you are also moving from, say, an old .co.uk to a new .com, the old domain has to keep answering. Redsun can take the old domain on as well and answer every request on it with a 301 to the same path on the new domain. It is set up for you as part of the move. Keep the old domain's hosting running until it is, or every old URL fails before a redirect can run.

Every other page on a recruitment site is written once and edited occasionally. Job pages are created every week and retired every week. That changes what a good migration looks like for them.

Live roles get new addresses from the CRM

On a Redsun site a role lives at /jobs/ followed by its ID, and that ID is assigned when the role first syncs from your CRM. You do not migrate job pages by hand. Connect the CRM, let it sync, and every advertised role appears on the new board at its new address.

Each job page is server-rendered with JobPosting structured data, built from the live job record, so Google for Jobs can read it without running any JavaScript. A closing date is included only when the role has a real one that has not passed. Active roles go into your sitemap automatically, and a closed role cannot reach the sitemap at all.

What happens to the old job URLs

Look at the job tab of your inventory and check which prefix the old site used.

The old site used something other than /jobs/ or /job/: /vacancies/, /job-search/, /current-roles/ and so on. Add one prefix rule sending the whole section to /jobs, the new board. A candidate following an old link lands on the list of roles that are open today, which is the most useful answer for a role that has probably closed.

The old site used /jobs/ or /job/: Redsun treats every path under those prefixes as a job address. An old job URL that does not match a live role answers with a 404 and a noindex header, and the redirect map is not consulted for those paths. For a vacancy that has closed, that is the answer Google asks for: it tells Google for Jobs the posting has gone, and it stops Google filing the page as a soft 404.

Either way, do not try to redirect each old job to a similar new one. The old role is filled or withdrawn, and a redirect to a different job is a page about something else.

Closed roles leave the board

The usual way an agency site embarrasses itself after a move is a board full of roles that closed in the CRM weeks ago. Redsun reads your full list of jobs from the CRM once a day and closes any open role that list no longer returns, so a role closed upstream comes off the site even if the CRM never sent an update about it. On JobAdder, only roles with a live advert on your job board are shown on the site, described by the advert.

Order matters here more than anywhere else. If you point the domain at the new site and then connect the CRM, the jobs page is empty for as long as the first import takes. Connect the CRM first.

The order of work

1. Connect the CRM: in Redsun, connect your CRM from the Connections screen. Redsun connects natively to Atlas, Crelate, Ezekia, Firefish, Invenias, itris, JobAdder, JobDiva, Loxo, Manatal, Recruit CRM, Recruiterflow, SourceWhale, Spott and Top Echelon.

2. Let the first import finish: a large CRM does not come over in one run. The import carries on in the background, run after run, and the Connections screen shows what has come in, what is still to come and a rough time left. Wait for it to finish before you go live.

3. Count the roles: compare the number of roles on the new board with the number you advertise in the CRM. If they differ, find out why before cutover.

4. Check applications land: submit a test application on the new site and confirm it arrives in the CRM against the right role. Applications, registrations and enquiries are written into your CRM the moment someone submits them, so you should see it straight away.

5. Switch the domain: only now.

Turn the old feed off afterwards

Leave the old site's job feed running until the domain has switched, then turn it off. If job aggregators or multiposting tools were reading roles from the old site, give them the new jobs page address. Your new board publishes the same roles your CRM holds, so there is nothing to rekey.

Search Console is where a migration problem shows up first. It is also the tool most often lost in a platform move, because it was set up years ago by someone who has since left.

Before cutover

Keep the existing property: do not delete it and do not start a new one. The property holds your history, and you want to see the before and after in one place. A Domain property covers www and the bare domain together, which makes it the easiest kind to keep across a move.

Check how it is verified: if the property was verified with an HTML file or a meta tag on the old site, that verification disappears when the old site does. Add DNS verification (a TXT record) before you switch, and keep that record in place when you change DNS for the new site.

Get access for whoever will watch it: make sure at least two people at the agency are owners.

On cutover day

Connect Search Console inside Redsun, from Growth, then Organic, then Found on Google. When you pick your property, Redsun submits your new sitemap to Google for you. From then on that screen shows when Google last fetched the sitemap and whether it reported errors, and it can inspect your pages one by one and tell you which are in Google's index.

Your new site serves its own sitemap.xml, robots.txt and llms.txt on your domain. Open all three in a browser once the domain is live.

If you changed domain, use Search Console's Change of Address tool on the old property as well. It applies only to domain moves; a platform move on the same domain does not need it.

The first four weeks

Test your top URLs by hand: take the twenty old URLs with the most traffic or the most links and open each one. Each should land on its new page in one hop.

Read the Pages report weekly: new 404s on old URLs are the ones your map missed. Add a rule for each one that has a real destination and send it over.

Watch impressions as well as clicks: a short dip while Google re-crawls is normal. A drop that keeps going after three or four weeks means something is still wrong, usually a section of old URLs that was never mapped.

If you ever leave

A platform move is easier when the next one is possible too. From Settings, then Account, you can download your whole Redsun site as a zip: every page as static HTML with its words as Markdown, your site document, and your leads and applications as CSV files. If you leave, you take the site with you and start the next migration with a full inventory.