Map first, then redirect
Google's guidance for moving a site with changed addresses begins with a map: every old address paired with its closest new equivalent, starting from the addresses that matter most and drawn from your sitemaps, server logs, analytics and any links report. It adds that images, scripts and stylesheets move like any other content. It also warns against sending many old addresses to one unrelated page, such as the home page, because that may be treated as a soft 404; sending several pages to one page is fine only when their content was actually merged there. A row with no sensible destination is better left as a not-found page than redirected to a page that does not answer the visitor's question.
- Write the reason for each row, so a reviewer can disagree with it.
- Mark rows with no equivalent for a human decision.
- Include old image and download addresses if other sites link to them.
One permanent redirect, straight to the end
Google distinguishes permanent redirects (301 and 308), which signal that the destination should become the canonical address, from temporary ones (302, 303 and 307), which do not. Server-side redirects are the ones it interprets most reliably; JavaScript redirects are a last resort because rendering can fail. Redirects should point directly to the final address. Googlebot can follow up to ten hops, but chains add delay and some clients handle long ones badly; the guidance suggests keeping a chain to no more than three hops and fewer than five if one cannot be avoided. Google says to keep redirects generally for at least a year so that signals, including links from other sites, can transfer.
- Test every row for status code, number of hops and the status of the destination.
- A rule that points to an address that itself redirects is a chain; rewrite it.
Canonical signals add up, and they can conflict
A canonical address is the one a page names as its preferred version. Google lists redirects and the rel="canonical" annotation as strong signals and inclusion in a sitemap as a weak one, and says the methods can stack. It advises a self-referencing canonical on the canonical page, absolute rather than relative addresses, and internal links that point to the canonical version. It warns against conflicting signals, such as a sitemap address that differs from the page's canonical, and against using robots.txt or noindex to choose a canonical. After a restructure the most common conflict is a sitemap still listing old addresses, or a canonical tag still pointing to a staging site.
- View the source of five destination pages and read the canonical tag.
- Check that the sitemap lists only addresses that return 200 and name themselves.
What WordPress already redirects, and what it does not
WordPress's redirect_canonical function sends a 301 between the www and non-www form of the host, normalises trailing slashes and turns parameter addresses such as ?p=123 into pretty permalinks; a filter of the same name can cancel it. The wp_old_slug_redirect function helps only in a narrow case: it acts on a 404 with a name query variable and sends a 301 to the post's current address, but its reference page says it does nothing if the post type is hierarchical, which includes pages. Renaming or re-parenting pages, changing the permalink structure or merging content is therefore not covered by either, and needs a map.
- Do not assume that WordPress remembers an old address for a page.
- Test an old page address after a rename; do not infer the result.
Staging settings that leak into the live site
A site kept hidden from search engines while it is rebuilt often uses the setting that discourages indexing. WordPress documents that since version 5.3 it adds a robots noindex,nofollow meta tag, that it does not block access, and that honouring it is up to search engines. Google's site-move guidance tells you to remove migration-only noindex rules and robots.txt blocks at go-live. Include that in the launch checklist. The paid redirect job has a published test price of GBP 450 for up to 300 old addresses; it is accepted when every row reaches its destination in one step and every destination names itself, and it does not cover a domain change, content rewriting or any ranking promise.
- Check the Reading setting and the robots.txt file on the day the structure goes live.
- Prices are untested proposals and payment follows the agreed checks.
Sources and limits
- Google Search Central: site move with URL changes Checked 2026-10-11.
- Build a mapping from each old URL to its new equivalent; do not send many old URLs to one unrelated page such as the home page, which may be treated as a soft 404; use permanent server-side redirects such as 301 and 308.
- Keep redirects generally at least one year; redirect straight to the final destination; Googlebot can follow up to 10 hops, but chains should ideally be no more than 3 and fewer than 5.
- Google Search Central: redirects and Google Search Checked 2026-10-11.
- Permanent redirects (301, 308) are a canonicalization signal that the destination should be canonical; temporary ones (302, 303, 307) are not; server-side redirects are the most reliably interpreted and JavaScript redirects a last resort.
- Google Search Central: consolidate duplicate URLs Checked 2026-10-11.
- Redirects and rel="canonical" are strong signals and sitemap inclusion a weak one; use absolute paths and a self-referencing canonical; avoid conflicting signals, robots.txt or noindex for canonicalization, and internal links to duplicate URLs.
- WordPress developer reference: redirect_canonical() Checked 2026-10-11.
- It redirects between www and non-www hosts, adds or removes trailing slashes, and redirects ?p=, ?page_id= and similar parameters to pretty permalinks, issuing a 301; returning false from the redirect_canonical filter cancels the redirect.
- WordPress developer reference: wp_old_slug_redirect() Checked 2026-10-11.
- It acts only on a 404 request with a non-empty name query variable, does nothing if the post type is hierarchical, and sends a 301 to the post's current permalink.
- WordPress documentation: Reading settings screen Checked 2026-10-11.
- Since WordPress 5.3 the Discourage search engines setting adds a robots noindex,nofollow meta tag; it does not block access and it is up to search engines to honour it.