301 Redirects: What They Are and How to Set Them Up Correctly

أبرز النقاط

• A 301 tells search engines and AI crawlers that a URL has moved permanently. It is the only redirect type that reliably transfers ranking signals, and it is also the only one most crawlers will use to update their stored index entry.
• Google has confirmed that PageRank is not lost through 301 redirects, so the old advice about a 15% damping penalty is obsolete. What still costs you traffic is a bad mapping, not the redirect itself.
• The single most common failure we see on client sites in Egypt and the Gulf is not a missing redirect. It is a redirect that lands everything on the homepage, which Google then treats as a soft 404 and drops entirely.
• Arabic URLs need percent encoding in the redirect rule. A rule written with raw Arabic characters will silently fail on most Apache and LiteSpeed hosts used in the region.
• AI answer engines follow redirects but they cache aggressively. Expect a longer lag before ChatGPT or Perplexity stop quoting your old URL than before Google does.

Every site migration, rebrand, URL cleanup and domain consolidation runs through the same narrow gate: whether the old addresses still lead somewhere useful. Get that gate right and a migration is invisible to your traffic. Get it wrong and you can lose most of your organic visibility in a fortnight, with no penalty, no manual action and no obvious cause in your indexing reports.

This guide covers what a 301 redirect actually does, when to reach for a different status code, how to implement redirects across the server stacks that are common in this region, and how to verify the result. It also covers the part most guides skip: what redirects do to your visibility inside AI answers, which behaves differently from classic search.

What a 301 redirect actually is

A 301 is an HTTP status code. When a browser or crawler asks for a URL, the server can answer with the content, or it can answer with a status code and a new address in the Location header. A 301 means the resource has moved permanently and the new address should be used from now on.

Three things follow from the word permanently:

• Search engines eventually replace the old URL with the new one in their index. The old URL stops appearing in results and the new one inherits its position.
• Browsers cache the redirect, sometimes for a very long time. This is why a mistaken 301 is painful to undo: visitors who hit it once may keep being redirected even after you remove the rule.
• Ranking signals pass through. Links pointing at the old URL count for the new one.

That last point used to carry an asterisk. For years the accepted wisdom was that a 301 leaked a percentage of link equity. Google has since stated plainly that no PageRank is lost through 30x redirects. If you are working from a checklist that still tells you to minimise redirects to preserve equity, that checklist predates the change.

301 versus every other option

Choosing the wrong status code is a quiet mistake. Nothing breaks, the page loads, and it takes weeks for the ranking damage to show up. This table is the decision you are actually making.

The distinction people get wrong most often is 301 against 410. There is a reflex to redirect everything, on the theory that a redirect is always safer than an error. It is not. If you redirect a discontinued product to a category page that does not answer the same question, Google classifies it as a soft 404, drops the old URL anyway, and you have gained nothing while adding a hop. A clean 410 tells the crawler to stop asking and reallocates crawl budget to pages that matter. See our guide on finding and fixing broken links for how to tell the two situations apart at scale.

When you need a 301

• Moving from HTTP to HTTPS. Still not universal in the region, and still worth fixing today.
• Moving from a non-www to a www hostname or the reverse. Pick one, redirect the other, never serve both.
• Changing a URL structure, for example dropping dates from post slugs or flattening a deep folder hierarchy.
• Consolidating a duplicate domain. If you own both a .com and a country domain serving the same content, one of them is diluting the other.
• Merging two thin pages that compete for the same query. Redirect the weaker one into the stronger one and you often outrank both previous positions.
• Retiring a page that has a true replacement, such as an old service page superseded by a rewritten one.

That third to last case is worth dwelling on, because it is the one with the fastest return. If you have two articles both half answering the same query, they split their own signals. Merging them and redirecting is usually a bigger ranking gain than any amount of on page editing. It is also one of the causes we check first when diagnosing why a site has lost rankings.

How to set up a 301, by environment

The rule is the same everywhere. The syntax is not. Work out which layer is actually serving your site before you edit anything, because a rule written at the wrong layer either does nothing or fights with a rule above it.

Apache and LiteSpeed, using .htaccess

Most shared hosting in Egypt and the Gulf runs Apache or LiteSpeed, and LiteSpeed reads .htaccess with Apache syntax. Put redirects near the top of the file, above the WordPress block, or WordPress will handle the request first.

# Single URL to single URL
Redirect 301 /old-page/ https://www.example.com/new-page/

# Same thing with regex, needed for patterns
RewriteEngine On
RewriteRule ^old-folder/(.*)$ /new-folder/$1 [R=301,L]

# Force HTTPS and www in one pass, no chain
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^www\. [NC]
RewriteRule ^(.*)$ https://www.example.com/$1 [R=301,L]

# Whole domain to whole domain, preserving the path
RewriteCond %{HTTP_HOST} ^old-domain\.com [NC]
RewriteRule ^(.*)$ https://www.new-domain.com/$1 [R=301,L]

Note the combined HTTPS and www rule. Writing them as two separate rules produces a chain: the browser is redirected twice for every request. It works, but it doubles the latency on a step that already sits on the critical path for page load speed.

Nginx

Nginx does not read .htaccess. Rules live in the server block and require a reload to take effect.

# Single URL
location = /old-page/ {
    return 301 https://www.example.com/new-page/;
}

# Pattern
location ~ ^/old-folder/(.*)$ {
    return 301 https://www.example.com/new-folder/$1;
}

# Whole domain
server {
    listen 443 ssl;
    server_name old-domain.com www.old-domain.com;
    return 301 https://www.new-domain.com$request_uri;
}

WordPress with Rank Math

For anything under a few hundred rules, and for teams without server access, doing it in the plugin is the pragmatic choice. Rank Math has a Redirections module that is off by default.

1. Go to Rank Math, then Dashboard, and switch the Redirections module on.
2. Open Rank Math, then Redirections, then Add New.
3. Enter the source without the domain, choose Permanent move (301) as the type, and enter the full destination URL.
4. For bulk work use Import and Export and upload a CSV. This is far faster and gives you a record of the mapping you can diff later.
5. Leave the built in 404 monitor on for a few weeks after a migration. It will show you the URLs you forgot.

One caution. Plugin level redirects run in PHP, which means WordPress boots for every redirected request. On a large migration with heavy traffic to old URLs this is measurable. Above roughly one thousand rules, move them to the server layer.

Cloudflare and other proxies

If you sit behind Cloudflare you have a fourth place a redirect can live. Bulk Redirects and Redirect Rules execute at the edge before the request reaches your host, which is the fastest option and survives an origin outage. It is also the layer people forget when a redirect behaves inexplicably. When a rule you cannot find keeps firing, check the proxy before you doubt your own config.

The regional problems that generic guides do not cover

Arabic URLs break naive redirect rules

If your slugs contain Arabic characters, the browser sends them percent encoded. A rule written with the literal Arabic string will not match, because the server never sees those characters. It sees the encoded form.

# This will not fire
Redirect 301 /[raw-arabic-slug]/ https://www.example.com/seo-services/

# This will
Redirect 301 /%D8%AE%D8%AF%D9%85%D8%A7%D8%AA-%D8%B3%D9%8A%D9%88/ https://www.example.com/seo-services/

Encode the source, and leave the destination in readable form. If you are moving away from Arabic slugs entirely, which we usually recommend for the .com property because it makes links shareable and analytics readable, do it in one pass rather than gradually. A half migrated URL structure is harder to audit than either end state.

The .com and country domain problem

A very common setup in this market: a business owns example.com and example.com.eg, or example.com and example.ae, and both serve the same content because someone thought it would help local ranking. It does the opposite. Two domains with identical content split every signal between them, and neither accumulates enough authority to compete.

The fix is to choose the primary property and 301 the other domain across, path for path. Choose based on where the links and the existing rankings already are, not on which one feels more local. If you genuinely need separate country properties, they need genuinely different content and correct hreflang, which is a different project.

Bilingual sites and language paths

When a site moves from a language subdomain to a language folder, or the reverse, the redirect map must preserve the language pair. Sending every Arabic URL to the English homepage is the single fastest way to destroy an Arabic search presence. Map ar to ar and en to en, then handle the unmatched remainder deliberately.

Redirect chains, loops and the mistakes that cost traffic

The last row is the one that catches experienced teams. Blocking an old directory in robots.txt feels tidy during a migration. It guarantees the redirect is never discovered, because the crawler is not allowed to make the request that would reveal it.

What redirects do to your visibility in AI answers

This is the part that has changed since most redirect guides were written, and it is where our own testing has been most useful.

AI answer engines do follow redirects. A crawler operated by OpenAI, Perplexity or Google for its AI surfaces will land on the destination and read it. What differs is the update cycle. Classic search reprocesses a redirected URL within days to weeks. Model grounding layers and retrieval caches are slower and less predictable, and some assistants continue to surface a cached snippet of the old URL well after Google has stopped.

Three practical consequences:

1. Do not remove redirects after a few months. The old convention was to keep them for a year. Keep them permanently where you can, because an AI system may still be resolving the old address long after your analytics say nobody uses it.
2. After a migration, expect a period where an assistant quotes your old page title or an outdated statistic. Republishing the destination with a fresh date and a clearly structured answer accelerates the correction. Our guide on writing content that gets quoted covers the structural side of this.
3. Redirect the URLs that AI systems actually cite, not just the ones with traffic. A page with almost no clicks can still be the source an assistant leans on, because citation follows structure and clarity rather than popularity. Audit your citation surface before you decide what is safe to retire.

If you want the fuller picture of how visibility works across these surfaces, start with the دليل GEO.

A verification routine that actually catches problems

Implementing redirects is the easy half. Verifying them is where migrations are won. This is the sequence we run on every project.

1. Check the status code directly, not in a browser. A browser hides the hop. Use curl and read the chain: curl -sIL https://www.example.com/old-page/ and confirm you see exactly one 301 followed by one 200.
2. Crawl the old URL list. Take the pre migration URL export, feed it to a crawler as a list, and check that every entry returns 301 and that no destination returns 404, 500 or another 301.
3. Confirm no chains. Sort the crawl output by number of hops. Anything above one hop gets rewritten to point at the final destination.
4. Compare destination content. Spot check that the destination genuinely answers the same question. This is the step that separates a real mapping from a lazy one, and no tool can do it for you.
5. Regenerate and resubmit the sitemap. It should contain destinations only.
6. Rewrite internal links. Search the database for the old URLs and replace them. Leaving them in place means every internal click and every crawl path pays an unnecessary hop.
7. Watch Search Console for four weeks. Coverage should show the old URLs moving to a redirect state and the new URLs entering the index. A spike in soft 404s is the signal that some of your mapping was too loose.
8. Re run the check after thirty days. Redirects get lost in deployments more often than anyone admits.

For sites where the destination is rendered client side, verify against the rendered output rather than the raw response, because the status code and the visible content can tell different stories. Our دليل JavaScript SEO explains why.

How long it takes to see the effect

There is no fixed number, but there are reliable ranges. Small sites of a few hundred URLs usually stabilise within two to four weeks. Sites in the tens of thousands take one to three months, because Google recrawls at a rate proportional to how often it already visits you. Sites with weak crawl frequency take longest, which is the argument for fixing crawl efficiency before a migration rather than after.

A dip in the first two weeks is normal and not evidence of a mistake. A dip that is still deepening in week five is. The diagnostic is whether the old URLs are being replaced by the new ones in the index, or simply disappearing. The first is a migration in progress. The second is a mapping problem.

الأسئلة الشائعة

Does a 301 redirect lose link equity?

No. Google has confirmed that no PageRank is lost through 30x redirects. The older belief that a redirect cost around 15% of equity reflected an earlier system and no longer applies. What does cost you is redirecting to an irrelevant destination, which is a relevance failure rather than a redirect failure.

How long should I keep a 301 in place?

Permanently, where the cost allows. The old guidance of one year predates AI answer engines, which resolve cached URLs on a slower and less visible schedule. If the rule set becomes unwieldy, prune by traffic and citation value rather than by age.

301 or canonical tag?

Use a 301 when only one URL should remain reachable. Use a canonical when both URLs need to stay live but only one should rank, such as a print view or a filtered listing. A canonical is a hint that Google may ignore. A 301 is not.

Can I redirect to a different domain?

Yes, and signals transfer normally, provided the destination content is genuinely equivalent. Cross domain redirects are how rebrands work. The failure mode is the same as always: redirecting to a homepage instead of a matching page.

What happens if I redirect a page to one that does not exist?

The visitor gets a 404 after a pointless hop, and the crawler concludes the old URL leads nowhere. This is worse than leaving the original 404 in place, because it also burns crawl budget. Always crawl your destinations, not only your sources.

Do redirects slow down my site?

Each hop adds a round trip. One hop is negligible. Chains of three or four are noticeable on mobile connections, and they compound with every other latency source on the page. Collapse chains as a routine part of any redirect audit.

أين يندرج هذا؟

Redirects are one control in a larger technical system that also covers crawlability, indexation, structured data and site speed. If you are working through a migration or a cleanup, the دليل SEO التقني maps how these controls interact, and the site navigation guide covers the internal link rewriting step that most redirect projects leave half finished.

أدلة ذات صلة

• الروابط المعطوبة: كيف تجدها وتصلحها بنفسك
• فهرسة المواقع: كيف تسرّعها وتتحقق من وجود الصفحات في البحث
• ما هي الصفحات المكررة ولماذا تُعدّ خطيرة؟
• Screaming Frog for JavaScript Sites: How to Crawl What Search Engines Actually See