A 301 redirect is the server response "301 Moved Permanently" plus a Location header pointing to the new URL. Browsers follow it automatically, and search engines treat it as a strong signal that the destination should replace the old URL in the index. It is the standard tool for changing URLs, merging pages, moving to HTTPS, or migrating a site to a new domain.
How a 301 works
When a client requests the old URL, the server answers with status 301 and a Location header. The client then requests the new URL. No page content is served from the old address. Defined in RFC 9110, the status means the resource has a new permanent URI and future references should use it.
Google has documented that permanent server-side redirects (301 and 308) are a strong signal that the target should become the canonical URL, and that redirecting does not cause a loss of PageRank in itself. Ranking signals consolidate onto the destination over time as Google recrawls.
GET /pricing-plans HTTP/1.1
Host: www.example.com
HTTP/1.1 301 Moved Permanently
Location: https://www.example.com/pricingWhen to use one
Use a 301 whenever the move is meant to last and you want search engines to forget the old URL.
- Renaming or restructuring URLs, for example /features/sso to /security/single-sign-on
- Merging two thin or overlapping pages into one stronger page
- Moving from HTTP to HTTPS, or from non-www to www
- Domain migrations and rebrands
- Moving a blog or docs from a subdomain into a subfolder, or the reverse
301 versus 308
A 308 Permanent Redirect means the same thing as a 301 but requires the client to repeat the same HTTP method and body. That matters for form posts and APIs, not for normal page loads. Google treats 301 and 308 the same way for indexing. Some frameworks default to 308: Next.js, for example, uses 308 for permanent redirects in its config. Either is fine for SEO.
Implementing redirects well
Redirect each old URL to its closest equivalent, one to one, rather than sending everything to the homepage. Google may treat mass redirects to an unrelated page as soft 404s. Keep redirects in place for a long time; Google's guidance for site moves is at least a year, and keeping them indefinitely is common and harmless.
After the redirects go live, update internal links, canonical tags and sitemaps to point straight at the new URLs so crawlers do not have to pass through the redirect at all.
Example
Consolidating feature pages
A billing SaaS, Quillbrook, has three pages that cover the same ground: /invoicing, /features/invoices and /invoice-software. They compete with each other and none ranks well. The team picks /invoicing as the keeper, merges the useful copy into it, and 301-redirects the other two there.
They then change the nav, footer and blog links to point at /invoicing directly and remove the old URLs from the sitemap. Over the following weeks, Search Console shows the old URLs dropping out and the kept page picking up their queries, though how much it gains depends on the content and competition.
Common mistakes
Redirecting everything to the homepage
Mass redirects to an unrelated page do not pass relevance and can be treated as soft 404s. Map each URL to its closest match, and let truly dead pages return 404 or 410.
Leaving internal links on the old URLs
Redirects work, but every internal link through one adds a request and a hop. Update links at the source.
Removing redirects too early
Backlinks, bookmarks and old emails keep hitting the old URLs for years. Pulling redirects after a few months throws that traffic and link value away.
Questions
Google has stated that 3xx redirects do not lose PageRank. The destination still has to earn its rankings on its own content, so a redirect to a weaker or less relevant page can still perform worse.
It depends on how often Google crawls the old URL. Frequently crawled pages can update within days; rarely crawled ones can take weeks or longer. There is no fixed timeline.
Google can follow both, and treats an instant meta refresh as permanent, but server-side redirects are more reliable and are read by every client, including crawlers that do not run JavaScript.
