What Does a 301 Actually Tell a Search Engine?

What does a 301 actually tell a search engine?

That a page has permanently moved, and that the destination should probably be the canonical one. The word probably is doing real work there. Google's documentation describes a permanent redirect as a signal that the redirect target should be canonical, not as an instruction that it will be.

Almost everything people get wrong about redirects follows from missing that distinction. A redirect is evidence you are offering, weighed against other evidence. It is not a command, and treating it as one leads to a specific set of expensive mistakes.

So let me go through what each redirect type actually communicates, in Google's own terms, and what that means when you are moving pages around on a real site.

Why is a redirect a signal rather than an instruction?

Because canonicalisation is a conclusion the search engine reaches, using several inputs, and your redirect is one of them. Google's documentation says the indexing pipeline uses a permanent redirect as a signal that the redirect target should be canonical, which is precise language and worth taking literally.

The practical consequence appears on the temporary side, where Google is even more explicit. It says that with a temporary redirect, Googlebot follows the redirect but the indexing pipeline does not use it as a canonical signal, and then adds that the target page might still be indexed if other canonicalisation signals are present.

Read that twice. A temporary redirect does not guarantee that the destination stays out of the index. It only removes one reason for it to be there. If your internal links, your sitemap, and your canonical tags all point at the destination, you have supplied the other signals yourself.

This is why redirects fail in ways that feel mysterious. People set the redirect correctly, leave every other signal pointing the other way, and conclude that redirects do not work. The redirect worked. It was outvoted.

What is the real difference between permanent and temporary?

Which URL appears in search results. Google states it in one line: permanent redirects show the new redirect target in search results, and temporary redirects show the source page in search results.

That framing is more useful than thinking about the numbers, because it turns the decision into a question you can actually answer. Which address do you want people to find in six months. If the answer is the new one, that is a permanent redirect. If you want the original address to keep its place while you send traffic elsewhere for a while, that is a temporary one.

Google attaches a condition to the permanent choice that is worth respecting. It says to use permanent redirects when you are sure the redirect will not be reverted. That is the whole risk. A permanent redirect you undo later is a second move, and you will spend longer recovering the original URL than you spent moving away from it.

My rule is uncomfortable and it has saved me repeatedly: if you cannot commit to the new address for a year, do not use a permanent redirect. Temporary is not a weaker version of permanent. It is a different statement, and choosing it deliberately is not indecision.

Does it matter which method you use?

Yes, and Google ranks the methods for you. Its documentation presents the redirect types ordered by how likely Google is able to interpret them correctly, and says explicitly that a server-side redirect has the highest chance of being interpreted correctly.

The recommendation that follows is unambiguous. Google says that if you need to change the URL of a page as it is shown in search results, it recommends a permanent server-side redirect whenever possible, describing it as the best way to ensure that both Search and people are directed to the correct page.

The other methods are listed as fallbacks with warnings attached. On JavaScript redirects, Google says to use them only if you cannot do server-side or meta refresh redirects. On crypto redirects, it says not to rely on them for telling search engines that content has moved unless you have no other choice. Those are not neutral descriptions, they are a preference order.

There is a detail in the method list that catches people out. Google groups meta refresh and HTTP refresh redirects by their delay: zero seconds counts as permanent, more than zero seconds counts as temporary. So the same mechanism means two different things depending on a number you might have set without thinking about it.

When should you deliberately choose a temporary redirect?

When the original URL is the one you want to keep. Google gives a clean example: if a service your site offers is temporarily unavailable, you can use a temporary redirect to send users to a page explaining what is happening, without compromising the original URL in search results.

That pattern generalises further than people use it. A seasonal page that is out of season, a product that is out of stock, a landing page paused between campaigns, a section under maintenance. In all of those, the address should survive the interruption, and a permanent redirect would throw it away to solve a temporary problem.

The other good use is testing. If you are trying a new page and you might revert, temporary is the honest description of what you are doing. Declaring a move permanent because it feels more decisive is how sites end up with redirects nobody can explain two years later.

What I would not do is use a temporary redirect as a hedge on a move you have already made. If the new address is the real one, say so. Hedging leaves the old URL in search results, which means your users keep landing on a redirect instead of the page, and every measurement you take is about the wrong address.

What about 308, 303, and 307?

They exist, Google handles them, and most sites will never need to choose them deliberately. Google's documentation lists 301 and 308 together as permanent, saying both status codes mean a page has permanently moved to a new location. On the temporary side it lists 302, 303, and 307.

For content pages, 301 and 302 remain the two you will actually use, and the reason is compatibility rather than correctness. Every server, proxy, CDN, and tool in the chain understands them, and the newer codes exist mainly to fix ambiguity in how request methods are handled rather than to change the search meaning.

The practical advice is to use whatever your platform emits by default, then verify what it actually emitted. A great many redirect problems I have diagnosed were not a wrong choice of code. They were somebody assuming a code and never checking it.

If you are redirecting something that is not a page, such as an API endpoint or a form handler, the distinction between these codes starts to matter for reasons that have nothing to do with search. That is a different conversation and it is worth having with whoever maintains the endpoint.

What goes wrong on a hosted platform?

You often cannot write server configuration directly, which means you are using the platform's redirect feature and inheriting its behaviour. That is usually fine, and it means your job shifts from implementing redirects to verifying them.

There is one access detail worth knowing on Webflow if you plan to manage redirects programmatically rather than by hand. The tooling that creates, lists, updates, and deletes 301 redirects through the API is documented as requiring an Enterprise workspace plan or higher, returning an error otherwise. That is a statement about the API surface specifically, so check what your own plan gives you in the interface before you design a workflow around automation.

The more common hosted-platform problem is scale. A redirect list maintained by hand grows until nobody knows which entries are still needed, and chains form when a page moves twice and the first redirect is never updated to point at the final address. Chains are slow for users and they add interpretation steps you did not need.

The fix is boring and it works. When a page moves a second time, update the original redirect to point at the final destination rather than adding another hop. That keeps every old address one step from the truth, and it is far easier than untangling a chain later. If you are planning a larger move, build a redirect map before the migration rather than after.

How do you check a redirect is doing what you think?

Request the old URL and read the response status and the location header, without following the redirect automatically. That is the only check that tells you what actually happened rather than where you ended up.

Most tools follow redirects silently by default, which is exactly what hides the problem. A browser will show you the destination whether you sent a permanent or a temporary code, and whether you went through one hop or four. The destination looking right is not evidence that the signal was right.

The three things worth reading are the status code, the destination, and the number of hops. If the code is not what you intended, fix the rule. If the destination is a URL that itself redirects, collapse the chain. If the code is right and the destination is right, you are done, and you should record that you checked.

Then check the other signals, because as Google's documentation makes clear, the redirect is one input among several. Make sure your canonical tags, your internal links, and your sitemap all agree with the redirect, which is the same discipline I describe in using canonical tags properly. A redirect arguing against your own sitemap is a fight you picked with yourself.

What should you do next?

Pick the three most important URLs you have ever moved and check them properly. Request each old address, read the status code and destination without following, and confirm the code matches what you intended and the destination is final rather than another redirect.

Then look at your redirect list as a whole and ask one question per entry: is this permanent because the move is permanent, or because permanent sounded stronger. Any entry where the honest answer is the second one is worth revisiting, and doing it now is much cheaper than after the address has settled. If you need the mechanics on Webflow specifically, I have covered setting up 301 redirects in Webflow separately.

If you are about to move a site and you want someone to check the map before you pull the trigger, reach out. Redirects are one of the few things where an hour of review beforehand genuinely prevents months of cleanup afterwards.