Broken links and redirects: 301 vs 302 vs 308, chains, 404 or 410

Any site older than a year has broken links and redirects. Pages get deleted, sections get renamed, the catalogue moves to a new URL structure, and links to the old addresses stay behind in menus, in articles, on other people's sites and in bookmarks. A 404 or a 301 is not a problem in itself. The trouble starts when the site links to its own missing pages, when a redirect passes through three intermediate URLs, or when a deleted section is redirected wholesale to the home page. This article covers how 301, 302 and 308 differ, when to return 404 and when 410, how to find broken links with a crawler, in Yandex Webmaster and in Search Console, and in what order to fix them so you keep the links and traffic the old URLs earned.

What counts as a broken link

Yandex's Webmaster help defines a broken link as one that does not lead to the intended page or resource, or leads to an error (checked 15 October 2026). In practice it helps to split them into three kinds, because each is fixed differently.

• Internal: a link from one of your pages to a missing page on your own site. You control these completely, and they are the first thing to fix.
• Inbound external: a link from another site to a URL on yours that no longer exists. You cannot change the link, but you decide what that URL returns.
• Outbound: a link from your page to a missing page on someone else's site. These barely affect how your site is indexed, but they spoil the article for the reader.

An internal link to a redirecting URL sits in between. Technically it works, since the visitor ends up in the right place. But every such link costs the robot an extra request, and at the next migration it easily becomes a chain.

Broken internal links are expensive for two reasons. The robot spends crawl effort on URLs that lead nowhere, and the pages those links used to point at lose internal signals. A visitor who hits a 404 from the main menu usually leaves.

Permanent and temporary redirects: 301, 308, 302, 303, 307

A redirect tells the browser and the robot that the content lives at another address. The main difference between the codes is whether the move is permanent or temporary, and Yandex and Google group them the same way:

Google's documentation on redirects (developers.google.com, last updated 14 April 2026, checked 15 October 2026) classes 301 and 308 as permanent and 302, 303 and 307 as temporary. Yandex's help page on processing redirects lists the same groups. Both engines also treat a meta refresh as a redirect. Google counts an instant refresh as permanent and a delayed one as temporary; Yandex counts a refresh with a short delay as temporary. Google recommends JavaScript redirects only when neither a server-side redirect nor a meta refresh is possible, because rendering can fail and the robot may never see the redirect.

Yandex's HTTP status code reference adds two practical rules. Use 302 only for temporary situations such as maintenance or a comparison test; if the redirect is meant to be permanent, use 301. And keep a permanent redirect in place for at least six months.

What happens to the old URL in search results

The difference between a permanent and a temporary redirect shows up in which URL the search engine displays.

Google states the rule plainly: with a permanent redirect the results show the new URL, with a temporary one they show the source. A permanent redirect is a strong signal that the target should be treated as canonical. Google keeps the old URL as an alternate name for the page and may show it for a while, especially after a domain move; the documentation says these alternate names fade away on their own.

Yandex words it differently. Its status code reference uses the same sentence for 301, 302 and 308: the robot does not index the redirecting page, but it will index the target if the target is available. For redirects within one host, the help adds that search results will link to the target. Yandex's site migration guide also says that redirecting the old site's inner pages to the matching pages on the new site passes the old pages' metrics to the new ones. So for a permanent move, use 301 or 308 regardless of how a given engine treats temporary redirects; that way both receive the same signal.

A common mistake is a 302 left behind by a CMS or plugin default. The page moved for good, and the server has been saying "moved temporarily" for two years. Google may keep the old URL in its results in that case. The check is quick: curl -sI https://example.com/old-page/ prints the status line and the Location header.

Redirect chains and loops

A chain forms when URL A redirects to B and B redirects to C. It is usually the residue of several migrations: first the site moved to HTTPS, then dropped www, then changed its URL structure, and each rule was added on top of the last.

Google's documentation on HTTP status codes (checked 15 October 2026) says its crawlers follow up to 10 redirect hops. Its site-move guide recommends redirecting straight to the final destination, and if that is not possible, keeping chains short: ideally no more than 3 hops and fewer than 5. A chain that is too long, a loop, a URL that grows past the maximum length, and a bad or empty URL in the chain all land in a single Search Console status, "Redirect error".

Tidy sites have short chains too. On 15 October 2026, http://www.gbseo.ru/blog/site-indexing-check took two hops on our own site: first to HTTPS without www, then to the version with a trailing slash. That is acceptable because nothing links to that URL; every internal link and the sitemap point to the final address. The chains that matter are the ones real links lead into, and sites that have migrated twice tend to have more of them.

The fix is always the same: every rule should point straight at the final URL. If you keep a mapping table of old and new URLs, then at each migration update the destination column for every old row instead of adding a new rule on top. A loop (A → B → A) usually comes from two conflicting rules, for example a forced trailing slash in the server config and the opposite rule in the CMS, and the browser shows it straight away as a "too many redirects" error.

404 or 410 for a deleted page

A 404 means the page was not found. A 410 means it was removed permanently. The difference matters less than many people think.

Google's documentation on status codes says all 4xx errors except 429 are treated the same: a previously indexed URL is removed from the index, and Google gradually crawls it less often (developers.google.com, checked 15 October 2026). For Google, then, 404 and 410 are equivalent. Yandex's status code reference recommends 410 for resources removed for good and a 301 for resources that moved. For removing a page from Yandex search, its help accepts 404, 403 or 410.

The working rule: if a deleted page has a close replacement, 301 it there. If there is no replacement, return 404 or 410, whichever is easier to configure. Do not redirect deleted pages to the home page or to a general section. Google warns that redirecting many old URLs to one irrelevant destination, such as the home page, may be treated as a soft 404, an error disguised as a normal page.

A soft 404 is its own kind of breakage. The page says "nothing found" while the server returns 200, so to a search engine it is a real page, and such URLs pile up in the index. Yandex covers this with a diagnostics recommendation about incorrect handling of non-existent or deleted pages. Its help suggests requesting a URL made of random characters and checking the response code; if you cannot get the server to return 404, use any other 4xx except 429. Yandex advises against 429 and 5xx because they tell the robot the server is overloaded, which slows indexing.

Finding broken links with a crawler

A crawler walks the site the way a search robot does: it starts at the home page and follows links. Any of them will do, whether Screaming Frog SEO Spider, Netpeak Spider, or the site audit in Semrush or Ahrefs. We covered the Semrush version in our article on Semrush Site Audit; what matters here is what you export.

1. Every internal link pointing to a 4xx or 5xx URL, with the page that holds the link and the anchor text. That is your list of edits.
2. Every internal link pointing to a 3xx URL. Replace each with a direct link to the final address.
3. Redirect chains: the source URL, every intermediate URL, the final URL and the number of hops.
4. Sitemap URLs that return anything other than 200. A sitemap should contain only final URLs that return 200.
5. Canonical tags that point to a redirect or a 404.

A crawler has one limitation: it only sees what your own site links to. Pages reached only through external links, and URLs from older versions of the site, are invisible to it. For those you need the search engines' data.

Finding broken links in Yandex Webmaster and Search Console

Yandex Webmaster has three reports for this in its Links section. According to Yandex's help (checked 15 October 2026):

• Internal links lists broken links between pages of your site: the linking page, the target URL, the 4xx or 5xx code, the anchor text and the date the data was updated. Up to 10,000 such links are shown per site.
• External links lists broken links to your site from other sites, up to 200,000 of them. By default the list is sorted by the linking site's IKS, and links can be grouped by site. It is a ready-made list of redirect candidates, with the most prominent sources at the top.
• Clicks on broken links is built from anonymised data on real user clicks and split into external, internal and outbound. If someone actually clicks a link and lands on an error, it appears here.

The help also explains why some links never appear in these reports: the linking page is unknown to the robot, the link points to a non-main mirror of your site, or it passes through an intermediate redirect, such as a link from a social network. One more source is Crawl statistics filtered by 404, which lists every URL the robot tried and failed to fetch.

In Search Console the report you need is Page indexing. The statuses that matter here are "Not found (404)", "Page with redirect", "Redirect error" and "Soft 404". Google's help is relaxed about the first: a 404 is not necessarily a problem if the page was removed without a replacement, and in general it recommends fixing only the 404s you link to yourself or list in a sitemap (support.google.com, checked 15 October 2026). "Page with redirect" is not an error either; the URL is not indexed because it redirects elsewhere. "Redirect error" and "Soft 404" are the two that need attention.

One detail about checking individual URLs: according to Google's documentation, its inspection tools do not follow redirects. To see where an old URL ends up, inspect the final URL separately or trace the chain with curl -sIL.

How to fix them without losing link equity

Start with internal links. If you start with redirects, you can spend a day writing rules for URLs nobody needs and miss the broken links in your own menu.

1. Fix internal links. Replace every link to a 404 or to a redirect with a direct link to the current final URL. It costs nothing, does not depend on the search engines, and removes wasted crawling at once.
2. Collect the deleted and moved URLs that have value: external links (the External links report in Yandex Webmaster, or the backlink index in Ahrefs or Semrush), search traffic over the past year, and real user clicks.
3. For each of those, choose the closest replacement by meaning and set a 301 to it. A product page goes to the nearest product or to its category, not to the home page.
4. Leave URLs with no value and no replacement returning 404 or 410.
5. Update the sitemap and canonical tags so they contain only final URLs that return 200.
6. Keep the rules for a long time. Yandex recommends keeping a permanent redirect for at least six months; Google's site-move guide says as long as possible, generally at least a year (developers.google.com, last updated 20 August 2026). Delete the rules a month after a migration to "tidy the config" and the external links to the old URLs go back to returning 404.

For the most valuable external links there is one more step: ask the site owner to update the URL. A direct link is better than a redirect, and changing one address in an old article takes the owner a minute.

Migrations and restructures: a separate case

A move to a new domain or a new URL structure produces broken links and chains by the hundred, so plan the work in advance.

The basis of any migration is a mapping table: each old URL and the URL it should lead to. Google's site-move guide suggests building the list of old URLs from sitemaps, server logs, analytics and a CMS export. The more complete the table, the fewer 404s appear after the switch.

Yandex's migration help covers the case where the domain and the paths change at once, with an example of a double redirect: http://сайт.рф/стр/ → http://example.ru/стр/ → http://example.ru/page/. The same page says a redirect from the old home page to the new home page is required for the move to work, while redirecting every page of the old site to the new home page is inconvenient for users and slows indexing. Yandex accepts either a 301 or a 302 for a site move, but a 301 is the sensible choice for a permanent change of address, because that is the signal Google expects as well.

After the switch, crawl the site from the list of old URLs, not only from the home page, so that every redirect in the table gets tested. A week later, check Crawl statistics in Yandex Webmaster filtered by 404, and the Page indexing report in Search Console for "Not found (404)" and "Redirect error". Problems the robots see and your crawler does not usually turn up there. If the migration also retires old sections, do not block them in robots.txt too early: the robot needs to see both the redirects and the 404s. Our article on robots.txt vs noindex explains why a crawl block gets in the way here.

Two or three weeks later, confirm that the new URLs are indexed in both engines; the procedure is in our guide on how to check whether your site is indexed. Response codes and redirect chains are step three of our technical SEO audit checklist, and after a migration it is worth running the whole checklist.

Frequently asked questions

What is the difference between a 301 and a 302 redirect?

A 301 says the page has moved permanently, a 302 that it has moved temporarily. With a 301, Google shows the new URL in results; with a 302 it keeps the old one. Yandex recommends 302 only for temporary situations such as maintenance, and a 301 for a permanent move.

Should I use 308 instead of 301?

Not for ordinary pages. Both engines treat 308 as a permanent redirect, the same as 301. The difference is that 308 preserves the request method and body, which matters for forms and APIs.

Which is better for a deleted page, 404 or 410?

For Google there is no difference: all 4xx codes except 429 are handled the same way. Yandex recommends 410 for resources removed permanently. If the page has a close replacement, a 301 to it is better than either.

How many redirects in a chain are acceptable?

Google follows up to 10 hops but recommends redirecting straight to the final URL, and if that is not possible, keeping chains to 3 hops or fewer. Internal links and the sitemap should always point to the final URL.

Can I redirect all deleted pages to the home page?

No. Google may treat those redirects as soft 404s, and Yandex's migration help calls the approach inconvenient for users and says it slows indexing. A redirect should lead to a page with similar content.

How long should a 301 redirect stay in place?

Yandex recommends at least six months; after a site move, Google says as long as possible, generally at least a year. If external links point to the old URLs, it is better never to remove the rules.