İçindekiler Tablosu SEO: Sayfa İçi Bağlantı Rehberi

İçindekiler tablosu, uzun bir makalenin en üstünde yer alan ve her bölüme tek tıkla ulaştıran bağlantı listesidir. Böyle bir liste düzenli görünür, ama asıl soru şudur: okuyucuya, arama motoruna ve klavyeyle gezinen kişiye gerçekten bir şey kazandırıyor mu, yoksa yalnızca ekranın ilk yarısını mı işgal ediyor? İçindekiler tablosu SEO açısından bir sıralama düğmesi değildir; doğru kurulduğunda gezinmeyi hızlandıran, yanlış kurulduğunda ise erişilebilirliği ve sayfa düzenini bozan bir arayüz parçasıdır.

Bu yazı blog editörleri ve şablonu yazan frontend geliştiriciler için hazırlandı. Önce içindekiler tablosunun hangi uzunlukta ve hangi türde yazıda anlamlı olduğunu tartışır. Ardından fragment bağlantısının tarayıcıda nasıl çalıştığını, Google'ın resmî belgelerinin snippet içindeki bölüm bağlantıları hakkında ne söylediğini ve neyi söylemediğini ayırır. Başlık hiyerarşisiyle uyum, klavye ve atlama bağlantıları, sabit başlık çubuğu sorunu, kaydırma animasyonu ve mobil yerleşim ayrı bölümlerde ele alınır. Sonunda yayın öncesi kontrol listesi ve ölçüm önerisi vardır. Arama hacmi ya da rakip verisi paylaşılmaz; belge dışı genel uygulama bilgisi ayrıca etiketlenir.

İçindekiler Ne Zaman Gerekir?

İçindekiler tablosunu eklemeden önce ilk karar, yazının gerçekten taranmaya mı yoksa baştan sona okunmaya mı yöneldiğidir. Hikâye gibi akan bir köşe yazısında bölüm bağlantıları okuma akışını böler. Başvuru niteliğindeki bir rehberde, örneğin bir kontrol listesinde, bir sürece adım adım yön veren yazıda ya da birden çok alt konuyu kapsayan teknik anlatımda ise okuyucu çoğu zaman yalnızca tek bir bölüme gelir. Onun için tablo bir yol haritasıdır.

Uzunluk ve bölüm sayısı eşiği

Kesin bir kelime sayısı yoktur ve Google bu konuda bir eşik açıklamaz. Pratikte karar iki göstergeye bakar: sayfada kaç tane H2 var ve bir okuyucu sayfanın tamamını kaç ekran kaydırmadan görebiliyor. Üç H2'si olan, iki ekranda biten bir yazıda tablo gereksizdir; başlıklar zaten ekrana sığar. Yedi ya da sekiz H2'li, her bölümü birkaç yüz kelimeyi bulan bir rehberde tablo, okuyucuya yazının kapsamını daha ilk bakışta gösterir. Bu eşik yazar tecrübesine dayalı bir yönlendirmedir, Google belgelerinden gelen bir kural değildir.

Okuyucu niyeti

Aynı sayfaya gelen iki kişiyi düşünün. Biri bir terimin tanımını arıyor, diğeri bir uygulama sırasının üçüncü adımına dönüyor. Birincisi sayfanın girişini okur ve çıkar; ikincisi doğrudan ilgili bölüme atlamak ister. İçindekiler tablosu ikinci kişiyi kazanır, birinci kişiyi rahatsız etmez, yeter ki sayfanın en üstünde fazla yer kaplamasın. Bu yüzden tablo kısa, tek satırlık başlıklarla ve gerekirse yalnızca H2 düzeyinde kurulmalıdır.

Ne zaman gereksiz ya da zararlı?

Aşağıdaki durumlarda tabloyu eklememek daha iyidir:

• Yazı kısadır ve başlıklar zaten tek ekranda görünür.
• Başlıklar birbirine çok benziyor ve tablodaki satırlar ayırt edici değil.
• Tablo, giriş paragrafının önüne geçip okuyucunun yazının ne anlattığını görmesini engelliyor.
• Şablon, tabloyu H3 ve H4 düzeyine kadar açıyor ve ortaya yirmi satırlık bir duvar çıkıyor.
• Bölümler birbirine bağlı bir hikâyeyi anlatıyor ve rastgele bir bölümden girmek anlamsız kalıyor.

Tablo, belge kaynaklı bir sınıflandırma değil, editoryal bir değerlendirme önerisidir. Kurgusal örnek: bir blogda çok bölümlü bir kurulum rehberi yayınlanıyor. Okuyucu geri dönüp yalnızca beşinci adımı yeniden okumak istiyor. Tablo olmadığında sayfayı kaydırarak başlık arıyor; tablo varsa tek tıkla o başlığa iniyor. Bu örnekte rakam ya da gerçek bir site sonucu yoktur, yalnızca kullanım senaryosunu gösterir. Yazıların genel biçim kuralları için okunabilir içerik biçimlendirme rehberini ayrıca okuyabilirsiniz.

Çapa (Fragment) Bağlantıları ve SERP'te Sayfa İçi Bağlantı

İçindekiler tablosunun teknik temeli fragment bağlantısıdır. Bu bölümde önce tarayıcının bu bağlantıyı nasıl işlediğine, sonra Google'ın bağlantılarla ilgili iki ayrı belgesinden hangi sonucu çıkarabileceğinize bakılır. İki belge arasında sık karıştırılan bir fark vardır: biri taranabilir bağlantı biçimini anlatır, diğeri arama sonucunda görünen bölüm bağlantılarını.

Fragment tarayıcıda nasıl çalışır?

MDN'nin URL fragment açıklamasına (yeni sekmede açılır) göre fragment, adresin # işaretiyle başlayan son bölümüdür ve sunucuya gönderilmez; kaynak alındıktan sonra tarayıcı tarafından işlenir. HTML belgesinde tarayıcı, fragment'in id niteliğiyle eşleşen öğeye kaydırır. Örneğin adresin sonunda #kurulum varsa tarayıcı id değeri kurulum olan öğeyi arar ve sayfayı oraya taşır. Bu yüzden tablodaki her bağlantının hedefi, sayfada gerçekten var olan benzersiz bir id olmalıdır.

Belge, eşleşen öğe bulunmazsa ne olacağını anlatmaz. Genel gözleme göre tarayıcı genellikle sayfayı olduğu yerde bırakır ve hata göstermez, bu da kırık bir bağlantıyı fark etmeyi zorlaştırır. Bu davranış belgede geçmediği için kesin bilgi olarak değil, test edilmesi gereken bir varsayım olarak okunmalıdır. Kırık fragment'leri yakalamanın yolu, yayın öncesinde tablodaki her bağlantının hedef id'sinin sayfada bulunduğunu otomatik ya da elle sınamaktır.

Taranabilir bağlantı olmanın koşulu

Google'ın taranabilir bağlantılar belgesi (yeni sekmede açılır), Google'ın bir bağlantıyı yalnızca href niteliği olan bir a öğesi olduğunda tarayabildiğini söyler. onclick ile çalışan ya da javascript: ile başlayan adresler önerilmeyen örnekler arasında sayılır; belge, Google'ın bunları yine de çözmeye çalışabileceğini ekler. Belge ayrıca iyi bağlantı metninin açıklayıcı, makul ölçüde kısa ve hem bulunduğu sayfa hem hedef sayfa ile ilgili olması gerektiğini yazar. Aynı belge fragment kimliklerini ayrıca anlatmaz; bu yüzden fragment bağlantısının arama sonucunda nasıl işleneceğine dair çıkarım bu belgeden yapılmamalıdır. Pratik sonuç şudur: içindekiler tablosunu düğme ya da script ile kaydıran bir yapı yerine, gerçek href taşıyan bağlantı olarak kurun. Bu, hem erişilebilirlik hem de bağlantı davranışı için en az riskli yoldur.

Snippet'te bölüm bağlantısı: belge ne söylüyor?

Arama sonucunda bazen sayfanın belirli bir bölümüne giden bir bağlantı görünür. Google'ın snippet belgesi (yeni sekmede açılır) bunu "Read more" derin bağlantısı olarak adlandırır ve snippet içinde kullanıcıyı sayfadaki belirli bir bölüme götüren bağlantı olarak tanımlar. Belge bu bağlantıların çıkma olasılığını artıran üç uygulamayı sıralar: içeriğin bir insan için hemen görünür olması, yani genişleyen bir bölümün ya da sekmeli bir arayüzün arkasında saklı olmaması; sayfa yüklenirken kaydırma konumunu JavaScript ile kontrol etmemek; ve sayfa yüklenirken history API ya da hash değişikliği yapılıyorsa URL'deki hash fragment'ini silmemek, çünkü bu derin bağlantı davranışını bozar.

Bu üç madde içindekiler tablosu açısından anlamlıdır, ama belge iki şeyi söylemez. Birincisi, içindekiler tablosu eklemenin bu bağlantıları getireceğini söylemez. İkincisi, hangi sonuçta ve hangi sorguda bu bağlantıların gösterileceğini sizin seçebileceğinizi söylemez. Belge yalnızca olasılığı artıran uygulamaları sıralar. Dolayısıyla "içindekiler eklersek sonuçta bölüm bağlantıları çıkar" demek belge dışı bir iddiadır. Doğru ifade şudur: tablo gezinmeyi kolaylaştırır, derin bağlantı davranışını bozabilecek hataları ise ayrıca önlemek gerekir.

Derin bağlantıyı bozan tipik hatalar

Belgenin üç maddesinden yola çıkarak şablon düzeyinde şunlara dikkat edin:

1. Bölüm içerikleri akordeon ya da sekmeye gömülmüşse hedef metin ilk yüklemede kullanıcıya görünmez. Okunması gereken ana metni genişleyen bir alanın içine saklamayın.
2. Sayfa yüklenirken script ile en üste ya da başka bir yere kaydırma yapan bileşenler, tarayıcının fragment'e gitmesini geçersiz kılabilir. Yükleme sonrası kaydırma konumunu elle değiştirmeyin.
3. Tek sayfa uygulaması mantığıyla çalışan sayfalarda yönlendirme kodu hash'i silebilir. URL'de # sonrasını koruyun.
4. Çerez bildirimi ya da sabit bir üst çubuk hedefin üstünü kapatabilir; bu sorun sonraki bölümde erişilebilirlik açısından da ele alınır.

Bölüm adreslerini paylaşmanın pratik yararı

Arama sonucundan bağımsız olarak, fragment adresi paylaşılabilir bir bölüm bağlantısıdır. Bir ekip arkadaşına ya da müşteriye sayfanın yalnızca üçüncü bölümünü göstermek istediğinizde adresin sonuna id'yi eklemeniz yeter. Başlıkların yanında küçük bir bağlantı simgesi gösteren şablonlar bu kullanımı kolaylaştırır. Bu özellik bir arama sıralama avantajı sunmaz; okuyucuya ve ekibe kolaylık sağlar.

Başlık Hiyerarşisiyle Uyum

İçindekiler tablosu başlıkların bir kopyasıdır; başlıklar bozuksa tablo da bozuk olur. Bu nedenle tablonun kaynağı serbest yazılan bir liste değil, makalenin gerçek H2 ve H3 başlıkları olmalıdır. Başlık seviyelerinin nasıl kurulacağı başlık etiketleri rehberinde ayrıntılı anlatılıyor; burada yalnızca tabloyla kesişen noktalar ele alınır.

Tabloyu başlıklardan üretmek

El ile yazılan bir tablo bir süre sonra makaleden ayrışır: editör bir başlığı yeniden adlandırır, tablo eski adı taşımaya devam eder. Başlıklardan otomatik üretilen tablo bu sapmayı önler. Şablon, gövdedeki H2 ve gerekiyorsa H3 öğelerini tarayıp her biri için bir bağlantı üretir. Bunun için başlıkların bir id taşıması gerekir; id yoksa şablon başlık metninden bir id türetir. Türetilen id'lerde Türkçe karakterler, boşluklar ve noktalama işaretleri sadeleştirilmeli, aynı metne sahip iki başlık için ikinci id'ye ayırt edici bir ek getirilmelidir. Aksi halde iki bağlantı aynı yere gider.

İd'ler kalıcı olmalı

Bir başlığın id'si, yazı yayınlandıktan sonra dışarıdan bağlantılara dönüşebilir: bir okuyucu paylaşır, başka bir yazar bölümü kaynak gösterir. Başlığın metnini sonradan düzeltirseniz ve id otomatik olarak yeniden türetilirse eski bağlantı sessizce kırılır. Bu yüzden id'yi başlık metninden bağımsız, bir kez üretilip kaydedilen bir değer olarak tutmak ya da değişen başlıklarda eski id'yi koruyacak bir kural yazmak gerekir. Hangi stratejiyi seçerseniz seçin, kural ekibin ortak notunda yazılı olmalıdır.

Türkçe ve İngilizce sürümleri olan bir sitede id'ler dil bazında ayrı olabilir. İki dilde aynı id'yi kullanmak zorunlu değildir; kullanıcı kendi dilindeki sayfada kendi dilindeki id'yi görür. Yine de dil değiştirici bölüm düzeyinde çalışacaksa eşleştirme tablosu gerekir. Basit çözüm, dil değiştirdiğinde kullanıcıyı sayfanın üstüne götürmektir.

Hangi başlık düzeyleri tabloya girmeli?

Çoğu yazıda yalnızca H2'ler yeterlidir. H3'ler tabloya eklenirse liste kalabalıklaşır ve okuyucu yazının ana iskeletini görmekte zorlanır. Çok uzun, referans niteliğindeki sayfalarda H3'leri iç içe bir alt liste olarak göstermek mantıklı olabilir. Uygulamada bir sınır belirleyin: tablo ekranın üçte birinden fazlasını kaplıyorsa daraltın. Bu eşik de belge kaynaklı değil, tasarım önerisidir. Başlık ağacında seviye atlamak, örneğin H2'den doğrudan H4'e geçmek, hem tabloda anlamsız girintilere hem de ekran okuyucu gezinmesinde karışıklığa yol açar.

Başlık metni tabloda da anlaşılır olmalı

Tablo satırları bağlamdan koparak okunur; bu nedenle başlık metni tek başına bir anlam taşımalıdır. "Giriş", "Sonuç" ya da "Devam" gibi etiketler listede ne anlattığını söylemez. "Sabit başlık çubuğunda hedefin kapanması" gibi somut bir etiket, okuyucuya o bölümde ne olduğunu önceden gösterir. Bu aynı zamanda Google'ın bağlantı metni için verdiği ölçütle uyumludur: açıklayıcı, kısa ve hedefle ilgili. Başlıkları yazarken anahtar kelime doldurma ihtiyacı duymayın; doğal ve açıklayıcı ifade hem tablo hem arama için yeterlidir. Uygun uzunluk ve bölüm sayısı için SEO içerikleri için ideal kelime sayısı yazısındaki yaklaşım da yardımcı olur.

Erişilebilirlik: Klavye ve Atlama Bağlantıları

İçindekiler tablosu bir gezinme aracıdır; bu yüzden fare kullanmayan okuyucular için de çalışmalıdır. W3C'nin WCAG 2.2 anlama belgeleri birkaç kriteri bu konuyla ilişkilendirir. Aşağıdaki başlıklar bu belgelerin ilgili kriterlerine dayanır.

Atlama bağlantısı ve içerik bağlantıları

WCAG 2.2'nin bloklar atlanabilir kriteri (yeni sekmede açılır) (2.4.1, A düzeyi), birden çok sayfada tekrarlanan içerik bloklarını atlamak için bir mekanizma bulunmasını ister. Anlama belgesi yeterli teknikler arasında sayfanın başında ana içeriğe giden bir bağlantıyı (G1) ve sayfanın üstüne her içerik alanına bağlantılar eklemeyi (G124) sayar. Her bölümün başında başlık öğesi kullanmak da (H69) bu tekniklerdendir. Belge ayrıca tarayıcıların çoğunun sayfanın üstüne odak taşıyan klavye kısayolları sunduğunu belirtir, bu yüzden bir atlama bağlantısı her koşulda şart olmayabilir.

Bu bilgi uygulamada şuna çevrilir: makalenin üstündeki içindekiler tablosu, kendi başına bir bölüm atlama aracı olarak işe yarar. Bu değerlendirme bir yorumdur; belge içindekiler tablosunu doğrudan bir yeterli teknik olarak adlandırmaz. Ana içeriğe atlama bağlantısı ayrıca sitenin şablonunda bulunmalıdır. Kullanıcı klavye ile sayfaya girdiğinde ilk Tab ile ana içeriğe geçebiliyorsa, makale içi tabloya geldiğinde de bölümler arasında benzer bir kolaylık bulur.

Anlamlı işaretleme

Tabloyu bir gezinme bölgesi olarak işaretlemek, ekran okuyucu kullanıcılarının onu bulmasını kolaylaştırır. Bir nav öğesi ve ona verilmiş kısa bir ad (örneğin "Bu yazıda") yeterlidir. Belge, ilişkili bağlantıları nav ile gruplamayı tavsiye niteliğinde bir teknik olarak sayar. Tablo liste yapısıyla kurulmalıdır, çünkü ekran okuyucular listede kaç öğe olduğunu bildirir; bu son ayrıntı belge dışı genel bir gözlemdir. Tablonun başlığı da görünür olmalı; yalnızca kutu içinde bağlantı sıralamak yeterince açıklayıcı değildir.

Klavyeyle odak ve sabit başlık çubuğu

Tablodaki bağlantıya Enter ile geçildiğinde tarayıcı hedef başlığı görünür alana getirir. Sitenin üst kısmında sabit bir menü varsa hedef başlık bu menünün altında kalabilir. WCAG 2.2'nin odak gizlenmemeli kriteri (yeni sekmede açılır) (2.4.11, AA düzeyi) odaktaki bir bileşenin, yazar tarafından oluşturulmuş içerik tarafından tamamen gizlenmemesini ister. Anlama belgesi sabit üst ve alt çubukları ve etkileşimli olmayan iletişim kutularını yaygın örnekler olarak anar ve geçmek için CSS scroll-padding kullanımını yeterli bir teknik (C43) olarak listeler. Bu, kaydırma sırasında odaklanan öğenin sabit alanın altına düşmesini engeller.

Uygulamada tarayıcı fragment hedefine kaydırdığında başlığın menü altında kalmaması için kaydırma payı bırakın. Belge scroll-padding tekniğini odak bağlamında anlatır; fragment hedefi için aynı payın nasıl uygulandığını sayfanızda sınayın ve gerçek tarayıcıda doğrulayın. Aynı soruna bir diğer yaklaşım sabit menüyü küçültmek ya da makale sayfalarında sabit olmaktan çıkarmaktır.

Kaydırma animasyonu ve hareket tercihi

İçindekiler bağlantılarına tıklandığında yumuşak kaydırma kullanmak cazip gelir. MDN'nin scroll-behavior sayfası (yeni sekmede açılır), smooth değerinin gezinme ya da CSSOM kaydırma API'leriyle tetiklenen kaydırmalarda yumuşak bir kaydırma ürettiğini, varsayılanın ani kaydırma olan auto olduğunu ve kullanıcı aracılarının bu özelliği yok sayabileceğini belirtir. Sayfa içi bir bağlantıya tıklamanın da yumuşak kaydırmayı tetiklediği belgedeki örnekte gösterilir.

Hareket duyarlılığı olan kullanıcılar için W3C'nin etkileşimden doğan animasyon kriteri (yeni sekmede açılır) (2.3.3, AAA düzeyi) gereksiz hareket animasyonunun kapatılabilmesini ister. Belge, parallax kaydırmayı vestibüler tepki yaratabilen gereksiz animasyon örneği olarak anar. Aynı sayfada prefers-reduced-motion CSS ortam sorgusunun hareketi önlemek için yeterli bir teknik (C39) olduğu yazılıdır. Bu AAA düzeyinde bir kriterdir; projenizin hedefi AA ise zorunlu değildir, ama içindekiler tablosunda yumuşak kaydırma kullanıyorsanız bu tercihi gözetmek iyi bir uygulamadır.

Dokunma hedefi boyutu

Tablodaki satırlar mobilde parmakla basılır. WCAG 2.2'nin hedef boyutu kriteri (yeni sekmede açılır) (2.5.8, AA düzeyi) işaretçi hedeflerinin en az 24 x 24 CSS pikseli olmasını ister; aralık, eşdeğer kontrol, cümle içi bağlantı ve kullanıcı aracısı denetimi gibi istisnaları vardır. Bu kural zoom'dan bağımsızdır. Cümle içi bağlantılar istisna olsa da ayrı satırda yer alan tablo bağlantılarının bu istisnaya girdiğini varsaymayın; tablo satırlarında yeterli dikey iç boşluk bırakın.

Hızlı klavye testi

1. Fareyi bırakın ve yalnızca Tab ile tabloya ulaşabildiğinizi doğrulayın.
2. Odak halkasının her bağlantıda görünür olduğunu kontrol edin.
3. Enter'a bastığınızda hedef başlığın sabit menünün altında kalmadığını görün.
4. Hedefe geldikten sonra bir sonraki Tab'ın hedef bölümdeki ilk etkileşimli öğeye gidip gitmediğine bakın.
5. Tarayıcının hareketi azalt ayarını açıp yumuşak kaydırmanın kapandığını doğrulayın.

Mobilde Yerleşim ve Ölçüm

İçindekiler tablosu masaüstünde sağ sütunda sabit durabilir; mobilde böyle bir lüks yoktur. Dar ekranda tablo gövdeyi aşağı iter ve ilk paragrafa ulaşmayı geciktirir. Bu bölümde yerleşim seçenekleri ve ölçüm önerileri yer alır. Buradaki yerleşim önerileri tasarım pratiğidir, belge kaynaklı kural değildir.

Yerleşim seçenekleri

Daraltılmış listede bir ayrıntı vardır. Google'ın snippet belgesi, içeriğin genişleyen bir bölümün arkasında saklanmamasını önerir. İçindekiler listesi ana içerik değil gezinme yardımıdır, bu yüzden daraltmak bu uyarının doğrudan konusu değildir; yine de başlıkların ve gövde metninin kendisi daraltılmış bir bileşenin içine alınmamalıdır. Bu bir yorumdur ve belge içindekiler listesini özel olarak anmaz.

İlk ekranı koruma

Mobilde tablo, sayfanın başlığı ve giriş paragrafından sonra gelmelidir. Okuyucu ilk saniyelerde yazının neyi anlattığını görmek ister. Bölüm sayısı çoksa liste varsayılan olarak kapalı başlayabilir ve "Bu yazıda" gibi açıklayıcı bir düğmeyle açılabilir. Düğme gerçek bir button olmalı, klavyeyle çalışmalı ve açık ya da kapalı durumunu ekran okuyucuya bildirmelidir. Daraltma bileşeninin sayfa yüklemesinde yer değiştirmeye neden olmadığından emin olun; düzen kayması okuyucuyu rahatsız eder.

Okunabilirlik ve satır uzunluğu

Uzun makaleler küçük ekranda kolay yorar. Kısa paragraflar, bol boşluk ve iyi ayrılmış başlıklar okuyucunun kaybolmasını önler. İçindekiler tablosu bu yapıyı tamamlar ama onun yerini tutmaz. Dar bir ekranda yirmi satırlık bir liste okuyucuyu yazıdan uzaklaştırır; satır sayısını azaltmak için başlıkları gözden geçirin. Çok sayıda H2'si olan bir yazı bazen iki ayrı yazıya bölünmeye daha uygundur.

Ölçüm: neye bakılmalı?

Tablonun işe yarayıp yaramadığını görmek için yalnızca sıralamaya bakmak yanıltıcıdır. Google'ın belgelerine göre içindekiler tablosunun sıralamaya etkisi hakkında bir iddia yoktur. Bunun yerine davranışsal ve teknik göstergeleri izleyin:

• Tablo bağlantılarına tıklanma oranı ve en çok tıklanan başlıklar.
• Tabloya tıklayan oturumlarda kaydırma derinliği ve sayfada geçirilen süre.
• Mobil ve masaüstü kullanıcılarda tablo kullanımının karşılaştırması.
• Düzen kayması ve ilk ekran içeriğinin görünme süresi gibi performans göstergeleri.
• Search Console'da yazıya gelen sorguların ve görüntülemelerin, tablo eklenmeden önce ve sonra karşılaştırması; nedensellik iddia etmeden.

Ölçüm kurarken önce tıklamaları etkinlik olarak kaydedin; kullanıcının çerez tercihine saygı gösterin. Karşılaştırmada yalnızca tek değişkeni değiştirin, yani tabloyu ekleyin ya da kaldırın ve diğer şablon değişikliklerini aynı döneme koymayın. Aksi halde bir sonuç gözlemlediğinizde bunun tablodan mı yoksa başka değişiklikten mi geldiğini ayıramazsınız.

Kurgusal örnek: bir şablon güncellemesi

Kurgusal örnek: bir blog ekibi uzun rehberlerine içindekiler tablosunu ilk kez ekliyor. Tablo yalnızca H2 düzeyindedir ve mobilde varsayılan olarak kapalıdır. İlk hafta ekip, hangi başlığın en çok tıklandığına bakıyor ve yazının ortasındaki bir bölümün beklenenden çok daha sık seçildiğini fark ediyor. Bu bilgi, o bölümün yazının girişinde kısaca özetlenmesi gerektiğini gösteriyor. Örnek rakam içermez ve gerçek bir sonuç değildir; tıklama verisinin editoryal karar için nasıl kullanılabileceğini gösterir.

Sık Yapılan Hatalar

• Tabloyu sıralama aracı sanmak: Google'ın belgeleri içindekiler tablosunun sıralamayı ya da snippet bağlantısını garanti ettiğini söylemez.
• Bağlantıyı script ile çalıştırmak: href yerine onclick kullanmak Google'ın bağlantıyı tarama güvenilirliğini düşürür.
• Tekrar eden id kullanmak: İki başlığa aynı id verilirse iki bağlantı aynı yere gider.
• Başlık değişince id'yi değiştirmek: Dışarıdan alınmış eski bağlantılar sessizce kırılır.
• Sabit menüyü hesaba katmamak: Hedef başlık menünün altında kalır, odak gizlenebilir.
• Ana metni daraltılmış bileşene gömmek: Derin bağlantı olasılığını azaltabilir.
• Tabloyu gereğinden uzun yapmak: Okuyucu yazıya ulaşmadan yoruluyor.
• Hareket tercihini yok saymak: Zorunlu yumuşak kaydırma bazı kullanıcılar için rahatsız edicidir.

Yayın Öncesi Kontrol Listesi

1. Yazı gerçekten uzun ve taranmaya yönelik mi, yoksa tablo gereksiz mi?
2. Tablo, makalenin gerçek H2 başlıklarından mı üretiliyor?
3. Her bağlantı href taşıyan gerçek bir a öğesi mi?
4. Her hedef id sayfada tek mi ve başlık metni değişse bile kalıcı mı?
5. Başlık seviyeleri sırayla mı, H2'den H4'e atlama var mı?
6. Tablo bir nav bölgesi içinde, görünür başlıkla ve liste yapısıyla mı kurulu?
7. Sabit menü hedef başlığı kapatıyor mu, kaydırma payı ayarlı mı?
8. Satırlar mobilde yeterince büyük ve odak halkası görünür mü?
9. Yumuşak kaydırma varsa hareket azaltma tercihi korunuyor mu?
10. Gövde metni daraltılmış bir bileşenin içinde gizlenmiyor mu?
11. Tıklama etkinliği ve düzen kayması izleniyor mu?

Bu liste bir erişilebilirlik denetiminin yerini tutmaz; amacı içindekiler tablosunun yaygın hatalarını yayın öncesinde yakalamaktır.

Sıkça Sorulan Sorular

İçindekiler tablosu SEO'ya yardımcı olur mu?

Google belgeleri içindekiler tablosunun sıralamayı artırdığını söylemez. Tablo gezinmeyi kolaylaştırır ve doğru kurulursa bağlantıların taranabilir olmasını sağlar. Etkisi okuyucu deneyimi üzerinden dolaylı olabilir, ancak bunu kesin sonuç gibi sunmak doğru olmaz.

İçindekiler tablosu arama sonucunda sayfa içi bağlantı çıkarır mı?

Garanti yoktur. Google'ın snippet belgesi bölüm bağlantılarının çıkma olasılığını artıran uygulamaları sıralar: içeriğin hemen görünür olması, sayfa yüklenirken kaydırmayı JavaScript ile yönetmemek ve hash fragment'i silmemek. Hangi sonuçta görüneceği Google'ın kararıdır.

İçindekiler bağlantıları için hangi HTML kullanılmalı?

Href niteliği olan gerçek bağlantılar kullanılmalı ve hedef başlıklar benzersiz id taşımalıdır. Google yalnızca href niteliği olan bağlantıları güvenilir biçimde tarayabildiğini söyler; onclick ya da javascript: adresleri önerilmez.

Sabit menü hedef başlığı kapatırsa ne yapılmalı?

WCAG 2.2'nin odak gizlenmemeli kriteri sabit üst çubukların odaktaki bileşeni tamamen kapatmamasını ister. CSS scroll-padding bu amaçla önerilen bir tekniktir. Sayfanızda gerçek tarayıcıyla hedefe giderek başlığın görünür kaldığını doğrulayın.

Mobilde tabloyu kapalı başlatmak sorun olur mu?

İçindekiler listesi gezinme yardımı olduğu için kapalı başlatmak genellikle kabul edilebilir. Ana makale metnini daraltılmış bir bileşenin içine koymak ise derin bağlantı davranışını olumsuz etkileyebilir. Düğme klavyeyle çalışmalı ve durumunu bildirmelidir.

Yumuşak kaydırma kullanmak doğru mu?

Kullanılabilir, ancak hareket duyarlı kullanıcılar için prefers-reduced-motion tercihini gözetmek iyi bir uygulamadır. Bu tercih W3C'nin etkileşimden doğan animasyon kriterinde yeterli bir teknik olarak anılır. Kullanıcı aracılarının scroll-behavior özelliğini yok sayabileceğini de unutmayın.

Sonuç

İçindekiler tablosu, doğru yazıda ve doğru biçimde kurulduğunda uzun makalelerde gezinmeyi hızlandıran güvenilir bir yardımcıdır. Tablonun temeli gerçek başlıklar, kalıcı id'ler ve href taşıyan bağlantılardır. Erişilebilirlik tarafında klavye, sabit menü, hareket tercihi ve dokunma hedefi boyutu birlikte düşünülmelidir. SEO tarafında beklenti sınırlı tutulmalıdır: Google'ın belgeleri tablonun sıralama ya da snippet bağlantısı getireceğini söylemez, yalnızca derin bağlantı olasılığını artıran uygulamaları sıralar.

Uzun makalelerinizi yapılandırılmış, okunabilir ve kaynaklı biçimde hazırlatmak isterseniz Akua Adforce'ta SEO içerik yazımı hizmetini inceleyebilirsiniz; kapsam ve koşullar ilgili ürün sayfasında yazılıdır. Bu yazıdaki öneriler genel teknik rehberdir ve belirli bir sıralama ya da dizinleme sonucu garanti etmez.