---
title: "WordPress Redirect Plugin or Server Rule: Which to Use"
url: https://hostmy.blog/wordpress-redirect-plugin-or-server-rule/
date: 2026-10-20
modified: 2026-10-20
lang: en
author: "Aditya Sharma"
description: "A redirect can live in a plugin, in the web server or in code. Here is how to pick the right status code, the right place, and how to check it with curl."
categories:
  - "WordPress"
image: https://hostmy.blog/wp-content/uploads/2026/10/hmb-card-2562-1024x538.jpg
word_count: 1435
---

# WordPress Redirect Plugin or Server Rule: Which to Use

A redirect sends a visitor, and a search engine, from one URL to another. On WordPress there are three places to make one: a WordPress redirect plugin, a rule in the web server's configuration, or a few lines of code. They all work. They differ in how fast they answer, how easy they are to get wrong, and what happens when you change something else on the site.

This post helps you pick. It starts with the status code, because choosing the wrong one causes more damage than choosing the wrong tool. It then compares the places a redirect can live, and ends with how to check that yours works. If you are changing your permalink structure, [how to safely change WordPress permalinks](/change-wordpress-permalinks/) covers that specific case.

## Pick the status code first

Google's documentation on redirects splits them into permanent and temporary. A 301 or 308 says the move is for good, and Google treats the target as the canonical page. A 302, 303 or 307 says it is temporary, and Google follows the redirect but does not treat the target as canonical, so the old URL can stay in results. Google's advice is to use a permanent redirect only when you are sure it will not be reversed. It also says to prefer server-side redirects, which have the highest chance of being interpreted correctly. It sets this out in its [guide to redirects](https://developers.google.com/search/docs/crawling-indexing/301-redirects).

| Status | Meaning | Use it when |
| ------ | ------- | ----------- |
| 301 | Moved permanently | A post or page has a new address for good |
| 308 | Moved permanently, and the request method is preserved | You need a permanent redirect that keeps POST requests intact, which is rare on a blog |
| 302 | Found, treated as temporary | The old URL will come back, for example during a short test |
| 307 | Temporary, method preserved | Same as a 302 where the method matters |
| 410 | Gone on purpose, not a redirect | The content is removed and there is nothing to send people to |

For most blog changes the answer is a 301. The common mistake is a 302 left in place by a plugin default or a rushed setting. It does not break anything visibly, but it tells Google the old URL is still the real one.

If nothing replaces the page, do not send everything to the homepage. Send readers to a page that answers the question they came with, or let the old URL return a 404 or 410. [Content pruning for AI](/content-pruning-for-ai/) walks through the delete, redirect or refresh decision.

## Where a redirect can live

| Where | Example | Strength | Weakness |
| ----- | ------- | -------- | -------- |
| A plugin | Your SEO plugin's redirect manager, or a dedicated redirect plugin | Anyone on the team can add one, and many keep a log of 404s | WordPress has to load before the redirect happens, and it stops working if the plugin is deactivated |
| The web server | A rule in .htaccess on Apache or LiteSpeed, or in the nginx configuration | Answers before WordPress loads, and handles whole patterns in one line | One typo can take the site down, and an editor cannot change it |
| Code in WordPress | A function in a small custom plugin | Can use logic, such as redirect by category | You now maintain code, and it is the least visible place to look when something breaks |

The code option is for a developer with a specific reason. For everyone else the choice is between the first two rows.

## When a plugin is the right choice

Use a plugin when the redirects are individual and the people who need to add them are not comfortable editing server files. A single post moved, a slug fixed after a typo, an old campaign URL pointed at a new page: these are one-off jobs, and a plugin makes them safe and visible. If your SEO plugin already includes a redirect manager, as SEOPress does on this site, using it avoids adding another plugin to the list, which matters because [every plugin has a cost](/wordpress-plugin-bloat/).

The trade-off is that the redirect lives inside the thing you might later remove. Deactivate the plugin during a clean-up and every redirect it held stops working, with no error. Old URLs simply start returning 404. Export the list before you remove anything.

## When a server rule is the right choice

Use a server rule when the change is a pattern, not a single URL, or when speed and permanence matter. Moving a whole folder, forcing https or a single hostname, dropping a trailing slash, or retiring an entire section: each is one rule at the server and hundreds of entries in a plugin. A server rule also answers before WordPress loads, so it costs less per request, and it keeps working whatever you do to the plugins.

The risk is the file itself. On Apache and LiteSpeed the rules go in .htaccess, above the WordPress block, and on nginx in the site configuration, followed by a reload. A syntax error can return a server error for the whole site, so take a copy first and test straight after. Some managed hosts do not let you edit these files at all, in which case a plugin is the only option.

`# .htaccess, above the line that says # BEGIN WordPress
# One page
Redirect 301 /old-page/ https://example.com/new-page/

# A whole folder, keeping the rest of the path
RewriteEngine On
RewriteRule ^old-folder/(.*)$ /new-folder/$1 [R=301,L]`

The nginx version of the first rule is shorter.

`# nginx, inside the server block, then reload nginx
location = /old-page/ { return 301 /new-page/; }`

## A rule of thumb

| Your situation | Use |
| -------------- | --- |
| A handful of individual URLs, edited by non-technical people | A plugin |
| A pattern, a folder or the whole site | A server rule |
| Hundreds of old URLs after a migration | A server rule for the pattern, a plugin for the exceptions |
| You are not sure how your host reads redirects | A plugin, and check the result with curl |

## Check the result with curl

A redirect that looks right in a browser can still be wrong, because browsers cache them. Test from the command line instead. This shows each hop and the status code it returned.

`curl -sIL https://yourdomain.com/old-page/ | grep -iE '^(HTTP|location)'`

You want to see one 301, a Location line pointing to the new URL, and a final 200. Two redirects in a row is a chain, and a repeated URL is a loop. Chains slow the page down and loops break it, so fix both. The method is the same one used in [our five curl commands](/ai-crawler-test/), only pointed at an old URL.

## Mistakes that cost the most

The usual ones are redirecting every dead URL to the homepage and leaving a 302 where a 301 was meant. Another is forgetting to update your own internal links, so they keep pointing at the old address and take a hop every time. A fourth is deleting redirects too early. Google's page gives no recommended lifetime, so keep a redirect for as long as the old URL still has links pointing at it or visitors arriving through it. A broader move between hosts or domains has its own checklist, in [the WordPress migration checklist](/how-to-migrate-wordpress-site/).

## A worked example: changing one slug

Say you shorten a post's address from /best-coffee-grinders-2025/ to /best-coffee-grinders/. Four jobs follow, and the order matters.

`1. Change the slug in the editor, then add a 301 from the old address to the new one.
2. Update internal links, menu entries and the sitemap so they point at the new address directly.
3. Run the curl check above and confirm one 301 and a final 200.
4. Inspect the new URL in Search Console, and request indexing if it has not been picked up.`

Step 2 is the one most people skip. A redirect is a safety net and not a replacement for correct links, and every internal link that still points at the old address costs a hop. WordPress core can redirect an old post slug to the new one in simple cases. Do not rely on that for a moved folder, a changed domain or a page that is not a post. Confirm it with curl instead of assuming.

The same four jobs apply at any scale. A hundred changed URLs after a migration is the same job with a server rule in step one and a spreadsheet in step two.

## Where Host My Blog fits

Everything above is free to do yourself. Reviewing 404s and redirects is one of the checks in a normal maintenance month on the blogs we look after. It takes about twelve minutes, as set out in[what a WordPress maintenance month actually contains](/wordpress-maintenance-service/). It catches the quiet failures, such as a slug changed without a redirect. If you would rather someone else read that log, [our care for bloggers](/for-bloggers/) includes it.

How many redirects does your site hold right now, and do you know where each one lives?