logo
GeekFormat

Pemeriksa Rantai Pengalihan

Pemeriksa rantai pengalihan

Periksa 301/302/307/308 per hop, identifikasi loop, pengalihan lintas domain, dan masalah penurunan tingkat HTTPS.

Ketika Anda memasukkan alamat situs web di browser, di balik layar mungkin terjadi serangkaian pengalihan yang tidak Anda lihat: HTTP→HTTPS, non-www→www, domain lama→domain baru, tautan pendek→tautan panjang... Setiap pengalihan menghabiskan waktu, memengaruhi peringkat SEO, bahkan mungkin diam-diam menurunkan HTTPS menjadi HTTP. Pemeriksa rantai pengalihan melacak jalur pengalihan lengkap URL dari perspektif server hop demi hop, menampilkan kode status (301/302/303/307/308), header Location dan alamat target setiap hop, secara otomatis mendeteksi masalah seperti pengalihan loop, pengalihan lintas domain, penurunan HTTPS dan pemutusan rantai, membantu Anda menemukan bahaya pengalihan tersembunyi dalam migrasi domain, penerapan HTTPS dan optimasi SEO.

Rekomendasi Terkait

Analisis HSTS

Pemeriksa Sertifikat SSL

Pencarian Kode Status HTTP

Pemeriksa Header HTTP

URL Parser

Site Network Audit

Kasus penggunaan

  • Verifikasi migrasi domain: setelah situs web beralih dari domain lama ke domain baru, konfirmasi hop demi hop apakah URL lama benar-benar dialihkan secara permanen 301 ke alamat baru, menghindari hilangnya lalu lintas yang disebabkan oleh pengalihan berantai dan kode status salah
  • Pemeriksaan penerapan HTTPS: konfirmasi apakah rantai pengalihan HTTP→HTTPS adalah 301 satu hop, periksa apakah ada loop penurunan HTTP→HTTPS→HTTP, verifikasi apakah konfigurasi HSTS berlaku
  • Deteksi halaman tujuan tautan pendek: lacak jalur pengalihan lengkap tautan pendek (t.cn/bit.ly dll.), tautan UTM pemasaran atau tautan berbagi sosial, konfirmasi apakah halaman tujuan akhir adalah alamat yang diharapkan, selidiki apakah pengalihan perantara menyisipkan parameter pelacakan atau pengalihan berbahaya
  • Normalisasi www dan non-www: periksa apakah domain www dan domain root benar-benar saling mengalihkan 301 ke versi standar, menghindari masalah konten duplikat SEO yang disebabkan oleh operasi ganda
  • Pemecahan masalah pengalihan loop: ketika browser melaporkan error ERR_TOO_MANY_REDIRECTS, gunakan alat untuk menentukan secara akurat node tempat loop terjadi, bedakan apakah itu kesalahan konfigurasi Nginx/Apache, konflik aturan CDN atau loop yang disebabkan oleh plugin WordPress
  • Debugging CDN dan proxy terbalik: selidiki konflik pengalihan dalam arsitektur berlapis seperti Cloudflare, CDN Alibaba Cloud, proxy terbalik Nginx, identifikasi masalah pengalihan timbal balik antara aturan CDN dan aturan sumber
  • Audit kesehatan SEO: periksa secara teratur panjang rantai pengalihan halaman inti situs web, evaluasi dampak pengalihan multi-hop pada efisiensi transfer PageRank, optimalkan rantai pengalihan yang terlalu panjang
  • Evaluasi risiko pengalihan lintas domain: deteksi skenario yang melibatkan pengalihan lintas domain seperti pengalihan login, panggilan balik OAuth, pengalihan pembayaran, konfirmasi apakah Cookie dan Session diteruskan dengan benar selama proses lintas domain
  • Verifikasi load balancing dan multi-aktif: periksa strategi pengalihan dalam skenario pusat data multi-aktif, load balancing global GSLB, konfirmasi pengguna di berbagai wilayah dialihkan dengan benar ke node terdekat yang tersedia
  • Debugging cache pengalihan: verifikasi pengaturan header Cache-Control dan Expires untuk pengalihan permanen 301 dan pengalihan sementara 302, selidiki akses abnormal yang disebabkan oleh browser yang menyimpan aturan pengalihan lama di cache

Fitur

  • Pelacakan lengkap hop demi hop: mengikuti setiap pengalihan dari perspektif server, menampilkan URL asli, kode status setiap hop, teks status, header respons Location dan jalur pengalihan lengkap secara berurutan, tidak melewatkan node perantara mana pun
  • Dukungan kode status lengkap: mencakup lima kode status pengalihan standar 301 Moved Permanently, 302 Found, 303 See Other, 307 Temporary Redirect, 308 Permanent Redirect, dan menandai perbedaan semantik setiap kode status
  • Deteksi loop pengalihan: secara otomatis mengenali pola pengalihan loop seperti A→B→A, menandai posisi node spesifik tempat loop terjadi dan panjang loop, menentukan akar penyebab error ERR_TOO_MANY_REDIRECTS secara akurat
  • Pengenalan pengalihan lintas domain: mendeteksi perubahan Host/Domain hop demi hop, menandai node pengalihan lintas domain, mengingatkan risiko kehilangan Cookie dan masalah preflight CORS
  • Peringatan penurunan HTTPS: menghitung jumlah node HTTP (non-HTTPS) dalam rantai pengalihan, menandai pengalihan penurunan HTTPS→HTTP, mengingatkan risiko keamanan dan dampak negatif SEO
  • Perlindungan pemutusan rantai: mengatur batas kedalaman pengalihan maksimum (20 hop), ketika rantai terlalu panjang secara otomatis memutus dan menandai, menghindari waktu habis permintaan yang disebabkan oleh pelacakan tanpa batas
  • Ringkasan statistik pengalihan: menyediakan ikhtisar metrik kunci seperti total jumlah pengalihan, URL tujuan akhir, apakah terdeteksi loop, apakah lintas domain, jumlah node HTTP, apakah rantai terputus
  • Evaluasi dampak SEO: secara otomatis mengevaluasi tingkat dampak pada transfer PageRank dan Core Web Vitals berdasarkan jumlah pengalihan, jenis kode status, cakupan HTTPS
  • URL pengujian preset: dilengkapi dengan alamat pengujian umum seperti geekformat.com, github.com, httpbin.org/redirect, layanan tautan pendek, isi sekali klik untuk pengalaman cepat
  • Riwayat kueri terbaru: secara otomatis menyimpan 8 catatan kueri terbaru (disimpan secara lokal di browser), mendukung deteksi berulang satu klik, memudahkan perbandingan efek sebelum dan sesudah perbaikan
  • Kartu saran diagnostik:untuk masalah seperti pengalihan loop, pengalihan lintas domain, penurunan HTTP, rantai terlalu panjang yang terdeteksi, berikan saran perbaikan spesifik dan panduan praktik terbaik
  • Dua tampilan detail dan ringkasan: secara default menampilkan kartu ringkasan rantai, perluas dapat melihat URL permintaan lengkap setiap hop, status respons, target Location dan penanda HTTPS

Cara Penggunaan

  1. Isi URL yang perlu dideteksi di kolom input (harus menyertakan awalan protokol http:// atau https://), atau klik tombol URL preset (geekformat.com/github.com/httpbin.org/redirect dll.) untuk mengisi cepat alamat pengujian
  2. Klik tombol«lacak rantai pengalihan», alat akan memulai permintaan dari sisi server, mengikuti header respons Location hop demi hop untuk mencatat informasi lengkap setiap pengalihan
  3. Lihat kartu ringkasan pengalihan di bagian atas: total jumlah pengalihan, URL tujuan akhir, apakah terdeteksi loop, apakah ada pengalihan lintas domain, jumlah node HTTP, apakah rantai terputus karena terlalu banyak hop
  4. Lihat informasi rinci setiap hop di area visualisasi rantai: nomor urut, URL permintaan, kode status respons dan teks deskripsi, URL target di header respons Location, penanda keamanan HTTPS
  5. Perhatikan kartu peringatan diagnostik: jika terdeteksi pengalihan loop (merah), penurunan HTTPS (oranye), pengalihan lintas domain (kuning) atau rantai terlalu panjang (kuning), alat akan menyorot dan memberikan penjelasan masalah di posisi yang sesuai
  6. Gunakan area evaluasi dampak SEO untuk melihat tingkat dampak rantai pengalihan saat ini pada efisiensi transfer PageRank, kecepatan pemuatan halaman dan Core Web Vitals serta saran optimasi
  7. Setelah deteksi selesai, Anda dapat mengklik catatan apa pun dari riwayat kueri terbaru untuk mendeteksi ulang dengan cepat, membandingkan perubahan rantai pengalihan sebelum dan sesudah perbaikan; juga dapat mengambil tangkapan layar hasil deteksi atau menyalin teks untuk komunikasi tim dan catatan tiket

Pertanyaan Umum

Berapa hop rantai pengalihan dianggap terlalu banyak? Apa dampaknya terhadap SEO?

Google secara resmi merekomendasikan untuk mengendalikan rantai pengalihan pada satu hop, maksimal tidak lebih dari 3 hop. Menurut dokumentasi Google Search Central, Googlebot biasanya mengikuti maksimal 5 hop pengalihan lalu berhenti melacak, tetapi ini tidak berarti 5 hop aman. Setiap pengalihan akanmenambah latensi pemuatan halaman (100-300ms/hop), membuang anggaran perayapan, dan mungkin menyebabkan redaman transfer PageRank. 1 hophampir tidak ada dampak SEO; 2 hop dapat diterima tetapi disarankan dioptimalkan; lebih dari 3 hop mulai memengaruhi LCP dan efisiensi perayapan; lebih dari 5 hop ada risiko halaman tidak diindeks. Gunakan alat ini untuk mendeteksi rantai pengalihan halaman inti Anda, pastikan URL kunci (beranda, halaman produk inti, halaman dalam lalu lintas tinggi) semuanya satu hoplangsung menuju.

Apakah pengalihan 301 akan merusak SEO? Bisakah PageRank ditransfer sepenuhnya?

Pengalihan permanen 301 yang digunakan dengan benar tidak akan merusak SEO. Gary Illyes dan John Mueller dari Google telah mengonfirmasi berkali-kali bahwa pengalihan 301 dari migrasi domain HTTP ke HTTPS, serta migrasi permanen halaman dalam domain yang sama, transfer PageRank adalah 100%, tidak ada kerugian. Tetapi perlu diperhatikan: 1) Pengalihan sementara 302 tidak mentransfer PageRank (atau efisiensi transfer sangat rendah); 2) Jika ada noindex, blokir robots.txt, kesalahan 4xx/5xx dalam rantai pengalihan, transfer bobot akan terputus; 3) Setelah migrasi lintas domain 301, perlu mengirimkan pemberitahuan perubahan domain di Google Search Console untuk mempercepat migrasi indeks; 4) 301 akan disimpan dalam cache jangka panjang oleh browser, tahap pengujian disarankanpertama gunakan 302 untuk verifikasi lalu ubah menjadi 301.

Mengapa situs web saya secara otomatis dialihkan ke HTTP bukan HTTPS? Bagaimana cara memperbaikinya?

Pengalihan penurunan HTTPS→HTTP biasanya disebabkan oleh alasan berikut: 1) Proxy terbalik/CDN kembali ke sumber dengan HTTP, Nginx/Apache sumber menggunakan variabel $scheme untuk mendapatkan protokolyang didapatkan adalah httpbukan melainkan https; 2) Kode lapisan aplikasi hardcode URL dengan awalan http://; 3) Home URL atau Site URL dari CMS seperti WordPress diatur sebagai http; 4) Ada sisa aturan HTTP lama di .htaccess; 5) Pengaturan SSL/TLS layanan pihak ketiga (CDN/WAF) adalah mode«fleksibel»bukan mode«ketat». Langkah perbaikan: pertama gunakan alat ini untuk menentukan di hop mana penurunan terjadi; atur SSL CDN menjadi mode«Full (strict)»; di Nginx tangani header X-Forwarded-Proto dengan benar; WordPress tambahkan $_SERVER['HTTPS']='on'; di wp-config.php; terapkan header respons HSTS untuk mencegah penurunan tingkat browser; periksa semua aturan pengalihan pastikan targetnya adalah https://.

Bagaimana cara memperbaiki loop pengalihan (ERR_TOO_MANY_REDIRECTS) di Nginx?

Lebih dari 90% loop pengalihan Nginx disebabkan oleh tidak ditanganinya header X-Forwarded-Proto dengan benar dalam skenario proxy terbalik/CDN. Metode perbaikan: 1) Pastikan CDN/load balancing mengirimkan header X-Forwarded-Proto ke backend: proxy_set_header X-Forwarded-Proto $scheme; 2) Saat Nginx menentukan gunakan X-Forwarded-Proto daripada $scheme untuk memutuskan apakah akan dialihkan ke HTTPS. Direkomendasikan menggunakan blok map: map $http_x_forwarded_proto $is_https { default 0; "https" 1; } server { listen 80; if ($is_https = 0) { return 301 https://$host$request_uri; } } 3) Hindari menulis aturan rewrite di blok server yang cocok dengan dirinya sendiri tanpa batas; 4) Pengalihan www dan non-www hanya dikonfigurasi satu arah di satu blok server, jangan dikonfigurasi dua arah.

Bagaimana cara memperbaiki loop pengalihan di Apache .htaccess?

Loop .htaccess Apache biasanya disebabkan oleh konflik aturan RewriteRule. Langkah perbaikan: 1) Pastikan RewriteEngine On hanya muncul sekali; 2) Aturan pengalihan HTTP→HTTPS diletakkan di paling depan semua aturan, gunakan: RewriteCond %{HTTPS} off RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]; 3) Aturan www/non-www diletakkan setelah pengalihan HTTPS, dan hanya melakukan pengalihan satu arah (non-www→www atau sebaliknya); 4) Perhatikan arti tanda [L] adalah«last»tetapi jika aturan memodifikasi URL akan cocok ulang dari yang pertama, mungkin menyebabkan loop, aturan kompleks pertimbangkan menggunakan tanda [END] (Apache 2.3.9+); 5) Periksa apakah ada beberapa file .htaccess (.htaccess di subdirektori juga akan berlaku); 6) Sementara ubah R=301 menjadi R=302 untuk pengujian, menghindari gangguan cache browser.

Bagaimana cara memperbaiki loop pengalihan yang disebabkan oleh Cloudflare?

Penyebab paling umum dari loop Cloudflare adalah kesalahan pengaturan mode enkripsi SSL/TLS atau konflik aturan halaman: 1) Ubah mode SSL/TLS Cloudflare dari«Flexible»menjadi«Full»atau«Full (strict)»— dalam mode Flexible Cloudflare ke sumber menggunakan HTTP, jika sumber dikonfigurasi pengalihan paksa HTTPSmaka akan loop; 2) Periksa apakah«Always Use HTTPS»di«Edge Certificates»Cloudflare diaktifkan, jangansekaligus mengonfigurasi pengalihan HTTPS berulang di sumber dan Cloudflare; 3) Periksa apakah ada aturan penerusan yang saling bertentangan di Page Rules; 4) Jika menggunakan plugin Cloudflare WordPress, jangansekaligus mengonfigurasi pengalihan HTTPS di plugin dan Cloudflare; 5) Periksa apakah aturan Forwarding URL menunjuk ke alamat yangjuga dialihkan oleh Cloudflare.

Apa perbedaan pengalihan 301, 302, 307, 308? Mana yang harus dipilih?

Perbedaan inti ada di dua dimensi«apakah permanen»dan«apakah mempertahankan metode permintaan». Panduan pilihan cepat: untuk permintaan GET halaman web biasa (pengguna mengakses halaman) — migrasi permanen gunakan 301 (migrasi domain, peralihan HTTPS, perubahan permanen URL), pengalihan sementara gunakan 302 (pengujian A/B, pemeliharaan sementara, pengalihan login); untuk permintaan POST/PUT/DELETE (panggilan API, pengiriman formulir) — migrasi permanen gunakan 308, pengalihan sementara gunakan 307, memastikan metode dan data permintaan tidak hilang; 303 khusus digunakan untuk dialihkan ke halaman hasil setelah pengiriman formulir POST (paksa GET, mencegah pengiriman ulang). Ingat sederhana: 301=permanen aman GET, 302=sementara aman GET, 307=sementara semua metode, 308=permanen semua metode, 303=setelah POST lompat ke halaman hasil.

Apakah browser akan menyimpan cache pengalihan 301 secara permanen? Bagaimana cara menghapus cache 301?

Pengalihan permanen 301 secara default akan disimpan dalam cache browser, tetapi waktu cache tergantung pada pengaturan Cache-Control dan Expires di header respons. Jika tidak secara eksplisit menentukan header cache, perilaku cache default browser berbeda: Chrome biasanya menyimpan cache pengalihan 301 selama berminggu-minggu hingga berbulan-bulan (bahkan mungkin masih di-cache setelah browser restart); Firefox default menyimpan cache 301 tetapi mungkin memverifikasi ulang setelah browser restart; strategi cache Safari relatif konservatif. Metode menghapus cache 301: 1) Chrome: Pengaturan→Privasi dan keamanan→Hapus data penjelajahan→rentang waktu pilih«semua waktu»→centang«gambar dan file yang di-cache»→hapus data; 2) Saat alat pengembang (F12) dibuka centang«Disable cache»di panel Network; 3) Tambahkan parameter kueri tidak berarti di belakang URL (?nocache=1) untuk melewati cache; 4) Pengembang Chrome dapat Flush sockets di chrome://net-internals/#sockets, atau Clear host cache di chrome://net-internals/#dns; 5) Tahap pengujian gunakan pengalihan sementara 302 menggantikan 301, setelah dikonfirmasi benar lalu ubah menjadi 301.

Apa perbedaan antara Meta Refresh dan pengalihan HTTP? Mana yang lebih baik?

Meta Refresh adalah pengalihan yang diimplementasikan oleh tag <meta> dalam dokumen HTML (seperti <meta http-equiv="refresh" content="0;url=https://example.com/new">), dieksekusi setelah browser mengurai HTML, sedangkan pengalihan HTTP melalui kode status 3xx di tingkat protokol HTTP diinstruksikan langsung oleh server untuk dialihkan. Perbandingan perbedaan: 1) Kecepatan: pengalihan HTTP mulai mengalihkan saat menerima header respons, Meta Refresh perlu menunggu HTML diunduh dan diurai baru mengalihkan, kecepatan lebih lambat; 2) SEO: Google biasanya dapat mengenali Meta Refresh dan mentransfer bobot (jika delay=0), tetapiresmi merekomendasikan penggunaan pengalihan HTTP 301/302, karena Meta Refresh adalah pengalihan sisi klien, sinyal tidak sejelas pengalihan sisi server; 3)latensi: Meta Refresh dapat mengatur waktulatensi (seperti content="5;url=..." berarti dialihkan setelah 5 detik), tetapi pengalihan HTTP tidak memiliki fungsi ini; 4) Aksesibilitas: W3C tidak merekomendasikan penggunaan Meta Refresh,karena teknologi bantu seperti pembaca layar menangani dengan buruk, juga mungkin membuat pengguna bingung; 5) Tombol kembali: Meta Refresh di beberapa browsermungkin merusak perilaku tombol kembali. Kesimpulan: selaluutamakan gunakan pengalihan HTTP 301/302/307/308, hindari penggunaan Meta Refresh, kecuali Anda tidak dapat mengontrol konfigurasi server (seperti di-host di platform halaman statis tidak dapat mengonfigurasi aturan sisi server).

Apakah pengalihan akan memengaruhi LCP dalam Core Web Vitals?

Ya, dan dampaknya sangat besar. Pengalihan terjadi sebelum browser mendapatkan dokumen HTML, ini berarti setiap pengalihan akan menunda waktu mulai pengunduhan dokumen HTML. Titik awal perhitungan LCP (Largest Contentful Paint) adalah waktu mulai navigasi, dan browser harus mendapatkan HTML akhirbaru bisa mulai mengurai DOM, memuat CSS dan merender elemen LCP. Diasumsikan setiap pengalihanmenambah latensi jaringan 150ms (DNS+TCP+TLS+respons permintaan), 3 hop pengalihan akan membuat LCP setidaknyamenambah 450ms, ini cukup untuk mendorong LCP dari«baik»(≤2,5s) ke interval«perlu ditingkatkan»(2,5-4s). Dokumentasi Core Web Vitals Google secara eksplisit mencantumkan«hindari pengalihan berulang kali»sebagai salah satu saran kunci untuk mengoptimalkan LCP. Praktik terbaik: pastikan halaman inti nol pengalihan (tautan langsung ke URL akhir), pengalihanperlu seperti HTTP→HTTPS dan normalisasi www dikendalikan pada satu hop.

Bagaimana cara memeriksa ke mana tautan pendek akhirnya dialihkan?

Tautan pendek (t.cn, bit.ly, dwz.cn, url.cn dll.) biasanya mencapai URL akhir melalui 1-3 hop pengalihan,dalamantara mungkintermasuk parameter pelacakan UTM, pengalihan deteksi perangkat, pengalihan geografis dll. Menggunakan alat ini dapat: 1) Masukkan URL tautan pendek (termasuk http:// atau https://); 2) Klik lacak untuk melihat jalur lengkap setiap hop; 3) Lihat URL tujuan akhir, jumlah pengalihan, jenis kode status; 4) Periksa apakah ada penurunan HTTP atau pengalihan lintas domain abnormal di pengalihan perantara. Catatan: sebagian tautan pendekberdasarkan User-Agent atau wilayah IP mengembalikan target akhir yang berbeda, alat ini menggunakan permintaan IP server, mungkin sedikit berbeda dengan hasil yang dilihat browser Anda langsung (terutama layanan tautan pendek luar negeri). Untuk tautan pendek url.cn WeChat/QQ, mungkin perlu dalam lingkungan WeChatbaru bisa benar-benar dialihkan ke halaman target.

Pengalihan paksa HTTPS gunakan 301 atau 302? Perlu menambahkan HSTS?

Pengalihan paksa HTTPS harus menggunakan pengalihan permanen 301, karena dari HTTP ke HTTPS adalah perubahan permanen, bukan pengalihan sementara. Setelah mengonfigurasi 301 juga harus menerapkan header respons HSTS. Skema paksa HTTPS lengkap dibagi menjadi tiga tahap: 1) Tahap pertama (masa uji): pertama konfigurasikan pengalihan 301 HTTP→HTTPS, tidak aktifkan HSTS, amati 1-2 minggu pastikan semua sumber daya dan subdomain berfungsi normal; 2) Tahap kedua (masa stabil): tambahkan header respons Strict-Transport-Security, awal max-age diatur ke waktu yang lebih pendek (seperti max-age=300 yaitu 5 menit), secara bertahapmenambah hingga max-age=31536000 (1 tahun); 3) Tahap ketiga (Preload): setelah mengonfirmasi semua subdomain mendukung HTTPS, tambahkan includeSubDomains dan instruksi preload, lalu kirimkan ke HSTS Preload List (hstspreload.org),membuat browser memiliki strategi HSTS domain Anda secara bawaan, menghilangkan jendela HTTP akses pertama. Perhatikan bahwa setelah HSTS di-cache di browser, sebelum max-age berakhir tidak dapat dibatalkan melalui sisi server, jadi pastikan untuk menguji sepenuhnya.

Apa perbedaan antara pengalihan window.location JavaScript dan pengalihan HTTP?

Pengalihan JS (seperti window.location.href='https://example.com') dan pengalihan HTTP 3xxada perbedaan esensial: 1) Tingkat eksekusi: pengalihan HTTP di tingkat protokololeh server mengembalikan kode status, browser segera mengalihkan saat menerima header respons; pengalihan JS perlu HTML diunduh, JS diurai dan dieksekusi baru mengalihkan, kecepatan lebih lambat; 2) SEO: crawler mesin pencari dapat mengenali dan mengikuti pengalihan HTTP 301/302 untuk mentransfer bobot, tetapi efek SEO pengalihan JS tergantung pada apakah crawler mengeksekusi JS dan waktu eksekusi, sinyal lemah dan tidak stabil; 3) Tahapan menengah: sebelum pengalihan JS halaman sudahmulai dimuat (mungkinmuncul layar putih atau konten sebagian berkedip), pengalihan HTTP pengguna langsungmencapai halaman target, pengalaman lebih lancar; 4) Keandalan: JS mungkin diblokir oleh browser, plugin atau Content Security Policy, pengalihan HTTP ditangani oleh inti browser, keandalan tertinggi. Kesimpulan: ketika perlu mengalihkan URL secara permanen/sementara, selalu gunakan pengalihan HTTP 301/302 sisi server, pengalihan JS hanya digunakan untuk navigasi halaman dalam logika interaksi (seperti pengalihan setelah verifikasi formulir, pengalihan klik tombol dll.).

Apakah rantai pengalihan akanmenyebabkan hasil pengujian A/B tidak akurat?

Ya, rantai pengalihan memiliki dampakbanyak aspek pada pengujian A/B: 1) Jika pengujian A/B diimplementasikan melalui pengalihan (50% pengguna 302 ke versi A, 50% ke versi B),latensi pengalihan akan membuat kecepatan pemuatan halaman kedua versi berbeda, kecepatan itu sendiri mungkin memengaruhi tingkat konversi (versi yang cepat secara alami tingkat konversi tinggi),menyebabkan bias pengujian; 2) Selama proses pengalihan mungkin kehilangan parameter UTM atau tanda sumber,menyebabkan data atribusi tidak akurat; 3) Jika pengalihan 302 berlangsung terlalu lama, Google mungkin menilainya sendiri sebagai 301 mentransfer bobot, memengaruhi SEO halaman pengujian; 4) Jikatertentu hop dalam pengalihan multi-hop mengatur Cookie, mungkin memengaruhi logika pengelompokan pengguna. Disarankan pengujian A/B menggunakan pembagian render sisi server atau pembagian JS sisi klien (seperti Google Optimize, Optimizely), menghindari penggunaan pengalihan untuk pembagian. Jika harus menggunakan pengalihan (seperti menguji jalur URL yangsepenuhnya berbeda), gunakan 302 (bukan 301) dan pastikan satu hoplangsung menuju, setelah pengujian selesai segera hapus pengalihan.

Bagaimana cara memeriksa rantai pengalihan seluruh situs web secara batch?

Pemeriksaan batch rantai pengalihan situs web perlu dikombinasikan dengan alat crawler: 1) Gunakan alat crawler seperti Screaming Frog SEO Spider untuk merayapi seluruh situs web, lihat semua URL pengalihan dan panjang rantai dalam laporan Redirect Chains; 2) Gunakan fungsi audit situs dari alat SEO seperti Ahrefs, Semrush atau Sitebulb, mereka akan secara otomatis mendeteksi rantai pengalihan dan loop; 3) Untuk daftar halaman inti, dapat menulis skrip memanggil API backend alat ini untuk deteksi batch; 4) Lihatpemberitahuan«kesalahan pengalihan»dan«rantai pengalihan terlalu panjang»dalam laporan«indeks halaman»Google Search Console; 5) Gunakan audit Lighthouse Chrome DevTools, bagian Performance akan menandai masalah pengalihan. Disarankan untuk memeriksa terlebih dahulu: beranda, halaman navigasi utama, halaman arahan lalu lintas tinggi, halaman yang baru saja dimigrated/direvisi, semua URL HTTP setelah peralihan HTTPS, semua URL di bawah domain lama.

术语表

Pengalihan (Redirect)
Mekanisme di mana server mengembalikan kode status 3xx dan header respons Location, menginstruksikan klien untuk secara otomatis mengakses URL lain. Pengalihan biasanya transparan bagi pengguna, browser akan secara otomatis mengikuti pengalihan.
301 Moved Permanently
Kode status pengalihan permanen. Menunjukkan sumber daya telah berpindah secara permanen ke lokasi baru, mesin pencari akan mentransfer PageRank URL lama ke URL baru, browser akan menyimpan pengalihan ini dalam cache jangka panjang. Disarankan untuk skenario permintaan GET seperti migrasi domain, peralihan HTTPS, perubahan permanen lainnya.
302 Found
Kode status pengalihan sementara (dulu disebut Moved Temporarily). Menunjukkan sumber daya untuk sementara berada di lokasi lain, mesin pencari tidak akan mentransfer bobot, browser tidak menyimpan cache jangka panjang. Catatan: sebagian besar browser akan mengubah permintaan POST menjadi GET untuk dialihkan setelah menerima 302, mungkin kehilangan badan permintaan.
303 See Other
Kode status lihat lokasi lain. Biasanya digunakan untuk pengalihan halaman hasil setelah pengiriman formulir POST, secara eksplisit meminta klien meminta URL baru dengan metode GET, mencegah pengiriman ulang formulir. Respons 303 tidak boleh di-cache.
307 Temporary Redirect
Kode status pengalihan sementara (diperkenalkan HTTP/1.1). Semantik sama dengan 302, tetapi secara tegas mensyaratkan mempertahankan metode permintaan dan badan permintaan — permintaan POST setelah menerima 307 harus tetap meminta URL baru dengan metode POST, tidak akan kehilangan data formulir. Cocok untuk pengalihan sementara skenario API dan formulir.
308 Permanent Redirect
Kode status pengalihan permanen (didefinisikan RFC 7538). Semantik sama dengan 301, tetapi secara tegas mensyaratkan mempertahankan metode permintaan dan badan permintaan — permintaan POST setelah menerima 308 masih dialihkan dengan metode POST. Adalah versi«aman metode»dari 301, browser modern telah mendukung sepenuhnya.
Header Location
Field header respons HTTP, digunakan untuk menentukan URL target dalam respons pengalihan 3xx. Bisa berupa URL absolut (direkomendasikan) atau URL relatif, klien setelah menerima secara otomatis mengirimkan permintaan baru ke URL tersebut. Karakter non-ASCII di header Location harus dilakukan pengkodean URL.
Rantai Pengalihan (Redirect Chain)
Serangkaian pengalihan berkelanjutan yang dialami dari URL awal ke URL tujuan akhir. Misalnya A→B→C→D membentuk rantai pengalihan 3 hop. Rantai pengalihan yang terlalu panjang akan memperlambat kecepatan pemuatan, mengurangi bobot SEO, disarankan dikendalikan pada satu hop, maksimal tidak lebih dari 3 hop.
Loop Pengalihan (Redirect Loop)
URL tertentu muncul berulang dalam rantai pengalihan, membentuk loop pengalihan tanpa batas (seperti A→B→A). Browser setelah mencapai jumlah pengalihan maksimum (biasanya 20 kali) akan menampilkan error ERR_TOO_MANY_REDIRECTS. Penyebab umum termasuk HTTP↔HTTPS saling mengalihkan, www↔non-www saling mengalihkan dan kehilangan protokol proxy terbalik.
Migrasi Domain (Domain Migration)
Proses di mana situs web beralih secara permanen dari satu domain ke domain lain, seperti pergantian nama domain merek, akuisisi dan merger perusahaan. Saat migrasi perlu mengalihkan semua URL domain lama ke halaman yang sesuai di domain baru melalui 301 permanen, dan mengirimkan pemberitahuan perubahan domain di Google Search Console.
Normalisasi URL (URL Canonicalization)
Proses menyatukan beberapa varian URL dari konten yang sama (www/non-www, dengan/tanpa garis miring di akhir, HTTP/HTTPS, perbedaan huruf besar-kecil) ke URL standar tunggal, biasanya diimplementasikan melalui pengalihan 301. Normalisasi menghindari masalah konten duplikat, memusatkan bobot SEO.
Pengalihan Paksa HTTPS
Konfigurasi yang mengalihkan semua permintaan HTTP (port 80) ke HTTPS (port 443) melalui 301, adalah langkah yang diperlukan setelah menerapkan sertifikat SSL/TLS. Biasanya digunakan bersama dengan header respons HSTS, menghilangkan jendela teks HTTP akses pertama.
HSTS
HTTP Strict Transport Security, melalui header respons Strict-Transport-Security memberi tahu browser bahwa dalam waktu yang ditentukan hanya dapat mengakses domain ini melalui HTTPS, browser secara internal secara otomatis meningkatkan HTTP ke HTTPS, tidak perlu pengalihan server. Efektif mempertahankan serangan SSL stripping.
Tautan Pendek (Short URL)
Layanan yang mengubah URL panjang menjadi URL pendek (seperti bit.ly, t.cn), saat diakses dialihkan ke URL asli melalui pengalihan 301/302. Di balik tautan pendek sering kali menyembunyikan rantai pengalihan multi-hop, mungkin mengandung parameter pelacakan atau dialihkan ke target berbeda dalam kondisi tertentu.
PageRank
Algoritma peringkat halaman web yang ditemukan oleh pendiri Google Larry Page dan Sergey Brin, mengevaluasi otoritas halaman melalui hubungan tautan. Pengalihan permanen 301 akan mentransfer PageRank URL lama ke URL baru, sedangkan pengalihan sementara 302 biasanya tidak mentransfer atau sangat sedikit mentransfer.
Core Web Vitals
Indikator pengalaman web inti yang didefinisikan Google, termasuk LCP (Largest Contentful Paint, mengukur kinerja pemuatan, standar baik ≤2,5s), FID/INP (responsivitas interaksi, standar baik ≤100ms/200ms) dan CLS (stabilitas visual, standar baik ≤0,1). Rantai pengalihan akan menunda pengunduhan HTML, langsung memperburuk indikator LCP.
Pengalihan Lintas Domain (Cross-origin Redirect)
URL target pengalihan berbeda dengan domain URL asli (termasuk domain yang benar-benar berbeda atau subdomain berbeda). Pengalihan lintas domain dibatasi oleh kebijakan same-origin, mungkin menyebabkan Cookie tidak dikirim, Cookie pihak ketiga diblokir, preflight CORS gagal dan masalah lainnya.
Pemutusan Rantai (Chain Truncation)
Ketika jumlah hop rantai pengalihan melebihi batas kedalaman maksimum yang ditetapkan oleh alat atau browser (alat ini 20 hop, Chrome 20 hop), pelacak berhenti mengikuti pengalihan berikutnya dan menandai rantai terputus. Pemutusan rantai biasanya mengindikasikan adanya loop tanpa batas atau konfigurasi pengalihan yang luar biasa rumit.

Tabel Perbandingan Lengkap Kode Status Pengalihan HTTP

301Moved PermanentlyYa (permanen)Mungkin berubah (POST→GET)Migrasi domain, peralihan HTTPS, normalisasi www/non-www, perubahan permanen URL
302FoundTidak (sementara)Mungkin berubah (POST→GET)Halaman pemeliharaan sementara, pengalihan login, pengujian A/B, halaman promosi jangka pendek
303See OtherTidak (sementara)Ya (paksa GET)Dialihkan ke halaman hasil setelah pengiriman formulir POST, mencegah pengiriman ulang
307Temporary RedirectTidak (sementara)Tidak (metode asli dipertahankan ketat)Pengalihan sementara API, pengalihan sementara yang perlu menyimpan data POST
308Permanent RedirectYa (permanen)Tidak (metode asli dipertahankan ketat)Migrasi permanen RESTful API, pengalihan permanen yang perlu mempertahankan metode PUT/DELETE

Tabel Perbandingan Dampak Rantai Pengalihan terhadap SEO

0 hop (langsung sampai)Tidak berdampak, kondisi terbaikTidak adalatensi tambahanPertahankankondisi saat ini, tautan internal langsung menunjuk ke URL akhir
1 hopPageRank ditransfer normal, dampak SEO dapat diabaikanMenambahlatensi sekitar 100-300ms (satu putaran)Dapat diterima, jumlah hop umum untuk HTTP→HTTPS dan normalisasi domain
2 hopTransfer bobot mungkin sedikit berkurang, crawler dapat melacaknormalMenambahlatensi sekitar 200-600msDisarankan dioptimalkan menjadi satu hop, periksa apakah tautan internal menunjuk ke URL pengalihan perantara
3 hopEfisiensi transfer bobot menurun, sebagian crawler mungkin menyerah melacakMenambahlatensi sekitar 300-900ms, LCP mungkin terpengaruhHarus dioptimalkan, gabungkan aturan pengalihan langsung ke URL akhir
4-5 hopPageRankjelas berkurang, indeksasi mungkin terpengaruh, pemborosan anggaran perayapanMenambahlatensi 500ms-1,5s, LCP kemungkinan besar melebihi standarPerbaiki segera, periksa tumpang tindih pengalihan multi-lapisan CDN/sumber/aplikasi
Lebih dari 6 hopRisiko serius, mesin pencari mungkin berhenti melacak menyebabkan halaman keluar dari indekslatensi lebih dari 1 detik, pengalaman pengguna sangat burukSelidiki segera loop atau kesalahan konfigurasi, susun ulang aturan pengalihan
Loop (ERR_TOO_MANY_REDIRECTS)Halamansepenuhnya tidak dapat diakses, mesin pencari akan menghapusnya dari indeksHalaman tidak dapat dimuat, browser menampilkan errorPerbaikan prioritas tertinggi, gunakan alat ini untuk menentukan node loop

Kesalahan Konfigurasi Pengalihan Umum dan Solusi Perbaikan

Error loop ERR_TOO_MANY_REDIRECTS, HTTP↔HTTPS berulang kali dialihkanCDN/load balancing kembali ke sumber dengan HTTP, sumber tidak menangani header X-Forwarded-Proto dengan benar, selalu dialihkan ke HTTPSTambahkan dalam konfigurasi Nginx: set $forwarded_scheme $http_x_forwarded_proto; if ($forwarded_scheme != "https") { return 301 https://$host$request_uri; } atau gunakan variabel $scheme dikombinasikan dengan konfigurasi proxy_set_header X-Forwarded-Proto
www dan non-www saling mengalihkan membentuk loopLapisan CDN mengonfigurasi pengalihan www→non-www, sedangkan Nginx sumberjuga mengonfigurasi pengalihan non-www→www, aturan bertentanganPilih satu versi standar (direkomendasikan non-www atau www, tetap konsisten), hanya konfigurasikan pengalihan di satu lapisan (CDN atau sumber), hapus aturan yang sesuai di lapisan lain
Rantai pengalihan melewati 4-5 hop baru sampai ke halaman akhirHTTP→HTTPS hop→non-www→www hop→tambah garis miring di akhir hop→jalur lama→jalur baru, aturan berlapis tumpang tindihGabungkan aturan pengalihan, langsung dari URL awal satu langkah dialihkan ke URL akhir. Di Nginx gunakan instruksi return untuk satu langkah dialihkan ke alamat akhir lengkap
Node HTTP muncul dalam rantai pengalihan situs HTTPS (penurunan)Konfigurasi server hardcode target pengalihan dengan awalan http://, atau aplikasi menghasilkan URL pengalihan tanpa mengenali saat ini adalah HTTPSKonfigurasikan aplikasi untuk mempercayai proxy terbalik, baca X-Forwarded-Proto dengan benar; di Nginx gunakan URL absolut https:// atau variabel $scheme (asalkan proxybenar mengatur skema); terapkan HSTS
Setelah pengalihan 301 dimodifikasi browser masih dialihkan ke alamat lamaBrowser menyimpan aturan pengalihan permanen 301 dalam cache jangka panjang, refresh F5 tidak efektifPada tahap pengujian gunakan pengalihan sementara 302 untuk dikonfirmasi benar lalu ubah menjadi 301; bersihkan cache browser (Chrome: Pengaturan→Privasi→Hapus data penjelajahan→gambar dan file yang di-cache); gunakan opsi Disable cache di DevTools
Data formulir hilang setelah pengalihan permintaan POSTMenggunakan pengalihan 301 atau 302, browser secara otomatis mengubah POST menjadi permintaan GET, badan permintaan dibuangUntuk permintaan non-GET seperti POST/PUT/DELETE, ganti dengan pengalihan 307 (sementara) atau 308 (permanen), secara ketat mempertahankan metode dan badan permintaan
Karakter pengkodean ganda seperti %2520 muncul di URL setelah pengalihanParameter URL telah dikodekan URL sekali, serverjuga mengodekannya untuk kedua kalinyaPeriksa logika pengalihan, pastikan URL hanya dikodekan sekali; di Nginx gunakan $request_uri (URI asli, tidak terdekode) daripada $uri (terdekode)
Pengalihan lintas domain permintaan AJAX/fetch melaporkan error CORSServer target pengalihan lintas domain tidak mengonfigurasi header respons CORS (Access-Control-Allow-Origin dll.)Pastikan server setiap hop dalam rantai pengalihan mengonfigurasi header CORS dengan benar; atau hindari menggunakan pengalihan lintas domain dalam permintaan AJAX, ganti dengan front-end mendapatkan URL target lalu meminta langsung

Troubleshooting