Hoppa till innehåll 
Prestanda för HTTP-omdirigering avgör mätbart hur snabbt användare och sökrobotar når dina målwebbadresser och hur mycket auktoritet som behålls när du byter. I den här guiden kommer jag att visa dig specifika 301- och 302-strategier som minskar latensen, SEO och undvika felkällor.
Centrala punkter
Jag sammanfattar de viktigaste riktlinjerna kortfattat innan jag går in mer i detalj. På så sätt får du först en röd tråd och kan sedan prioritera. Jag fokuserar på att välja rätt kod, minimera omdirigeringsstigar, cachestrategier och diagnostik. Sedan går jag vidare till implementering i hostingkonfigurationer, övervakning och mobilprestanda. Varje rekommendation syftar till att minimera latens, ren indexering och stabil prestanda. Användarupplevelse.
- Val av kod301 för permanent, 302/307 för tillfällig.
- Avlägsna kedjorVarje steg kostar tid och budget.
- Cache-huvud: 301 cache lång, 302 håll kort.
- 1:1 målRelevanta målsidor ger säker ranking.
- ÖvervakningKontrollera 3xx quota, TTFB och loopar.
Jag förlitar mig på enkla regler och direkta vägar. Det är så jag håller Fördröjning låg och undvik omvägar som förlänger lastningstiden.
301 vs. 302: Effekt på SEO, cache och UX
En 301 signaler permanent, en 302 endast tillfälligt - detta val formar auktoritetsflöde, cachelagring och användarupplevelse. 301 överför det mesta av länkkraften och cachelagras vanligtvis mer av webbläsaren. 302 håller ursprunget i fokus, vilket är användbart för testning, men kontrolleras på nytt vid varje besök. För permanenta förändringar som HTTPS, ny struktur eller domänflytt använder jag 301. För kampanjer, underhållsfönster eller stegvisa tester använder jag 302 eller 307 om förfrågningsmetoden ska bevaras.
| Typ av omdirigering | Signal | SEO-överföring | Caching | Användning |
|---|---|---|---|---|
| 301 | Permanent | Hög | Stark | Migration, struktur, HTTPS |
| 302 | Tillfälligt | Begränsad | Svag | A/B-test, åtgärder |
| 307 | Tillfälligt | Medium | Svag | Ta emot formulär-POST |
| 308 | Permanent | Hög | Stark | API:er, ta emot metod |
Jag väljer alltid statuskod med avsikt, inte av vana. På så sätt undviker jag Rangordning av förluster och minska omarbetningar.
Prestandakostnader: Varje omdirigering räknas
Varje vidarebefordran orsakar ytterligare RundresorDNS, handskakning, begäran och svar. Även ett enda steg kostar ofta 100-300 ms, beroende på nätverk och avstånd. I mobilnät ökar effekten snabbt, särskilt med flera hopp. Omdirigeringar av resurser (CSS, JS, bilder) är dubbelt skadliga eftersom de fördröjer kritisk rendering. Jag minskar därför omdirigeringarna till ett steg och håller alla tillgångar direkt tillgängliga.
Jag förkortar vägarna ytterligare genom att paketera protokolländringar. En ren 301 från http:// till https:// och parallell standardisering av www/non-www sparar Förfrågningar. Med HSTS minskar jag framtida kostnader för omdirigering eftersom webbläsaren föredrar HTTPS direkt. För internationella användare lönar det sig att använda en edge redirect på CDN-noden. På så sätt minimeras väntetiden innan den faktiska sidan laddas.
Undvik kedjor av omdirigeringar: Diagnos och förkortning
Ge bort kedjor som A → B → C Budget för genomsökning och tid. Jag kontrollerar först startwebbadresser, huvudnavigering, interna webbplatskartor och ofta länkade målsidor. Sedan öppnar jag nätverksloggar i webbläsaren och följer alla 3xx-svar. Jag tar itu med varje steg vid källan och leder direkt från A till C tills kedjan försvinner. Hur mycket kedjor saktar ner dig förklaras i den här artikeln på Varför omdirigeringskedjor ökar laddningstiden levande.
Sedan rensar jag upp bland interna länkar så att inga nya hopp skapas. Detta gör arbetet dubbelt värt: robotar når snabbt den slutliga webbadressen och användare sparar klicktid. Jag kontrollerar också regler på serversidan för duplicerade villkor. Saknade undantag skapar ofta loopar eller onödiga Humle. En annan krypning i slutet bekräftar att allt hamnar i ett steg.
HTTPS-migrering utan omvägar
För övergången till HTTPS ställde jag in en global 301 från alla http-sökvägar till https-ekvivalenten. Samtidigt definierar jag en canonical (antingen med eller utan www) och vidarebefordrar konsekvent den alternativa varianten. Jag uppdaterar interna länkar, sitemaps och canonicals så att inga dolda hopp finns kvar. Efter att ha gått live aktiverar jag HSTS när alla subdomäner är klara. Mer djupgående information finns i den här artikeln om Prestanda för HTTPS-omdirigering med frekventa konfigurationsfel.
Sedan kontrollerar jag om API:er, webhooks och callbacks för betalningar fortfarande fungerar korrekt. Särskilt POST-vägar behöver ofta 307/308 så att metoden förblir intakt. Jag blockerar proaktivt blandat innehåll för att förhindra fallbacks till http. Jag tar bort gamla certifikat så att klienter inte kan använda Varningar se. I slutet kontrollerar jag 3xx-statistiken och TTFB tills värdena är stabila.
Caching-strategier och CDN:er
Med lämpliga cache-rubriker kan en 301 den första omdirigeringen till framtida direktsamtal. Jag anger en lång giltighetstid för 301 och håller den kort för 302 för att förbli flexibel. På CDN flyttar jag reglerna till kanten så att användarna får den slutliga URL:en vid nästa nod. Origin-förfrågningar minskar, tiden till den första byten är kortare. Jag kontrollerar också om cookies eller Vary-rubriker i onödan kringgår cacher.
För hög trafik väljer jag 301 302-hosting med snabb I/O så att omdirigeringar svarar utan fördröjning. Edge-regler sparar rundresor till ursprunget och minskar toppbelastningar. Jag undviker duplicerade regler mellan CDN och origin eftersom de skapar hopp. Testregioner visar tydligt på skillnader i latens. Detta innebär att mer budget går till innehåll och mindre till tomgång.
Implementering på serversidan: Apache, Nginx, WordPress
Jag prioriterar omdirigeringar serversidan eftersom den reagerar snabbare och på ett tillförlitligt sätt styr botar. Under Apache räcker det ofta med en kort omskrivningsregel i .htaccess. I Nginx använder jag return eller rewrite direkt i serverkonfigurationen. För specialfall arbetar jag med PHP-rubriker, men förlitar mig inte på JavaScript-hopp på klientsidan. En bra översikt över prioriteringar finns i den här guiden till Vidarebefordran av domäner och prestanda.
# Apache (.htaccess)
RewriteEngine På
# Direkt 301 från gammal till ny URL
RewriteRule ^old-url$ /new-url [R=301,L]
# Nginx (serverkontext)
plats = /old-url {
returnera 301 /ny-url;
}
# PHP (som fallback)
header("Plats: https://example.com/neue-url", true, 301);
utgång;
I WordPress undviker jag alltför många plugin-regler och föredrar att lagra kärnvägar i servern. Jag delar upp stora uppsättningar regler enligt mönster så att utvärderingen förblir snabb. Jag använder sparsamt med platshållare för att minimera regexkostnaderna. Jag håller antalet villkor nere och använder tydliga Prioriteringar. Efter utrullningen kontrollerar jag sekvensen med verkliga förfrågningar.
Övervakning, mätning och feldiagnos
Jag mäter omdirigeringseffekter med krulla (-I, -L), webbläsarens devtools, serverloggar och externa kontroller. De avgörande faktorerna är antalet hopp, TTFB, cacheträffar och HTTP-status. Jag övervakar också 3xx-frekvensen i Analytics och loggfiler. Märkbara spikar indikerar nya kedjor eller loopar. Jag testar från flera regioner och känner igen skillnader i latens och CDN-missar.
Jag ställer in varningar för 301/302-aktier över ett definierat tröskelvärde. En regelbunden genomsökning avslöjar gamla interna länkar som fortfarande omdirigeras. För kampanjer ställer jag in slutdatum så att 302:or tas bort efter avslutad kampanj. För API-vägar kontrollerar jag om 307/308 fungerar korrekt. Jag kontrollerar varje korrigering omedelbart med en ny Begäran.
Mobilprestanda och vitala webbdata
På smarttelefonen har ytterligare Rundresor särskilt märkbar. Varje hopp fördröjer LCP och förskjuter den visuella stabiliteten. Jag behåller därför alla kritiska rutter utan omdirigering och levererar viktiga tillgångar direkt. Om det behövs använder jag preconnect till måldomänen och minskar DNS-tiden. För återkommande användare förhindrar HSTS protokollhoppet vid framtida samtal.
Jag undviker omdirigeringar till resurser som används ovanför vecket. Bilder och CSS ska vara tillgängliga utan nya sökvägar. Jag ställer in parametrar för statiska filer sparsamt, eftersom kantcacher annars är mindre exakta. För mobila användare är det värt att ha en kort TTL på 302-tester så att ändringar träder i kraft snabbt. Detta håller laddningstiden och interaktionen märkbar vätska.
E-handel: filter, parametrar och kampanjer
Butikerna är beroende av många Parametrar men varje felaktigt inställd omdirigering kostar intäkter. Jag uppdaterar kategorier med 301 så att signaler kommer fram, medan temporära åtgärder körs via 302. Jag vidarebefordrar inte filtersidor i blindo, annars förlorar användarna sitt sammanhang. För UTM-parametrar kontrollerar jag om spårningen fungerar utan att bygga omdirigeringsslingor. Jag avaktiverar säsongsbetonade rutter i slutet och omdirigerar till ämnesrelaterade målsidor.
Jag definierar tydliga regler: Produkt raderad, produkt ersatt, produkt permanent slutsåld. Var och en av dessa situationer kräver en annan omdirigering. Jag använder canonicals och noindex när varianter inte ska rankas. Jag testar URL:er för starka rabatter i förväg med en riktig session så att formulärvägarna bibehålls. Så UX konsekvent och konverteringsfriktionen låg.
Vanliga fel och snabba lösningar
Ett vanligt fel är dubbla regler för protokoll och värd, som tillsammans bildar en Kedja form. Jag kombinerar båda i en omdirigering och sparar ett hopp. En andra klassiker: 302 för permanenta flyttar, vilket fördröjer indexeringen. Här byter jag till 301 och håller rutten aktiv under lång tid. För det tredje blockerar omdirigeringsslingor åtkomst, vanligtvis på grund av saknade undantag - jag korrigerar specifikt detta tillstånd.
Uteblivna uppdateringar av interna länkar orsakar belastning och kostnader. Jag korrigerar navigering, sidfot, sitemaps och populära teasers omedelbart. Jag använder inte hopp på klientsidan via JavaScript eller meta refresh eftersom de är långsammare och osäkra för bots. Jag stoppar resursomdirigeringar direkt vid källan och justerar referenserna i HTML och CSS. Detta eliminerar onödiga Häckar och tiden till visning minskar.
Prioriteringar för arkitektur och regler
Jag organiserar omdirigeringar längs kedjan från användaren till applikationen: DNS/CDN → WAF/lastbalanserare → omvänd proxy/webbserver → applikation. Jag placerar regler med hög träfffrekvens och låg komplexitet så tidigt som möjligt (vid CDN/edge) och komplexa enskilda fall närmare applikationen. På så sätt sparar man tid och håller beslutsvägarna korta. Det är viktigt att varje nivå redan känner till den kanoniska mål-URL:en - jag förhindrar duplicerade eller konkurrerande regler mellan CDN och Origin genom tydliga ansvarsområden och tester.
Jag normaliserar host, protocol, path och små bokstäver i en hoppa. Jag tar hänsyn till undantag (t.ex. API-vägar, uppladdningssökväg, adminområde) för att undvika loopar. Jag markerar tydligt regler som utvärderar frågeparametrar och skyddar dem från cachningsfel (Vary: cookie/user agent endast om det är absolut nödvändigt).
HTTP/2-, HTTP/3- och TLS-effekter
Protokoll påverkar kostnaderna för omdirigering. Med HTTP/2 drar webbplatsen nytta av anslutningsmultiplexering, men en ytterligare 3xx är fortfarande en roundtrip-fördröjning. Under HTTP/3 (QUIC) hjälper 0-RTT återupptagande med återbesök, men en omdirigering kostar fortfarande tid och kan omförhandla anslutningen om värd / port ändras. Jag säkerställer därför konsekventa ALPN-erbjudanden (h2, h3) och ställer in HSTS, så att framtida anrop direkt väljer HTTPS. I förekommande fall meddelar jag HTTP/3 via alt-svc så att klienterna snabbare byter till det optimala protokollet. Jag håller certifikatkedjorna smala och aktiverar OCSP-häftning för att ytterligare minska TLS-fördröjningen under den första omdirigeringen.
Språk- och landsvägar utan SEO-förluster
För internationalisering förlitar jag mig på en tydlig åtskillnad mellan erkännande och vidarebefordran. Vid första besöket är en 302 till den lokaliserade rutten, styrd via accept-language eller geo-signaler och säkrad med en cookie så att efterföljande anrop kan göras utan ytterligare omdirigering. Jag respekterar botar och djuplänkar genom att aldrig tvinga fram en omdirigering när en URL på ett visst språk anropas. Jag håller hreflang-signalerna konsekventa och använder en neutral standardsida utan ett påtvingat hopp som fallback. Detta håller indexering, användarkontroll och prestanda i balans.
Frågesträngar, normalisering och statusalternativ
Jag ser till att vidarebefordran Frågesträngar korrekt, särskilt för kampanjparametrar. I Nginx säkrar jag detta med $is_args$args eller . $query_sträng, i Apache med lämpliga flaggor (standard är: keep query, QSD tas bort avsiktligt). Jag tar medvetet bort överflödiga parametrar i ett steg om de inte längre har någon funktion för att öka träfffrekvensen i cacheminnet. I stället för att reflexmässigt använda 301 ställer jag också in 410 Gone - Detta förkortar genomsökningscyklerna. Jag dirigerar obefintligt men relaterat innehåll till starka alternativ. Jag undviker specifikt mjuka 404:or (301 → irrelevant sida) eftersom de försvagar både UX och signaler.
Omdirigera kartor för stora migreringar
För omfattande nylanseringar arbetar jag med Avstämningar, som jag versionerar och importerar automatiskt. För Nginx använder jag karta-block eller inkluderingsfiler, för Apache Omskrivningsmapp med text- eller DB-backends. Detta gör att tusentals gamla sökvägar kan mappas till nya destinationer med hög prestanda utan att behöva kontrollera dyra regex i varje begäran. Jag skapar en kvalitetskontroll i förväg: varje gammal URL måste ha exakt ett mål, frågehantering definieras och konflikter utesluts. En separat staging validerar kedjefrihet och statuskoder innan reglerna går live.
# Nginx: Kartbaserad routing (exempel)
map $request_uri $redir_target {
/alt/väg-1 /ny/väg-1;
/alt/sökväg-2 /ny/sökväg-2;
# ...
}
server {
if ($redir_target) {
return 301 $scheme://example.com$redir_target$is_args$args;
}
}
Exempel: Kanonisk vidarebefordran i ett steg
Jag kombinerar host- och protokollkanonisering på ett smidigt sätt för att undvika dubbelhopp. Jag löser sökvägsnormalisering (efterföljande snedstreck, indexfiler) på samma gång - med undantag för filer.
# Nginx
server {
lyssna 80;
lyssna 443 ssl http2;
server_namn www.example.com example.com;
# En kanonisk host/HTTPS-regel
if ($host != 'example.com') {
return 301 https://example.com$request_uri;
}
om ($scheme != 'https') {
returnera 301 https://example.com$request_uri;
}
# Efterföljande snedstreck för kataloger, men inte för filer
if ($request_uri ~ ^(.+[^/])$) {
if ($uri ~ ^.*\.[a-zA-Z0-9]{2,5}$) { }
else { return 301 https://example.com$1/; }
}
}
# Apache
RewriteEngine On
RewriteCond %{HTTPS} off [OR]
RewriteCond %{HTTP_HOST} !^example\.com$ [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [R=301,L]
# Efterföljande snedstreck endast för "katalog"-utseende
RewriteCond %{REQUEST_URI} !\.[a-zA-Z0-9]{2,5}$
Omskrivningsvillkor %{REQUEST_URI} !/$
RewriteRule ^ https://example.com%{REQUEST_URI}/ [R=301,L]
API:er, webhooks och formulärflöden
Maskinklienter följer ofta inte omdirigeringar eller tappar bort metoder / kropp. För POST/PUT använder jag 307/308, så att metoden förblir intakt. När det är möjligt håller jag webhooks destinationsadresser stabila och undviker omdirigeringar helt och hållet. För underhåll använder jag 503 med retry-after i stället för 302 så att avsändarna omdirigerar korrekt. Jag dokumenterar förväntningar på omdirigeringar för integrationer, testar med HEAD och kontrollerar att auktoriseringsrubriker i klienter kvarstår över omdirigeringar.
Säkerhet: Öppna omdirigeringar och cache-kontroll
Jag förhindrar Öppna omdirigeringar, genom att strikt vitlista målparametrar till tillåtna värdar/sökvägar. Jag normaliserar relativa sökvägar på serversidan och tar bort absoluta externa mål om de inte uttryckligen är tillåtna. För dynamiska, användarberoende omdirigeringar minimerar jag riskerna med cache: ingen inställning av långlivade cache-rubriker och Vary endast så brett som nödvändigt. För känsliga rutter förhindrar jag cacheförgiftning genom att tydligt separera cookies och auktoriseringsstatus och inte göra omdirigeringar beroende av manipulerbara rubriker.
Servicearbetare, SPA och omskrivningar
I appar med en sida skiljer jag tydligt mellan omskrivningar av navigering (serverinternt, 200) och riktiga omdirigeringar (3xx). Servern ska leverera /app-vägar utan hopp, medan gamla, offentliga webbadresser går till nya semantiska mål via 301. I servicearbetaren ser jag till att inga omdirigeringssvar cachelagras oavsiktligt och kontrollerar hämtningshanterare så att navigationsförfrågningar inte hamnar i loopar. För SEO-kritiska dokument föredrar jag 301 på serversidan framför routerhopp på klientsidan för att överföra signaler på ett tillförlitligt sätt.
Finjustering: små bokstäver, kodning och indexfiler
Inkonsekventa versaler, dubbla snedstreck eller felaktigt kodade umlaut kostar prestanda och skapar duplicerade varianter. Jag normaliserar sökvägar (t.ex. omdirigeringar med gemener), säkerställer korrekt UTF-8-kodning i mål och tar bort dubbla slash-sekvenser i ett steg. Jag riktar indexfiler (index.html, index.php) till katalogens URL och ser till att exakt denna kanoniska form länkas i mallar. Tillgångar med filtillägg undantas från sådana regler för att undvika onödiga hopp.
Rollback-strategi och webbläsare som är “gifta” med 301
Eftersom webbläsaren 301 ofta ständigt cachar, planerar jag en väg tillbaka. I testfaser använder jag inledningsvis 302/307 och byter till 301/308 först när det är godkänt. Om en felaktig 301 går live avbryter jag den med en ny, mer specifik regel, levererar rätt mål-URL utan ytterligare hopp och korrigerar interna länkar. Jag informerar teamet och supporten om att lokala cacher/HSTS-listor kan vara orsaken till avvikande beteende och väntar på att majoriteten ska lösa det korrekt igen.
Fördjupa mätningen: Budgetar och segmentering
Jag definierar budgetar: högst en omdirigering per navigering, mål TTFB under X ms, 3xx-frekvens under Y procent. Jag mäter separat per enhetstyp, region och sidtyp (hemsida, kategori, produkt, kassa). Syntetiska tester avslöjar strukturella kedjor, RUM visar verkliga effekter på LCP/INP/FID. I loggar markerar jag omdirigeringssvar med latenshinkar och korrelerar dem med cachestatus (HIT/MISS/BYPASS). Vid avvikelser justerar jag sekvenser, undantag och kantregler tills kurvorna är stabila.
Checklista för kvalitetssäkring före driftsättning
- Alla testade topp-URL:er: 200 utan omdirigeringar eller en enda 301/308 till den slutliga mål-URL:en.
- Inga kedjor A→B→C, ingen blandning av protokoll- och värdregler i separata hopp.
- Frågesträngar och fragment överförs korrekt, kampanjparametrar bibehålls.
- API:er/webhooks/formulär: Metod bevarad för omdirigeringar (307/308), kroppar intakta.
- Edge och Origin reglerar konfliktfria, identiska testfall på båda nivåerna.
- HSTS aktiv efter HTTPS-terminering, förladdning endast när den är helt förberedd.
- Interna länkar, canonicals, sitemaps uppdaterade; inga fler interna 3xx.
- Övervakningslarm inställt för 3xx-kvot och TTFB; test från flera regioner.
Sammanfattning och nästa steg
Jag prioriterar först Urval av lämplig kod, sedan förkortas alla vägar till exakt ett hopp. Sedan säkerställer jag cachelagring: 301 lång, 302 kort, kantregler vid CDN-kanten. Samtidigt rensar jag upp interna länkar, sitemaps och canonicals så att förfrågningar kommer fram direkt. Jag mäter TTFB, 3xx-andel och LCP tills stabila värden har uppnåtts. Slutligen planerar jag revisioner med jämna mellanrum så att kedjor, loopar och tillfälliga tester inte blir permanenta byggarbetsplatser.
Den här sekvensen håller omdirigeringar smidiga, söksignaler intakta och sidor snabba. Så här ökar jag HTTP-omdirigeringsprestanda mätbart och permanent. Varje korrigering har en inverkan på användarupplevelsen, crawling-effektiviteten och serverbelastningen. Jag håller reglerna så kortfattade som möjligt och kontrollerar dem konsekvent. Detta sparar tid, budget och skyddar Resurser.
