303 See Other Used as a Page Redirect

What’s actually happening

A page that moved returns 303 instead of 301. Browsers follow it fine, so it looks like it works. But crawlers treat 303 as a non-cacheable, see-this-other-thing response tied to a request you just made — not a permanent move — so the old URL doesn't consolidate into the new one and rankings don't transfer. You notice it as flat or dropping authority on a page you thought you'd cleanly redirected.

Common causes

• A framework's generic redirect() helper defaults to 303 (some HTTP/1.1 stacks do this for POST handling) and it got reused for a GET page move.
• A developer picked 303 thinking 'see other' means 'this content is over there,' confusing the Post/Redirect/Get pattern with a permanent move.
• An API or form handler's redirect logic leaked onto front-end page routes.
• A reverse proxy rewriting status codes downgraded a 301 to 303.

How to fix it

1. Confirm the statuscurl -sI https://example.com/old-page and check the status line. A page move showing 303 is the bug. Note the Location target so you can verify it lands on a 200.
2. Change moves to 301For a permanent page move, return 301. In Express, res.redirect(301, '/new'). In nginx, return 301 https://...; In Rails, redirect_to new_path, status: :moved_permanently. Don't leave it on the framework default if that default is 303.
3. Keep 303 only for Post/Redirect/Get303 is correct after a form POST when you want the browser to GET a result page (so refresh doesn't resubmit). Leave it there. Just don't use it to relocate a URL crawlers should follow for ranking.
4. Re-crawl and verify consolidationAfter switching to 301, fetch the old URL in Search Console URL Inspection and confirm Google sees the permanent redirect. Equity consolidation takes weeks — check that the old URL drops out and the new one holds its position.