Renaming a Wiki Page Without Losing Its Search Traffic

Every fan wiki reaches the point where a page name stops making sense. A character gets an official name after launch, a patch renames an item, a guide written for season two now covers season five. Someone renames the page, the old title vanishes, and a few weeks later the page that used to pull steady search visits is getting a trickle. Nobody connects the two events, because the rename felt like housekeeping.

I ran a clan site and a fan wiki for years, and I lost traffic exactly this way more than once before I understood what was happening. A rename is a change of address. Search engines, other sites and your own readers all have the old address saved, and unless something at that address tells them where the page went, they hit a dead end.

What actually breaks when you change a URL

A search engine ranks a specific address, not an idea of a page. When the address changes, the new one starts out as a stranger. The signals the old one earned, links from forums and Reddit threads and other wikis, still point at the old address. If that address now returns a "page not found" error, those signals lead nowhere, and the search engine eventually drops the old address from its index without handing anything to the new one.

A redirect is the note on the door. A permanent redirect, known by its status number 301, tells browsers and crawlers that the page has moved for good and where to find it. Search engines treat it as a strong hint to move the ranking signals across. Traffic usually wobbles for a while and then settles on the new address, though I would not promise every page recovers fully; pages that ranked on the old exact wording sometimes lose a little.

Your software may already be doing half the job

Before you add anything by hand, check what your platform does on its own, because doubling up causes its own mess.

MediaWiki and wiki farms

Moving a page in MediaWiki leaves a redirect page at the old title by default, unless whoever moves it unticks that box. These wiki redirects work differently from a server 301: the old address shows the new page's content with a small "redirected from" line, and the page tells search engines through its canonical tag which address is the real one. In practice this works well. The risk is human: an editor later deletes the "pointless" redirect page during cleanup, and the old address dies.

WordPress

When you change the slug of a published post, WordPress normally remembers the old slug and sends visitors on to the new one. That covers the simple case. It is less dependable for pages, custom post types made by plugins, category renames, and anything moved between sites. If you rely on it, test the old address in a private browser window after the change, and use a redirect plugin or a server rule for anything it misses.

A rename, in the order that avoids damage

1. Write down the old URL exactly, including any trailing slash, before you touch anything.
2. Check search tools or your analytics for how much traffic the old page gets, so you can tell later whether the move hurt.
3. Rename the page and confirm a redirect exists from the old address, either created by the software or added by you.
4. Open the old address in a private window and confirm it lands on the new page in one hop.
5. Update the internal links on your own site to point straight at the new address.
6. Update the page title and description if the rename changes what the page is about.
7. Leave the redirect in place. Do not schedule it for removal.

Step five is the one wikis skip. A redirect catches outside visitors, but internal links that still point at the old name send every reader and crawler through an extra hop forever. On long-running wikis these pile up quietly, the same way described in how broken internal links pile up on fan wikis. Most wiki software has a "what links here" tool on the old title; work through that list.

Step six matters more than people expect. If a guide moves from "Season 2 Builds" to "Builds", the old description probably still talks about season two, and the snippet in search results will look stale. A rewrite along the lines of meta descriptions that earn clicks takes five minutes.

Redirect chains and the homepage dump

Two habits do more harm than a missing redirect.

The first is chains. A page renamed three times over the years can end up redirecting A to B, B to C, and C to D. Browsers cope, and Google has said it follows several hops, but each hop adds delay and a point of failure, and some crawlers give up early. When you rename a page that was itself the target of an earlier redirect, update the old redirects to point directly at the newest address.

The second is sending every removed or renamed page to the homepage because it seems tidy. Search engines tend to treat a redirect to an unrelated page as if the page were simply gone, a so-called soft 404, so you get the downside of a deletion without the honesty of one. Redirect to the closest matching page. If nothing on the site matches, a proper "not found" response is the better answer.

Redirect to the page a reader was actually looking for, or let the old address honestly say it is gone.

The advice to stop following

A common line in community admin circles is that redirects can be cleaned up after a few months, once the search engines have "picked up" the new address. Google's own guidance suggests keeping them for at least a year, and in my experience a fan wiki should keep them indefinitely. The reason is not search engines. It is the old forum post from 2019 that still sends a handful of readers every week, the Discord pin nobody updated, and the bookmark in a player's browser. Those links never get fixed, and a redirect costs nothing to keep.

The one place to be careful is hosting. If you ever move platforms, your redirects have to move with you, which is easy to forget during a migration. It is one of the things worth asking about when you go through picking a reliable host for a fan community.

Something to do this week

Pull up your wiki's move log or your site's list of recently changed slugs for the last six months. Take the ten oldest renames and open each old address in a private browser window. Note any that end in an error, a chain of more than one hop, or the homepage, and fix those ten before renaming anything new.