06 Ara 2025·8 dk
Arama Sonuçlarında Sıralanan Bir Bilgi Tabanı Web Sitesi Nasıl Oluşturulur
Bilgi tabanı sitesi nasıl kurulur: yapı, anahtar kelimeler, şablonlar, dahili bağlantılar, schema, sayfa hızı ve uygulayabileceğiniz analizler öğrenin.
Bilgi tabanı sitesi nasıl kurulur: yapı, anahtar kelimeler, şablonlar, dahili bağlantılar, schema, sayfa hızı ve uygulayabileceğiniz analizler öğrenin.
Bir bilgi tabanı web sitesi sadece makalelerin bir koleksiyonu değildir—aynı zamanda bir ürün kanalıdır. Başta net hedefler belirlediğinizde, içerik kararları (ve SEO tercihleri) neyi optimize ettiğinizi bildiğiniz için daha kolay olur.
Yardım merkezinizin sağlaması gereken temel sonucu seçin:
Öncelik konusunda dürüst olun. Sorun giderme odaklı bir bilgi tabanı, ürün eğitimi amaçlı olan bir merkezden farklı görünecektir.
Çoğu bilgi tabanı birden fazla kitleye hizmet eder ve her birinin farklı bir kelime dağarcığı vardır:
İlk içerik dalgası için en iyi 1–2 hedef kitleyi tanımlayın. Bu, erken SEO hedeflerini gerçekçi tutar ve henüz kimsenin ihtiyaç duymadığı makaleler yazmanızı engeller.
Trafiği iş değeriyle bağlayan küçük bir metrik seti izleyin:
“Şifre sıfırlama ticket’larını 90 günde %30 azalt” veya “kurulum rehberlerine gelen organik girişleri bu çeyrekte %40 artır” gibi hedefler koyun.
Yayınlayacaklarınızı netleştirin—ve doğruluğu korumaya taahhüt edin:
Hedefler, kitleler, metrikler ve içerik türleri tanımlandıktan sonra net bir SEO kapsamınız olur: hangi konular önemli, “başarı” nasıl görünür ve hangilerini henüz oluşturmamanız gerektiği.
Bilgi tabanı için anahtar kelime araştırması, müşterilerin gerçekten sorduğu sorularla başladığında en iyi sonucu verir—pazarlamanın varsaydığıyla değil. Destek kanallarınız, gerçek sorgularda görünen ifade biçimini, aciliyeti ve bağlamı zaten içerir.
Birkaç hafta (veya ay) verisini çekin:
Sadece konu satırını kopyalamayın. Tam soruyu, ürün alanını ve herhangi bir hata metnini yakalayın. “Faturam neden pending durumda kaldı?” gibi tam ifadeler genellikle en iyi uzun kuyruk sorgusu olur.
Soruları topladıktan sonra, onları arama terimlerine çevirin ve niyeti etiketleyin:
Bu önemlidir çünkü makale formatı niyete uymalıdır. Bilgilendirici sorgular genellikle net bir tanım ve örnekler ister. Sorun çözme sorguları hızlı teşhis, adım adım düzeltmeler ve “eğer bu ise, şu” rehberleri gerektirir.
İnsanların ürününüzü öğrenme biçimine göre soruları kümelere ayırın:
Kümelenme, yinelenen makalalardan kaçınır ve bir “ebeveyn” sayfa (geniş rehber) ile “çocuk” sayfaları (belirli görevler ve çözümler) tanımlamanıza yardımcı olur.
Her soru hemen bir makale gerektirmez. Üç sinyale göre önceliklendirin:
Pratik bir kural: sık tekrar eden ve ekibiniz için maliyeti yüksek destek sorunlarıyla başlayın; temel kurulumlar tamamlandığında daha geniş eğitim içeriklerine genişleyin.
Bir bilgi tabanı, yapısı kadar aranabilirdir. Amaç, her bölümün neyle ilgili olduğunu (hem kullanıcılar hem arama motorları için) ve sayfaların birbirleriyle nasıl ilişkili olduğunu açıkça göstermektir.
Çoğu yardım merkezi üç seviyeli bir modelle daha iyi çalışır: kategoriler → alt kategoriler → makaleler. Site genelinde tutarlı tutun ki ziyaretçiler nerede olduklarını düşünmeden “taramayı” devam ettirebilsin.
Pratik bir örnek:
Derin iç içe geçmiş yapılardan (beş ya da altı tıklama) kaçının. Önemli cevaplar ana sayfadan birkaç adım içinde erişilebilir olmalı.
Her büyük konu için, konuyu yüksek seviyede açıklayan ve en sık yapılan görevlere yönlendiren bir pillar sayfası oluşturun.
Örneğin, “Manage invoices” gibi bir pillar sayfası temel kavramları (fatura takvimi, ödeme yöntemleri, iadeler) kısaca ele alıp “Download an invoice” veya “Change billing email” gibi görev makalelerine bağlantı verebilir. Bu, küme içinde alaka düzeyini güçlendirir ve her anahtar kelimeyi tek bir sayfaya yığmadan etki yaratır.
Yıllarca sabit kalabilecek URL desenleri seçin. Sık URL değişiklikleri sıralama kaybına, kırık yer imlerine ve daha fazla destek ticket’ına yol açar.
İyi desenler:
Yaygın seçenekler:
/help/billing/invoices/download-invoice//kb/account/security/enable-2fa/Eğer kategori isimlerini sıkça yeniden adlandırıyorsanız, kategori adlarını URL’lerden çıkarıp /help/ gibi sabit bir taban kullanmayı düşünebilirsiniz. Eğer kategoriyi URL’ye dahil ederseniz, değişikliklerden kaçının.
Çekirdek sayfaların normal gezinme ve dahili bağlantılar yoluyla keşfedilebilir olduğundan emin olun (sadece dahili arama yoluyla değil). Ayrıca:
Açık bir mimari ve sabit URL’ler, hem okuyucular için sürtünmeyi azaltır hem de arama motorlarına bilgi tabanınızın güçlü, tutarlı bir haritasını verir.
Gezinim, bilgi tabanı SEO ile kullanıcı deneyiminin kesiştiği yerdir. Eğer müşteriler hızlıca cevap bulamıyorsa, siteyi terk ederler (ve ticket açarlar). Eğer tarayıcılar hiyerarşinizi yorumlayamazsa, en iyi makaleleriniz sıralanamayabilir.
Kullanıcıların düşündüğü şekilde (Billing, Account, Troubleshooting, Integrations) küçük bir üst düzey kategori setiyle gezinim oluşturun. Etiketlerde dahili ekip isimlerinden kaçının; ifadeler sade olsun.
Her makaleye breadcrumbs ekleyin ki hem insanlar hem arama motorları sayfanın yapısını görsün ve kullanıcılar yeniden başlamak zorunda kalmadan geri dönebilsin.
Her kategori içinde bir yan menü en önemli makaleleri listelemeli (tüm makaleleri değil). Çok fazla içeriğiniz varsa, yan menüyü alt konulara ayırın ve geçerli bölümü genişletilmiş gösterin.
Bilgi tabanınızın başlık kısmında belirgin bir arama kutusu olmalı; arama sayfasına gömülü veya indeks sayfasına saklı olmamalı.
Otomatik tamamlama önerileri kullanıcının kendini düzeltmesine yardımcı olur ve kitlenizin kullandığı ifadeleri ortaya çıkarır. Öncelik verin:
Arama sonuçları zayıfsa kullanıcılar tekrar Google’a döner—bu güven ve dönüşüm açısından kötüdür.
Her kategoriyi birkaç cümleyle özetleyen ve ana makalelere bağlantı veren dizin sayfaları oluşturun. Bu sayfalar:
Hedef: ana sayfadan herhangi bir makaleye 2–3 adım içinde ulaşılabilsin. Beş katmandan fazla tıklama gerekiyorsa, hem insanlar hem tarayıcılar içeriği daha az önemli olarak algılar.
Pratik kontrol: on yüksek değerli makaleyi seçin (en çok ticket üretenler) ve kategori → alt kategori → makale yoluyla erişilebilir olduklarını doğrulayın; ölü sonlar veya yinelenen yollar olmadığından emin olun.
Tutarlı bir makale şablonu, yardım merkezinizin yazılmasını, taranmasını ve arama motorlarının anlamasını kolaylaştırır. Ayrıca destek tekrarlarını azaltır çünkü her makale aynı “eksik parçaları” (bu neyi çözer, neler gerekir, başarısız olursa ne yapılır) cevaplar.
Sayfa başına bir H1 kullanın ve müşterinin yazacağı ana sorguyla eşleşsin.
İlk paragrafı kısa tutun (2–3 cümle) ve niyeti onaylayın: bu makale okuyucuya ne yaptıracak.
Çoğu nasıl yapılır ve sorun giderme makalesi için bu yapıyı kullanın:
Taranabilir bölümler yazın: kısa paragraflar, adım listeleri ve gerekiyorsa küçük tablolar.
| Problem | Olası neden | Çözüm |
|---|---|---|
| Reset e-postası hiç gelmiyor | Yanlış adres veya spam filtresi | Spam klasörünü kontrol edin, e-postayı doğrulayın, tekrar gönderin |
Takip sorularını önleyecek detayları ekleyin:
Görseller ekliyorsanız, erişilebilirlik ve sayfa konusunu güçlendirmek için tanımlayıcı alt metin ve başlık kullanın (örn. “Giriş sayfasındaki şifre sıfırlama bağlantısı”).
Tekrarlayan bölümler (Önkoşullar, Sorun giderme, Destek ile iletişim) için yeniden kullanılabilir parçalar oluşturun. Tutarlılık kalite kontrolü artırır ve güncellemeleri hızlandırır—böylece makale doğru kalır, daha uzun süre sıralanır ve daha fazla ticket yönlendirir.
Dahili bağlantılar, hem okuyucuların hem de arama motorlarının yardım içeriğinizin nasıl bağlandığını anlamasına yardımcı olur. Güçlü bir bağlantı sistemi, parçalanmış makale yığınını birbirini destekleyen bir kaynağa dönüştürür.
En büyük temalarınız için küçük bir pillar sayfa seti seçin (ör. “Başlarken”, “Faturalama”, “Entegrasyonlar”, “Sorun Giderme”). Her pillar, konuyu özetlemeli ve en iyi adım adım makalelere işaret etmelidir.
Niyetli bağlantı verin:
Kategoriler genellikle geniştir; kullanıcılar görev düşünür. Küçük bir “İlgili makaleler” bloğu ekleyin ve kullanıcının muhtemel bir sonraki adımını yansıtın.
İyi “İlgili” örüntüleri:
Anchor metin, aranan sayfanın ne hakkında olduğunu arama motorlarına söyler; kullanıcıya da ne alacaklarını bildirir.
“Buraya tıklayın” veya “daha fazla öğren” gibi belirsiz etiketlerden kaçının. “Fatura adresinizi güncelleyin”, “CSV’ye rapor dışa aktarın” veya “‘izin reddedildi’ hatasını düzeltin” gibi açıklayıcı ifadeleri tercih edin.
Yardım merkeziniz satış amaçlı olmamalı, ama bazı makaleler doğal olarak ürün akışlarına bağlanır. İlgili olduğunda, okuyucunun plan sınırlarını, politikaları veya yetenekleri teyit etmesi için görece göreli URL’ler kullanarak ana ürün sayfalarına bağlanın (örn. /pricing veya /security).
Yayınlamadan önce, her makalenin en az şunlara sahip olduğundan emin olun:
Zaman içinde bu bağlantılar en güçlü konularınızın daha fazla görünürlük kazanmasına yardımcı olur ve kullanıcıları doğru cevaba daha hızlı yönlendirerek destek yükünü azaltır.
Yapılandırılmış veri, arama motorlarının yardım içeriğinizin ne olduğunu (SSS, adım adım rehber, breadcrumb) daha iyi anlamasına yardımcı olan küçük bir kod katmanıdır. Doğru kullanıldığında, sayfalarınızın sonuçlarda görünüşünü iyileştirebilir ve bilgi tabanınızı yorumlamayı kolaylaştırabilir.
FAQPage schema’sını, gerçekten soru-cevap listesinden oluşan sayfalara ekleyin (ör. “Faturalama SSS” veya “Sorun Giderme SSS”). Bir sayfada bir SSS bölümü olduğu için her sayfaya eklemeyin—aşırı kullanım niyeti karıştırabilir ve uygunluk sorunları yaratabilir.
A basit JSON-LD örneği:
{
"@context": "https://schema.org",
"@type": "FAQPage",
"mainEntity": [
{
"@type": "Question",
"name": "How do I reset my password?",
"acceptedAnswer": {
"@type": "Answer",
"text": "Go to Settings > Security, then choose Reset password. You'll receive an email with a link."
}
}
]
}
Açık adımları olan (ve isteğe bağlı önkoşulları dahil) makalelerde HowTo schema’sını kullanın. Kurulum rehberleri, taşıma kontrol listeleri ve “nasıl yapılır” iş akışları için uygundur.
Markup içindeki adımların sayfada görünenlerle (aynı sıra, aynı anlam) uyumlu olmasına dikkat edin. Sayfa açıklayıcıdan çok prosedürel ise HowTo kullanmayın.
Çoğu bilgi tabanı makalesi ayrıca şu işaretlemelerden fayda sağlar:
Breadcrumbs, arama motorlarının ilişkili sayfaları bağlamasına yardımcı olur ve arama sonuçlarından gezinirken kullanıcılar için netlik artırabilir.
Schema ekledikten sonra sayfaları Google’ın Rich Results Test ile doğrulayın ve uyarıları/hataları giderin. Bu kontrolü bir sürüm kontrolü gibi ele alın: şablon değişirse birkaç temsili sayfayı yeniden test edin (SSS, HowTo, standart makale).
Eğer yardım merkezi genelinde şablonları standartlaştırıyorsanız, uygun sayfaların şablon seviyesinde işaretlenmesini düşünün ki her uygun sayfa tutarlı şekilde işaretlensin—uygunsuz sayfalar temiz kalsın.
Teknik SEO, arama motorlarının yardım içeriğinizi taramasına, anlamasına ve güvenilir şekilde sunmasına yardımcı olan altyapıdır. Bilgi tabanları için küçük hatalar (yavaş sayfalar, çoğaltılmış URL’ler, bozuk yönlendirmeler) yüzlerce makaleyi sessizce baskılayabilir.
Hızlı sayfalar daha iyi sıralanır ve zaten bir problemi çözmeye çalışan kullanıcıların hayal kırıklığını azaltır.
Sayfaları hafif tutun:
Çoğu destek araması telefonda yapılır. Rahat font boyutları, üst üste binmeyen dokunma hedefleri ve yatay kayan kod blokları gibi mobil dostu bir düzen kullanın.
Önemli içeriğin çoklu dokunuşla açılan akordeonların arkasına gizlenmediğinden emin olun—özellikle kilit adımlar, önkoşullar ve uyarılar.
Dokümanlar genellikle şu yollarla çoğalır:
Her makale için bir canonical URL seçin ve buna sadık kalın. <link rel="canonical"> etiketleri ekleyin, son eğik çizgi (veya olmaması) konusunda tutarlı olun ve içeriği hafifçe değiştirmeksizin aynı içeriği farklı slug’larda yayınlamayın.
Makaleler yeniden adlandırılabilir. Bu normaldir—kırık izler olmamalı.
Açık dokümanlar için bir XML site haritası sağlayın, robots.txt ile önemli bölümlerin engellenmediğinden emin olun ve sunucu tarafında render edilen içeriğin erişilebilir olmasını sağlayın (ana makale gövdesi için sadece istemci tarafı render’ına güvenmeyin).
Bir bilgi tabanı güçlü sıralamalar kazanabilir, sonra ekran görüntüleri eskidiğinde, ürün akışları değiştiğinde ve cevaplar eksik kaldığında yavaşça değer kaybedebilir. Arama motorları kullanıcıların sonuçlara geri dönmelerini fark eder; müşteriler daha hızlı fark eder. Hafif bir yönetişim planı içerik sürüklenmesini önler ve hem SEO hem destek sonuçlarını stabil tutar.
Her makaleye açıkça bir inceleme tarihi ekleyin (içeride görünmese bile). Doğruysa, okuyucuların güvenini artırmak için üst kısımda “Son güncelleme” satırı gösterin.
Dikkat: Tarihleri anlamlı düzenleme yapmadan otomatik güncellemeyin. Kullanıcılar “dün güncellendi” görür ama adımlar UI ile uyuşmuyorsa güven düşer.
Sahiplik, “bunu güncellemeliyiz” ile “güncellendi” arasındaki farktır. Hangi kategorinin kim tarafından ne sıklıkta gözden geçirileceğini tanımlayın.
Örneğin: Faturalama makaleleri faturalama operasyonları sahibi tarafından aylık; API dokümanları mühendislik tarafından üç aylık; sorun giderme içerikleri destek liderleri tarafından tekrar eden ticket dalgalarından sonra gözden geçirilebilir.
İçerik büyüdükçe tutarlılığı korumak için adlandırma kurallarını belgeleyin:
Sabit slug’lar SEO için önemlidir; sık URL değişiklikleri sıralamayı düşürebilir ve dış referansları kırabilir.
İçerik güncellemelerini sürüm sürecinize bağlayın:
Sürüm notları yayınlıyorsanız, iş akışını onlara bağlayın (örn. /release-notes) ki destek ve doküman uyumlu kalsın.
Eğer bu iş akışı etrafında araçlar geliştiriyorsanız, pratik tutun: ekipler genellikle planlama kontrol listeleri ve yeniden kullanılabilir şablonlarla tutarlı doküman üretir. Koder.ai gibi platformlar, yapılandırılmış bir prompt’u (özellik değişikliği + etkilenen UI yolları + önkoşullar) bir ilk taslağa çevirerek aynı hızda doküman güncellemeleri yapmanıza yardımcı olabilir—ürün değişiklikleriyle eş zamanlı doküman yayınlamanız gerektiğinde faydalıdır.
Büyüme bilgi tabanı için çift taraflı bir kılıçtır: daha fazla makale daha fazla trafik getirebilir, ancak yalnızca içerik düzenli, tutarlı ve gerçekten faydalıysa. İyi ölçeklendirme, içerik kümeleri halinde yayımlamak, yeni dillere dikkatli genişlemek ve kaliteyi düşüren sayfaları kaldırmak veya birleştirmek demektir.
Sürekli tekil makaleler eklemek yerine, ilgili içeriği küratörlü dizinler olarak davranan hub sayfaları altında gruplayın.
Yüksek niyetli sorunlar ve özellikler için iniş sayfaları oluşturun (örn. “Giriş sorunlarını düzeltin” veya “SSO kurun”), sonra en uygun sorun giderme adımlarına ve ayar makalelerine link verin. Bu hub’lar daha geniş aramalar için trafik çekerken kullanıcıları ve arama motorlarını en alakalı detaylara yönlendirir.
Karşılaştırma ve “başlarken” hub’ları oluşturmayı düşünün. Karşılaştırma sayfaları, değerlendirme aşamasındaki kişiler için yararlı olur (“Basic vs Pro”, “API anahtarları vs OAuth”), “başlarken” hub’ları ise yeni kullanıcıların ilk başarılı sonucu elde etmesine yardımcı olur.
Çevrilmiş yardım içeriği, ancak ilgili lokali güncel tutabiliyorsanız bir değer olur.
UI dizesi, ekran görüntüleri, yasal ifadeler ve destek iş akışlarını tamamen destekleyebileceğiniz lokallerde çeviri yapın. Bir lokali güncel tutamıyorsanız, geniş ama eski bir kütüphane yerine daha küçük, yüksek kaliteli bir rehber seti sunmak daha iyidir.
Zayıf sayfalardan kaçının: örtüşen makaleleri tek bir güçlü rehberde birleştirin. Aynı soruya cevap veren birden çok kısa yazınız varsa, bunları birleştirin, en iyi URL’yi koruyun ve diğerlerini yönlendirin.
Basit bir budama rutini:
Hub’lar + dikkatli yerelleştirme + düzenli budama, yardım merkezinizin SEO’sunu odaklı tutar ve bilgi tabanını daha gezinilebilir kılar.
Ne işe yaradığı kanıtlanamıyorsa, bilgi tabanınız “daha fazla makale” sarmalına düşer. SEO kazanımlarının ve destek başarılarının aynı panoda görünmesini sağlayacak ölçüm kurun.
Dokümanlarınızın gerçekten bulunduğu yeri takip edin—alt klasör (örn. /help/) veya ayrı bir alt alan adı olsun. GA4’te o path/hostname’e filtrelenmiş özel bir içerik grubu veya keşif oluşturun. Google Search Console’da da tam property’yi ekleyin (bir domain property en iyisidir) ve bilgi tabanı URL’lerinin dahil olduğunu doğrulayın.
Ayrıca kilit “destek yönlendirme” eylemlerini olay (event) olarak etiketleyin:
Arama kutunuz bir altın madendir. Şunları izleyin:
Her “sonuç yok” sorgusu yeni bir makale başlığı adayıdır. Zaten bir makaleniz varsa, sorgu isimlendirme sorunu işaret ediyor olabilir—başlıkları, eşanlamlıları ve ilk paragrafı kullanıcıların sorduğu şekilde güncelleyin.
Sorguları, CTR’yi ve sıralamaları konu (faturalama, entegrasyonlar, sorun giderme) bazında izleyin. Bu, dahili bağlantılarınızın ve hub’ların otorite inşa edip etmediğini görmeyi kolaylaştırır ve tekil sayfalardaki “gösterişli” kazanımlara odaklanmayı önler.
Arama metriklerini destek ve ürün sinyalleriyle birleştirin:
Aylık döngülerle kapanışı sağlayın: kazananları gözden geçirin, performansı düşükleri düzeltin ve yeni “sonuç yok” konularını editoryal plana ekleyin.
Öncelikle yapılacak birincil işi seçin ve buna göre optimize edin:
İlk etapta 1–2 hedef sonucu seçin ki erken SEO hedefleriniz ve içerik yol haritanız odaklı kalsın.
Destek yükü en yüksek olan veya iş açısından en çok etkisi olan kitleleri seçin ve onların diline göre yazın:
İlk içerik dalgası için 1–2 birincil hedef kitle belirleyin; böylece kimsenin aramadığı makaleler yazmaktan kaçınmış olursunuz.
SEO’yu iş sonuçlarına bağlayan küçük bir metrik seti kullanın:
Belirli bir alana yönelik hedefler koyun; örn. “Şifre sıfırlama ticket’larını 90 günde %30 azalt.”
Müşterilerin gerçekte sorduğu sorularla başlayın:
Hata mesajları gibi tam ifadeleri yakalayın (çoğu zaman en iyi uzun kuyruk anahtar kelimelerdir). Ardından bu ifadeleri makale başlıklarına ve bölümlere çevirin.
Her konuyu niyete göre etiketleyin ki sayfa formatı arayanın ihtiyacına uyum sağlasın:
Niyet karışıksa, önce en hızlı başarı yolunu gösterin, sonra bağlamı ekleyin.
Basit bir hiyerarşi kullanın ve derin katmanlardan kaçının:
Bu yapı, tarayıcıların ilişkileri anlamasına yardımcı olur ve kullanıcıların arama yapmadan yanıt bulmasını kolaylaştırır.
Yıllarca sabit kalabilecek URL desenleri seçin:
Örnekler:
/help/billing/invoices/download-invoice//kb/account/security/enable-2fa/Eğer kategori adlarını sık değiştiriyorsanız, kategori adlarını URL’den çıkarıp tabanlı bir yapı düşünebilirsiniz.
Tutarlı, taranması kolay bir şablon kullanın:
Bir H1 kullanın ve kullanıcıların yazacağı ana sorguyla eşleşsin; UI’daki tam buton/alan isimlerini ekleyin.
Sayfanın türüne uygun olduğunda schema kullanın:
Yayınlamadan önce (ve şablon değişince) Google’ın Rich Results Test aracında doğrulayın.
Doküman sitelerinde sıkça görülen hatalara odaklanın:
/help//sitemap.xmlBu düzeltmeler genellikle tarama verimliliğini artırır ve yüzlerce makalenin sıralamasını istikrara kavuşturur.