1. FAQ/SSS içeriklerinin rolü (Üst–Mid–Bottom funnel)
FAQ’lar “sadece bilgi” değildir; funnel içinde farklı görevleri vardır. Üst funnel’da (ToFu) kullanıcı hızlı tanım ister; mid funnel’da (MoFu) kıyas ve risk azaltma ister; bottom funnel’da (BoFu) ise “kapanış soruları” sorar (fiyat, süreç, iptal, SLA, teslimat, rezervasyon adımları gibi). Aynı SSS bloğuna her şeyi doldurmak yerine, soruları funnel rolüne göre dağıtmak hem UX’i hem SEO’yu güçlendirir.
Funnel’a göre soru örnekleri (otel/hizmet)
- •ToFu: “X nedir?”, “Nasıl çalışır?”
- •MoFu: “Hangisi daha iyi?”, “Ne kadar sürer?”, “Hangi durumda önerilir?”
- •BoFu: “Ücretlendirme nasıl?”, “Rezervasyon/teklif süreci nasıl?”, “İade/iptal nasıl?”
☑ Mini Check
- •SSS’ler “tek blok” mu, yoksa sayfa rolüne göre mi dağıtıldı?
- •BoFu sorularında net CTA ve süreç bilgisi var mı?
- •Cevaplar kısa ve jargon düşük mü?
Ne yapmalıyım?
- • Soruları önce ToFu/MoFu/BoFu diye etiketle.
- • Hizmet/destinasyon sayfalarında BoFu sorularını sayfa içine yerleştir.
- • Bloglarda ToFu/MoFu sorularla öğrenme akışını hızlandır.
2. Soru toplama kaynakları (veri + gerçek müşteri soruları)
SSS stratejisi “kafadan soru yazmak” değildir; soru havuzu kanıtlı kaynaklardan çıkar. En değerli kombinasyon: arama verisi + gerçek müşteri iletişimi. Arama verisi size “ne soruluyor”u, çağrı merkezi ise “neden soruluyor”u verir.
Hangi soruları SSS’ye almalıyım?
SSS’ye; (1) arama verisinde tekrar eden sorgular, (2) satış/çağrı merkezi kayıtlarında en çok gelen sorular ve (3) dönüşüm öncesi “tereddüt” yaratan itiraz soruları alınır. Öncelik, kullanıcı kararını hızlandıran ve destek yükünü azaltan sorulardadır. Aynı soruyu farklı şekillerde tekrar etmek yerine bir “ana soru + net cevap” standardı kullanın.
Kaynak listesi (pratik)
- •Google Search Console → “queries” ve sayfa bazlı performans (hangi sorularla görünüyorsunuz?)
- •PAA (People Also Ask) → SERP’te tekrar eden soru kalıpları
- •Çağrı merkezi / satış / müşteri hizmetleri → itirazlar, süreç soruları, fiyat/iptal soruları
- •Site içi arama (varsayım) → “kullanıcı sitenizde ne arıyor?”
- •E-posta/DM kayıtları (varsayım) → yazılı sorular
Mini örnek (otel)
“Çocuk ücretsiz mi?”, “İptal koşulları nedir?”, “Transfer var mı?” gibi sorular doğrudan dönüşüm öncesi tereddütleri kapatır.
Mini örnek (hizmet)
“Kaç haftada sonuç alırım?”, “Hangi raporları sunuyorsunuz?” gibi sorular risk azaltır.
☑ Mini Check
- •Search Console’dan “soru kalıpları” çıkarıldı mı?
- •Çağrı merkezi verisi “kategorilere” ayrıldı mı (fiyat, süreç, iptal, vb.)?
- •Soruların %60+’ı gerçek veriden mi geliyor?
Ne yapmalıyım?
- • 30 günlük soru havuzu çıkar: 30–50 soru (ham liste).
- • Benzer soruları grupla: 10–20 “çekirdek” soruya indir.
- • Her çekirdek soruya “sayfa rolü” ata: blog / hizmet içi / SSS hub.
3. SSS yapısının kurgulanması (kısa cevap standardı + yerleşim)
SSS’lerde amaç uzun makale yazmak değildir. En iyi cevap formatı: “kısa, net, tatmin edici” ve gerekiyorsa bir sonraki adıma link veren yapı. AEO/voice için bu özellikle kritiktir: gereksiz jargon ve dolambaçlı cümleler hem kullanıcıyı hem de voice/AI cevaplarını zorlar.
Yanıt standardı (önerilen)
- •1. cümle: direkt cevap (15–25 kelime)
- •2. cümle: koşul/istisna (varsa)
- •3. cümle: next step (iç link veya CTA)
☑ Mini Check
- •Cevabın ilk cümlesi “direkt mi”, yoksa açıklamayla mı başlıyor?
- •Her cevap 2–4 cümle bandında mı?
- •Gerekli yerde iç link/CTA var mı?
Ne yapmalıyım?
- • Cevapları 2–4 cümle bandında sabitle (uzun metni bloga taşı).
- • “İlgili rehber” ve “ilgili hizmet” linklerini ölçülü ekle.
- • Aynı soruyu sayfa içinde 2 kez tekrar etme; tek yerde doğru cevap ver.
4. Blog, hizmet sayfası ve dedicated SSS sayfaları (rol dağılımı)
SSS’yi nereye koyacağınız, en az “hangi soruyu yazacağınız” kadar önemlidir. En iyi pratik çoğu projede hibrittir: sayfa içi SSS + ayrı SSS hub birlikte çalışır. Bu, voice aramalar ve AEO için de iyi bir mimaridir.
SSS sayfası mı, sayfa içi blok mu daha iyi?
Tek bir doğru yok: dönüşümle ilgili sorular genellikle hizmet/destinasyon sayfası içinde daha etkilidir; çünkü kullanıcı karar anındadır. Genel sorular ve çok sayıda alt soruyu kapsayan başlıklar için ayrı bir SSS hub daha iyi çalışır. En iyi model, sayfa içi SSS’nin “en kritik 5–10 soru”yu, SSS hub’ın ise kapsamlı soru kütüphanesini taşımasıdır.
Yerleşim önerisi (pratik)
- •Blog: Bölüm sonlarında 3–6 soru (konu içi) + sayfa sonunda geniş FAQ
- •Hizmet sayfası: itiraz/tereddüt soruları (fiyat, süreç, teslimat, SLA)
- •Otel sayfası: iptal/rezervasyon, transfer, çocuk, check-in/out, konsept
- •SSS hub (/sss/ veya /faq/): kategori bazlı SSS (varsayım: site yapınız uygunsa)
☑ Mini Check
- •BoFu soruları hizmet/otel sayfasında mı (doğru yerde mi)?
- •SSS hub’da kategori/filtre mantığı var mı?
- •Bloglardaki FAQ’lar ilgili hizmet sayfasına akıyor mu?
Ne yapmalıyım?
- • SSS’leri “sayfa rolü”ne göre böl: blog/hizmet/otel/hub.
- • Hub sayfada 5–7 ana kategori belirle (rezervasyon, iptal, ödeme, vb.).
- • Her kategoriye 10–15 soru hedefle (kademeli büyüt).
5. FAQ Schema ile zengin sonuçlar (gerçekçi beklenti + doğru kullanım)
FAQ schema (FAQPage structured data) sayfanın soru-cevap yapısını makinelere anlatır. Ancak burada kritik nokta: zengin sonuç (FAQ rich result) görünürlüğü artık sınırlı. Google Search Central, FAQ rich results görünürlüğünü azaltıp yalnız “well-known, authoritative government and health websites” için düzenli gösterileceğini belirtir.
Bu şu anlama gelir: çoğu ticari site için SERP’te eski “FAQ açılırları” daha az görünebilir; fakat yapılandırılmış veri yine de sayfanın anlaşılmasına, kalite kontrolüne ve farklı yüzeylerde (ör. asistan/voice gibi) kullanılabilirliğe katkı sağlar.
FAQ schema nasıl uygulanır?
FAQ schema için sayfada gerçek SSS içeriği olmalı; ardından JSON-LD ile FAQPage ve mainEntity altında Question/Answer alanları eklenir. Zorunlu alanları doldurduktan sonra Rich Results Test ile doğrulayın ve URL Denetimi ile Google’ın sayfayı nasıl gördüğünü kontrol edin.
(Kısaltılmış) örnek FAQ schema snippet’i
Key Statistics / Data Point (yumuşak kullanım)
FAQ schema kullanılan sayfaların, benzer içeriklere göre “SSS bloklu rich result” alma olasılığının daha yüksek raporlandığı örnekler var; ancak Google bugün FAQ rich results görünürlüğünü ve uygunluğunu önemli ölçüde sınırladı. Bu yüzden hedefi “her zaman SERP’te açılır SSS” değil; “doğru soru-cevap mimarisi + doğru işaretleme + güçlü UX” olarak kurgulamak daha sağlıklı.
☑ Mini Check
- •Sayfada gerçekten SSS var mı (schema ile uydurma değil)?
- •SSS cevapları kısa ve anlaşılır mı?
- •Uygunluk/gösterim beklentisi gerçekçi mi (policy kısıtları biliniyor mu)?
Ne yapmalıyım?
- • FAQ schema’yı “önce içerik” prensibiyle uygula: gerçek soru-cevap yoksa ekleme.
- • Rich result hedefin varsa, eligibility kısıtlarını bil ve alternatif kazanımlara odaklan.
- • Schema doğrulama + URL denetimi + Search Console takip döngüsünü standartlaştır.
6. Uygulama ve test süreci (QA rutini + raporlama)
Schema “ekledim bitti” değildir. Test edilmezse hatalı kalır; template değişince bozulur; yeni soru eklenince yanlış işaretlenir. Bu yüzden süreç; içerik ekibi + teknik ekip + SEO ekibinin ortak rutinidir.
Minimum QA rutini
- •Yayına çıkmadan: Rich Results Test (kritik hatalar)
- •Yayından sonra: URL Denetimi ile canlı sayfa kontrolü
- •Periyodik: performance report’ta görünürlük ve tıklama sinyali takibi
☑ Mini Check
- •Template değişince schema bozuluyor mu?
- •Yeni SSS eklendiğinde test tekrar yapılıyor mu?
- •Takip raporu “aksiyona” dönüyor mu?
Ne yapmalıyım?
- • Her release sonrası “structured data check” maddesini checklist’e ekle.
- • SSS güncellemelerini aylık sprintte topla, test ederek yayınla.
- • Performans sinyalini (query’ler, sayfa etkileşimi) SSS seçim kriterine geri besle.
7. Teknik notlar (CWV, heading hiyerarşisi, sayfa performansı)
SSS bloğu eklerken sayfa hiyerarşisini bozmak (ör. tasarım yüzünden H2/H3’ü yanlış kullanmak) ya da sayfayı ağırlaştırmak (fazla JS accordion, ağır ikon setleri) sık yapılan hatadır. Ayrıca “her soruyu schema ile işaretleme” hevesi, kalite politikasına takılabilir. Structured data için genel kalite/teknik yönergeler; erişilebilirlik, spam politikaları ve doğru işaretlemeyi vurgular.
☑ Mini Check
- •SSS modülü mobilde sayfayı yavaşlatıyor mu?
- •Heading hiyerarşisi bozuldu mu?
- •SSS accordion JS’i gereksiz ağır mı?
Ne yapmalıyım?
- • SSS modülünü “hafif” tut: basit accordion + lazy olmayan gereksiz script yok.
- • Heading seviyelerini koru: tasarım için H2’yi H4’e çevirmeye çalışma.
- • SSS sayısını “kalite” üzerinden artır: 10 iyi soru, 50 zayıf sorudan iyidir.
8. Fark yaratan mini bölüm (Competitor gap): Dağınık SSS yerine “sistem”
Row’daki gap net: çoğu sitede SSS’ler dağınık veya rastgele eklenmiş; arama verisi + gerçek sorulara dayalı ve schema/test süreçleri olan bir FAQ stratejisi nadir. Bu boşluğu kapatan sistem şu 4 adım:
- Soru kaynaklarını birleştir (Search Console + PAA + çağrı merkezi)
- Rol dağılımı yap (blog/hizmet/otel/hub)
- Kısa cevap standardı uygula (2–4 cümle)
- Test ve takip rutinini işlet (rich results test + URL denetimi + rapor)
| Soru Türü | En İyi Yerleşim | Cevap Uzunluğu | İç Link | Schema |
|---|---|---|---|---|
| Süreç/iptal/rezervasyon | Otel/hizmet sayfası içi blok | 2–4 cümle | CTA / ilgili politika | FAQPage (uygunsa) |
| Genel tanım / nasıl çalışır | Blog + sayfa sonu FAQ | 2–4 cümle | ilgili rehber | FAQPage |
| Çok kapsamlı soru seti | SSS hub (/sss/) | kısa cevap + detay link | kategori linkleri | FAQPage |
| Kullanıcı destek soruları | Çağrı merkezi sayfası / destek alanı | kısa + yönlendirme | iletişim | FAQPage (uygunsa) |
9. FAQ İçerik & FAQ Schema Uygulama Checklist’ini İndir — SEO / Content SEO
FAQ İçerik & FAQ Schema Uygulama Checklist’ini İndir — SEO / Content SEO (v1.0)
Bu asset, SSS sorularını veriye dayalı seçip kısa cevap standardıyla yazmanızı ve FAQ schema’yı doğru şekilde uygulayıp test etmenizi sağlar. Amaç; dağınık SSS’leri “tek kaynak” bir sisteme dönüştürmek, sayfa hiyerarşisini bozmadan uygulamak ve AEO/voice tarafında net cevap blokları üretmektir. Ayrıca Google’ın FAQ rich results gösterimini sınırladığı gerçeğiyle, beklentiyi “SERP açılırları”ndan “kalite + anlaşılabilirlik + dönüşüm”e taşır.
Kim Kullanır?
SEO uzmanı, içerik editörü, çağrı merkezi/ satış lideri, web geliştirici.
Nasıl Kullanılır?
- 30–50 ham soruyu topla (Search Console + PAA + çağrı merkezi).
- 10 soruluk minimum seti seçip cevapları 2–4 cümle standardında yaz.
- Schema’yı uygula, test et, 30/90 gün performans notu düş ve güncelle.
Ölçüm & Önceliklendirme (Kısa sürüm)
- ▢ ✅ Soruların kaynağı: arama verisi + gerçek müşteri soruları (en az 2 kaynak)
- ▢ ✅ Sorular funnel’a göre etiketlendi (ToFu/MoFu/BoFu)
- ▢ ✅ Aynı sorular birleştirildi, tekrar azaltıldı
- ▢ ✅ Her cevap 2–4 cümle; ilk cümle direkt cevap
- ▢ ✅ Cevaplarda jargon azaltıldı, net “next step” eklendi
- ▢ ✅ SSS yerleşimi seçildi (sayfa içi blok / SSS hub / blog sonu)
- ▢ ✅ FAQ schema yalnız gerçek SSS bulunan sayfaya eklendi
- ▢ ✅ Zorunlu alanlar dolu: FAQPage → mainEntity → Question/Answer
- ▢ ✅ Rich Results Test + URL Inspection ile doğrulandı
- ▢ ✅ Yayın sonrası takip: performance report + geri bildirim kanalı
PDF içinde: Problem→Kök Neden→Çözüm tablosu + 14 gün sprint planı + önce/sonra KPI tablosu
10. Sonuç: SSS içerikleri rastgele blok değil, soru tabanlı bir sistemdir
FAQ ve SSS stratejisi, sadece sayfa sonuna birkaç soru eklemek değildir. Doğru sistemde sorular gerçek veriden toplanır, funnel rolüne göre ayrılır, kısa ve net cevap standardıyla yazılır, doğru sayfa tipine yerleştirilir ve schema/test rutiniyle teknik olarak doğrulanır.
FAQ rich result görünürlüğü bugün sınırlı olsa da, doğru SSS mimarisi kullanıcı kararını hızlandırır, çağrı merkezi yükünü azaltır, AEO/voice için net cevap blokları üretir ve içerik SEO sistemini daha anlaşılır hale getirir.
Bir Sonraki Adım
SSS’leri veriye dayalı kurup sayfa hiyerarşisini bozmadan uygulamak isteyen otel ve ajans ekipleri için.