Népszerűsítsük a 301 és 302 állapotkódok közötti különbséget
A 301 Áthelyezett Állandóan kért erőforrást véglegesen új helyre helyezték át, és a jövőbeni hivatkozásoknak az ebben a válaszban visszaküldött több URI közül az egyikét kell használniuk. Ha lehetséges, a linkszerkesztő klienseknek automatikusan módosítaniuk kell a kért címet a szervertől visszaküldött címre. Ez a válasz gyorsítótározható is, hacsak nincs más módon.
A 302 Found által kért források most ideiglenesen válaszolnak egy másik URI-ből érkező kérésekre. Mivel az ilyen átirányítások ideiglenesek, az ügyfélnek továbbra is a jövőbeli kéréseket az eredeti címre kell küldenie. Ez a válasz csak akkor gyorsaváltható, ha a Cache-Control vagy Expires (Cache-Control vagy Expires) tartalmazza.
A 301-es verzió leggyakoribb módja a domain névugrások használata.
Például meglátogatjukhttp://www.baidu.comugrunk ahttps://www.baidu.comA kérés elküldése után visszaküldik a 301-es státuszkódot, majd egy helyet, amely új címet ad fel, és a böngésző ezt az új címet veszi fel.
Megjegyzés: a 301-es kérések gyorsancélozhatók, azaz az állapotkód megtekintésével a végén azt írják, hogy "from cache".
Vagy megváltoztatod a weboldalad nevét PHP-ről HTML-re, és közben egy állandó átirányítás is történik.
A 302-es út ideiglenes ugrásra szolgál
Például azok a felhasználók, akik nincsenek bejelentkezve, a felhasználói központba kerülésekor átirányítják a bejelentkezési oldalra.
Egy 404-es oldal megtekintése átirányítja a kezdőlapot.
Az Alibaba Cloud Load Balancing SLB konfigurációja a következő:
Mi http-t használunk https-re történő átirányításra, a nyilvánvaló szándék végleges, nem ideiglenesen, de itt az Alibaba Cloud megadja, amit visszaküldünkIdeiglenes átirányítás 302 státuszkód。 Ahogy az alábbiakban látható:
A Webmaster Home és Aizhan Network online tesztelt visszaküldési állapotkódja 302, és én is ezt a kódot használtam a 302-es állapotkód visszaküldéséhez.
Esettanulmány: A 302-es weboldal átirányítását a GOOGLE szabálytalan használat miatt büntették
Business.com az internet legnagyobb üzleti keresőmotorja és kategóriája, amely professzionálisan üzleti információkat nyújt, közel 190 000 weboldalt tartalmazott. Ha a Google-ben keresel a "business" kulcsszóra, a weboldal lesz az első. Azonban 2010. szeptember 5-én Business.com egy furcsa dologgal találkozott: a kezdőlapja PR-je 8-ról 0-ra változott, és a kezdőlap nem volt elérhető a Google keresőtalálatokban. Szerencsére csak a kezdőlap "elpárologtatja". Szerencsére a kezdőlap másnap visszatért a Google keresési eredményeibe, de a PR még mindig 0 volt.
Ma a Baidu webmaster platformján, az "HTTPS authentication"-on vagyok, és azt tapasztaltam, hogy egy oldal https-ellenőrzése sikertelen volt, ami éberséget váltott ki.
Funkcióban nincs különbség a 302 és a 301 között, de nagyon nagy hatással kellene lennie a SEO-ra, vagy két különböző státuszkódra osztják.
Mivel ez az oldal intelligens DNS-felbontást használ, különböző régiókhoz különböző címeket állíthatsz be, ez az oldal csak a belföldi és külföldi, belföldi Alibaba Cloud, külföldi Amazon AWS megkülönböztetésével rendelkezik, ahogy az alábbi ábrán látható:
A webmaster otthoni pingtesztjét használva azt találtam, hogy 29 független IP van, bár a felbontási címek eltérnek, de mindegyik átirányítja az URL-t HTTP-re https-re.
Teszteltem az Alibaba Cloud SLB-t és az Amazon CDN-t kóddal, és a HTTP redirect https eredménye a következő:
Az egyetlen különbség a kérések között, hogy az Amazon tesztelésekor egy proxyn keresztül kell kérelmezni, hogy külföldön keresztül lehessen elemezni és csatolni a kódot:
A tesztelés előtt egy jegyet beküldtek az Alibaba Cloudhoz, ahogy az alábbi ábrán látható:
Eddig azonban nem oldódott meg, és az okát sem magyarázták el.
(Vége)
|
Közzétéve 2019. 06. 20. 10:43:29
|
|
|
|
Háziúr|
Közzétéve 2019. 06. 21. 10:19:32
|
