چگونه هرس محتوا انجام دهیم؟ تجربه من از افزایش رتبه با حذف محتوا

چرا من سئوی سایت‌ها را با هرس محتوا شروع می‌کنم؟

وقتی یک سایت که قبل از من توسط فرد دیگری سئو شده باشد را برای سئو تحویل می‌گیرم، بررسی محتوای موجود برای من تقریباً به‌اندازه بررسی سئو تکنیکال از نطر زمانی اهمیت دارد. قبل از اینکه تصمیم بگیرم چه مقاله یا لندینگ جدیدی باید ساخته شود، باید بدانم الان چه URLهایی روی سایت وجود دارند و هرکدام قرار است چه نقشی در استراتژی سئو و مارکتینگ من داشته باشند.

در سایتی که چند سال فعالیت کرده، معمولاً افراد مختلف در دوره‌های مختلف محتواهای متفاوتی را با اهواف متفاوتی تولید کرده‌اند. ممکن است برای یک موضوع چند صفحه نزدیک به هم ایجاد شده باشد، صفحاتی برای کلمات کم‌ارزش ساخته شده باشند، بعضی URLها دیگر کاربردی نداشته باشند و در کنار آن‌ها صفحات ارزشمندی هم وجود داشته باشند که فقط نیاز به تقویت یا آپدیت دارند.

در چنین شرایطی همیشه راهکار درست، تولید محتوای بیشتر نیست. گاهی قبل از اینکه چیزی به سایت اضافه کنیم باید مشخص کنیم چه چیزهایی اصلاً باید روی سایت باقی بمانند.

این موضوع با توصیه‌های خود گوگل هم هم‌راستاست. گوگل صراحتاً می‌گوید اضافه یا حذف کردن حجم زیادی از محتوای قدیمی صرفاً با این تصور که سایت ساده‌تر به نظر برسد، راهکاری برای بهبود رتبه نیست.^[1]

تجربه من از هرس محتوا در یک سایت

وقتی یکی از پروژه‌های سئو در حوزه سازه‌های پیش‌ساختهرا قبول کردم، سایت روی بسیاری از کوئری‌های مرتبط جایگاه قابل قبولی نداشت و طی سال‌ها تعداد زیادی صفحه و نوشته روی آن ایجاد شده بود. به همین منظور ابتدا از صفحات سایت خروجی گرفتم و URLها را در یک شیت اکسل قرار دادم. بعد بررسی آن‌ها را یکی‌یکی شروع کردم.

هدفم این نبود که برای هر صفحه فقط یکی از دو گزینه بماند یا حذف شود را انتخاب کنم. سؤال اصلی این بود:

سرنوشت درست این URL چه باید باشد؟

در همین فایل مشخص می‌کردم کدام صفحه باید به‌عنوان صفحه اصلی یا Master باقی بماند، کدام محتوا قابلیت ادغام دارد، کدام URL باید ریدایرکت شود و کدام صفحه واقعاً ارزش نگهداری ندارد.

برای هرس محتوا چه چیزهایی را بررسی می‌کنم؟

یکی از اشتباه‌هایی که در هرس محتوا می‌بینم این است که یک معیار، مثلاً ترافیک، تبدیل به قانونی برای حذف صفحات می‌شود. من برای تعیین سرنوشت هر URL چند عامل را کنار هم بررسی می‌کنم.

آیا موضوع صفحه Search Demand دارد؟

اول بررسی می‌کنم موضوعی که صفحه برای آن ساخته شده اساساً تقاضای جست‌وجوی معناداری دارد یا خیز!

گاهی صفحه‌ای سال‌ها قبل برای یک عبارت تقریباً بی‌ارزش ساخته شده، در حالی که آن موضوع نه حجم جست‌وجوی قابل‌توجهی دارد و نه آن‌قدر مستقل است که به URL جداگانه نیاز داشته باشد.

اما نبود ترافیک فعلی به این معنی نیست که موضوع ارزش ندارد. ممکن است صفحه انتخاب خوبی برای یک موضوع ارزشمند باشد اما محتوای ضعیف، Intent اشتباه یا ساختار نامناسب باعث شده باشد هنوز عملکرد خوبی از خود نشان ندهد، در چنین شرایطی با تکیه بر تجربه، تصمیم بر حفظ صفحه و تقویت آن می‌گیرم و اگر در مدت زمان مشخصی، صفحه به فعالیت‌های من واکنش نشان ندهد، در آن صورت تصمیم دیگری برای سرنوشت URL  خواهم گرفت.

صفحه ترافیک و Impression دارد یا نه؟

داده‌های Search Console یکی از چیزهایی است که قبل از حذف صفحه بررسی می‌کنم. Click و Impression به من کمک می‌کنند بفهمم گوگل در حال حاضر چه ارتباطی بین URL و Queryهای مختلف پیدا کرده است.

اما من هیچ‌وقت از چنین فرمولی استفاده نمی‌کنم:

ترافیک ندارد ← حذف

مسیر تصمیم‌گیری بیشتر شبیه این است:

ترافیک ندارد ← دلیلش چیست؟ ← موضوع ارزش دارد؟ ← صفحه دیگری پاسخ بهتری دارد؟ ← سپس تصمیم

آیا صفحه بک‌لینک دارد؟

ممکن است یک URL از نظر ترافیک ارگانیک ضعیف باشد اما طی سال‌ها بک‌لینک‌هایی دریافت کرده باشد. حذف چنین صفحه‌ای بدون بررسی لینک‌های ورودی می‌تواند باعث از دست رفتن بخشی از ارزش ایجادشده شود.

به همین دلیل قبل از حذف URL بررسی می‌کنم آیا بک‌لینکی پشت آن وجود دارد و اگر وجود دارد، آیا مقصد مرتبط و منطقی دیگری برای انتقال آن URL داریم یا نه.

آیا صفحه دیگری می‌تواند جای این URL را بگیرد؟

این برای من یکی از مهم‌ترین سؤال‌ها در هرس محتواست.

اگر صفحه دیگری وجود داشته باشد که همان مسئله یا Intent را بهتر پوشش دهد، بررسی می‌کنم آیا بخش‌های مفید محتوای قدیمی را می‌توان به آن منتقل کرد یا نه.

اگر پاسخ مثبت باشد، یک صفحه را به‌عنوان Master انتخاب می‌کنم.

مسیر کار معمولاً به این شکل است:

صفحه ضعیف ← انتخاب صفحه Master ← انتقال بخش‌های مفید ← تقویت Master ← ریدایرکت URL قدیمی

چه زمانی محتوا را ادغام می‌کنم؟

اگر چند URL عملاً درباره یک موضوع نزدیک به هم صحبت کنند، نگه داشتن همه آن‌ها همیشه منطقی نیست.

در این شرایط بررسی می‌کنم کدام URL از نظر موضوع، سابقه، عملکرد، لینک‌ها و تناسب با Search Intent بهترین گزینه برای تبدیل شدن به صفحه اصلی است. سپس بخش‌های ارزشمند صفحات دیگر را به آن منتقل می‌کنم.

هدف ادغام فقط کم کردن تعداد URL نیست. هدف این است که به‌جای چند صفحه پراکنده، یک صفحه کامل‌تر و مشخص‌تر داشته باشیم که دقیقاً بدانیم قرار است برای چه Intent و چه مجموعه‌ای از Queryها رقابت کند.

چه زمانی یک URL را ریدایرکت می‌کنم؟

من صرفاً به این دلیل که یک صفحه حذف شده، آن را به نزدیک‌ترین URL موجود ریدایرکت نمی‌کنم.

معیار اصلی من این است:

اگر کاربری قصد ورود به صفحه قبلی را داشت، آیا صفحه مقصد جدیدی واقعاً می‌تواند پاسخ مناسبی به نیاز او بدهد؟

اگر جواب مثبت باشد، Redirect را انجام می‌دهم. گوگل نیز Redirect دائمی را زمانی مناسب می‌داند که محتوا به URL جدید منتقل شده یا صفحه جایگزین مشخصی برای URL قبلی وجود داشته باشد.^[2]

پس مسیر تصمیم من این است:

URL قدیمی ← مقصد واقعاً مرتبط وجود دارد؟ ← بله ← ادغام یا انتقال محتوا ← 301 Redirect

شباهت چند کلمه در عنوان دو صفحه برای من دلیل کافی برای ریدایرکت نیست. صفحه مقصد باید از نظر موضوع و Intent واقعاً جانشین مناسبی باشد. بارها برای من پیش آمده که بدون در نظر گرفتن ریدایرکت خاصی برای صفحه‌ای، آن‌را حذف می‌کنم و یا صفحه را با ریسپانس کد 410 به گوگل حذف شده اعلام می‌کنم یا صفحه را 404 نشان می‌دهم و از داشتن تعدادی url  با کد پاسخ 404 هیچ مشکلی ندارم.

چه زمانی صفحه را 410 می‌کنم؟

در فایل این پروژه تعداد قابل‌توجهی URL وجود داشت که بعد از بررسی به این نتیجه رسیدم واقعاً دلیلی برای نگهداری آن‌ها وجود ندارد.

یعنی صفحه Search Demand قابل‌اتکایی نداشت، ترافیکی ایجاد نمی‌کرد، بک‌لینک مهمی پشت آن نبود، محتوای ارزشمندی برای ادغام نداشت و صفحه دیگری هم وجود نداشت که مقصد طبیعی آن باشد.

در چنین شرایطی تلاش نمی‌کنم فقط برای جلوگیری از خطا، URL را به یک صفحه نامرتبط بفرستم. برای این گروه از صفحات در آن پروژه از وضعیت 410 Gone استفاده کردم؛ یعنی منبع حذف شده و قرار نیست دوباره در همان URL ارائه شود.

نکته مهم این است که حذف صفحه، تصمیم نهایی فرایند بررسی است، نه نقطه شروع آن.

نمونه واقعی از نحوه تصمیم‌گیری برای دو URL

اگر بخواهم روشی که استفاده کردم را خیلی ساده کنم، دو حالت واقعی از منطق تصمیم‌گیری به این شکل هستند:

حالت اول: صفحه‌ای که قابلیت ادغام دارد

URL قدیمی ← ترافیک ناچیز ← موضوع همچنان مرتبط ← صفحه Master مناسب وجود دارد ← انتقال بخش‌های مفید محتوا ← 301 به Master

حالت دوم: صفحه‌ای که ارزش نگهداری ندارد

URL قدیمی ← Search Demand معنادار ندارد ← ترافیک ندارد ← بک‌لینک مهم ندارد ← مقصد مرتبط ندارد ← 410

تفاوت مهم این دو مثال این است که من فقط به عملکرد فعلی URL نگاه نمی‌کنم. سؤال اصلی این است که آیا آن صفحه یا بخشی از ارزش آن هنوز جایی در ساختار سایت دارد یا نه.

جدول تصمیم‌گیری برای هرس محتوا

این جدول یک شایلون نیست که آن‌را روی یک سایت قرار دهیم و برنامه‌ هرس محتوایی آن‌را به ما بگویید. ممکن است URLی ترافیک نداشته باشد اما موضوع بسیار ارزشمندی داشته باشد. ممکن است صفحه‌ای چند بک‌لینک داشته باشد اما همچنان ادغام آن در یک URL قوی‌تر تصمیم بهتری باشد. تصمیم نهایی باید با دیدن مجموعه داده‌ها گرفته شود.

اشتباهی که در هرس محتوا انجام دادم و درس‌های بزرگی که گرفتم

مسیر سئو برای من پر از آزمون و خطا بود، یکی از اشتباهات من این بود که صفحات بدون کلیک را فیلتر می‌کردم و هرچه را در این فیلتر جا می‌گرفت، حذف می‌کردم.

مثلاً این قانون:

هر صفحه‌ای که ۶ ماه ترافیک نداشته حذف شود.

الان این موضوع دیگر برای من معیار قابل اتکایی نیست.

صفحه ممکن است Impression داشته باشد اما هنوز رتبه مناسبی نگرفته باشد. ممکن است موضوع آن برای سایت مهم باشد. ممکن است بک‌لینک داشته باشد. ممکن است بخشی از یک کلاستر محتوایی باشد یا مشکل واقعی آن نه خود موضوع، بلکه کیفیت محتوا یا Search Intent اشتباه باشد.

به همین دلیل هرس محتوا را یک فرایند تصمیم‌گیری URL به URL می‌بینم، نه یک عملیات حذف گروهی.

آیا هرس محتوا واقعاً باعث افزایش رتبه شد؟

در این پروژه بعد از هرس محتوا، فعالیت‌های سئو متوقف نشد. کار روی معماری صفحات، محتوا، سئو تکنیکال، لینک‌سازی و بخش‌های دیگر سایت ادامه داشت.

بنابراین نمی‌توانم بگویم تمام رشدی که در ادامه اتفاق افتاد صرفاً نتیجه حذف یا ادغام محتواها بوده است.

اما هرس محتوا یکی از اولین اقداماتی بود که به من کمک کرد ساختار سایت را دوباره تعریف کنم؛ مشخص شود کدام URLها باید باقی بمانند، کدام صفحات Master هستند و برای هر موضوع قرار است کدام صفحه در نتایج جست‌وجو رقابت کند.

وضعیت پروژه در آذر ۱۴۰۲

طبق گزارشی که از آن دوره نگه داشته‌ام، وضعیت پروژه در آذر ۱۴۰۲ تقریباً به این شکل بود:

• Impression: حدود ۲۷٬۳۰۰
• Click: ۶۹۱
• CTR: حدود ۲.۵٪
• Average Position: حدود ۱۲.۸

وضعیت پروژه در اردیبهشت ۱۴۰۵

در اردیبهشت ۱۴۰۵، گزارش Search Console همان پروژه اعداد زیر را نشان می‌داد:

• Impression: حدود ۱۶۸ هزار
• Click: حدود ۱۱ هزار
• CTR: حدود ۶.۵٪
• Average Position: حدود ۴.۸

جدول تغییرات از 1402 تا 1405

این مقایسه را نباید به‌عنوان اثبات اثر مستقل هرس محتوا تفسیر کرد. در فاصله این دو گزارش اقدامات متعدد دیگری روی پروژه انجام شده است. دلیل آوردن این داده‌ها این است که مسیر واقعی پروژه را نشان دهم و مشخص باشد روشی که در این مقاله درباره آن صحبت می‌کنم بخشی از یک تجربه اجرایی واقعی بوده، نه یک سناریوی فرضی.

چک‌لیست من برای تعیین سرنوشت هر URL

اگر بخواهم کل فرایند را به یک مسیر ساده تبدیل کنم، برای هر صفحه تقریباً این سؤال‌ها را پشت سر هم بررسی می‌کنم:

1. موضوع صفحه هنوز برای سایت و کاربر ارزش دارد؟
2. برای موضوع Search Demand معناداری وجود دارد؟
3. صفحه در Search Console Click یا Impression دارد؟
4. URL بک‌لینک ارزشمند دارد؟
5. محتوای صفحه هنوز قابل استفاده یا بهبود است؟
6. صفحه دیگری همان Intent را بهتر پوشش می‌دهد؟
7. اگر صفحه حذف شود، مقصد واقعاً مرتبطی برای Redirect وجود دارد؟

بعد از پاسخ دادن به این سؤال‌ها، معمولاً یکی از این پنج تصمیم گرفته می‌شود:

حفظ ← به‌روزرسانی ← ادغام ← ریدایرکت ← حذف

قبل از تولید محتوای بیشتر، محتوای فعلی سایت را بشناسید

وقتی یک سایت قدیمی را بررسی می‌کنم، اولین سؤال من همیشه این نیست که برای چه کلمات جدیدی محتوا تولید کنیم؟

قبل از آن می‌خواهم بدانم:

الان برای چه چیزهایی صفحه داریم و هرکدام چرا باید وجود داشته باشند؟

اگر جواب این سؤال مشخص نباشد، ممکن است برای موضوعی که همین حالا چند صفحه دارد URL دیگری بسازیم، Cannibalization بیشتری ایجاد کنیم یا محتوایی تولید کنیم که چند ماه بعد مجبور شویم دوباره آن را با صفحات قبلی ادغام کنیم.

به همین دلیل هرس محتوا برای من فقط یک کار دوره‌ای روی سایت‌های بزرگ نیست. در پروژه‌های قدیمی، هرس محتوا بخشی از فرایند شناخت سایت است؛ تقریباً همان‌قدر جدی که در ابتدای پروژه Crawl می‌گیریم و مشکلات تکنیکال را بررسی می‌کنیم.

قبل از اینکه تصمیم بگیرم چه صفحه‌ای باید ساخته شود، مشخص می‌کنم کدام صفحات فعلی واقعاً باید وجود داشته باشند.