برای سئوی انجمن، اول نقش هر URL را روشن کنید: دسته موضوع را معرفی کند، تاپیک یک گفتوگوی مشخص را نگه دارد و پروفایل مشارکت واقعی یک عضو را نشان دهد. صفحههای خالی و مشابه را بی‌دلیل نمایه نکنید، راه رسیدن خزنده به صفحههای بعدی را باز بگذارید و دادهٔ ساختاریافته را فقط برای نوع صفحهٔ واجد شرایط به کار ببرید.
فرض کنید در انجمن پشتیبانی یک نرم‌افزار، سه نفر جداگانه می‌پرسند «چرا بعد از به‌روزرسانی نمی‌توانم وارد حساب شوم؟». اگر هر پرسش، با عنوان تقریباً یکسان و بدون پاسخ، URL جدا بگیرد، جست‌وجوگر و عضو تازه نمی‌دانند کدام صفحه پاسخ اصلی است. اگر همهٔ پیام‌ها بدون توجه به نسخهٔ نرم‌افزار در یک تاپیک جمع شوند، تفاوت مسئله‌ها از بین می‌رود. طراحی انجمن باید این دو وضعیت را از هم جدا کند.
این مقاله دربارهٔ معماری صفحههای یک انجمن یا کامیونیتی متعلق به سایت است. راهنمای محتوای تولیدشده توسط کاربر معیار پذیرش نظر، کنترل لینک کاربر و رسیدگی به اسپم را جداگانه توضیح می‌دهد. مقالهٔ قدیمی سایت دربارهٔ انجمن‌های سئو نیز فهرستی از انجمن‌های آموزشی است؛ در اینجا قرار نیست انجمنی را معرفی یا رتبه‌بندی کنیم.
نقشهٔ URL انجمن را از چه صفحه‌هایی بسازیم؟
یک انجمن معمولاً به صفحهٔ دسته، صفحهٔ تاپیک و صفحهٔ پروفایل نیاز دارد. صفحهٔ دسته راه رسیدن به گفت‌وگوهای یک حوزه است؛ تاپیک متن اصلی و پاسخ‌ها را نگه می‌دارد؛ پروفایل، فعالیت یک عضو را نشان می‌دهد. URLهای جست‌وجوی داخلی، مرتب‌سازی و فیلتر نیز ممکن است ساخته شوند، اما معمولاً همان نقش این سه صفحه را ندارند.
در مثال فرضیِ انجمن پشتیبانی، دستهٔ «ورود به حساب» فهرست پرسشهای ورود را نشان می‌دهد. تاپیک «خطای ورود در نسخهٔ ۴.۲» باید همان مسئله و پاسخهای مربوط را در یک نشانی پایدار داشته باشد. پروفایل نویسنده نیز زمانی صفحهٔ مستقلی برای خواننده است که بیش از یک نام و تصویر پیش‌فرض به او نشان دهد.
| نوع صفحه | پرسش خواننده | محتوای اصلی که باید دیده شود |
|---|---|---|
| دستهٔ موضوعی | دربارهٔ این حوزه چه بحث‌هایی هست؟ | توضیح کوتاه دسته و فهرست تاپیکهای مرتبط |
| تاپیک | پاسخ یا تجربه دربارهٔ این مسئله چیست؟ | پرسش یا پست آغازین، پاسخ‌ها و وضعیت گفت‌وگو |
| پروفایل عضو | این شخص چه مشارکتی داشته است؟ | هویت نمایشی مجاز و فهرست مشارکتهای واقعی |
| جست‌وجو و فیلتر | کدام موارد با این شرط جورند؟ | نتیجهٔ موقت؛ تصمیم نمایهشدن بر اساس ارزش مستقل صفحه |
پیش از ساخت دسته‌های زیاد، چند مسیر واقعی کاربر را روی کاغذ بکشید. آیا عضو از صفحهٔ اصلی به دسته و سپس به تاپیک می‌رسد؟ آیا تاپیک از مقالهٔ راهنمای مربوط هم پیدا می‌شود؟ راهنمای ساختار سایت دربارهٔ رابطهٔ صفحههای مادر و فرزند توضیح می‌دهد؛ در انجمن این رابطه باید با لینک‌های واقعی و عنوان‌های روشن دیده شود.
صفحهٔ دسته را چگونه برای عضو و خزنده مفید کنیم؟
صفحهٔ دسته زمانی ارزش مستقل دارد که حوزه‌اش مشخص باشد و تاپیکهای آن واقعاً به همان موضوع تعلق داشته باشند. عنوان «سؤالات متفرقهٔ ۲» یا دسته‌ای با یک تاپیک بی‌پاسخ، مسیر خوبی برای خواننده نمی‌سازد. دسته‌ها را بر اساس مسائل پایدار بسازید، نه هر واژه‌ای که در یک پرسش آمده است.
در بالای دسته، یک توضیح کوتاه بنویسید: اینجا چه پرسش‌هایی مطرح می‌شوند، چه موضوع‌هایی جای دیگری‌اند و عضو از کجا شروع کند. فهرست تاپیک‌ها عنوان توصیفی، وضعیت پاسخ و زمان آخرین فعالیت را نشان دهد. عدد پاسخ‌ها مفید است، اما تعداد بالا به‌تنهایی کیفیت گفت‌وگو را ثابت نمیکند.
اگر دسته‌ای خالی است، یا آن را تا زمان داشتن محتوای واقعی در ناوبری عمومی برجسته نکنید، یا آن را با دستهٔ نزدیک ادغام کنید. برای دسته‌هایی که فهرست بلند دارند، صفحههای بعدی باید از صفحهٔ اول با پیوند قابل دنبالکردن در دسترس باشند. تصمیم دربارهٔ نمایهشدن خودِ صفحهٔ دسته را با محتوای واقعی و تفاوت آن با دسته‌های مجاور بسنجید.
هر تاپیک چه زمانی یک صفحهٔ مستقل می‌خواهد؟
تاپیک مستقل باید یک مسئله یا گفتوگوی قابل تشخیص داشته باشد. عنوانی مانند «کمک فوری» چیزی دربارهٔ موضوع نمی‌گوید؛ «خطای ورود پس از تغییر رمز در نسخهٔ ۴.۲» موضوع و زمینه را مشخص میکند. پست نخست باید اطلاعات لازم برای فهم پرسش را داشته باشد و پاسخ‌ها به همان مسئله برگردند.
از کاربر هنگام ساخت تاپیک چند نشانهٔ لازم را بگیرید، نه فرم طولانیِ بی‌دلیل: موضوع، نسخه یا شرایط مرتبط و آنچه پیش‌تر امتحان کرده است. پیش از ثبت، تاپیکهای مشابه را نشان دهید تا کاربر بتواند گفتوگوی موجود را بخواند. این پیشنهاد باید کمک به یافتن پاسخ باشد، نه مانعی که پرسش تازه را بی‌دلیل رد کند.
اگر موضوع حل شد، وضعیت آن را آشکار کنید و پاسخ مؤثر را قابل پیدا کردن نگه دارید. در گفتوگوی باز که چند تجربهٔ متفاوت دارد، برچسب «پاسخ قطعی» ممکن است گمراه‌کننده باشد. پرسش‌هایی که به نسخه یا تاریخ وابسته‌اند به توضیح شرایط نیاز دارند؛ پاسخ درست برای نسخهٔ قدیمی را بدون قید به خوانندهٔ نسخهٔ تازه نشان ندهید.
برای تاپیک قدیمی، تاریخ آخرین پاسخ به‌تنهایی نشان نمی‌دهد راه‌حل هنوز کار میکند. اگر محصول عوض شده، توضیح کوتاهی در ابتدای گفت‌وگو بگذارید که نسخهٔ پوشش‌داده‌شده را مشخص کند و به تاپیک تازهٔ همان مسئله پیوند دهد. اگر مسئله همچنان همان است، پاسخهای جدید را به همان تاپیک اضافه کنید و از ساخت نسخهٔ دوباره پرهیز کنید.
با تاپیکهای تکراری چه تصمیمی بگیریم؟
دو تاپیک با واژه‌های مشابه همیشه تکراری نیستند. پیش از ادغام، مسئله، نسخه، شرایط و پاسخ‌ها را مقایسه کنید. اگر هر دو دقیقاً یک پرسش را پاسخ می‌دهند، صفحهٔ کامل‌تر را نگه دارید و پاسخ منحصربهفرد صفحهٔ دیگر را با ذکر زمینه به آن منتقل کنید. سپس دربارهٔ تغییر مسیر URL اضافی تصمیم بگیرید.
در مثال ورود به حساب، «خطا پس از فراموشی رمز» با «خطا پس از فعال‌کردن ورود دومرحله‌ای» یکی نیست، حتی اگر هر دو واژهٔ «ورود» داشته باشند. اما دو تاپیکِ بدون تفاوت دربارهٔ همان پیام خطا و همان نسخه می‌توانند یک مسیر اصلی داشته باشند. تعداد مشابهت واژه‌ها به‌تنهایی معیار ادغام نیست.
اگر صفحهٔ دوم مشارکت و پیوند دارد، پیش از تغییر مسیر، پاسخهای ارزشمند و ترتیب گفت‌وگو را بررسی کنید. انتقال کورکورانهٔ تمام پیام‌ها می‌تواند پاسخ‌ها را از پرسش اصلی جدا کند. پس از ادغام، لینک‌های داخلی به مقصد نهایی را اصلاح کنید و مطمئن شوید نشانی قدیمی به صفحهٔ مرتبط می‌رسد، نه به صفحهٔ اصلی انجمن.
برای هر ادغام یک ثبت کوتاه داشته باشید: URL قدیمی، URL اصلی، دلیل یکی‌بودن مسئله، پاسخهای منتقل‌شده و نتیجهٔ بازکردن نشانی قدیمی. اگر پس از انتقال، کاربران هنوز همان پرسش را تکرار می‌کنند، شاید عنوان یا پاسخ اصلی برایشان روشن نیست. پیش از ساخت تاپیک سوم، همان صفحهٔ اصلی را اصلاح کنید.
canonical برای نسخه‌های واقعاً تکراری یک نشانهٔ ترجیح URL است، اما جای تصمیم محتوایی را نمی‌گیرد. تاپیک‌هایی که مسئله یا پاسخ متفاوت دارند نباید فقط به‌خاطر اشتراک چند واژه به یک canonical اشاره کنند. در نقشهٔ لینک‌سازی داخلی نیز مقصد هر ارجاع را به صفحهٔ نهایی و مفید وصل کنید.
صفحه‌بندی و «نمایش بیشتر» را چگونه اجرا کنیم؟
در انجمن پررفت‌وآمد، فهرست دسته و پاسخهای یک تاپیک ممکن است چند صفحه شوند. راهنمای صفحه‌بندی گوگل می‌گوید خزنده‌ها معمولاً URLهای داخل href را دنبال می‌کنند و دکمه‌هایی را که به اقدام کاربر نیاز دارند کلیک نمی‌کنند. بنابراین محتوای صفحهٔ دوم نباید فقط پشت دکمهٔ جاوااسکریپتیِ بدون URL پنهان باشد.
برای هر صفحهٔ فهرست، URL قابل دسترس و پیوند «بعدی» با href واقعی بگذارید. اگر URL صفحه‌ها با پارامتر تفاوت دارد، عدد صفحه را در بخش fragment پس از # نگذارید. وضعیت canonical هر صفحهٔ دارای محتوای متفاوت را جدا بررسی کنید؛ گوگل توصیه میکند صفحههای دنبالهدار به‌طور خودکار canonical صفحهٔ اول نشوند. برچسب‌های قدیمی rel="next" و rel="prev" را هم راه‌حل کشف صفحه‌ها فرض نکنید؛ گوگل دیگر از آن‌ها برای تشخیص این رابطه استفاده نمیکند.
دکمهٔ «نمایش بیشتر» می‌تواند برای کاربر بماند، به شرطی که مسیر URLهای صفحههای بعدی نیز قابل کشف باشد. در آزمون، جاوااسکریپت را موقتاً کنار بگذارید و ببینید آیا از HTML صفحهٔ اول می‌توان به صفحهٔ بعد و تاپیکهای آن رسید. اگر تنها راه رسیدن، کلیک در مرورگر است، مسیر خزش ناقص است.
برای مرتب‌سازی بر اساس «جدیدترین»، «پربازدیدترین» یا فیلتر برچسب، بررسی کنید چند URL تقریباً یک فهرست یکسان می‌سازند. همهٔ ترکیب‌های فیلتر به صفحهٔ قابل نمایه نیاز ندارند. ابتدا نمونهٔ واقعی را ببینید، سپس برای URLهای بدون ارزش مستقل، سیاست خزش یا نمایه‌سازی تعیین کنید؛ robots.txt و noindex کار یکسانی انجام نمی‌دهند.
پروفایل اعضا را چه زمانی نمایه کنیم؟
پروفایل عضو زمانی برای خواننده معنا دارد که مشارکتهای قابل مشاهده و زمینهٔ مشخصی از همان حساب داشته باشد. صفحه‌ای که فقط نام کاربری و تصویر پیش‌فرض دارد، معمولاً پاسخ مستقلی به جست‌وجو نمی‌دهد. برای حساب تازه یا غیرفعال، پیش از بازکردن نمایه‌سازی عمومی، مقدار محتوای واقعی و تنظیمات حریم خصوصی را بررسی کنید.
در راهنمای ProfilePage گوگل، پروفایل عضو یک انجمن نمونهٔ معتبر این نوع دادهٔ ساختاریافته است؛ تمرکز اصلی صفحه باید یک شخص یا سازمان وابسته به همان وب‌سایت باشد. وجود این اسکیما به‌تنهایی پروفایل خالی را مفید نمیکند و نمایش ویژه در نتایج را تضمین نمیکند.
در پروفایل، عنوان نمایشی، معرفی اختیاری و پیوند به مشارکتهای عمومی می‌تواند به خواننده برای ارزیابی سابقهٔ عضو کمک کند. اطلاعات شخصی‌ای را که کاربر برای انتشار عمومی نداده، برای کامل‌کردن پروفایل اضافه نکنید. شمار پست‌ها و نشان‌ها باید از فعالیت واقعی بیاید، نه عدد ساختگی برای غنی نشان دادن صفحه.
اگر هر عضو چند URL پروفایل با نام کاربری، شناسه و پارامترهای مختلف دارد، نسخهٔ اصلی را مشخص کنید. پس از تغییر نام نمایشی، نشانی‌های قدیمی را بی‌دلیل رها نکنید. برای صفحههای فهرست فعالیت عضو نیز همان مسئلهٔ صفحه‌بندی و دسترسی به مشارکتهای قدیمی مطرح است.
دادهٔ ساختاریافتهٔ گفت‌وگو را کجا بگذاریم؟
DiscussionForumPosting برای صفحه‌ای است که محتوای اصلی آن پست کاربر و گفتوگوی مرتبط است. مستند انجمن گوگل تصریح میکند مقالهٔ تحریریهٔ سایت، حتی اگر زیر آن نظر باشد، و صفحهٔ بررسی محصول محل این نشانهگذاری نیست. اگر انجمن به الگوی یک پرسش و پاسخهای کاربران تکیه دارد، گوگل استفاده از نشانهگذاری Q&A را مناسبتر میداند.
متن نشانهگذاری باید با پست و پاسخ‌هایی که کاربر همان صفحه می‌بیند هماهنگ باشد. وقتی پاسخ حذف یا ویرایش می‌شود، دادهٔ ساختاریافته نیز باید همان تغییر را بازتاب دهد. برای صفحهٔ دسته که فقط فهرست تاپیک‌هاست، یک تاپیک را بی‌دلیل mainEntity کل صفحه معرفی نکنید.
پیش از انتشار انبوه، چند تاپیک واقعی با حالت‌های متفاوت را آزمایش کنید: گفتوگوی خطی، پاسخ تودرتو، تاپیک چندصفحه‌ای و صفحه‌ای که محتوای نامناسبش حذف شده است. خطای ابزار آزمون را اصلاح کنید، اما تأیید ابزار را معادل تضمین نمایش ویژه ندانید. متن دیده‌شده، دسترسی خزنده و قواعد محتوایی هم باید درست باشند. این مقالهٔ تحریریه، خودش تاپیکِ کاربر نیست و نباید DiscussionForumPosting بگیرد.
مسئول انجمن چه چیزهایی را به‌طور دوره‌ای بررسی کند؟
کیفیت انجمن با انتشار هر تاپیک تمام نمی‌شود. مسئول مشخص باید صفحههای خالی، پرسشهای تکراری، لینک‌های شکسته، پاسخهای قدیمی و الگوی سوءاستفاده را ببیند. معیار رسیدگی را از قبل بنویسید تا یک پرسش مفید صرفاً به دلیل داشتن واژهٔ مشابه با تاپیک دیگر حذف نشود.
برای یک بازبینی نمونه، شش URL بردارید: دو تاپیک تازه، دو تاپیک قدیمی با بازدید بالا، یک پروفایل تازه و صفحهٔ دوم یک دسته. در هرکدام از خود صفحه به متن اصلی، پاسخ‌ها و مسیر بازگشت برسید؛ canonical، وضعیت نمایه و پیوندهای بعدی را در خروجی زنده ببینید. اگر یک صفحه بی‌پاسخ یا خالی است، آن را با صفحهٔ سالم در یک گزارش آماری جمع نکنید.
بعد روند را برای دسته‌هایی که رشد سریع دارند تکرار کنید. نسبت تاپیکهای بی‌پاسخ، شمار ادغام‌های درست و تعداد صفحههای فهرستِ دور از دسترس می‌تواند به مسئول انجمن نشان دهد کجا باید کار کند. این‌ها شاخص‌های داخلی برای تصمیم عملی‌اند، نه فاکتورهای رتبه‌بندی اعلام‌شدهٔ گوگل.
اگر اجرای معماری دسته‌ها، قالب‌ها و صفحه‌بندی به همکاری بیرونی نیاز دارد، دامنهٔ خدمات حرفه ای سئو را به خروجی قابل بررسی گره بزنید: فهرست URLهای هدف، قواعد ادغام تاپیک، مسئول هر تصمیم و آزمون دوره‌ای صفحههای زنده. ادارهٔ گفت‌وگوهای روزانه همچنان به مسئول انجمن نیاز دارد.
جمع‌بندی
در انجمن، هر صفحه باید کار مشخصی انجام دهد. دسته مسیر کشف موضوع‌هاست، تاپیک جای یک گفتوگوی متمایز و پروفایل نمایش مشارکت واقعی عضو است. پیش از افزایش URLها، تکرارها، صفحه‌بندی، محتوای پروفایل و خروجی دادهٔ ساختاریافته را روی نمونه‌های واقعی بسنجید.
سوالات متداول
آیا هر تاپیک جدید باید در گوگل نمایه شود؟
خیر. تاپیک خالی، اسپم یا تکراری ممکن است ارزش مستقل نداشته باشد. تصمیم را بر اساس متن واقعی، تفاوت مسئله و وضعیت بازبینی بگیرید؛ یک قاعدهٔ واحد برای همهٔ تاپیک‌ها کافی نیست.
آیا همهٔ تاپیکهای مشابه را به یک صفحه منتقل کنیم؟
فقط وقتی مسئله و پاسخ اصلی یکی است. نسخه، شرایط و مشارکتهای منحصربهفرد را پیش از ادغام بررسی کنید. پرسشهای متفاوت را با canonical مشترک پنهان نکنید.
آیا canonical صفحهٔ دوم فهرست باید به صفحهٔ اول اشاره کند؟
گوگل برای صفحههای دنبالهدار با محتوای متفاوت، canonical مستقل را توصیه میکند. URL و پیوند قابل دنبالکردن برای هر صفحه بگذارید و وضعیت نهایی را روی صفحهٔ زنده بررسی کنید.
آیا به هر پروفایل عضو اسکیما و امکان نمایهشدن بدهیم؟
ProfilePage برای پروفایل واقعی عضو مناسب است، اما صفحهٔ خالی با اسکیما ارزش پیدا نمیکند. محتوای عمومی، فعالیت واقعی و حریم خصوصی را پیش از تصمیم بررسی کنید.
برای انجمن `DiscussionForumPosting` بهتر است یا `QAPage`؟
اگر تاپیک گفتوگوی عمومی کاربران است، اولی را بررسی کنید. اگر صفحه حول یک پرسش و پاسخهای کاربران میچرخد، راهنمای گوگل Q&A را مناسبتر میداند. نوع نشانهگذاری باید با محتوای قابل مشاهده هماهنگ باشد.
منابع
- Google Search Central: Discussion forum (`DiscussionForumPosting`) structured data
- Google Search Central: Profile page (`ProfilePage`) structured data
- Google Search Central: Pagination, incremental page loading, and their impact on Google Search
