QAPage İşaretlemesi: Soru-Cevap ve SSS Farkı

QAPage işaretlemesi yalnızca tek bir soruyu ve o soruya gelen cevapları sunan sayfalar içindir. Siteniz kendi yazdığı sıkça sorulan sorulardan oluşuyorsa, bir blog yazısı bir soruyu yanıtlıyorsa ya da sayfada birden çok soru varsa Google'ın belgesine göre bu işaretleme uygun değildir. Aşağıdaki anlatım, kullanıcıların soru sorup cevap yazabildiği bir bölüm işleten site sahiplerine, forum yöneticilerine ve destek topluluğu sorumlularına yöneliktir. Sonuç sayfasında özel bir görünüm vaadi yoktur; amaç, veriyi belgenin kurallarına uygun kurmaktır.

QAPage ne için tasarlandı?

Belgenin kapsadığı kullanım

Google'ın soru-cevap yapılandırılmış veri belgesi (yeni sekmede açılır), işaretlemeyi tek bir soru ve ardından gelen cevapları sunan sayfalar için tanımlar. Belgedeki geçerli örnekler şunlardır: kullanıcıların tek bir soruya cevap gönderdiği bir forum sayfası ve kullanıcıların tek bir soruya cevap yazdığı bir ürün destek sayfası. Kullanım alanını belirleyen anahtar nokta, cevapların yalnız site sahibinden değil, kullanıcılardan da gelebilmesidir. Belge, kullanıcıların alternatif cevap gönderemediği bir sayfanın bu işaretlemeye uygun olmadığını açıkça yazar.

Uygun olmayan sayfalar

Belge kapsam dışı olanları da sayar: nasıl yapılır kılavuzları, bir soruyu cevaplayan blog yazıları ve denemeler, kullanıcıların birden çok soru sorduğu ürün sayfaları ve sıkça sorulan sorular sayfaları. SSS sayfaları, yani siteyi işleten tarafın kendi yazdığı ve kullanıcıların alternatif cevap gönderemediği sayfalar uygun değildir; birden çok soru içeren sayfalar da değildir. Soruların bir kısmının soru olmadığı bir forumda işaretlemenin site genelinde uygulanmaması gerektiği de belgede yazar.

Karar kuralı: bu sayfa QAPage mi?

Aşağıdaki sıra belgedeki sınırlardan türetilmiş bir uygulama önerisidir.

1. Sayfada tek bir soru mu var? Birden çok soru varsa dur, QAPage kullanma.
2. Soruya kullanıcılar cevap gönderebiliyor mu? Gönderemiyorsa sayfa bir SSS sayfasıdır, dur.
3. Sayfa bir kılavuz ya da blog yazısı mı? Öyleyse dur.
4. Yukarıdakilerin hiçbiri değilse ve soruya en az bir cevap var ya da cevap beklenen bir soru sayfasıysa QAPage'i değerlendir.

Üçüncü adım belgedeki "kılavuz ve blog yazısı uygun değil" ifadesini izler. Dördüncü adımdaki "en az bir cevap" koşulu ise zengin sonuç uygunluğuyla ilgilidir ve aşağıda ayrıca ele alınıyor.

Tek soru, çok cevap kuralı

Sayfa başına bir QAPage tanımı

Belgenin en net kuralı şudur: her sayfada yalnız bir QAPage tanımı olmalı ve sayfanın odağı tek bir soru ile onun cevapları olmalıdır. Bu kural, bir kategori sayfasına ya da soru listesine QAPage eklememenizi gerektirir. Soru listelerinde her satır ayrı bir sayfaya gidiyorsa işaretleme listeye değil, o ayrı sayfalara konur.

Forumun bir kısmı soru değilse

Belge, bazı sayfaları soru olmayan bir forumda işaretlemenin site genelinde uygulanmaması gerektiğini söyler. Pratikte, bir topluluk sitesinde sohbet başlıkları, duyurular ve gerçek sorular karışık duruyorsa şablonun yalnızca gerçek soru sayfalarında QAPage üretmesi gerekir. Sohbet akışı niteliğindeki başlıklar için forum işaretlemesi daha uygundur; Google'ın tartışma forumu belgesi de site esas olarak soru ve cevaplardan oluşuyorsa QAPage'e yönlendirir. Bu iki belge birbirini tamamlar: sohbet için forum işaretlemesi, tek soru ve cevapları için QAPage.

Örnek senaryo: ev tadilatı soru-cevap bölümü

Örnek senaryo: bir ev tadilatı sitesinde üyeler "balkon zemini için hangi derz dolgusu kullanılır?" gibi sorular soruyor ve diğer üyeler cevap yazıyor. Her soru kendi adresinde duruyor. Geliştirici soru sayfalarında QAPage kuruyor: soru Question olarak, kullanıcı cevapları Answer olarak işaretleniyor. Sitenin aynı bölümünde "Tadilat ruhsatı ne zaman gerekir?" başlığıyla editörün yazdığı bir rehber var. Bu rehber bir soruyu yanıtlayan makale olduğu için QAPage almıyor. Sitenin "Sıkça sorulan sorular" sayfası da kullanıcıların cevap gönderemediği, sitenin kendi yazdığı bir sayfa olduğu için işaretlenmiyor. Soru listesi sayfasında ise hiçbir QAPage tanımı bulunmuyor.

SSS ve blog yazısı için neden uygun değil?

Belgenin ayrımı

SSS sayfası ile QAPage arasındaki fark, cevapların kaynağı ve soru sayısıdır. SSS sayfasında soruları ve cevapları site sahibi yazar, tek bir cevap vardır ve birden çok soru bir arada durabilir. QAPage'de ise tek bir soru vardır ve cevaplar kullanıcılar tarafından gönderilir; birden çok cevap bulunabilir. Belge SSS sayfalarını bu nedenle açıkça kapsam dışında bırakır. Kısacası, SSS bölümünüz için QAPage kurmayın.

Belge SSS sayfaları için bir soru sayısı sınırı vermiyor; tablo iki türün tanımını yan yana koyar.

Blog yazısı bir soruyu yanıtlıyor diye QAPage olmaz

Başlığı soru olan bir blog yazısı QAPage değildir. Belge nasıl yapılır kılavuzlarını, bir soruyu yanıtlayan blog yazılarını ve denemeleri açıkça uygun saymaz. Blog yazısının altındaki yorumlar da QAPage'e dönüştürmez, çünkü sayfanın ana içeriği editörün makalesidir. Bu durumda doğru yol Article gibi türlerdir; ayrıntı için Article ve FAQ schema işaretlemesi rehberine bakın. Soru sormak isteyen okurlara ayrı bir soru-cevap bölümü açmak istiyorsanız o bölümün soru sayfaları QAPage kurallarına uyabilir, ama blog yazısının kendisi uymaz.

Ürün sayfasında müşteri soruları

Ürün sayfalarında kullanıcıların birden çok soru sorabildiği bölümler belgeye göre uygun değildir. Bir ürün için ayrı ve tek soruya ayrılmış sayfalar kurulabiliyorsa o sayfalar uygun olabilir; sayfa ürün sayfasının bir bölümüyse uygun değildir. Bu bölüm bir uygulama önerisidir: ürün sayfanızdaki soru bölümünü işaretlemeden bırakmak, yanlış işaretlemekten daha güvenlidir.

Cevap, kabul edilen cevap ve oylama alanları

Zorunlu alanlar

Belgeye göre QAPage için mainEntity zorunludur ve bu alan Question türünü taşır. Question'da answerCount (tam sayı, cevap yoksa 0), name (sorunun kısa hali) ve acceptedAnswer ya da suggestedAnswer alanlarından biri bulunur; zengin sonuç uygunluğu için en az bir cevap gerekir. Answer'da zorunlu alan text, yani cevabın tam metnidir.

Önerilen alanlar

Question için önerilenler şunlardır: author, author.url, comment, commentCount, dateModified, datePublished, digitalSourceType, image, text, upvoteCount ve video. Answer için ise author, author.url, comment, commentCount, dateModified, datePublished, digitalSourceType, image, upvoteCount, url ve video sayılır. Cevap için bir url vermek belgede özellikle tavsiye edilir. Comment türünde text zorunludur.

Kabul edilen cevap nedir?

Belgeye göre acceptedAnswer alanı, sitenizde kabul edilmiş cevabı yansıtmalıdır: soruyu soran kişi, bir moderatör ya da bir oylama sistemi tarafından kabul edilmiş olabilir. Cevapları en yeniye göre sıralamak kabul edilmiş cevap sayılmaz. Bu kural, bir cevabı sırf listede ilk sırada olduğu için kabul edilmiş gibi işaretlemenizi engeller. Bir soruya henüz kabul edilmiş cevap yoksa suggestedAnswer kullanılabilir.

Cevap ile yorum ayrımı

Belge, Answer türünün yalnız cevaplar için kullanılmasını, soruya ya da cevaba yazılan yorumlar için Comment türünün kullanılmasını ister. Pratikte bir soru sayfasında "teşekkürler, işe yaradı" ya da "hangi model?" gibi ek açıklamalar yorumdur; sorunun çözümünü sunan metin cevaptır. Bu ayrımı şablon düzeyinde yapabilmek için veritabanında cevap ile yorumun ayrı tutulması gerekir.

Oylama sayıları ve tarih alanları

upvoteCount hem soruda hem cevapta önerilen bir alandır. Uygulama önerisi olarak, yalnızca sayfada gerçekten gösterdiğiniz oy sayısını verin. Tarihler için belge datePublished ve dateModified alanlarını kullanır; dateCreated bu belgede yer almıyor.

Tam metin, reklam yasağı ve içerik uygunluğu

Belge, hem sorunun hem her cevabın tam metninin işaretlemede yer almasını ister. İşaretlemenin reklam amacıyla kullanılmaması gerektiği de yazılıdır. Müstehcen, zararlı ya da nefret içeren içerik zengin sonuç olarak görüntülenmeyebilir. Eğitime yönelik soru-cevap sayfalarında uzman tarafından seçilmiş tek bir cevap varsa, belge bu sayfaların soru-cevap karuselinde yer alabileceğini söyler. Bu son nokta yalnızca belirli bir eğitim senaryosunu ilgilendirir ve her sitenin hedefi olmak zorunda değildir.

Spam ve kullanıcı içeriği

Cevap açıkken ortaya çıkan risk

Kullanıcıların cevap yazabildiği her alan, Google'ın spam politikalarında tanımlanan kullanıcı tarafından üretilen spam için de bir kanaldır. Spam politikaları sayfası (yeni sekmede açılır) bu spamı, kullanıcıların kullanıcı içeriği için ayrılmış bir kanaldan siteye eklediği spam içerik olarak tanımlar ve forum konularındaki spam gönderileri örnek olarak anar. Cevap sayfalarında kullanıcı metni işaretlemede de yer alacağından, spam cevapları yayında bırakmak onları da veriye dahil etmek demektir. Bu yüzden onay akışı, reddetme kuralları ve bağlantı niteleme önerileri soru-cevap bölümünde de geçerlidir; ayrıntılar için dofollow, nofollow, sponsored ve ugc farkları yazısına bakın.

Cevaplardaki bağlantılar

Soru-cevap bölümlerinde cevaba eklenen bağlantılar bir kaynak göstermek için de, tanıtım için de kullanılabilir. Spam politikaları sayfası, forum yorumlarında ya da imzalarda optimize edilmiş bağlantıları link spamı örneği olarak sayar. Uygulama önerisi: cevaplardaki dış bağlantıları kullanıcı içeriği olarak niteleyin, ilgisiz tanıtım cevaplarını reddedin ve bir cevabın kabul edilmiş olması için yalnızca bağlantıdan ibaret olmamasını şart koşun. Konuya dair güvenli ve etik kullanım için forum ve topluluk linkleri yazısı bir başlangıç noktasıdır.

Cevapsız ve ince sayfalar

Cevabı olmayan ya da tek satırlık sorular çok sayıda ince sayfa üretebilir. Belge, cevabı olmayan bir soru için answerCount değerinin 0 olmasını söyler ama zengin sonuç uygunluğu için en az bir cevap ister. Bu tür sayfaları nasıl ele alacağınıza dair belgede bir yönlendirme yok. Uygulama önerisi olarak, cevap gelmemiş çok kısa soruların sitemap'e eklenmemesi ya da noindex ile ayrılması değerlendirilebilir; ince içeriğin nasıl bulunup düzeltileceği ince içerik yazısında ele alınıyor.

Doğrulama ve izleme

Yayın adımları

Belgenin doğrulama ve dağıtım adımları şöyle sıralanır: gerekli alanları ekleyin, Rich Results Test ile doğrulayıp kritik hataları giderin, birkaç sayfayı yayına alıp URL Inspection aracıyla botun erişebildiğini kontrol edin (robots.txt, noindex ve oturum zorunluluğu olmamalı), taramanın birkaç gün sürebileceğini hesaba katın, site haritası gönderin ve güncel tutun. Yayından sonra Search Console'daki zengin sonuç durum raporunu izleyin, şablon değişikliklerinden sonra geçersiz öğe artışına bakın. Rapor adları arayüz diline göre değişebilir; Türkçe arayüzde menü adları farklı görünebilir.

1. Sayfanın gerçekten tek soru ve kullanıcı cevaplarından oluştuğunu doğrulayın.
2. mainEntity içinde Question, answerCount, name ve en az bir cevap kurun.
3. Soru ve cevapların tam metnini işaretlemeye aktarın.
4. Kabul edilmiş cevabı yalnızca sitenizdeki gerçek kabul bilgisine göre belirleyin.
5. Answer ve Comment türlerini karıştırmayın.
6. Rich Results Test'te kritik hata kalmadığını görün.
7. Birkaç canlı sayfayı URL Inspection ile açın.
8. Raporu şablon değişikliklerinden sonra izleyin.

Sık yapılan hatalar

• Sitenin kendi SSS sayfasına QAPage eklemek.
• Bir sayfada birden çok QAPage ya da birden çok soru kurmak.
• Cevapları en yeniye göre sıralayıp ilkini kabul edilmiş cevap olarak işaretlemek.
• Yorumları Answer olarak işaretlemek.
• Soru-cevap bölümü olmayan bir ürün sayfasına şablonla işaretleme basmak.
• Soru listesi sayfasına QAPage koymak.
• Kısaltılmış cevap metni vermek.

Zengin sonuç beklentisi

Belge, yapılandırılmış veriyi kullanan özelliklerin sonuçlarda görüneceğini garanti etmediğini yazar ve nedenler için genel yapılandırılmış veri yönergelerine yönlendirir. Belgede son dönemdeki başka bir görünürlük değişikliği anlatılmıyor. Bu nedenle bu işaretlemeyi eklemenin amacı doğru ve tutarlı veri sunmaktır; belirli bir sonuç biçimi beklenmemelidir. Belgedeki kurallar değişebilir; uygulamadan önce güncel sayfaya bakın.

Alan eşleme tablosu

Örnek senaryo: kuruluşun kendi SSS bölümü

Örnek senaryo: bir tadilat firması sitesine yirmi kadar soruluk bir "Sıkça sorulan sorular" bölümü ekliyor ve geliştiriciden bunu QAPage ile işaretlemesini istiyor. Geliştirici belgeyi okuyunca üç engel görüyor: bölümde birden çok soru var, sorular ve cevaplar firmanın kendisi tarafından yazılmış ve kullanıcıların alternatif cevap gönderme yolu yok. Bu nedenle QAPage kurmuyor. Firmanın isterse yapabileceği şey, müşterilerin tek bir soru sayfasında cevap yazabildiği ayrı bir topluluk bölümü açmak ve işaretlemeyi yalnız o sayfalarda kullanmaktır. Bu açma kararı bir hizmet ve moderasyon yükü getirir; yalnız işaretleme için yapılacak bir bölüm olmamalıdır.

Veri modeli ve şablon kararları

Cevap, yorum ve kabul bilgisini ayrı tutmak

QAPage doğru kurulabilsin diye veritabanında en az üç şeyin ayrı tutulması gerekir: soru, cevap ve yorum. Cevap tablosunda bir de kabul bilgisi bulunmalıdır: soran kişi mi, moderatör mü, oylama sistemi mi kabul etti ve ne zaman. Cevap ile yorumu aynı tabloda karışık tutan sistemlerde şablon hangi satırın Answer, hangisinin Comment olacağını bilemez. Uygulama önerisi: kabul bilgisini bir işaretleme kolonu olarak değil, sitenin kendi arayüzünde de görünen gerçek bir durum olarak saklayın. İşaretlemede görünen kabul, sayfada da görünüyor olmalıdır.

Kabul edilmiş cevap yoksa

Belgeye göre acceptedAnswer ve suggestedAnswer alanlarından birinin bulunması gerekir. Kabul edilmiş bir cevap yoksa cevapları suggestedAnswer olarak vermek, yanlış bir kabul iddiası kurmaktan daha doğrudur. Hiç cevabı olmayan sorularda ise answerCount 0 olur; belge bu durumda zengin sonuç uygunluğunun oluşmayacağını açıkça belirtir. Bu sayfalara işaretleme koymak zorunda değilsiniz, ama koyarsanız cevap yok bilgisini dürüstçe taşıyın.

Soru sayfasının kalıcı adresi

Her soru kendi adresinde durmalı ve işaretleme bu adresteki sayfada bulunmalıdır. Belge her cevap için ayrı bir url vermenizi güçlü biçimde önerir; cevapları sayfa içi bölüm adresleriyle (örneğin bir bölüm kimliği) adreslemek bunun bir yoludur. Hangi adres biçiminin sisteminize uyacağı teknik ekibin kararıdır.

Soru sayfası kısaltma ve sayfalama

Çok sayıda cevap alan bir soru birkaç sayfaya bölünüyorsa belge bu duruma özgü bir kural vermiyor. Uygulama önerisi: tüm cevapların aynı adreste durabildiği bir tasarım, işaretleme ile sayfa metni arasındaki tutarlılığı en kolay sağlayan tasarımdır. Cevaplar sayfalandırılıyorsa, sayfada görünmeyen cevapların işaretlemede olmaması gerekir; çünkü belge tam metnin işaretlemede yer almasını ve sayfa içeriğiyle uyumu ister.

Topluluk bölümü açmadan önce karar

Yalnızca işaretleme için topluluk kurulmaz

Bu işaretlemeyi kullanabilmek için sıfırdan bir soru-cevap bölümü açmak cazip görünebilir. Belge böyle bir hedefi onaylamıyor; amaç, zaten var olan kullanıcı içeriğini doğru betimlemektir. Gerçek bir ihtiyaç olmadan açılmış bir bölüm hem moderasyon yükü hem de ince içerik riski doğurur. Uygulama önerisi: bir soru-cevap bölümü ancak kullanıcılarınızın sorularına karşılık gelen bir ihtiyaç ve moderasyon kapasitesi varsa açılsın.

1. Kullanıcılar sitenizde gerçekten soru soruyor mu, soruyorsa nerede?
2. Cevap yazacak biri var mı: kullanıcılar mı, uzmanlar mı, ekibiniz mi?
3. Gelen cevapları kim, ne sıklıkla denetleyecek?
4. Spam ve ilgisiz tanıtımla başa çıkacak bir kural listeniz var mı?
5. Cevapsız soruların birikmesi durumunda ne yapacaksınız?

Bu beş sorunun cevabı net değilse işaretleme konusunu erteleyin. Yorum alanıyla ilgili benzer bir değerlendirme için blog yorumu ve profil linkleri yazısı, kullanıcı içeriğinin bırakan taraf açısından değerini ele alır.

Destek topluluğu ile bilgi bankası farkı

Birçok şirket hem kendi yazdığı yardım makalelerini hem de kullanıcıların birbirine yardım ettiği bir topluluğu birlikte sunar. İkisinin işaretlemesi farklıdır: yardım makalesi editörün yazdığı bir kılavuz olduğundan QAPage'e uygun değildir, topluluktaki tek soru sayfası ise uygun olabilir. Aynı alan adı altında bunları ayırt eden bir şablon kuralı yazılmalıdır, örneğin sayfa türü alanına göre. Karma bir sitede tek bir şablonun her sayfaya işaretleme basması en sık yapılacak hatadır; bunu bir uygulama uyarısı olarak okuyun.

Örnek senaryo: bir yazılım ürününün topluluk forumu

Örnek senaryo: bir muhasebe yazılımının topluluk bölümünde kullanıcılar "Fatura şablonunda logo nasıl hizalanır?" gibi sorular açıyor. Diğer kullanıcılar cevap yazıyor ve soran kişi bir cevabı çözüm olarak işaretliyor. Her soru ayrı adreste. Şirket aynı sitede kendi yazdığı yardım makalelerini de yayınlıyor. Geliştirici sayfa türü alanını kullanarak yalnız topluluk soru sayfalarında QAPage üretiyor; çözüm olarak işaretlenen cevabı acceptedAnswer, diğerlerini suggestedAnswer olarak veriyor. Yardım makaleleri Article olarak kalıyor, kategori ve arama sayfalarında soru işaretlemesi bulunmuyor. Her cevabın kendi adresi var ve yorumlar Comment olarak ayrı işaretleniyor.

Denetim: yayından önce son kontrol

Denetim tablosu

Tabloya "Evet/Hayır" yazılan sütun sizin doldurmanız içindir. Bir tane bile "Hayır" varsa yayına almadan önce o maddeyi düzeltin.

Bir sayfa kuralı ihlal ediyorsa

Şablonunuz bir sayfa türünde yanlış kurulduğunu gösteriyorsa, işaretlemeyi o sayfa türünden kaldırmak hatalı veriyi bırakmaktan iyidir. Bu bir uygulama önerisidir. Belge, sayfada spam içerik ya da spam işaretleme bulunmasının Rich Results Test ile yakalanamayan sorunlara yol açabileceğini söyleyen genel yönergelere işaret eder; yani doğrulayıcıdan geçmek, işaretlemenin doğru olduğunun kanıtı değildir. Her şablon değişikliğinden sonra birkaç gerçek soru sayfasını açıp işaretlemedeki metni, cevap sayısını ve kabul bilgisini sayfayla gözle karşılaştırın. Bu karşılaştırma eksik cevapları, kırpılmış metni ve yanlış kabul işaretini yakalamaya yarar.

Sık Sorulan Sorular

Sitemin SSS sayfasını QAPage ile işaretleyebilir miyim?

Hayır. Google'ın belgesine göre SSS sayfaları, yani sitenin kendi yazdığı ve kullanıcıların alternatif cevap gönderemediği sayfalar uygun değildir. Birden çok soru içeren sayfalar da uygun değildir.

Bir sayfada birden çok soru ve cevap varsa ne yapmalıyım?

Belge sayfa başına tek QAPage tanımına izin verir ve sayfanın odağının tek soru olmasını ister. Birden çok soru varsa her soruyu kendi sayfasına taşımak ya da işaretleme kullanmamak gerekir.

Kabul edilmiş cevabı nasıl belirlerim?

Belgeye göre acceptedAnswer, sitenizde soran kişi, moderatör ya da oylama sistemi tarafından kabul edilmiş cevabı yansıtmalıdır. Cevapları en yeniye göre sıralamak kabul edilmiş cevap sayılmaz.

Cevabı olmayan soru sayfasına QAPage eklenir mi?

Belgeye göre answerCount cevap yoksa 0 olur, ancak zengin sonuç uygunluğu için acceptedAnswer veya suggestedAnswer ile en az bir cevap gerekir.

QAPage işaretlemesi zengin sonuç getirir mi?

Belge garanti vermez. Yapılandırılmış veriyi kullanan özelliklerin sonuçlarda görüneceği söylenmez; amaç veriyi doğru kurmaktır.

Blog yazımın altındaki yorumlara QAPage ekleyebilir miyim?

Belge bir soruyu yanıtlayan blog yazılarını ve kılavuzları uygun saymaz. Sayfanın ana içeriği editörün makalesi olduğundan altındaki yorumlar sayfayı QAPage yapmaz.

Sonuç

QAPage, tek bir soru ve ona kullanıcıların gönderdiği cevaplar için vardır. Sitenin kendi SSS sayfası, birden çok soru içeren sayfa, blog yazısı ve kılavuz uygun değildir. Zorunlu çekirdek mainEntity altında Question, answerCount, name, bir cevap ve cevap metnidir; kabul edilmiş cevap sitenizdeki gerçek kabule dayanmalıdır. Spam cevaplar da işaretlemeye girebileceği için moderasyon işin parçasıdır. Önce sayfalarınızı karar kuralıyla ayırın, uygun olanlara şablon kurun, küçük bir örneği doğrulayıp raporları izleyin. Zengin sonuç garanti edilmez ve belgenin koşulları değişebilir.

Kısa uygulama sırası: önce sitenizdeki sayfa türlerini karar kuralıyla ayırın; sonra uygun türde veri modelinde soru, cevap, yorum ve kabul bilgisinin ayrı tutulduğunu doğrulayın; ardından tek bir soru sayfası şablonunu kurup doğrulayın ve birkaç canlı sayfayı inceleyin; son olarak moderasyon düzenini ve raporları düzenli izlemeye alın. Süreleri sitenizin yorum ve soru hacmine göre siz belirlersiniz; belgede bir takvim yoktur.

Kullanıcı içeriği olan sayfaların dışından da güvenilir bağlantılar kazanmak istiyorsanız backlink paketlerine göz atabilirsiniz.