Büyük Ölçekte Hreflang Nasıl Denetlenir?

Büyük sitede hreflang denetimi için tekrarlanabilir, araç destekli süreç: üç uygulama yönteminden tüm bildirimleri toplama, küme grafikleri ve karşılıklı eşleme matrislerini okuma, düzeltmeleri sıklığa değil zarara göre önceliklendirme.

Bu sayfada 1 kanıt sinyali

Büyük ölçekte hreflang denetimi, etiket değil grafik doğrulama problemidir. Bir sayfada etiket olup olmadığını değil, kümedeki her sayfanın diğer her sayfaya geri işaret edip etmediğini kontrol edersiniz. Tarayıcı araçla üç uygulama yerinden — HTML head, HTTP başlıkları, XML site haritası — bütün bildirimleri toplayın. Google doğrulayıcı sunmaz; GSC Uluslararası Hedefleme raporu 22 Eylül 2022'de kaldırıldı. Ardından karşılıklı etiket matrisini oluşturun. Ücretsiz dönüş etiketi grafiğim ve matrisimle kümeyi görsel olarak örnekleyin veya tam site kapsamı için Ahrefs Site Audit ve Screaming Frog kullanın. Zarara göre önceliklendirin: önce eksik dönüş etiketleri — bütün çifti bozar —, sonra yanlış dil/bölge kodları ve canonical olmayan hedefler, en son eksik x-default; %56,3 ile en yaygın ama en az zararlı sorundur. Brighton SEO 2023'teki 374 756 alan adlı çalışmamda, hreflang kullananların %67'sinden fazlasında en az bir hata vardı.

TL;DR — Büyük ölçekli hreflang denetimi etiket değil, grafik doğrulamasıdır.

  1. adım: ccTLD/alt alan adı düzeninize göre yapılandırılmış bir crawler ile üç geçerli konumdaki (HTML head, HTTP Link başlıkları, XML sitemap) tüm bildirimleri alın. GSC bunu yapamaz; International Targeting 22 Eylül 2022’de kaldırıldı ve öncesinde bile kümenin yalnızca canonical üyesini raporluyordu. 2. adım: karşılıklı etiket matrisini kurun; kümedeki her URL’yi diğerleriyle eşleştirip A→B ve B→A bağlantılarını kontrol edin. Odaklı kontrolde returntag küme grafiğimi/matrisimi, site genelinde Ahrefs ve Screaming Frog’u kullanın. 3. adım: eksik dönüş etiketleri, yanlış kodlar, canonical olmayan hedefler ve karışık mutlak/göreli URL’ler olarak sınıflandırın. 4. adım: sıklığa değil zarara göre öncelik verin; önce çifti bozan dönüş etiketleri, sonra kodlar, en son en yaygın (%56,3) ama en az zararlı x-default. 5. adım: bildirilen canonical’a değil, dizine eklenen URL’ye göre yeniden doğrulayın.

Bu yazı, hreflang’i altı denetim alanından biri olarak ele alan geniş kapsamlı Uluslararası SEO Denetimi yazımın hreflang’e özel tamamlayıcısıdır. Burada yalnızca hreflang için büyük ölçekli yöntemi derinleştiriyorum. Temeller, üç uygulama yöntemi ve karşılıklılık kuralı için Hreflang merkezine; varsayılan etiket için x-default yazısına bakın.

Bu iddiaya ilişkin kanıt A complete audit needs to inspect HTML, HTTP Link headers, and XML sitemaps because Google supports hreflang in all three locations. Kapsam: Google Search-supported hreflang delivery methods. Güven düzeyi: yüksek · Doğrulandı: Google: Localized versions

Temel bakış açısı: Bu bir grafik problemidir

Büyük ölçekli denetimi yönetilebilir kılan zihinsel değişim şudur: “Bu sayfada hreflang etiketi var mı?” diye bakmıyorsunuz. “Bu sayfanın kümesindeki her sayfa ona geri bağlantı veriyor mu ve kümedeki her URL 200 döndüren, canonical ve dizine eklenebilir bir sayfa mı?” diye soruyorsunuz.

Bunun nedeni Google’ın kendi belgesidir:

“If page X links to page Y, page Y must link back to page X. If this is not the case for all pages that use hreflang annotations, those annotations may be ignored or not interpreted correctly.” (çeviri) “X, Y’ye bağlanıyorsa Y de X’e geri bağlanmalıdır. Bu karşılıklılık hreflang bildirimli tüm sayfalarda sağlanmazsa bildirimler yok sayılabilir veya yanlış yorumlanabilir.”

Bu iddiaya ilişkin kanıt A hreflang audit must verify return links because Google says non-reciprocal annotations may be ignored or interpreted incorrectly. Kapsam: Google Search hreflang reciprocity guidance; impact is stated as possible, not guaranteed cluster-wide invalidation. Güven düzeyi: yüksek · Doğrulandı: Google: Hreflang guidelines

Bunu dikkatle okuyun. Tek bir eksik dönüş bağlantısı, ilgili bildirimlerin yok sayılmasına veya yanlış yorumlanmasına neden olabilir. Bu yüzden tek sayfalık görünüm hreflang denetimi için yapısal olarak yetersizdir: hata bir sayfada değil, sayfalar arasındaki ilişkide bulunur. Tüm küme üyelerini kaydedip çapraz karşılaştıran bir tarama gerekir.

Kapsam da önemlidir: Yok sayılabilecek bildirimler, büyük kümedeki tüm ilişkiler değil, bozuk çiftteki bildirimlerdir. Bir dönüşü eksik beş sayfalık kümenin diğer tamamlanmış çiftleri genellikle çalışmaya devam eder. Aşağıdaki returntag görüntüsü tam bunu gösterir: dokuz karşılıklı çift sağlam, bir dönüş eksiktir. Tek bozuk kenarın tüm kümeyi yok ettiğini varsaymayın; araç her çifti kontrol ederek hangisinin bozuk olduğunu göstermelidir.

Site büyüdükçe iş zorlaşır; Google da büyük sitelerde hata görülmesini böyle açıklar. Search Off the Record bölümünde Gary Illyes, her birinin kendi URL yapısı olan çok sayıda mülkte kalıp değiştikçe hataların ortaya çıktığını anlattı. Lizzi Sassman da URL’ler yerelleştirilirken senkronizasyon ve yazım hatalarının zorlaştığını ekledi. Bu, farklı yayın kurallarına sahip çoklu ccTLD’li kurumsal düzenin tipik işaretidir. Bu nedenle iyi bir denetim bulguları mülk/alan adı grubuna göre ayırır; hatalar operasyonel olarak orada kümelenir.

1. adım — Site genelindeki tüm hreflang bildirimlerini alın

Hreflang’in bulunduğu üç yer

Google hreflang’i üç eşdeğer konumda kabul eder ve üçünü de kontrol etmelisiniz:

Bu iddiaya ilişkin kanıt A complete audit needs to inspect HTML, HTTP Link headers, and XML sitemaps because Google supports hreflang in all three locations. Kapsam: Google Search-supported hreflang delivery methods. Güven düzeyi: yüksek · Doğrulandı: Google: Localized versions
  1. <head> içindeki HTML <link> etiketleri — en yaygın yöntem.
  2. HTTP Link: yanıt başlıkları — PDF gibi HTML olmayan dosyalar için.
  3. XML sitemap içindeki xhtml:link girdileri — bildirimleri her sayfanın şablonuna koymak yerine tek dosyada merkezileştirdiği için büyük ölçekte yaygındır.

Yalnızca HTML head’i okuyan crawler, başlık veya sitemap üzerinden bildirilen alternatifleri sessizce kaçırır. Bunları bozuk diye işaretlemez; hiç görmez. Bu daha kötüdür, çünkü tam kümesi sitemap’te bulunan sayfada hreflang yok sanırsınız. Tek bir sayıya güvenmeden önce taramayı üç yöntemi de okuyacak şekilde yapılandırın.

Crawler’ı yapınıza göre yapılandırma

  • Screaming Frog: Configuration > Spider > Crawl Hreflang seçeneğini etkinleştirin; sitemap ve başlık hreflang’ini de kaynakları verdiğinizde alır. Birbirine referans veren ccTLD/alt alan adlarını Config > CDNs altına ekleyin. Aksi hâlde alanlar arası hreflang bağlantıları bozuk diye işaretlenmek yerine hiç doğrulanmaz. Kurumsal siteler ccTLD kullanmaya daha yatkın olduğu için büyük ölçekte en yaygın kör nokta budur.
  • Ahrefs Site Audit: Aynı nedenle kardeş alan adlarının proje kapsamında olduğundan emin olun. Ardından münferit olarak küme grafiklerine geçmeden önce sorun türüne göre büyük ölçekte filtrelemek için Page Explorer aracını kullanın.

GSC bunu neden yapamaz?

İki nedeni var; çoğu kişi ikincisini kaçırır:

  1. Rapor kaldırıldı. Bazı hreflang sorunlarını gösteren GSC International Targeting raporu kullanımdan kaldırıldı (Ağustos 2022’de duyuruldu; 22 Eylül 2022’den sonra kaldırıldı). Yerine doğrudan bir rapor gelmedi.
  2. Varken bile yalnızca canonical’ı gösteriyordu. Illyes, Search Off the Record’da Search Console’un yalnızca canonical URL’leri raporladığını açıkladı. Benzer dilli çoğu hreflang kümesinde alternatifler canonical değildir; Google bunları alternatif ayrıntıları tutmadan yinelenenler kümesinde sakladığı için canonical olmayan üyelerde olan biteni göremezdiniz. Bu, GSC’nin hiçbir zaman tam bir hreflang denetim aracı olamamasının yapısal nedenidir; yalnızca “rapor kaldırıldı” meselesi değildir ve crawler öncelikli yaklaşımı doğrudan gerekçelendirir.

Google ayrıca doğrulayıcı sunmaz. Aynı podcast’te Illyes, Google’ın hiç hreflang doğrulayıcısı sağlamadığını; az kullanılan raporlamayı kaldırıp kullanıcıları Aleyda Solis, Bill Hunt ve Merkle gibi haricî araçlara yönlendirdiğini söyledi. Bunu, GSC’nin yapamadığı işte üçüncü taraf crawler kullanma izni sayın; onay saymayın. Google kendi belgelerinde üçüncü taraf hreflang hata ayıklama araçlarını bakım veya kontrolden geçirmediğini açıkça belirtir. Benim aracım dâhil her aracın çıktısı, üzerinde düşünmeniz gereken tanısal kanıttır; resmî karar değildir. Önemli bir bulguyu aracın özetinde bırakmayın; ham HTTP yanıtı, sitemap XML’i veya oluşturulan HTML ile doğrulayın.

2. adım — Karşılıklı etiket matrisini oluşturun

Topladığınız verileri normalleştirin

Matrisi kurmadan önce her şeyi tek biçime getirin. Bildirilen her hreflang ilişkisi için kaynak URL, hedef URL, dil değeri, kaynak yöntemi (HTML head, HTTP başlığı veya sitemap) ve özellikle hedefin durum kodu, yönlendirme zinciri, dizine eklenebilirliği, canonical hedefi ile ham HTML’de mi oluşturulan DOM’da mı görüldüğünü kaydedin. Crawler’lar bunları farklı biçimlerde dışa aktarır. Bağlamı eklenmiş yönlü URL→URL kenarlarına normalleştirme, matrisi ve 3. adımdaki sınıflandırmayı güvenilir kılar.

Matris neyi gösterir?

Kavramsal olarak her küme için satır ve sütunları kümedeki URL’lerden oluşan bir tablo kurarsınız. Her hücre şu evet/hayır sorusunu yanıtlar: Satırdaki URL’den sütundaki URL’ye hreflang bağlantısı var mı? Doğru küme simetriktir: A→B varsa B→A da vardır. Her asimetrik hücre (yalnızca bir yönde bulunan bağlantı) eksik dönüş etiketidir.

Bu tabloyu büyük ölçekte elle kurmazsınız; araçlar kurar. Ancak matrisi zihninizde tutmak araç çıktısını doğru okumanızı sağlar. returntag matrisi grafik olarak çizer ve hücreleri gösterir; Screaming Frog’un “Missing Return Links” filtresi asimetrik hücreleri listeler, Ahrefs Site Audit ise başka bir büyük ölçekli küme görünümü sunar. Aynı ilişki kontrolü, farklı sunum ve tarama kapsamları.

Grafik olarak okuma: returntag küme doğrulayıcım

Odaklı küme kontrolünde ücretsiz returntag aracım, bildirilen dil ilişkilerini grafik ve karşılıklı matris olarak gösterir. Her dil bir düğüm, her bildirim bir kenardır; sorun listesi geri bağlantı vermeyen URL’yi belirtir. Aşağıdaki görüntü yalnızca sitemap çalıştırmasıdır: sitemap bildirimlerini okur, sayfa head etiketlerini veya HTTP Link başlıklarını bilerek getirmez. Bir sayfanın kümesinde üç kaynağın tamamını görmek için Page URL modunu kullanın.

Nasıl okunur:

  • Temiz küme, her düğümün diğerlerine iki yönde de bağlandığı tam ağdır.
  • Tek yönlü kenar, asimetrik hücrenizdir: X, Y’yi gösterir ama Y geri göstermez. Okumak yerine gördüğünüz dönüş etiketi hatası budur.
  • Yetim düğüm, kümede görünüp kümeye geri bağlanmayan URL’dir; bağlantısız hreflang URL’sidir.

Pratik kazanç, önceliklendirme hızı ve paydaş iletişimidir. Geliştiriciye soyut tablo satırı vermek yerine tek yönlü ilişkiyi ve tam eksik dönüş hatasını birlikte gösterirsiniz. Yüzlerce veya binlerce kümede tam tarama kapsamı için Ahrefs Site Audit ya da Screaming Frog’u koruyun; returntag belirli kümeyi hızla inceleyip açıklamak içindir.

Tablo olarak okuma: Screaming Frog filtreleri

Screaming Frog’da matris, dönüş bağlantısı verilerini doldurmak için tarama sonrasında Crawl Analysis çalıştırdığınızda filtreler olarak görünür. Bunları 4. adımdaki öncelik sırasına uyan şu sırayla ele alın:

  • Missing Return Links — asimetrik hücreler; en öncelikli bulgular.
  • Inconsistent Language & Region Return Links — dönüş bağlantısı vardır ama giden bağlantıdan farklı kod kullanır (A, B’ye fr-FR derken B, gerçekte en-US olan A’ya en-GB der); daha sinsi bir çift bozucudur.
  • Non-Canonical Return Links — dönüş bağlantısı başka yere canonical olan URL’yi gösterir; etiket bulunsa da sinyal zinciri kırılır.
  • Noindex Return Links — dönüş hedefi noindex’tir, bildirimi taşıyamaz.
  • Non-200 Hreflang URLs — hedef bir yönlendirme veya hata sayfasıdır.
  • Unlinked Hreflang URLs ve Incorrect Language & Region Codes — yetim düğümler ve kod doğrulama hataları.

Tüm kümeyi Reports > Hreflang üzerinden dışa aktarın. Özet düzeyindeki tüm filtreleri açıklayan Screaming Frog hreflang rehberi mükemmeldir; yapılandırma adımlarını burada yinelemiyorum.

3. adım — Bulguları dört hata düzenine ayırın

Tarama çıktısı gürültülü olacaktır. Her bulguyu, 374 756 alan adlı çalışmada tekrarlanan dört gruptan birine koyun. Öncelik savını destekleyen iki sayıyı kullanıyorum; dokuz hata türünün tamamı zaten Uluslararası SEO Denetimi yazısındadır.

1. Eksik dönüş etiketleri — çifti bozan hata

Matrisinizdeki asimetrik hücrelerdir. Hreflang kullanan alan adlarının %15,3’ünde bulunur. Çalışma yazısında şöyle ifade ettim: “As I mentioned, hreflang tags work in pairs. If both pages don’t reference each other, they can’t establish the connection and swap properly in the search results.” (çeviri) “Hreflang etiketleri ikili ilişkiler kurar. İki sayfa birbirini göstermediğinde aralarındaki bağ kurulamaz ve arama sonuçlarında uygun biçimde birbirinin yerine geçemez.” Google belgelerine göre tüm çiftin sinyalini geçersiz kılan kategori budur. En yaygın hata olmasa bile bu yüzden ilk sıradadır.

2. Yanlış dil/bölge kodları — sessizce hoşgörülen hata

Dil için ISO 639-1, bölge için ISO 3166-1 alpha-2 kullanın. Klasik hatalar: Japonca için ja yerine jp, ja yerine yazım hatası js, gb yerine üç harfli gbr ve “Latin America” için yanlış kullanılan la (Laos).

Denetime eklenmesi gereken ayrım şudur: Temel dil etiketi standardı BCP 47, Google’ın hreflang uygulamasının işlediğinden çok daha geniş değerleri kabul eder. Script alt etiketleri ve BCP 47’ye uygun başka yapılar Google’ın hreflang belgelerinde tanınmış değerler olarak doğrulanmayabilir. Bir kod BCP 47 bakımından kusursuz biçimlenmiş olup Google tarafından desteklenmeyebilir. Genel BCP 47 sözdizimine değil, Google’ın belgelenmiş dil/bölge/x-default kurallarına göre doğrulayın.

Ancak saf önceliklendirmeye karşı önemli nüans vardır: Google bunların bazılarını sessizce düzeltir, bazılarını düzeltmez. Belge şöyle der: “Google Search ignores that part of the annotation (for example, using EU, UN, or UK in hreflang annotations doesn’t have an effect on Google Search).” (çeviri) “Google Arama bildirimin o bölümünü yok sayar; örneğin hreflang bildirimlerinde EU, UN veya UK kullanmanın Google Arama üzerinde etkisi yoktur.” Dolayısıyla UK fiilen düşürülür (GB kullanmalısınız), ancak bildirimin kalanını yok etmez. Basitçe yanlış jp ise ja eşleşmesini bozar. Denetim, “teknik olarak yanlış ama Google işliyor” ile “yanlış ve çifti gerçekten bozuyor” durumlarını ayırmalıdır.

3. Hreflang’deki canonical olmayan URL’ler — görünmez hata

Etiket dışa aktarımında doğru görünüp yine de bozulan düzendir. Pubcon 2019’da vurguladığım temel ayrım: hreflang canonical değil, dizine eklenen sürümle ilgilidir. Hreflang gerçekten dizine eklenenden farklı bir URL’yi gösteriyorsa, etiket “geçerli” olsa bile sinyal zinciri kırılır. Bu ancak tarama dışa aktarımını dizin durumuyla çapraz karşılaştırdığınızda görülür; çoğu rehber hreflang’i dizine ekleme hattının parçası yerine yalıtılmış etiket kontrolü saydığı için bunu atlar. 5. adımda doğrulanır.

Buraya aynı dilde uyum kontrolünü de ekleyin. Birbirine çok benzeyen birkaç URL bir dil için canonical adayı olabiliyorsa Google’ın canonical kılavuzu aynı dildeki (veya en iyi ikame) URL’yi tercih eder ve eksiksiz karşılıklı hreflang kümesindeki sayfaya bir miktar öncelik verir. Hedefleri başka dildeki kopyaya kaydırmayın. Crawler bunu kesin kanıtlayamaz; yalnızca yapılandırılmış sinyalleri gösterir, Google’ın nihai seçimini değil. Tarama çıktısını doğrulama değil, tanısal kanıt sayın.

Bu iddiaya ilişkin kanıt Audit canonical targets for same-language or best-substitute alignment and compare reciprocal hreflang-cluster membership, because Google documents a cluster preference among otherwise similar URLs. Kapsam: localized HTML pages, HTTP headers, XML sitemaps and search systems as applicable Güven düzeyi: yüksek · Doğrulandı: How to specify a canonical URL with rel=canonical and other methods

4. Karışık mutlak/göreli URL’ler — şablon hatası

Google açıkça şöyle der: “Alternate URLs must be fully-qualified, including the transport method (http/https), so: https://example.com/foo, not //example.com/foo or /foo.” (çeviri) “Alternatif URL’ler taşıma yöntemiyle (http/https) birlikte tam nitelikli olmalıdır; yani https://example.com/foo kullanılmalı, //example.com/foo veya /foo kullanılmamalıdır.” Büyük ölçekte bu genellikle tek yazım hatası değil, kısmi URL kalıbından üretildiği için binlerce URL’yi etkileyen şablon hatasıdır. Crawler’ların sistemik sorun olarak işaretlemesinin nedeni budur: birini bulduğunuzda çoğunlukla tüm şablonu bulursunuz.

4. adım — Öncelik: Önce dönüş etiketleri, sonra kodlar, en son x-default

Bu yazının en önemli fikri: Hata önem derecesi, hata sıklığıyla orantılı değildir. Bulguları aracın döndürdüğü satır sayısına değil, zarara göre sıralayın.

KademeHata düzeniNeden burada?
1 — önce düzeltEksik dönüş etiketleri; tutarsız dönüş bağlantısı kodlarıGoogle belgelerine göre tüm çiftin sinyalini bozar; en yüksek zarar.
2 — sonra düzeltGoogle’ın sessizce düzeltmediği yanlış kodlar (jp→ja); canonical olmayan/bozuk hedeflerTekil ilişkileri bozar; bazıları sessizce işlenir, bazıları işlenmez.
3 — toplu düzeltKarışık mutlak/göreli URL’ler, eksik self-referenceGerçek ve genellikle şablon geneli temizlik sorunlarıdır; her zaman kümeyi bozmaz.
4 — en sonEksik x-defaultEn yaygın, en az zararlı.

x-default’un her yerde olmasına rağmen sona kalmasının nedeni, tüm çalışmalarda en yaygın bulgu olmasıdır: 374 756 alan adlı çalışmamda %56,3, Dan Taylor’ın bağımsız 18 786 alan adlı SALT.agency çalışmasında %47,95. Ölçekleri farklı iki çalışma aynı sonucu veriyor: çoğu sitede yok. Ancak çalışmada yazdığım gibi: “Setting an x-default is not required. But it is recommended if you need a fallback page for users whose language settings don’t match any of your localized versions.” (çeviri) “x-default ayarlamak zorunlu değildir; ancak dil ayarları yerelleştirilmiş sürümlerinizle eşleşmeyen kullanıcılar için yedek sayfaya ihtiyacınız varsa önerilir.” Google ekibi bunu dizine ekleme için kritik sinyal değil, kullanıcı deneyimi yedeği sayar. Illyes, eşleşen dil olmadığında yedek sayfayı bildirdiğini ve bunun özel seçici yerine başka dilde bir sayfa da olabileceğini anlattı. Düzeltin, ancak kümeyi gerçekten bozan sorunlardan sonra.

Self-reference aynı nedenle 3. kademededir. Google’ın hreflang uygulamasında çalışan Illyes bile neden zorunlu olduğunu tam hatırlamadığını ve kümelerin onsuz da çalışacağından oldukça emin olduğunu söyledi; bunu esas olarak aynı bloğu her yere kopyalayıp yapıştırmayı kolaylaştıran kurulum temizliği olarak anlattı. İşlevsel gereklilik değil, uygulama düzenidir.

Yalnızca hreflang değil, uluslararası denetimin altı alanını kapsayan daha geniş etki × emek matrisi için burada yeniden kurmak yerine Uluslararası SEO Denetimi yazısındaki Çerçeveler merceğini kullanın.

5. adım — Taramaya değil, dizine eklenen URL’ye göre yeniden doğrulayın

Taramanız etiketleri doğrular. Etiketin gösterdiği URL’nin Google’ın gerçekten dizine eklediği URL olduğunu doğrulamaz. Hreflang dizine eklenen sürümü izlediği için, başka yere canonical olan, yönlendirilen veya sonraki aşamada noindex olan bir URL’yi gösteren etiket, toplu düzeltmeniz “temiz” raporlasa bile sinyali bozar.

Düzeltmeler yayımlandıktan sonra en değerli kümeleri Search Console’daki URL Inspection ile örnekleyin. Google’ın dizine eklenmiş olarak bildirdiği URL’nin hreflang’in gösterdiği URL ile aynı olduğunu doğrulayın. Düz etiket dışa aktarımında görünmeyen canonical zinciri sapmasını bu adım yakalar. Her URL için değil, tarama tamamlandı dedikten sonra her pazardaki değerli sayfalar için yapın.

Bing hakkında tek satır

Bing Webmaster Tools’un bunları doğrulamasını beklemeyin. Bing hreflang’i Google’dan daha zayıf bir sinyal sayar ve Geo Targeting özelliğini 2020’de kaldırmıştır; onun yerine Content-Language başlığına dayanır. Büyük ölçekli hreflang denetimi esasen Google’a yöneliktir. Bing için Content-Language’i ayrıca kontrol edin; bu konu Uluslararası SEO Denetimi yazısında ele alınır.

Uzman notu ekle

Uzman alıntısını sabitle

Yeni biri mi? Sahipsiz profilini şu bağlantıdan oluşturun: /admin/experts/ → Uzman alıntısını sabitle Bu işlemi önce tamamlayın.