Setting up 301 redirects for a move from WordPress to an AI builder comes down to three steps done in the right order: crawl every old URL, map each to its new page, and apply the 301s at the new host before launch. The point of a 301 is that it passes the old page’s ranking signals to the new URL, so every old page that mattered needs one, or it 404s and forfeits its position. Get this right and the move is invisible to search engines; get it wrong and a good rebuild still loses traffic. WPBuildAI builds the complete redirect map and applies it as part of the move, so nothing 404s at launch.

Why 301 specifically

The type of redirect matters, because each says something different to search engines. Google’s redirects guidance is explicit that a 301, a permanent redirect, is what consolidates ranking signals on the new URL. A 302 (temporary) tells engines the move is not permanent, so they may keep the old URL indexed and hesitate to transfer authority. No redirect at all leaves a dead page that 404s and loses everything. For a platform change, where the old WordPress URLs are gone for good, 301 is the correct choice for every moved page, full stop. Using a 302 by accident, a common default in some tools, quietly undermines the whole point. The mechanism behind why the permanent redirect preserves rankings is covered in do 301 redirects preserve SEO.

The setup, step by step

  1. Crawl every old URL from internal links and the sitemap, then reconcile against analytics and Search Console so nothing ranking is missed.
  2. Map each to its new page in a URL mapping template, choosing the closest relevant destination.
  3. Apply the 301s at the new host or platform, since WordPress is gone, as single hops with no chains.
  4. Verify a sample after launch and watch Search Console for crawl errors.

Done in this order, you build a complete map first and apply it once, rather than discovering missing redirects after launch. Ahrefs found in its search traffic study that a small set of pages drives most organic traffic, so prioritise mapping and verifying those redirects, since an error there is where the real loss happens.

Where the redirects live now

Leaving WordPress means the redirects move too, and this trips people up because they look for the old WordPress redirect plugin that no longer exists. The redirects now live wherever the new site is hosted. Depending on your setup, that is a host configuration file, your platform’s built-in redirect feature, or edge rules at your CDN. The implementation differs by platform, but the rule is identical: every valuable old URL points to its new home with a 301. Because WordPress is no longer in the picture, there is no fallback there to catch a missed redirect; the new host is the only place the rules exist. So part of planning the move is deciding where the redirects will live and confirming that layer is in place before cutover, the full move covered in converting to an AI website.

A worked example: moving the redirects off WordPress

Picture a site that already had a WordPress redirect plugin handling a few hundred rules from past changes. In the move to an AI builder, those rules cannot come along, because the plugin and WordPress are being retired. So the redirect setup has two layers: the historical redirects the plugin used to serve, and the new redirects from the old WordPress URLs to the new pages. Both have to be recreated at the new host. The team exports the plugin’s existing rules, folds them into the new map so an old URL that previously redirected once still reaches its final destination in a single hop, and adds the WordPress-to-new-site redirects on top. At launch, the new host serves all of it. Forgetting the first layer would have re-broken URLs that were fixed years ago, which is why the crawl and the existing-rules export both feed the map.

Which pages need a redirect, which get a 404

Not every URL deserves a redirect, and deciding per URL keeps the map honest. Every URL that had value gets a 301: indexed pages, pages with backlinks, anything earning traffic or impressions. Pages you are genuinely retiring, with no relevant successor, should return a real 404 or 410 instead, which tells engines to drop them cleanly. The one thing to avoid is sending everything uncertain to the homepage, because Google treats an irrelevant blanket redirect to the homepage as a soft 404, so it preserves nothing. A full crawl reconciled with analytics tells you which URLs had value and which are truly dead, so you can map the first group to relevant destinations and give the second an honest not-found. That judgement, redirect what mattered, retire what did not, is part of building the map, not an afterthought.

Building single hops to avoid loops

Every redirect should take an old URL to its final destination in one hop, and on a platform move this matters doubly because you are layering new rules over any historical ones. A chain, old URL to an intermediate URL to the final page, slows every redirected visit and is the raw material for the too-many-redirects loop, where rules point back at each other until the browser gives up. When you fold old redirect rules into the new map, collapse them: if A used to redirect to B and B now lives at C, map A straight to C, not A to B to C. Normalise trailing slashes and https first so those conventions do not fight your path rules. Building the map as clean single hops from the start is how you avoid the too many redirects error rather than debugging it after launch.

Redirects keep the old external links and bookmarks working, but your own internal links should point at the new URLs directly, not rely on the redirects. Backlinko’s analysis of 11.8 million search results underlines how much internal linking and structure matter to ranking, so when you rebuild, link the new pages to each other using their new URLs, rather than carrying over links that now bounce through a redirect. A redirect is a safety net for inbound links you do not control; for your own navigation, menus, and in-content links, use the final URLs so visitors and crawlers reach pages in one step. Leaving internal links pointed at old URLs works, because the redirects catch them, but it adds a needless hop everywhere and wastes a little of the equity the redirects are meant to preserve.

Verifying after launch

A redirect map is only proven once it is live and tested. After cutover, test a sample of old URLs, weighted toward the high-traffic ones, and confirm each returns a single 301 to the correct final page, with no chain, loop, 404, or homepage catch-all. Then watch Search Console over the following weeks: the coverage report will surface old URLs slipping into not-found or soft-404 states, which flags rows the map missed or got wrong, and you fix those as they appear. Resubmit the sitemap so the new URLs are discovered. Verification turns “we set up redirects” into “every valuable old URL provably resolves to the right page,” which is the actual goal. Skipping it means a broken redirect on an important page can sit unnoticed until the ranking drop shows up in your traffic.

Common mistakes setting up redirects for a platform move

The recurring errors are predictable. Using 302s instead of 301s signals a temporary move and withholds the ranking transfer. Forgetting that the redirects must live at the new host, not in the retired WordPress, leaves old URLs with nothing serving them. Dropping the historical redirect rules re-breaks URLs that were fixed years ago. Building chains instead of single hops slows the site and risks loops. Blanket-redirecting unknown URLs to the homepage manufactures soft 404s. And skipping post-launch verification lets a broken redirect on a key page go unnoticed. Each is avoided by the same discipline: a complete crawl, a single-hop map to relevant destinations applied at the new host, historical rules folded in, and verification afterward, which is what makes the platform move invisible to search engines.

Key points to remember

Set up 301 redirects for a WordPress-to-AI-builder move by crawling every old URL, mapping each to its closest relevant new page, and applying single-hop 301s at the new host before launch, because a 301 is what carries ranking signals across and the redirects can no longer live in the retired WordPress. Redirect every URL that had value and give genuinely retired pages an honest 404 or 410 rather than a homepage catch-all. Fold any historical redirect rules into the map as collapsed single hops to avoid loops, point internal links at the new URLs, and verify the high-value redirects after launch while watching Search Console. WPBuildAI builds and applies the full redirect map as part of the move, so it keeps its rankings; send your site URL for a fixed quote.

Not affiliated with Google, WordPress, or Lovable.