Uzlabots novirzīšanas pārbaudītājs un tehniskais SEO analizators

Izsekojiet HTTP novirzīšanas ķēdes ar servera puses pieprasījumu. Salīdziniet atlasītās User-Agent un Client Hints pieprasījuma galvenes, pārbaudiet statusu un izmērīto atbildes laiku līdz piecām novirzīšanām un nosakiet pārejas no HTTPS uz HTTP. Pārbaudītājs neizpilda mērķa JavaScript un neanalizē lapas HTML.

🌐

Atlasītie User-Agent un Client Hints ir pieprasījuma galveņu testa profili; tie neautentificē īstu pārlūkprogrammu vai rāpuļprogrammu.

Audita rezultāti un vizuālā plūsma

⚠️ Drošības brīdinājums: konstatēts jaukts saturs. Novirzīšanas ķēdes laikā savienojums pārslēdzās uz nešifrētu HTTP.

Visaptveroša lietotāja rokasgrāmata un praktiski pielietojumi

RedirectChecker.Site nav tikai standarta HTTP galveņu lasītājs; tas ir uzlabots tīkla diagnostikas rīks SEO speciālistiem, sistēmu administratoriem un tīmekļa izstrādātājiem. Pareiza funkciju izmantošana palīdz novērst sarežģītas maršrutēšanas problēmas, kas var būtiski ietekmēt meklēšanas rezultātu pozīcijas un lietotāju pieredzi.

1. Pārbaudītāja lietošana: soli pa solim

Ievadiet pilnu publisku URL, iekļaujot protokolu (piemēram, https://example.com/old-page). Izvēlieties parauga User-Agent un, ja vajadzīgs, Client Hints galveņu profilu. Pārbaudītājs nosūta servera puses pieprasījumu ar šīm galvenēm; tas neatdarina pilnu pārlūkprogrammu, sīkdatnes, JavaScript vai rāpuļprogrammas tīkla identitāti.

2. Rezultātu un vizuālās plūsmas piemēru interpretēšana

Noklikšķiniet uz Izsekot URL lai redzētu katru HTTP atbildi novirzīšanas ķēdē, tās statusa kodu, izmērīto pieprasījuma laiku un nākamo Location URL, ja tāds ir. Vienā palaišanas reizē tiek izsekotas līdz piecām novirzīšanām; ja ķēde turpinās, nākamā URL atbilde šajā reizē netiek iekļauta.

3. Praktisks piemērs: SSL pazeminājuma noteikšana

Novirzīšana var pazemināt URL no HTTPS uz HTTP. Pārbaudītājs atzīmē šo pāreju, kad HTTPS URL atbilde norāda uz HTTP Location. Pirms paļaujaties uz rezultātu, pārbaudiet mērķi un konfigurējiet paredzēto HTTPS maršrutu.

Tehniskie pamati: HTTP statusa kodi un tīkla inženierija

HTTP statusa kodi raksturo pieprasījuma iznākumu, savukārt 3xx atbildes novirza klientus uz citu URL. Pastāvīgas novirzīšanas var palīdzēt meklētājprogrammām apvienot URL, taču tās negarantē konkrētu pozīciju vai indeksēšanas rezultātu. Izmantojiet paredzētajai situācijai atbilstošu statusa kodu un pārbaudiet visu ķēdi un galīgo atbildi.

Atšķirības starp 301, 302, 307 un 308

  • 301 Pastāvīgi pārvietots: Izmantojiet, ja resurss ir pārvietots pastāvīgi. Meklētājprogrammas pastāvīgu novirzīšanu uzskata par spēcīgu signālu par labu mērķim, taču neviena novirzīšana negarantē konkrētu pozīciju vai indeksēšanu.
  • 302 Atrasts (īslaicīgi): Norāda klientam uz laiku apmeklēt citu URL, liekot saprast, ka sākotnējais URL atgriezīsies. Meklētājprogrammas parasti nenodod pastāvīgu saišu vērtību, izmantojot 302.
  • 307 Īslaicīga novirzīšana: Mūsdienīgs HTTP/1.1 ekvivalents 302. Būtiski, ka 307 garantē — sekojot novirzīšanai, HTTP metode (GET vai POST) NETIKS mainīta.
  • 308 Pastāvīga novirzīšana: 307 pastāvīgā versija. SEO nolūkos tā darbojas līdzīgi 301, taču stingri aizliedz pārlūkprogrammai pārveidot POST pieprasījumu par GET pieprasījumu.

HTTP atbildes statusa kodu saderība ar pārlūkprogrammām

HTTP statusa kodi ir protokola signāli, ko apstrādā pārlūkprogrammas tīkla steks, nevis atsevišķas pārlūkprogrammu funkcijas. Mūsdienu Chrome, Edge, Firefox, Safari, Opera, Android WebView un iPhone WebView apstrādā standarta statusa klases; kļūdas attēlojums var atšķirties atkarībā no pārlūkprogrammas un starpniekservera.

HTTP atbilžu klaseChrome / EdgeFirefoxSafariOperaAndroid / iPhone WebViewPraktiskas saderības piezīme
1xx informatīvsAtbalstītsAtbalstītsAtbalstītsAtbalstītsAtbalsta tīkla slānis100 un 101 ir plaši ieviesti. 102 ir specializēts/novecojis; 103 Early Hints darbība var atšķirties pēc versijas, servera un starpniekservera.
2xx veiksmīga atbildeAtbalstītsAtbalstītsAtbalstītsAtbalstītsAtbalstītsProtokola semantika ir kopīga; joprojām jāievēro atbildes pamatteksta noteikumi, piemēram, 204/205 gadījumā atbildes pamatteksta nav.
3xx novirzīšanaAtbalstītsAtbalstītsAtbalstītsAtbalstītsAtbalstītsKlienti seko Location atbilstoši metodes, kešatmiņas, drošības un navigācijas noteikumiem. 307/308 saglabā metodi; 301/302 var pārveidot POST par GET.
4xx klienta kļūdaAtbalstītsAtbalstītsAtbalstītsAtbalstītsAtbalstītsAtbildes klase tiek atpazīta, taču servera pamatteksta attēlojums un pārlūkprogrammas kļūdas saskarne var atšķirties.
5xx servera kļūdaAtbalstītsAtbalstītsAtbalstītsAtbalstītsAtbalstītsStarpniekservera lapas, atkārtotas mēģināšanas darbība un diagnostikas attēlojums var atšķirties pat tad, ja statuss ir vienāds.
Neatpazīts kods zināmā klasēKlases līmeņa apstrādeKlases līmeņa apstrādeKlases līmeņa apstrādeKlases līmeņa apstrādeKlases līmeņa apstrādeKlienti var noteikt vispārīgo klasi pēc pirmā cipara. Pielāgots kods šīs noklusējuma apstrādes dēļ neiegūst universālu nozīmi.

Šī tabula apraksta protokola saderību, nevis identisku attēlojumu vai garantiju, ka katra pārlūkprogrammas versija vienādi parāda starpatbildes.

Maskēšana un dinamiskās renderēšanas pārkāpumi

Maskēšana ir prakse, kad meklētājprogrammām un cilvēkiem rāda būtiski atšķirīgu saturu vai mērķus. Varat salīdzināt atbildes uz atlasītajām User-Agent un Client Hints galvenēm infrastruktūrā, kuru esat pilnvarots pārbaudīt. Šie galveņu profili nepārbauda rāpuļprogrammas identitāti un nenosaka, vai vietne atbilst Google politikām.

Biežāk uzdotie jautājumi (tehniskie FAQ)

Kas ir “novirzīšanas ķēde” un kāpēc tā kaitē tehniskajam SEO?

Novirzīšanas ķēde veidojas, kad URL iziet cauri vairākām starpposma adresēm, pirms sasniedz galīgo lapu (piemēram, A → B → C → D). Katram solim vajadzīgs jauns pieprasījums, kas palielina aizkavi un padara pārmeklēšanu mazāk efektīvu. Maršrutus veidojiet pēc iespējas tiešākus; nākamais FAQ skaidro ieteicamo ķēdes garumu.

RFC 9110: HTTP semantika, novirzīšana · Google Search Central: vietņu pārvietošana un novirzīšana

Kā pēc novirzīšanas pārbaudīt canonical tagus?

Šis pārbaudītājs izseko HTTP statusa kodus un Location galvenes, taču nelejupielādē un neparsē mērķa lapas HTML, tāpēc nevar pārbaudīt rel=canonical. Atveriet galīgo URL un pārliecinieties, ka canonical saite norāda uz vēlamo, indeksējamo lapu. Google izvēlēto canonical URL varat pārskatīt Search Console URL pārbaudes rīkā.

Google Search Central: canonicalizācija · Google Search Central: canonical URL norādīšana

Vai šis rīks var noteikt JavaScript novirzīšanas?

Nē. Rīks seko HTTP 3xx atbildēm ar Location galveni. Tas neizpilda JavaScript un nepārbauda atbildes pamattekstā meta-refresh tagus; to pārbaudei vajadzīga pārlūkprogramma.

Google Search Central: novirzīšana un Google meklēšana

Kas ir novirzīšanas cilpa un kā to novērst?

Novirzīšanas cilpa ir bezgalīgs cikls, kurā URL A norāda uz URL B, bet URL B atpakaļ uz URL A, izraisot pārlūkprogrammas ERR_TOO_MANY_REDIRECTS kļūdu. Lai to novērstu, jārediģē servera .htaccess fails, Nginx konfigurācija vai CMS maršrutēšanas noteikumi.

RFC 9110: HTTP semantika, novirzīšana · MDN: HTTP atbildes statusa kodi

Kas ir Client Hints un kā pārbaudītājs tos izmanto?

Client Hints ir HTTP pieprasījuma galvenes, piemēram, Sec-CH-UA-Mobile un Sec-CH-UA-Platform. Atlasītais profils pievieno šīs galvenes pārbaudītāja servera puses pieprasījumam, lai varētu salīdzināt servera atbildes. Tas ir galveņu tests, nevis pilna pārlūkprogrammas simulācija vai pierādījums, ka pieprasījumu veicis noteikts pārlūks vai rāpuļprogramma.

MDN: HTTP Client Hints

Cik daudz 301 novirzīšanu drīkst būt ķēdē?

Google dokumentācijā norādīts, ka Googlebot var sekot līdz 10 novirzīšanas soļiem, vienlaikus iesakot, kad iespējams, izmantot tiešu maršrutu. Ja ķēdi nevar likvidēt, saglabājiet to īsu — ideālā gadījumā ne vairāk kā trīs soļi un mazāk par pieciem. Katrs solis pievieno pieprasījumu, un citiem klientiem var būt zemāki ierobežojumi. Izvēlieties pastāvīgu (301/308) vai īslaicīgu (302/307) kodu atbilstoši paredzētajai pārvietošanai. Google Search Central ieteikumi.

RFC 9110: HTTP semantika, novirzīšana

Kuri HTTP statusa kodi norāda uz pastāvīgu vai īslaicīgu pārvietošanu?

301 un 308 norāda uz resursa pastāvīgu pārvietošanu; 302 un 307 — uz īslaicīgu novirzīšanu. Izvēlieties statusu atbilstoši tam, vai sākotnējam URL paredzēts atgriezties, un nodrošiniet, ka mērķis atbilst sākotnējam pieprasījumam.

RFC 9110: HTTP semantika, novirzīšana

Kad 301 vai 302 vietā izmantot 307 vai 308?

307 un 308 novirzīšanas laikā saglabā pieprasījuma metodi. Izmantojot 301 vai 302, daži klienti var mainīt POST pieprasījumu uz GET. Izmantojiet 307 īslaicīgai vai 308 pastāvīgai pārvietošanai, ja svarīgi saglabāt metodi un pieprasījuma pamattekstu; pārbaudiet jūsu pakalpojuma atbalstīto klientu darbību.

RFC 9110: HTTP semantika, 307 un 308

Vai 301 novirzīšana garantē pozīcijas vai indeksēšanu?

Nē. Pastāvīga novirzīšana ir spēcīgs signāls, ka mērķa URL jāaizstāj ar avota URL, un Google norāda, ka pastāvīgas novirzīšanas nezaudē PageRank. Meklētājprogrammas joprojām lemj, ko pārmeklēt, indeksēt un ranžēt, ņemot vērā visus signālus un mērķa saturu.

Google Search Central: novirzīšana un Google meklēšana · Google Search Central: canonicalizācija

Ko apstiprina galīgā 2xx atbilde?

Tā apstiprina, ka pēdējais HTTP pieprasījums izsekošanas laikā saņēma veiksmīgas klases atbildi. Tas nepierāda, ka saturs ir noderīgs, pieejams visiem apmeklētājiem, indeksējams, pareizi canonicalizēts vai piemērots ranžēšanai.

RFC 9110: HTTP semantika, veiksmīgas atbildes · MDN: HTTP atbildes statusa kodi

Kāpēc pārbaudītājs saņem 403 vai 429, ja pārlūkprogrammā lapa atveras?

Pārbaudītājs nosūta servera puses pieprasījumu, kas var atšķirties no pārlūkprogrammas tīkla atrašanās vietas, sīkdatņu, autentifikācijas un galveņu ziņā. Ugunsmūris, CDN, ātruma ierobežojums vai robotu noteikums var pieprasījumu bloķēt vai ierobežot. Salīdziniet servera žurnālus un piekļuves noteikumus; neuzskatiet viena testa 403 vai 429 par pierādījumu, ka visi apmeklētāji ir bloķēti.

RFC 9110: 403 Forbidden · RFC 6585: 429 Too Many Requests

Vai Googlebot un meklēšanas rāpuļprogrammu profili ir pārbaudītas rāpuļprogrammas?

Nē. Profils maina tikai User-Agent galvenes tekstu. Pieprasījums nenāk no Google vai citas rāpuļprogrammas tīkla un nevar pierādīt, ka pieprasītājs ir autentiska rāpuļprogramma. Pārbaudiet tās identitāti, izmantojot pakalpojumu sniedzēja publicēto IP vai DNS verifikācijas procedūru.

Google Search Central: Googlebot un citu Google rāpuļprogrammu verifikācija

Kāpēc dažādi User-Agent profili var veidot atšķirīgas novirzīšanas ķēdes?

Serveri, CDN un lietojumprogrammu noteikumi var izvēlēties atšķirīgus mērķus vai statusa kodus, balstoties uz pieprasījuma galvenēm, ierīces signāliem, ģeogrāfiju, autentifikāciju vai sesijas stāvokli. Salīdziniet izsekojumus kā diagnostikas paraugus; tie var neatbilst katra reāla lietotāja vai rāpuļprogrammas pieprasījumam.

RFC 9110: Vary galvene un saskaņotās atbildes

Vai novirzīšanas laikā tiek saglabāti URL vaicājuma parametri?

Nākamo URL nosaka novirzīšanas atbildes Location galvene. Serveris var saglabāt, noņemt vai pārrakstīt vaicājuma parametrus. Pārbaudītājs seko saņemtajai Location vērtībai; salīdziniet parādītos URL, lai redzētu, ko serveris faktiski atgrieza.

RFC 9110: Location atbildes galvene

Ko nozīmē brīdinājums par pāreju no HTTPS uz HTTP?

Tas nozīmē, ka izsekošanā konstatēta novirzīšana no HTTPS URL uz Location, kurā izmantots HTTP. Šī pāreja samazina nākamā pieprasījuma pārraides aizsardzību. Pārbaudiet, vai tā ir apzināta, un, ja ir droša alternatīva, mainiet novirzīšanas mērķi uz HTTPS.

RFC 9110: URI shēma un novirzīšanas semantika · Google Search Central: HTTPS un jūsu vietne

Cik novirzīšanām šis pārbaudītājs seko vienā reizē?

Pašreizējais pārbaudītājs seko līdz piecām novirzīšanām. Ja pēc piektā soļa atbilde norāda uz citu URL, izsekojums var parādīt šo adresi, to neielādējot. Atveriet to kā jaunu pārbaudi vai saīsiniet ķēdi, lai pārbaudītu galīgo atbildi.

Kā Client Hints atlasītājs ietekmē pārbaudi?

Tas pievieno atlasītās Sec-CH-* pieprasījuma galvenes, piemēram, mobilās ierīces karodziņu vai platformas vērtību, blakus izvēlētajai User-Agent virknei. Tie ir konfigurējami galveņu paraugi; tie neatdarina visu pārlūkprogrammas tīkla darbību, un serveris tos var ignorēt.

MDN: HTTP Client Hints

Kad izdzēstam URL atgriezt 404 vai 410, nevis novirzīt?

Ja noņemtajai lapai nav patiesi līdzvērtīga aizstājēja, atgrieziet 404 (Not Found) vai 410 (Gone). Novirziet tikai tad, ja ir atbilstoša aizstājējlapa; nesaistītu URL pārsūtīšana uz sākumlapu var maldināt apmeklētājus un meklētājprogrammas to var uzskatīt par mīkstu 404.

RFC 9110: 404 Not Found · RFC 9110: 410 Gone · Google Search Central: pārmeklēšanas kļūdu novēršana

Cik ilgi saglabāt novirzīšanu pēc URL pārvietošanas?

Saglabājiet novirzīšanu pēc iespējas ilgāk. Google iesaka pēc vietnes pārvietošanas novirzīšanu uzturēt vismaz vienu gadu, lai meklētājprogrammas varētu apstrādāt izmaiņas; apmeklētāji var izmantot vecās grāmatzīmes un saites arī pēc šī perioda.

Google Search Central: vietņu pārvietošana un novirzīšana

Pēc URL pārvietošanas, kas jāatjaunina papildus novirzīšanai?

Atjauniniet iekšējās saites, mērķa lapas canonical URL, hreflang anotācijas, ja tās tiek izmantotas, un XML vietnes karti, lai tās norādītu uz jauno URL. Aizstājējam jābūt atbilstošam; pēc tam pārbaudiet, vai novirzīšana atrisinās tieši un konsekventi.

Google Search Central: vietņu pārvietošana un novirzīšana