URL'deki Hash Kısmı Google'da İndekslenir mi? Fragment ve SPA Rehberi

URL'deki hash kısmı Google'da indekslenir mi?

URL'deki hash kısmı, yani # işaretinden sonra gelen fragment (parça), Google'da ayrı bir sayfa olarak indekslenmez. Google Search Central belgesi fragment'lerin genel olarak desteklenmediğini söyler. Aynı sayfanın içindeki bir noktayı gösteren hash zararsızdır. İçeriği hash ile değiştiren yapı ise sorun çıkarır.

Bu kısa cevabın arkasında birkaç ayrım var. Ayrıca her sitenin durumu aynı değil. Bu yazıda URL'deki hash konusunu tek bir soruya indirip anlatıyoruz: # sonrası değişen içerik Google için neden görünmez, tek sayfa uygulamalarda ne yaparsınız, sayfa içi atlama bağlantıları ve UTM etiketleri bu tabloda nerede durur?

Biz Talha Aslan ve ekibi olarak bu konuyu genellikle yeni açılan bir sitede "bazı sayfalarımız Google'da yok" şikâyetiyle görüyoruz. Nedenin arkasında çoğu zaman yönlendirme biçimi çıkıyor.

Fragment nedir ve tarayıcıda ne yapar?

Fragment, adresin sonunda # işaretiyle başlayan bölümdür. Örneğin example.com/rehber#fiyatlar adresinde "fiyatlar" kısmı fragment'tir. Tarayıcı sayfayı yükler, sonra aynı kimliğe sahip öğeye kaydırır.

Önemli ayrıntı şudur: tarayıcı fragment'i normalde sunucuya göndermez. Yani sunucu, "rehber" sayfası ile "rehber#fiyatlar" sayfası arasında fark görmez. Fragment tamamen tarayıcı tarafında çalışır.

Bu davranış iki sonuç doğurur:

• Sunucu tarafında farklı içerik üretemezsiniz, çünkü sunucu hash'i bilmez.
• Sayfayı sizin yerinize JavaScript (tarayıcıda çalışan kod) okuyup içeriği değiştirir.

Dolayısıyla URL'deki hash ile içerik değişiyorsa aslında içeriği bir betik değiştiriyor demektir. Arama motoru ise adres başına tek bir yanıt bekler. Bu beklenti ile hash tabanlı yapı arasındaki uyumsuzluk sorunun kökünü oluşturur.

URL'deki hash Google için neden ayrı sayfa sayılmaz?

Google'ın URL yapısı belgesi bunu açıkça yazar: sayfanın içeriğini değiştirmek için fragment kullanmayın, çünkü Google Search genel olarak URL fragment'lerini desteklemez. Belgedeki kötü örnek, adresin içinde #/ ile başlayan bir yol taşır.

Mantık basittir. Google bir adresi tarar, yanıtı alır ve o yanıtı o adresle ilişkilendirir. Fragment sunucuya gitmediği için "example.com/#/urunler" ile "example.com/#/iletisim" aynı yanıtı döndürür. Google'ın gözünde bunlar tek sayfadır.

Bu nedenle şu cümleyi güvenle kurabilirsiniz: Google, fragment ile ayrılan adresleri genelde ayrı sayfalar olarak ele almaz. "Genelde" kelimesi belgenin kendi ifadesinden gelir. Biz de tam bir garanti vermiyoruz, ama mimarinizi bu varsayıma dayandırmak yerine tersini varsaymak daha güvenlidir.

Pratik sonuç: her görünümün kendi arama değeri varsa, o görünüme gerçek bir URL vermelisiniz. Hash ile ayrılmış görünümler arama sonuçlarında kendi başlığı ve açıklamasıyla yer alamaz.

URL'deki hash ile içerik değiştiren bir sitede ne olur?

Bir örnek senaryo kuralım. Bir ürün tanıtım sitesi, tüm menüyü hash ile yönetiyor: ana sayfa example.com/#/, ürünler example.com/#/urunler, fiyatlar example.com/#/fiyatlar. Tarayıcıda her şey düzgün çalışıyor.

Google bu siteyi gezdiğinde yalnızca example.com adresini görür. Menüdeki bağlantıların hedefi fragment içerdiği için ayrı sayfa keşfi gerçekleşmez. Sonuç olarak aramada sitenin yalnızca ana sayfası çıkar. "Fiyatlar" sayfanız hiçbir sorguda görünmez.

URL'deki hash ile yönetilen böyle bir sitede üç ayrı kayıp yaşarsınız:

• Keşif kaybı: Alt görünümler ayrı sayfa olarak bulunmaz.
• Sinyal kaybı: Dış bağlantılar çoğu zaman hash'li adrese gelir ve ana sayfaya sayılır.
• Ölçüm kaybı: Analitikte tüm ziyaretler tek sayfa gibi görünür.

Bu örnek hesap değil, mimari bir senaryodur; gerçek bir müşteri sonucu anlatmıyoruz. Yine de sahada benzer yapıyı sık görürsünüz. Özellikle eski JavaScript çatılarıyla yazılmış kurumsal sitelerde bu desen yaygındır.

Tek sayfa uygulamalarda doğru yönlendirme nasıl kurulur?

Tek sayfa uygulama (SPA, yani sayfayı yeniden yüklemeden görünüm değiştiren web uygulaması) kullanıyorsanız çözüm History API'dir. Google'ın JavaScript SEO temelleri belgesi, uygulamanızdaki görünümler arası yönlendirme için History API kullanmanızı önerir.

History API, tarayıcının adres çubuğunu sayfayı yenilemeden güncellemenizi sağlar. Böylece kullanıcı "Fiyatlar" görünümüne geçtiğinde adres example.com/fiyatlar olur. Bu adres gerçek bir yoldur ve sunucu tarafında da yanıt verebilir.

Doğru kurulumda şunlar bulunur:

1. Her görünümün kendine ait, temiz ve kalıcı bir yolu vardır.
2. O yolu doğrudan tarayıcıya yazdığınızda sunucu aynı içeriği döndürür.
3. Menü bağlantıları gerçek bağlantı öğeleridir ve href değeri o yolu taşır.
4. Her görünümün kendi başlığı ve açıklaması vardır.

Ayrıca sunucu tarafı oluşturma (SSR) ya da önceden oluşturma, yani içeriği önceden HTML olarak hazırlama, Google'ın içeriği görmesini kolaylaştırır. Bu seçim performans ve bakım kararınıza bağlıdır; zorunlu olup olmadığını sitenizin yapısına bakarak değerlendirmek gerekir.

Hashbang (#!) adresleri hâlâ çalışır mı?

Hashbang, adreste #! karakterleriyle başlayan eski bir biçimdir. Bir dönem Google, bu adresleri özel bir "AJAX tarama şeması" ile işlemek için bir yöntem önermişti. Bugün bu şema kullanımdan kaldırılmıştır.

Google Search Central'ın resmi hesabı bu konuda şunu belirtmiştir: hashbang ve AJAX tarama şeması uzun zaman önce kullanımdan kaldırıldı ve # ya da #! gerektirmeyen daha temiz bir URL yapısına geçilmesi öneriliyor. Bu yüzden yeni bir projede hashbang kurmak için hiçbir neden yoktur. URL'deki hash gibi, #! de arama için ayrı sayfa üretmez.

Eski bir sitede #! görüyorsanız şunları yapın:

• Şemanın artık desteklenmediğini kabul edin, bu yapıya güvenmeyin.
• Her #! adresi için gerçek bir yol belirleyin.
• Eski adreslerden yeni yollara yönlendirme planı çıkarın.

Not: Sunucu bir hash'i hiç görmediği için hash'li adresi doğrudan 301 ile yönlendiremezsiniz. Bu sınırlama, geçiş bölümünde ele aldığımız ayrı bir çözüm gerektirir.

Sayfa içi atlama bağlantılarında # kullanmak sorun olur mu?

Hayır, sayfa içi atlama bağlantılarında # kullanmak sorun değildir. Bu kullanımda hash, içeriği değiştirmez. Yalnızca aynı sayfadaki bir başlığa ya da bölüme kaydırır.

Uzun bir rehberin başındaki içindekiler listesi iyi bir örnektir. "Fiyatlar" bağlantısı sayfadaki fiyatlar başlığına gider. İçerik zaten sayfada durur, dolayısıyla Google'ın ayrı bir URL görmesine gerek kalmaz.

Bu kullanım kullanıcı deneyimi açısından da faydalıdır. Okur, yazının ortasındaki bilgiye tek tıkla ulaşır. Üstelik klavye ve ekran okuyucu kullanan ziyaretçiler için de gezinmeyi kolaylaştırır.

Dikkat etmeniz gereken tek şey şudur: hedef kimliğin gerçekten sayfada olması ve içeriğin ilk yüklemede HTML içinde bulunmasıdır. Kimlik, JavaScript ile sonradan oluşuyorsa atlama çalışmayabilir.

Atlama bağlantılarının arama sonucunda "Atla" benzeri bağlantılar olarak görünmesi ise ayrı bir konudur; bunu içindekiler tablosu ve Google'daki atla bağlantıları yazımızda anlattık. Burada tekrar etmiyoruz.

Sekmeler, akordeonlar ve filtreler hash ile mi yönetilmeli?

Arama değeri olan bir görünüm için hayır. Sekme ve akordeon içindeki metin sayfa HTML'inde zaten varsa, hash yalnızca hangisinin açık olduğunu belirtir; bu durumda içerik görünür kalır. Sorun, içeriğin hash değişince yüklendiği durumlarda başlar.

Şu ayrımı kullanabilirsiniz:

• Görsel durum: Hangi sekmenin açık olduğu gibi bilgiler hash ile tutulabilir.
• Ayrı içerik: Her sekmenin kendi aranabilir sayfası olmasını istiyorsanız o sekmeye gerçek URL verin.
• Filtreler: Filtreli listeleri hash yerine sorgu dizesiyle (?renk=mavi gibi) oluşturabilirsiniz, ama filtre kombinasyonları çoğalınca ayrı bir indeksleme planı gerekir.

Filtre kombinasyonlarının yarattığı sorunları ayrıntılı biçimde faceted navigation yazımızda ele aldık. Hash'e kaçmak o sorunu çözmez, yalnızca görünmez kılar.

Kısacası: kullanıcıya bir ayar gösteriyorsanız URL'deki hash yeterlidir. Google'ın bulmasını istediğiniz her içerik için gerçek bir adres gerekir.

UTM parametrelerini # sonrasına koymak analitiği nasıl etkiler?

UTM etiketlerini # sonrasına koyarsanız analitik verinizin bozulma riski vardır. Google Analytics Yardım belgesi, parametreleri URL'den bir soru işaretiyle ayırmanızı söyler; parametreler ad ve değer çiftleri olarak yazılır ve aralarında & bulunur.

Neden önemli olduğunu anlamak kolay. Hash, sunucuya gitmez ve birçok kurulum yalnızca sorgu dizesini okur. Etiketiniz # sonrasında kalırsa kampanya kaynağı "doğrudan" ya da "referans" gibi yanlış bir gruba düşebilir.

Bu davranış her araca göre değişebilir. Bu nedenle kendi kurulumunuzda test etmeniz gerekir; ayrıca reklam platformlarının hedef URL'deki fragment'i nasıl işlediğini ilgili platformun resmi yardımından kontrol edin.

Güvenli kural şudur: önce sorgu dizesi, en sonda hash gelsin. Örneğin example.com/sayfa?utm_source=bulten#fiyatlar biçimi doğrudur. Etiketleri elle yazmak yerine UTM oluşturucu aracımızı kullanabilirsiniz. UTM mantığının tamamı için UTM nedir yazımıza bakın.

URL'deki hash, sorgu dizesi ve History API arasındaki fark nedir?

Üç yöntem aynı amaca hizmet etmez. URL'deki hash tarayıcıda kalır; sorgu dizesi sunucuya gider, History API ise gerçek yolu tarayıcıda günceller. Tabloda üçünü yan yana görebilirsiniz.

Tablodaki "Genelde hayır" ifadesi Google belgesindeki "genel olarak desteklemez" diliyle uyumludur. Kesin kural gibi okumayın.

Buradan çıkan karar ağacı basittir. İçerik aynı sayfadaysa hash kullanın. İçerik farklıysa gerçek yol verin. Sıralama ya da kampanya gibi isteğe bağlı değişkenlerde sorgu dizesi kullanın, ama bu adreslerin kanonik durumunu da planlayın. Kanonik konusu için canonical etiketi yazımıza bakabilirsiniz.

URL'deki hash hakkında en sık yapılan yanlış varsayımlar nelerdir?

Konu teknik göründüğü için etrafında birkaç yanlış inanış dolaşır. Hepsini sahada duyduk.

• "Google JavaScript'i çalıştırıyor, hash de çalışır." JavaScript'in çalışması başka bir konudur. Sorun, fragment'in adres olarak ayrı sayfa sayılmamasıdır.
• "Hash'li adresi site haritasına eklersem indekslenir." Haritaya eklemek, Google'ın adresi ayrı sayfa saymasını sağlamaz.
• "Canonical etiketi hash'li görünümleri ayırır." Kanonik etiket aynı içeriğin tekrarını yönetir; ayrı sayfa yaratmaz.
• "Hash tüm SEO'ya zararlıdır." Sayfa içi atlama için hash tamamen güvenlidir.
• "Bir kez geçersem sorun biter." Geçişten sonra durum kodu, bağlantı ve site haritası kontrolü de gerekir.

Bu varsayımların ortak noktası şudur: hepsi, çözümü etiketlerde ya da dosyalarda arıyor. Oysa asıl çözüm adresin kendisindedir. Bir görünümün aranabilir olması için sunucunun cevap verebildiği, tekil ve kalıcı bir adresi olmalıdır.

Sitenizin öbür SEO sorunlarını aramak için SEO analiz aracımızı kullanabilirsiniz. Araç hash mimarisini tek başına çözmez, ama temel teknik eksikleri hızla gösterir.

Dil ya da bölge seçimini hash ile yapmak doğru mudur?

Bazı siteler dil seçimini example.com/#tr ve example.com/#en gibi hash değerleriyle yönetir. Bu yapıda iki dilin içeriği aynı adreste durur ve Google dillerden yalnızca birini görebilir. Üstelik ikinci dil için ayrı bir sayfa oluşmaz.

Her dil için ayrı yol kullanmak daha sağlıklıdır: /tr/ ve /en/ gibi. Böylece her dilin kendi sayfası, başlığı ve açıklaması olur. Dil sürümlerini birbirine bağlama konusu ayrı bir uzmanlık alanıdır.

Kullanıcıyı IP adresine göre otomatik yönlendirmek de bu tabloda ayrı bir risk taşır. O konuyu IP'ye göre otomatik dil yönlendirmesi yazımızda ayrıntılı biçimde inceledik. Burada yalnızca şunu vurguluyoruz: dil ya da ülke seçimi, hash değil gerçek adres gerektirir.

Çok dilli bir sitede dil seçeneği yalnızca bir arayüz tercihiyse, örneğin sayfa metni zaten HTML'de her dil için ayrı duruyorsa hash zarar vermez. Ayrım, içeriğin hangi adreste durduğundadır.

Gerçek URL'ye geçince sunucu tarafı oluşturma şart mı?

Şart değildir, ama seçeneği bilmek gerekir. Gerçek yollara geçmek tek başına yeterli bir adımdır; içeriğin nasıl üretileceği ayrı bir karardır.

Üç yaygın yaklaşım vardır:

• İstemci tarafı oluşturma: Tarayıcı boş bir kabuk alır, içeriği JavaScript doldurur. Kurulumu kolaydır, ama içeriğin ilk yanıtta bulunmaması riski taşır.
• Sunucu tarafı oluşturma: Sunucu her istekte tam HTML üretir. İçerik ilk yanıtta hazır gelir.
• Önceden oluşturma: Sayfalar yayın sırasında HTML olarak hazırlanır. Değişmeyen içerikler için pratiktir.

Hangisinin uygun olduğu, içeriğin ne sıklıkla değiştiğine, ekibin yetkinliğine ve bakım bütçesine bağlıdır. Bu yüzden bir yaklaşımı "her zaman doğru" ilan etmiyoruz.

Önemli olan, gerçek yolların sunucuda yanıt vermesi ve önemli metnin Google'ın göreceği biçimde sayfada bulunmasıdır. Kararınızı verirken sayfa hızını da hesaba katın; konuyu JavaScript optimizasyonu yazımızda işledik.

Hash'li bir siteyi taşımadan önce hangi soruları sormalısınız?

Geçiş projelerinin çoğu, plan aşamasında atlanan sorular yüzünden uzar. Başlamadan önce şu soruları yanıtlayın:

1. Hangi görünümler kendi başına aranmak istenen içerik taşıyor?
2. Mevcut altyapı sunucu tarafında yeni yollara cevap verebiliyor mu?
3. Eski hash'li adresler dış sitelerde ya da reklam bağlantılarında kullanılıyor mu?
4. Reklam hedef adreslerinde UTM etiketleri hash öncesinde mi, sonrasında mı?
5. Analitik olayları yeni yol değişimlerinde tetikleniyor mu?
6. Geliştirici ekibin durum kodu ve hata sayfası planı var mı?

Bu soruların bir kısmına cevap veremiyorsanız endişelenmeyin. Cevapsız kalan soru, projenin ilk iş listesidir. Eksik bilgiyi tahminle doldurmak yerine ölçümle tamamlamak daha güvenlidir.

Geçiş sonrası performansı izlemek için Search Console ile trafik düşüşü teşhisi yazımızdaki adımları kullanabilirsiniz.

Sitenizde hash tabanlı yönlendirme olduğunu nasıl anlarsınız?

Belirtiler genellikle ilk aylarda ortaya çıkar. Birkaç net işaret vardır, hepsi kolayca kontrol edilir.

Şu işaretlere dikkat edin:

• Menüde gezindiğinizde adres çubuğunda # ve ardından bir yol görüyorsunuz.
• Google aramasında sitenizden yalnızca ana sayfa ya da çok az sayfa çıkıyor.
• Search Console'da keşfedilen sayfa sayısı, sitenin gerçek görünüm sayısından çok az.
• Analitikte neredeyse tüm oturumlar tek bir sayfa adresine yazılıyor.
• Sayfa kaynağında farklı görünümlerin metni yok, içerik sonradan geliyor.

URL'deki hash belirtilerinden iki ya da üçünü birlikte görüyorsanız yapıyı mutlaka inceleyin. Her ikisi de tek başına kesin kanıt sayılmaz; örneğin yeni bir site henüz taranmamış olabilir.

Search Console'a yeni başlıyorsanız Google Search Console nasıl kullanılır yazımız temel raporları anlatıyor. İndekse girmeyen sayfalar için indekslenmeyen sayfaların tespiti rehberine göz atın.

Hash'li yapıyı adım adım nasıl denetlersiniz?

Denetim için ileri düzey araç gerekmez. Aşağıdaki sırayı izleyerek durumu bir saat içinde netleştirebilirsiniz.

1. Sitenizi tarayıcıda açın ve menüdeki her bağlantıya tıklayın; adres çubuğunun nasıl değiştiğini not edin.
2. Her görünümün adresini kopyalayıp yeni bir sekmede doğrudan açın. Aynı içeriği görüyor musunuz?
3. Search Console'da URL denetimi aracıyla (URL Inspection) bu adreslerin Google tarafından nasıl görüldüğüne bakın.
4. Sayfa kaynağında, görünümün ana metninin bulunup bulunmadığını kontrol edin.
5. Menü bağlantılarının gerçek bağlantı öğesi olup olmadığını ve href değeri taşıyıp taşımadığını doğrulayın.
6. Analitikte sayfa bazlı raporu açın ve görünümlerin ayrı satırlarda görünüp görünmediğine bakın.

Bu adımlar sonunda iki liste çıkarırsınız: gerçek URL'si olan görünümler ve yalnızca hash ile açılanlar. İkinci liste, düzeltme planınızın omurgasıdır.

Not: Menü ve düğme adları araçların arayüz güncellemeleriyle değişebilir. Bu yüzden kesin buton metni yerine "ilgili rapor" diyoruz; kendi panelinizde karşılığını bulursunuz.

Hash'li eski adreslerden gerçek URL'lere nasıl geçersiniz?

Geçişin en zor tarafı, hash'in sunucuya gitmemesidir. Sunucu tarafında "#/fiyatlar adresini /fiyatlar yoluna yönlendir" diyemezsiniz. Bu yüzden iki katmanlı bir plan gerekir.

İlk katman, yeni yapıyı kurmaktır. Her görünüme gerçek yol verin, sunucunun bu yollara doğrudan yanıt verdiğinden emin olun ve eski menü bağlantılarını yeni yollara çevirin.

İkinci katman, eski adresleri gelen ziyaretçiler için taşımaktır. Eski hash'li adresi açan kullanıcıyı, sayfa yüklenince çalışan küçük bir istemci tarafı eşleştirmesi yeni yola gönderebilir. Bunun Google için tam bir 301 karşılığı olmadığını bilin; bu eşleştirme ziyaretçiyi korur ama sinyal aktarımı garanti etmez.

Geçişte dikkat edilecekler:

• Yeni yolların hepsini site haritasına ekleyin.
• Dahili bağlantıları eski hash'li biçimden yeni yollara taşıyın.
• Eski adreslere dış bağlantı alan sayfaları öncelikli kontrol edin.
• Geçişten sonra Search Console'da kapsam raporunu birkaç hafta izleyin.

Yönlendirme türleri hakkında emin değilseniz 301, 302, 307 ve 308 farkı yazımıza bakın.

SPA'larda durum kodları ve soft 404 neden önemlidir?

Tek sayfa uygulamalarda yönlendirme istemci tarafında yapıldığı için, sunucu çoğu zaman her yola 200 durum kodu döndürür. Google belgesi bunu açıkça kabul eder: istemci tarafı yönlendirmede anlamlı HTTP durum kodlarını kullanmak imkânsız ya da pratik olmayabilir.

Sorun şuradadır: kullanıcı olmayan bir yola giderse uygulama "bulunamadı" mesajı gösterir, ama sunucu yine 200 döndürür. Google bunu soft 404 (hata sayfası gibi görünen ama başarılı kodla dönen sayfa) olarak değerlendirebilir.

Belge iki çözüm sunar: hata durumunda gerçek bir 404 sayfasına yönlendirmek ya da hata sayfasına JavaScript ile noindex robots meta etiketi eklemek. Etiketin kendisini burada kod olarak yazmıyoruz; geliştiricinizin belgeyi doğrudan açması yeterlidir.

Bu konu hash meselesinden ayrı görünse de aynı mimari tercihten doğar. Hash'ten çıkıp History API'ye geçtiğiniz anda, geçersiz yollar için doğru yanıtı vermek de sizin sorumluluğunuza girer. Noindex davranışını noindex ve nofollow farkı yazımızda bulabilirsiniz.

Bağlantıları Google'ın izleyebileceği biçimde nasıl yazarsınız?

Google'ın bağlantılar belgesine göre bağlantı keşfi için href özniteliği olan gerçek bağlantı öğeleri gerekir. JavaScript ile eklenen bağlantılar da kabul edilebilir, ama aynı kurallara uymaları gerekir.

Menü öğesi bir düğme ya da tıklanabilir kutu olarak yazılmışsa Google onu bağlantı olarak görmeyebilir. Hash'e geçiş yapan, ama href taşımayan yapılar bu gruba girer. Belge ayrıca "javascript" şemasıyla başlayan adreslerin sorunlu olduğunu ve gerçek bir web adresine çözülmediğini belirtir.

Kontrol listeniz şöyle olsun:

• Her menü öğesi, gerçek bir adrese işaret eden href taşısın.
• Tıklama olayı, bağlantının yerine geçmesin; bağlantıya ek davranış katsın.
• Sayfalama ve filtre bağlantıları da gerçek adres kullansın.
• Dahili bağlantıların anlamlı bağlantı metni olsun.

Bu kural hash konusuyla doğrudan ilişkilidir, çünkü çoğu hash tabanlı menü tıklama olaylarıyla çalışır ve ayrı sayfaları keşfedilebilir kılacak bir adres sunmaz. Sitenizin JavaScript yükünün hıza etkisi için JavaScript ve site hızı yazımıza bakabilirsiniz.

Hash'ten gerçek URL'ye geçerken hangi hatalar yapılır?

Geçişte en sık görülen hatalar acelenin sonucudur. Hepsi önlenebilir.

• Yarım geçiş: Yeni yollar çalışır, ama menü hâlâ eski hash'li bağlantıları kullanır. Google yeni yolları keşfedemez.
• Her yola 200 dönmek: Olmayan yollar da başarı kodu döndürür ve soft 404 oluşur.
• Başlık ve açıklama kopyası: Tüm görünümler aynı başlığı taşır. Kendi yolu olan görünümün kendi başlığı da olmalı.
• Site haritasını unutmak: Yeni yollar haritada yer almaz, keşif yavaşlar.
• Analitiği güncellememek: Sayfa görüntüleme olayları yeni yol değişimlerinde tetiklenmez ve oturumlar yine tek sayfa gibi görünür.
• Canlıya doğrudan almak: Önce test ortamında her yolu elle açmadan yayına çıkmak.

Sayfa adreslerini planlarken URL slug yazım kuralları yazımızdaki ilkeler işinize yarar. Burada slug konusunu tekrarlamıyoruz, yalnızca yolun okunur ve kalıcı olması gerektiğini hatırlatıyoruz.

Geçişten sonra kanonik hatalarını izlemek için canonical hatalarını Search Console'da tespit etme rehberi bir kontrol listesi sunar.

Hash kullanımı ne zaman tamamen sorunsuzdur?

Bazen hash tam olarak doğru araçtır. Kullanımınız aşağıdaki gruba giriyorsa kaygılanmanız gerekmez.

• İçindekiler listesinden sayfa içi bölüme atlama.
• Uzun bir sayfada "başa dön" bağlantısı.
• Aynı sayfada açık olan sekmeyi belirtmek.
• Sayfa içi yorum ya da dipnot bağlantısı.
• Bir formun hata mesajına odaklanmak.

Ortak nokta şudur: içerik zaten sayfanın HTML'indedir ve hash yalnızca konumu ya da durumu gösterir. Google'ın aynı adresi tek sayfa olarak görmesi bu durumda tam olarak istediğiniz sonuçtur.

Yani hash'e karşı değiliz. Karşı olduğumuz şey, ayrı sayfa olması gereken içeriği hash'in arkasına saklamaktır. Bir içeriğin kendi aranabilir sayfası olup olmayacağına karar verin; olacaksa gerçek yol, olmayacaksa hash yeterlidir.

Bu işi ekip olarak nasıl ele alıyoruz?

Talha Aslan ve ekibi olarak SEO danışmanlığı kapsamında bu tür teknik sorunlara önce tespitle başlıyoruz. Hash tabanlı sitelerde ilk bakacağımız şey, hangi görünümlerin arama değeri taşıdığıdır.

Süreç genellikle şu sırayla ilerler:

1. Mevcut yapıyı ve görünüm listesini çıkarırız.
2. Hangi görünümlerin ayrı sayfa olması gerektiğini sorgu verisiyle belirleriz.
3. Geliştirici ekibine gerçek yol, durum kodu ve bağlantı gereksinimlerini yazılı veririz.
4. Geçiş sonrası Search Console ve analitik verisini izleriz.

Sonuç garantisi vermeyiz; çünkü indeksleme kararını Google verir. Yaptığımız şey, Google'ın içeriğinizi bulmasını engelleyen mimari engelleri kaldırmaktır.

Yeni bir site planlıyorsanız bu kararı en başta almak çok daha ucuzdur. Web tasarım hizmetimizde yönlendirme yapısını tasarım aşamasında netleştiriyoruz. Mevcut bir sitenin teknik incelemesi için SEO danışmanlığı sayfamıza bakabilirsiniz.

Ne zaman uzman desteği almalısınız?

Bazı durumlarda kendi başınıza ilerlemek yerine teknik destek almak zaman kazandırır.

Şu durumlarda destek almayı düşünün:

• Sitenin tamamı hash tabanlı çalışıyor ve yeniden yazım gerekiyor.
• Geçişten sonra trafik düşüşü yaşıyorsunuz ve nedenini bulamıyorsunuz.
• Sunucu tarafı oluşturma gibi mimari kararlar için ekibinizde deneyim yok.
• Eski adreslere çok sayıda dış bağlantı geliyor ve sinyal kaybı riski taşıyorsunuz.

Destek almadan önce yapabileceğiniz hazırlık da vardır: görünüm listesini çıkarın, hangi görünümlerin Google'da aranmasını istediğinizi işaretleyin ve analitikteki mevcut trafiği not edin. Bu üç bilgi, her teknik görüşmeyi hızlandırır.

Son olarak şunu hatırlayın: hash konusunda tek bir doğru yoktur. Doğru çözüm, içeriğin aranabilir bir sayfa olup olmadığına bağlıdır. İçerik aranacaksa gerçek bir URL verin, aranmayacaksa hash'i rahatça kullanın.