Panduan Skema QAPage

TL;DR — Skema QAPage adalah kode yang ditambahkan ke halaman yang berpusat pada satu pertanyaan yang dijawab oleh orang-orang berbeda—misalnya thread forum, halaman dukungan berstatus “solved” (terjemahan) “terselesaikan”, atau halaman bergaya Stack Overflow. Markup ini memberi label pada pertanyaan dan setiap jawaban agar Google dapat menampilkan hasil Tanya Jawab yang lebih kaya. QAPage bukan untuk bagian FAQ yang Anda tulis sendiri (gunakan FAQPage), dan kabar baiknya pada 2026, QAPage masih menjadi fitur Google yang didukung.

Apa itu skema QAPage

Sebagian halaman memang berpusat pada satu pertanyaan yang dijawab oleh komunitas. Seseorang bertanya, “How do I fix X?” (terjemahan) “Bagaimana cara memperbaiki X?”, lalu orang lain mengirim jawaban—satu diterima sebagai solusi, sementara jawaban lain memperoleh suara. Stack Overflow bekerja seperti ini, demikian pula thread forum berstatus “solved” (terjemahan) “terselesaikan” atau halaman dukungan produk tempat pengguna saling membantu.

Skema QAPage adalah blok kode kecil—hampir selalu berupa JSON-LD — yang menjelaskan isi halaman kepada mesin pencari: “this is the question” (terjemahan) “ini pertanyaannya”, “these are the answers” (terjemahan) “ini jawaban-jawabannya”, “this one was accepted” (terjemahan) “jawaban ini diterima”, dan “this one has 12 upvotes” (terjemahan) “jawaban ini memperoleh 12 suara positif”. Pembaca manusia dapat memahaminya sekilas; mesin pencari memerlukan label yang eksplisit.

Mengapa skema ini layak diterapkan

Manfaatnya adalah rich result Tanya Jawab—tampilan hasil yang lebih kaya dan berguna untuk halaman komunitas, yang dapat menyertakan pertanyaan serta jawaban teratas dalam hasil penelusuran. Tampilan yang lebih informatif berpotensi memperoleh lebih banyak klik.

QAPage vs. FAQPage—perbedaan yang wajib dipahami

Bagian ini paling sering membingungkan. Ada dua jenis skema yang namanya terdengar mirip:

• FAQPage—untuk daftar pertanyaan yang Anda tulis dan Anda jawab, seperti bagian “Frequently Asked Questions” (terjemahan) “Pertanyaan yang Sering Diajukan” pada halaman produk. Penulisnya satu pihak: pemilik situs.
• QAPage—untuk satu pertanyaan yang jawabannya dikirim oleh pengguna berbeda. Ini merupakan konten komunitas, bukan salinan yang Anda tulis sendiri.

Uji sederhananya: siapa yang menulis jawaban? Jika Anda sendiri, gunakan FAQPage. Jika komunitas Anda yang menjawab, gunakan QAPage. Google secara eksplisit melarang markup QAPage pada halaman FAQ biasa.

Kabar baik untuk 2026

Pada Mei 2026, Google menghentikan FAQPage sehingga rich result tersebut tidak lagi muncul. HowTo telah dihentikan lebih dahulu. Mudah untuk mengira QAPage ikut dihentikan, tetapi tidak demikian. QAPage masih didokumentasikan dan tetap aktif; halaman dokumentasinya tidak memuat pemberitahuan penghentian. Jika Anda mengelola situs tanya jawab komunitas yang autentik, QAPage merupakan salah satu dari sedikit rich result bertema Tanya Jawab yang masih tersedia.

Kekeliruan yang paling umum

• Jangan menandai FAQ milik Anda sendiri sebagai QAPage untuk menghindari penghentian FAQPage. Google mencadangkan QAPage untuk jawaban yang benar-benar dikirimkan pengguna.
• Markup valid ≠ rich result dijamin tampil. Markup hanya membuat halaman memenuhi syarat; Google tetap memutuskan apakah hasilnya ditampilkan.
• Tandai hanya konten yang benar-benar ada di halaman. Teks pertanyaan dan jawaban dalam kode harus sama dengan yang dilihat pengunjung.

Ingin versi lengkap—properti wajib dan rekomendasi, batas antara QAPage dan DiscussionForumPosting, contoh JSON-LD, serta kebijakan konten yang dapat menggugurkan kelayakan halaman? Buka tab Advanced.

TL;DR — Markup schema.org/QAPage (JSON-LD) membuat halaman memenuhi syarat untuk rich result Tanya Jawab Google. Strukturnya berupa QAPage dengan mainEntity berupa satu Question (wajib: name, answerCount, dan setidaknya salah satu dari acceptedAnswer atau suggestedAnswer); setiap Answer memerlukan text. Properti upvoteCount dan url yang sangat direkomendasikan sering diabaikan panduan lain. Pembeda dari FAQPage adalah kepengarangan: FAQPage merupakan daftar tetap yang ditulis pemilik situs, sedangkan QAPage berisi satu pertanyaan dengan jawaban yang dikirim komunitas. Google menganggap QAPage sebagai kasus khusus DiscussionForumPosting dan menyarankan markup Tanya Jawab saat forum tersusun dalam pola pertanyaan dan jawaban. Jangan menerapkannya ke semua thread, menyamarkan konten yang dijawab sendiri sebagai tanya jawab komunitas, atau menyamakan Answer dengan Comment. Pada 2026, tidak seperti FAQPage (dihentikan 7 Mei 2026) dan HowTo (dihapus pada 2024), QAPage tidak memiliki pemberitahuan penghentian dan tetap aktif. Markup valid hanya memberi kelayakan; Google tetap menentukan apakah hasilnya tampil.

Mengapa QAPage masih penting pada 2026—penghentian FAQPage tidak mencakupnya

Mulailah dari sini karena inilah perkembangan terbaru yang paling sering disalahpahami. Google telah menghentikan beberapa rich result yang berkaitan dengan Tanya Jawab:

• HowTo—dibatasi hanya untuk desktop pada 2023, lalu dihentikan sepenuhnya pada 2024.
• FAQPage—Google menambahkan pemberitahuan penghentian pada dokumentasi FAQPage pada 7 Mei 2026, dan rich result FAQ berhenti tampil pada hari itu. Menurut laporan Search Engine Journal, penerapannya bertahap: rich result berhenti pada 7 Mei 2026; filter tampilan penelusuran FAQ, laporan rich result, dan dukungan Rich Results Test dihapus pada Juni 2026; dukungan data FAQ di Search Console API berakhir pada Agustus 2026.

QAPage tidak termasuk dalam kedua perubahan tersebut. Saat riset ini dilakukan (pertengahan 2026), QAPage docs tidak memuat banner penghentian, peringatan, atau keterangan “Note:” (terjemahan) “Catatan:”. QAPage masih didokumentasikan sebagai jenis rich result tersendiri yang didukung. Kontras terpentingnya: FAQPage sudah dihentikan, sedangkan QAPage belum. Penghentian salah satunya tidak mengancam yang lain karena keduanya mencakup jenis konten yang benar-benar berbeda. Google bahkan terus memperbarui QAPage; sekitar Oktober 2021, Google menghapus kewajiban author dari suggestedAnswer, kebalikan dari spesifikasi yang dibiarkan terbengkalai.

Namun ada catatan penting: tidak seorang pun di Google menjamin masa depan QAPage secara terbuka, dan riset ini tidak menemukan pernyataan khusus tentang QAPage dari perwakilan Google bernama seperti Mueller, Illyes, atau Sullivan. Bukti bahwa fiturnya masih sehat berasal dari status dokumentasi dan pemeliharaan berkelanjutan, bukan sebuah janji. Pernyataan “Google hasn’t had to publicly walk QAPage back the way it did FAQPage” (terjemahan) “Google belum perlu menarik kembali QAPage secara terbuka seperti yang dilakukan terhadap FAQPage” merupakan pembacaan yang wajar atas situasinya.

QAPage vs. FAQPage: pembeda sebenarnya adalah siapa yang menjawab

Jumlah pertanyaan pada halaman bukan inti pembeda. Pembeda sebenarnya adalah kepengarangan:

• FAQPage = pemilik situs menulis daftar tetap pasangan pertanyaan dan jawaban; konten serta jawabannya berasal dari pemilik situs.
• QAPage = satu pertanyaan dengan jawaban yang dikirim oleh anggota komunitas yang berbeda, dan satu pertanyaan dapat memiliki banyak jawaban.

Dalam bahasa kelayakan Google, frasa “user-submitted” (terjemahan) “dikirim oleh pengguna” adalah kuncinya. Dokumentasi QAPage menyebut contoh yang valid secara eksplisit: “a forum page where users can submit answers to a single question” (terjemahan) “halaman forum tempat pengguna dapat mengirim jawaban untuk satu pertanyaan” dan “a product support page where users can submit answers to a single question” (terjemahan) “halaman dukungan produk tempat pengguna dapat mengirim jawaban untuk satu pertanyaan”. Contoh tidak valid juga disebutkan dengan jelas: halaman FAQ tanpa kemampuan pengiriman jawaban oleh pengguna, halaman dengan beberapa pertanyaan, panduan cara melakukan sesuatu, dan posting blog. Secara praktis, ujiannya bukan hanya siapa yang sudah menjawab, melainkan apakah struktur halaman memungkinkan pengguna berbeda mengirim jawaban alternatif. Thread dukungan yang saat ini seluruh balasannya ditulis pemilik situs masih dapat sesuai dengan QAPage jika pengguna lain dapat menambahkan jawaban tandingan. Halaman yang hanya dapat dijawab pemilik situs tidak sesuai, apa pun redaksinya. Karena itu, mengganti label FAQ Anda sendiri menjadi QAPage untuk menghindari penghentian FAQPage tidak akan berhasil; justru jenis konten itulah yang dilarang untuk QAPage.

QAPage vs. DiscussionForumPosting: batas menurut Google

Jika Anda mengelola forum, ada keputusan kedua yang lebih halus: apakah suatu thread merupakan halaman Tanya Jawab atau diskusi? Google menjawabnya langsung dalam dokumentasi Forum Diskusi: “Note that for most of Google’s use cases, a Q&A page is considered a special case of a discussion forum page. If the structure of the forum website is primarily questions with answers, we recommend that you use Q&A markup instead. If the structure is more general and isn’t usually question and answer content, DiscussionForumPosting would be a better choice.” (terjemahan) “Dalam sebagian besar penggunaan Google, halaman Tanya Jawab diperlakukan sebagai bentuk khusus halaman forum diskusi. Bila forum terutama tersusun dari pertanyaan beserta jawabannya, Google menyarankan markup Tanya Jawab. Bila susunannya lebih umum dan biasanya bukan konten tanya jawab, DiscussionForumPosting merupakan pilihan yang lebih tepat.” Dokumentasi yang sama memberikan uji praktis: bila forum mengikuti pola pertanyaan dan jawaban, gunakan markup Tanya Jawab sebagai gantinya.

Model mentalnya berupa hierarki: DiscussionForumPosting adalah kasus umum, sedangkan QAPage merupakan kasus khusus yang dipakai hanya jika strukturnya benar-benar satu pertanyaan beserta jawabannya. Thread Reddit bergaya AMA atau “ask me anything” (terjemahan) “tanyakan apa saja kepada saya” cenderung merupakan Tanya Jawab; thread komentar subreddit umum merupakan diskusi dan lebih tepat memakai DiscussionForumPosting.

Answer vs. Comment—perbedaan yang memang dibuat Google

Di dalam QAPage, tidak setiap balasan merupakan Answer. Google membedakan:

• Answer—jawaban yang benar-benar menjawab pertanyaan. acceptedAnswer dan suggestedAnswer menunjuk ke jenis ini.
• Comment—keterangan klarifikasi pada pertanyaan atau jawaban yang sudah ada. Google mendokumentasikan Comment sebagai jenis opsional dan menegaskan bahwa jenis ini tidak sama dengan Answer.

Menandai setiap komentar pada jawaban sebagai Answer tambahan akan menggelembungkan jumlah jawaban dan menyajikan halaman secara keliru. Ketidakcocokan konten seperti ini dapat memicu tindakan manual data terstruktur. Properti Google mencerminkan pemisahan tersebut: answerCount menghitung jawaban, commentCount menghitung komentar, dan keduanya direkomendasikan pada Question serta objek Answer/Comment terkait agar kedua total dapat dicocokkan secara terpisah.

Properti wajib dan yang direkomendasikan

Strukturnya terdiri atas tiga jenis bertingkat: QAPage, mainEntity-nya (satu Question), dan satu atau beberapa Answer yang terkait dengan pertanyaan tersebut.

Tingkat QAPage

Tingkat Question (mainEntity)

Tingkat Answer (acceptedAnswer / suggestedAnswer)

Ada tiga hal yang sering disalahartikan oleh panduan implementasi. Pertama, pisahkan aturan representasi yang valid dari aturan kelayakan: answerCount: 0 merupakan cara yang sah untuk merepresentasikan pertanyaan yang belum dijawab, tetapi dokumentasi Google menegaskan bahwa “questions without answers aren’t eligible for the rich result” (terjemahan) “pertanyaan tanpa jawaban tidak memenuhi syarat untuk rich result”. Nilai 0 valid sebagai markup, tetapi belum memenuhi syarat untuk rich result. Kedua, acceptedAnswer dan suggestedAnswer tidak saling eksklusif. Istilah “one of” (terjemahan) “salah satu” berarti Anda memerlukan setidaknya satu, bukan hanya satu. Halaman nyata lazimnya memiliki satu jawaban diterima dan beberapa jawaban saran; masing-masing properti dapat berulang (tabel Google mengizinkan “zero or more” (terjemahan) “nol atau lebih”). Ketiga, Answer.url sangat direkomendasikan karena pada halaman dengan puluhan jawaban, properti ini memungkinkan Google dan pengguna membuka jawaban tertentu secara langsung, bukan hanya bagian atas thread.

Identitas penulis. Selain menyebutkan siapa yang bertanya atau menjawab, Google menyarankan agar author.url mengarah ke halaman milik orang tersebut dan halaman itu diberi data terstruktur ProfilePage sehingga identitasnya tidak ambigu. Seperti properti rekomendasi lain, hal ini bukan jaminan; tidak ada janji mengenai peringkat atau tampilan, hanya membantu Google mengenali identitas setiap orang dengan lebih mudah.

Kebijakan konten dan penyebab halaman tidak memenuhi syarat

Markup yang valid bukan satu-satunya syarat. Dokumentasi QAPage dan aturan umum data terstruktur Google juga memberlakukan batasan konten:

• Bukan untuk halaman FAQ atau beberapa pertanyaan per halaman. Satu QAPage hanya untuk satu pertanyaan. Halaman yang mencantumkan beberapa pertanyaan berbeda tidak memenuhi syarat.
• Jangan menerapkannya ke semua thread. Dokumentasi menegaskan: “Don’t apply QAPage markup to all pages on a site or forum if not all the content is eligible.” (terjemahan) “Jangan menerapkan markup QAPage ke semua halaman di sebuah situs atau forum jika tidak semua kontennya memenuhi syarat.” Ini jebakan bagi perangkat lunak forum yang menyisipkan blok skema sama pada setiap URL thread. Terapkan template secara kondisional, hanya pada halaman yang benar-benar sesuai.
• Kesetaraan dengan konten terlihat. Teks pertanyaan dan jawaban dalam markup harus sama dengan yang dilihat pengunjung manusia.
• Konten terlarang. Bahasa cabul, eksplisit secara seksual, mengandung kekerasan grafis, atau kebencian membuat halaman tidak memenuhi syarat meskipun markup valid.
• Tindakan manual. Catatan pemecahan masalah Google menyatakan: “If you received a structured data manual action against your page, the structured data on the page will be ignored (although the page can still appear in Google Search results).” (terjemahan) “Jika halaman Anda menerima tindakan manual data terstruktur, data terstruktur pada halaman akan diabaikan (meskipun halaman masih dapat muncul di hasil Google Penelusuran).” Pemicu umum bukan sesuatu yang khusus untuk QAPage, melainkan pelanggaran aturan “don’t mark up content a user can’t see” (terjemahan) “jangan menandai konten yang tidak dapat dilihat pengguna”, misalnya menandai jawaban yang tidak ada di halaman atau menggelembungkan Answer dengan konten Comment.

Pemisahan antara kelayakan dan tampilan berlaku untuk semua data terstruktur: QAPage tidak menjamin rich result atau peningkatan peringkat. QAPage bukan faktor peringkat; markup ini hanya membuat halaman memenuhi syarat untuk rich result Tanya Jawab, dan Google tetap menentukan apakah hasilnya ditampilkan.

Cara platform nyata menerapkannya

Bukti implementasi dunia nyata yang paling jelas adalah Discourse, platform forum sumber terbuka. Ketika tim Discourse membahas penerapan markup Google untuk plugin discourse-solved—fitur “mark this reply as the solution” (terjemahan) “tandai balasan ini sebagai solusi”—pendirinya, Sam Saffron, menyatakan QAPage sebagai pilihan yang tepat. Struktur QAPage dipetakan ke fitur yang sudah dikenal: balasan terselesaikan menjadi acceptedAnswer, balasan lain menjadi suggestedAnswer, dan jumlah suara menjadi upvoteCount. Jika Anda membangun atau mengonfigurasi forum, hubungkan markup dengan mekanisme “accepted answer” (terjemahan) “jawaban diterima” yang sudah tersedia dan keluarkan markup hanya pada thread yang benar-benar mengikuti pola Tanya Jawab.

QAPage dan Education Q&A bukan fitur yang sama

Nama kedua fitur mudah tertukar. Google mendokumentasikan data terstruktur Education Q&A secara terpisah. Markup Quiz + Question + Answer dengan eduQuestionType: Flashcard mendukung carousel bergaya kartu belajar untuk topik pendidikan. Tampilannya berbeda. Dokumentasi tersebut mengarahkan halaman komunitas dengan satu pertanyaan kembali ke QAPage: jika halaman Anda berisi satu pertanyaan yang diikuti beberapa jawaban pengguna, gunakan QAPage, bukan Education Q&A.

Memvalidasi dan menguji markup

Uji markup QAPage dengan Rich Results Test, yang melaporkan kelayakan Tanya Jawab, serta Schema Markup Validator dari schema.org untuk sintaks. Alur yang masuk akal: tambahkan properti → periksa terhadap pedoman QAPage → terapkan sebagai JSON-LD → validasi. Setelah tayang, pantau kesalahan data terstruktur di Search Console dan pastikan peningkatan benar-benar muncul, dengan mengingat bahwa kelayakan tidak menjamin tampilan.

Catatan tentang Bing

Riset ini tidak menemukan dokumentasi QAPage khusus Bing. Bing Webmaster Tools mendokumentasikan dukungan umum untuk data terstruktur JSON-LD, Microdata, dan RDFa, serta menyediakan Schema Markup Validator, tetapi tidak ada panduan khusus QAPage. Pernyataan yang jujur adalah: Google memiliki panduan QAPage khusus dan rich result Tanya Jawab yang terdokumentasi; dukungan Bing relatif tidak terdokumentasi. Ini merupakan kekosongan dalam materi yang diterbitkan Bing, bukan klaim tentang cara Bing atau sistem lain mengurai maupun menampilkan markup. Markup yang valid dan sesuai schema.org tidak membuktikan bahwa konsumen non-Google tertentu menggunakannya. Perilaku Bing harus diverifikasi langsung pada hasil Bing, bukan disimpulkan dari validitas teknis.

Posisi QAPage dalam data terstruktur

QAPage berada di bagian Social & Community dalam data terstruktur, bersama skema FAQPage dan skema DiscussionForumPosting. Ketiganya perlu sering dibandingkan. Untuk istilah yang lebih luas dan posisi QAPage, lihat hub Data Terstruktur dan Schema Markup yang menaungi artikel ini.

Ringkasan AI

Ringkasan singkat dari versi Advanced:

• Definisi: markup schema.org/QAPage (JSON-LD) untuk halaman berisi satu pertanyaan dengan jawaban dari komunitas, seperti thread forum, halaman dukungan berstatus “solved” (terjemahan) “terselesaikan”, atau halaman bergaya Stack Overflow.
• Status 2026: QAPage tidak memuat pemberitahuan penghentian dan tetap aktif, tidak seperti FAQPage (dihentikan 7 Mei 2026) dan HowTo (2024).
• QAPage vs. FAQPage: pembeda utamanya kepengarangan, bukan jumlah pertanyaan. FAQPage ditulis pemilik situs; QAPage dijawab oleh pengguna berbeda.
• QAPage vs. DiscussionForumPosting: QAPage merupakan kasus khusus forum diskusi untuk struktur pertanyaan dan jawaban; diskusi umum memakai DiscussionForumPosting.
• Struktur: QAPage memiliki mainEntity berupa satu Question, dengan name, answerCount, dan setidaknya salah satu acceptedAnswer/suggestedAnswer; setiap Answer memerlukan text, sedangkan url sangat direkomendasikan dan upvoteCount direkomendasikan. Nilai answerCount: 0 valid untuk representasi pertanyaan tanpa jawaban, tetapi belum memenuhi syarat rich result.
• Answer ≠ Comment: jawaban merupakan respons nyata; komentar hanya klarifikasi. Karena itu, answerCount dan commentCount dihitung secara terpisah.
• Identitas penulis: author.url dan markup ProfilePage direkomendasikan untuk membantu identifikasi, bukan sebagai jaminan peringkat atau tampilan.
• Kebijakan konten: satu pertanyaan per halaman; jangan terapkan markup ke semua thread; markup harus sesuai dengan konten terlihat dan mematuhi kebijakan konten.
• Kelayakan ≠ tampilan: QAPage bukan faktor peringkat; Google tetap menentukan apakah rich result ditampilkan.
• Contoh platform: plugin discourse-solved milik Discourse memetakan balasan diterima ke acceptedAnswer.
• Bing: tidak ditemukan dokumentasi khusus QAPage; Google merupakan mesin dengan rich result Tanya Jawab yang terdokumentasi.

Dokumentasi resmi

Dokumentasi sumber primer dari mesin pencari.

Google

• Data terstruktur untuk halaman Tanya Jawab (QAPage) — referensi utama untuk properti, penggunaan valid/tidak valid, aturan cakupan, dan kebijakan konten.
• Data terstruktur forum diskusi — batas antara QAPage dan DiscussionForumPosting.
• Data terstruktur Education Q&A — fitur carousel kartu belajar/kuis yang terpisah.
• Markup FAQ dengan data terstruktur FAQPage — kini memuat pemberitahuan penghentian 2026.
• Rich Results Test — memvalidasi markup dan memeriksa kelayakan Tanya Jawab.

Schema.org

• QAPage dan Question — definisi kosakata dasarnya.

Bing / Microsoft

• Menandai situs dengan data terstruktur — dukungan umum data terstruktur Bing.

Kutipan dari sumber

Pernyataan tercatat dari dokumentasi Google dan pengelola perangkat lunak forum yang mengadopsi QAPage. Jika halaman sumber menyediakan teksnya, tautan akan membuka bagian yang dikutip secara langsung.

Dokumentasi Google—cakupan dan aturan QAPage

• Mengenai Question.name yang wajib: “The full text of the question in its short form.” (terjemahan) “Teks lengkap pertanyaan dalam bentuk ringkas.” — dokumentasi QAPage Google Search Central. Buka kutipan
• Mengenai larangan menerapkan template ke semua halaman: “Don’t apply QAPage markup to all pages on a site or forum if not all the content is eligible.” (terjemahan) “Jangan menerapkan markup QAPage ke semua halaman di sebuah situs atau forum jika tidak semua kontennya memenuhi syarat.” Buka kutipan
• Mengenai tindakan manual: “If you received a structured data manual action against your page, the structured data on the page will be ignored (although the page can still appear in Google Search results).” (terjemahan) “Jika halaman Anda menerima tindakan manual data terstruktur, data terstruktur pada halaman akan diabaikan (meskipun halaman masih dapat muncul di hasil Google Penelusuran).” Buka kutipan

Dokumentasi Google—batas antara QAPage dan DiscussionForumPosting

• “Note that for most of Google’s use cases, a Q&A page is considered a special case of a discussion forum page. If the structure of the forum website is primarily questions with answers, we recommend that you use Q&A markup instead. If the structure is more general and isn’t usually question and answer content, DiscussionForumPosting would be a better choice.” (terjemahan) “Untuk sebagian besar kasus penggunaan Google, halaman Tanya Jawab dianggap sebagai kasus khusus dari halaman forum diskusi. Jika struktur situs forum terutama berupa pertanyaan beserta jawaban, sebaiknya gunakan markup Tanya Jawab. Jika strukturnya lebih umum dan biasanya bukan konten pertanyaan dan jawaban, DiscussionForumPosting merupakan pilihan yang lebih tepat.” — dokumentasi Discussion Forum Google Search Central. Buka kutipan
• “Does your forum follow a question and answer pattern? Use Q&A markup instead.” (terjemahan) “Apakah forum Anda mengikuti pola pertanyaan dan jawaban? Gunakan markup Tanya Jawab.” Buka kutipan

Sam Saffron, pendiri Discourse (Discourse Meta, thread implementasi perangkat lunak forum)

• Saat menyatakan QAPage sebagai markup yang tepat untuk plugin discourse-solved: “Introduce QAPage - Schema.org Type which is the best anyway.” (terjemahan) “Perkenalkan QAPage—jenis Schema.org yang memang merupakan pilihan terbaik.” Baca thread

Ringkasan praktis QAPage

Skema yang sesuai untuk tiap jenis halaman

Struktur bertingkat

QAPage → mainEntity → satu Question → acceptedAnswer dan/atau suggestedAnswer (masing-masing berupa Answer).

Properti wajib

Kolom rekomendasi bernilai tinggi

• Answer.url—sangat direkomendasikan; menautkan langsung ke jawaban tertentu.
• upvoteCount—pada pertanyaan dan setiap jawaban.
• author, datePublished—pada pertanyaan dan jawaban.

Fakta singkat

• Format: JSON-LD (direkomendasikan).
• answerCount: 0 valid untuk pertanyaan tanpa jawaban, tetapi belum memenuhi syarat rich result sampai ada jawaban. Diperlukan setidaknya satu dari acceptedAnswer/suggestedAnswer; keduanya dapat digunakan bersama dan berulang.
• Answer ≠ Comment; answerCount dan commentCount dihitung terpisah.
• author.url dan markup ProfilePage direkomendasikan sebagai bantuan identitas, bukan jaminan peringkat.
• Jangan terapkan ke semua thread; gunakan hanya pada halaman yang sesuai.
• Konten harus sama dengan yang terlihat dan mematuhi batasan konten.
• 2026: QAPage masih aktif; FAQPage (Mei 2026) dan HowTo (2024) dihentikan.
• Markup valid berarti memenuhi syarat, bukan dijamin tampil, dan bukan faktor peringkat.

QAPage vs. FAQPage vs. DiscussionForumPosting—pilih yang mana?

Ketiga jenis skema Social & Community ini sering tertukar. Jawab pertanyaan pada pohon keputusan untuk memilih jenis yang tepat berdasarkan batas yang ditetapkan Google.

Mitos dan kesalahan QAPage yang harus dihindari

Mitos: “QAPage got killed along with FAQPage in the May 2026 deprecation.” (terjemahan) “QAPage ikut dihentikan bersama FAQPage pada Mei 2026.” Salah. Keduanya merupakan fitur terpisah dengan kriteria kelayakan dan dokumentasi masing-masing. Hanya FAQPage dan, sebelumnya, HowTo yang dihentikan; dokumentasi QAPage tidak memuat pemberitahuan penghentian dan rich result ini tetap aktif.

Mitos: “QAPage and FAQPage are interchangeable — pick whichever.” (terjemahan) “QAPage dan FAQPage dapat dipertukarkan—pilih saja salah satu.” Salah. Google secara eksplisit melarang QAPage pada halaman FAQ. Uji pembedanya adalah kepengarangan: jawaban terkurasi dari satu sumber (FAQPage) dibandingkan jawaban dari banyak anggota komunitas (QAPage). Mengganti label FAQ sendiri menjadi QAPage justru merupakan jenis konten yang dilarang untuk QAPage.

Mitos: “Any forum thread should use QAPage since it’s about Q&A.” (terjemahan) “Semua thread forum harus memakai QAPage karena membahas tanya jawab.” Salah. QAPage hanya merupakan kasus khusus ketika strukturnya benar-benar satu pertanyaan dengan jawaban. Thread diskusi umum memakai DiscussionForumPosting, dan klarifikasi ditandai sebagai Comment, bukan Answer.

Kesalahan: menerapkan markup QAPage ke semua template thread di seluruh situs. Google memperingatkan secara eksplisit: “Don’t apply QAPage markup to all pages on a site or forum if not all the content is eligible.” (terjemahan) “Jangan menerapkan markup QAPage ke semua halaman di sebuah situs atau forum jika tidak semua kontennya memenuhi syarat.” Terapkan template secara kondisional hanya pada halaman yang memenuhi syarat.

Kesalahan: menandai komentar pada jawaban sebagai jawaban tambahan. Answer benar-benar menjawab pertanyaan; Comment hanya mengklarifikasi pertanyaan atau jawaban yang ada. Mencampur keduanya menggelembungkan answerCount, menyajikan konten secara keliru, dan berisiko memicu tindakan manual data terstruktur.

Kesalahan: menandai halaman dengan beberapa pertanyaan sebagai satu QAPage. QAPage hanya untuk satu pertanyaan per halaman. Halaman berisi beberapa pertanyaan berbeda tidak memenuhi syarat.

Kesalahan: markup tidak sesuai dengan halaman yang terlihat. Teks pertanyaan dan jawaban dalam JSON-LD harus sama dengan yang dilihat pengunjung. Menandai jawaban yang tidak ada di halaman merupakan pemicu klasik tindakan manual; setelah itu Google mengabaikan seluruh data terstruktur halaman.

Mitos: “QAPage guarantees a rich result or a ranking boost.” (terjemahan) “QAPage menjamin rich result atau peningkatan peringkat.” Berlebihan. Seperti semua data terstruktur, QAPage hanya membuat halaman memenuhi syarat untuk rich result Tanya Jawab. QAPage bukan faktor peringkat, dan kelayakannya tetap dibatasi mutu serta kebijakan bahasa/konten.

JSON-LD QAPage yang benar vs. rusak

QAPage yang benar (satu pertanyaan, satu jawaban diterima, dan satu jawaban saran)

Satu pertanyaan sebagai mainEntity, answerCount yang benar, satu acceptedAnswer, dan satu suggestedAnswer, masing-masing dengan upvoteCount serta Answer.url yang sangat direkomendasikan. Contoh disederhanakan agar mudah dibaca.

{
  "@context": "https://schema.org",
  "@type": "QAPage",
  "mainEntity": {
    "@type": "Question",
    "name": "How do I redirect an old URL to a new one without losing rankings?",
    "text": "We're consolidating two blog posts. What's the right redirect to keep the rankings?",
    "answerCount": 2,
    "author": { "@type": "Person", "name": "Dana R." },
    "datePublished": "2026-05-20T09:12:00-05:00",
    "upvoteCount": 8,
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Use a 301 permanent redirect from the old URL to the new one — it passes signals and tells Google the move is permanent.",
      "url": "https://example.com/community/redirect-question#answer-341",
      "upvoteCount": 27,
      "author": { "@type": "Person", "name": "Marcus T." },
      "datePublished": "2026-05-20T10:03:00-05:00"
    },
    "suggestedAnswer": {
      "@type": "Answer",
      "text": "A rel=canonical can work if both pages stay live, but for an actual move a 301 is the clearer instruction.",
      "url": "https://example.com/community/redirect-question#answer-352",
      "upvoteCount": 5,
      "author": { "@type": "Person", "name": "Priya S." },
      "datePublished": "2026-05-20T11:40:00-05:00"
    }
  }
}

Halaman yang sama, tetapi rusak

Setiap baris yang ditandai di bawah menunjukkan kesalahan umum yang nyata:

{
  "@context": "https://schema.org",
  "@type": "FAQPage",
  "mainEntity": {
    "@type": "Question",
    "name": "How do I redirect an old URL to a new one?",
    "acceptedAnswer": {
      "@type": "Answer",
      "text": "Use a 301 redirect."
    },
    "suggestedAnswer": {
      "@type": "Comment",
      "text": "Thanks, that worked!"
    }
  }
}

Masalahnya:

• "@type": "FAQPage" digunakan pada jawaban komunitas. Ini seharusnya QAPage; FAQPage merupakan jenis yang salah dan kini sudah dihentikan.
• Tidak ada answerCount, padahal properti ini wajib pada Question.
• suggestedAnswer berupa Comment, bukan Answer; “Thanks, that worked!” (terjemahan) “Terima kasih, itu berhasil!” merupakan komentar klarifikasi, bukan jawaban. Properti suggestedAnswer harus menunjuk ke sebuah Answer.
• Tidak ada upvoteCount maupun Answer.url; url sangat direkomendasikan agar Google dapat menautkan langsung ke jawaban tertentu dalam thread panjang.
• Tidak ada masalah jika author dihilangkan dari suggestedAnswer karena Google mencabut kewajiban tersebut pada 2021. Namun, answerCount yang hilang dan penggunaan Comment sebagai Answer merupakan kesalahan nyata.

Menerapkannya pada fitur forum “solved” (terjemahan) “terselesaikan”

Petakan skema ke fitur yang sudah Anda miliki, mengikuti pola plugin discourse-solved milik Discourse:

• Balasan yang ditandai sebagai solusi → acceptedAnswer.
• Setiap balasan lain yang menjawab pertanyaan → suggestedAnswer.
• Balasan yang hanya berupa klarifikasi (“did you try X?” (terjemahan) “apakah Anda sudah mencoba X?”, “thanks!” (terjemahan) “terima kasih!”) → Comment, bukan Answer.
• Jumlah suara thread → upvoteCount pada pertanyaan dan setiap jawaban.
• Keluarkan blok hanya pada thread yang mengikuti pola Tanya Jawab, bukan pada setiap URL forum.

Uji pemahaman Anda: Skema QAPage

Lima pertanyaan singkat tentang kegunaan QAPage, perbedaannya dari jenis terkait, dan properti wajibnya. Pilih satu jawaban untuk setiap pertanyaan, lalu periksa hasilnya.

Referensi yang layak dibaca

Tulisan saya tentang topik ini

Saya belum menerbitkan panduan QAPage mandiri. Karena itu, pilihan yang jujur adalah mengarahkan Anda ke sumber primer di bawah dan tulisan data terstruktur terkait di situs ini. Untuk kosakata yang lebih luas serta posisi QAPage, lihat hub Data Terstruktur dan Schema Markup. Jenis yang paling dekat adalah skema FAQPage dan skema DiscussionForumPosting dalam subklaster Social & Community yang sama. Untuk sudut pandang AI, baca Schema Markup untuk AI.

Dari industri

• Data terstruktur untuk halaman Tanya Jawab (QAPage) (Google Search Central) — referensi utama untuk properti, penggunaan valid/tidak valid, dan kebijakan konten.
• Data terstruktur forum diskusi (Google) — batas QAPage dan DiscussionForumPosting yang dikutip di tab Quotes.
• Data terstruktur Education Q&A (Google) — fitur carousel kartu belajar yang terpisah.
• Google menghapus rich result FAQ dari Penelusuran (Search Engine Journal) — penghentian FAQPage 2026 dan jadwal bertahap Mei–Agustus.
• Google mengubah lebih banyak persyaratan data terstruktur (Search Engine Journal, Roger Montti, Oktober 2021) — laporan tentang pencabutan kewajiban suggestedAnswer.author.
• Google meluncurkan data terstruktur Tanya Jawab untuk halaman pertanyaan dan jawaban (Search Engine Land) — liputan peluncuran awal QAPage.
• Dukungan schema.org QAPage dan rich result Google (Discourse Meta) — tim perangkat lunak forum yang mengadopsi QAPage untuk plugin discourse-solved.
• r/TechSEO — komunitas untuk pemecahan masalah data terstruktur dan rich result.

Log perubahan