تحلیل رقبا در سئو: از شکاف محتوا تا برنامه انتشار
تحلیل رقبا در سئو را با تشخیص رقیب واقعی، نیت جست‌وجو، ماتریس محتوا و کنترل همپوشانی انجام دهید؛ همراه مثال و قالب سفارش مقاله برای تیم محتوا.
علت ایندکس نشدن سایت یک پاسخ ثابت ندارد. ممکن است گوگل هنوز صفحه را پیدا نکرده باشد، امکان دریافت آن را نداشته باشد، دستور منع ایندکس ببیند یا نسخهٔ دیگری را اصلی تشخیص دهد. گاهی هم صفحه دریافت شده، اما برای حضور در ایندکس انتخاب نشده است. قبل از تغییر قالب یا درخواست‌های مکرر، مرحلهٔ توقف را مشخص کنید. یک بررسی اولیه با ابزار رایگان سئوی آریا سئو انجام دهید و شواهد گوگل را از سرچ کنسول بگیرید.
این مقاله برای صاحب سایت و متخصصی است که باید مشکل را تشخیص دهد و به تیم فنی یا محتوا ارجاع دهد. در ادامه، روش بررسی یک URL، تفاوت وضعیتهای رایج، چک‌لیست اصلاح و یک نمونهٔ گزارش اجرایی را می‌بینید. زمان مشخصی برای ایندکس یا رتبه وعده نمی‌دهیم؛ هدف این است که مانع واقعی را پیدا کنید و اقدام متناسب انجام دهید. درخواست ایندکس، جای رفع خطا یا ساخت محتوای مفید را نمی‌گیرد.
ایندکس نشدن با رتبه نگرفتن چه تفاوتی دارد؟
صفحهٔ ایندکس‌شده ممکن است برای عبارت دلخواه شما جایگاه مناسبی نداشته باشد. از طرف دیگر، نیامدن صفحه در یک جست‌وجوی دستی الزاماً ثابت نمی‌کند که ایندکس نشده است. عبارت، کشور، زبان و نوع نتایج هم در دیده‌شدن اثر دارند. برای تشخیص اولیه، URL دقیق را در ابزار بازرسی سرچ کنسول بررسی کنید. وضعیت صفحه و موضوع رتبه را جدا نگه دارید تا راه‌حل مشکل دوم را برای مشکل اول اجرا نکنید.
جست‌وجوی site: میتواند برای نگاه سریع مفید باشد، اما آن را شمارش کامل و قطعی تمام صفحات ایندکس‌شده ندانید. گزارش رسمی و بازرسی URL شواهد دقیق‌تری دربارهٔ یک صفحهٔ مشخص ارائه می‌دهند. اگر صفحه ایندکس است ولی برای نام برند یا کلمهٔ اصلی دیده نمی‌شود، بررسی نیت، عنوان، محتوا و رقابت را ادامه دهید. روش سنجش جایگاه را در راهنمای بررسی رتبه سایت بخوانید.
آیا همهٔ صفحات سایت باید ایندکس شوند؟
خیر. صفحهٔ حساب کاربری، نتیجهٔ جست‌وجوی داخلی، نسخهٔ تکراری محصول، فیلتر کم‌ارزش و صفحهٔ حذف‌شده ممکن است نباید در نتایج دیده شوند. هدف، بیشترین تعداد URL ایندکس‌شده نیست؛ هدف حضور صفحههای مفید و مناسب جست‌وجوست. قبل از اعلام خطا، مشخص کنید URL مورد نظر چه نقشی دارد و سیاست سایت دربارهٔ آن چیست. کاهش تعداد آدرس‌های تکراری گاهی بخشی از اصلاح درست معماری است.
یک فهرست ساده تهیه کنید: آدرس، نوع صفحه، اهمیت تجاری، وضعیت مورد انتظار و وضعیت فعلی. محصول فعال و راهنمای مستقل معمولاً با یک مسیر خصوصی یا نسخهٔ فیلترشده یکسان نیستند. اگر تیم دربارهٔ هدف صفحات توافق نداشته باشد، یک نفر noindex اضافه می‌کند و نفر دیگر آن را حذف می‌کند. این رفت‌وبرگشت، تشخیص را دشوار می‌کند. سیاست روشن ایندکس باید بخشی از مستندات CMS و قالب‌های سایت باشد.
قدم اول: URL دقیق و مالکیت درست را بررسی کنید
نسخهٔ http و https، دامنه با www و بدون آن، اسلش پایانی و پارامترها را با هم اشتباه نگیرید. آدرس نهایی را از مرورگر یا لینک اصلی صفحه بردارید و همان را بازرسی کنید. همچنین مطمئن شوید گزارش سرچ کنسول مربوط به property درست است. مشاهدهٔ یک property محدود به مسیر یا پروتکل دیگر میتواند باعث شود دادهٔ مورد انتظار را نبینید و نتیجهٔ اشتباه بگیرید.
در راهنمای URL Inspection گوگل تفاوت اطلاعات نسخهٔ ایندکس‌شده و آزمایش زنده توضیح داده شده است. در کار عملی، هر دو را با تاریخ یادداشت کنید. ممکن است مشکل امروز رفع شده باشد ولی گزارش نسخهٔ قبلی را نشان دهد. برعکس، صفحه‌ای که قبلاً سالم بوده ممکن است اکنون به علت انتشار جدید مشکل داشته باشد. بدون تاریخ مشاهده نمی‌توان این دو وضعیت را مقایسه کرد.
جدول وضعیت‌ها و اقدام متناسب
| وضعیت | برداشت اولیه | بررسی بعدی |
|---|---|---|
| Discovered – currently not indexed | URL شناخته شده، ولی هنوز دریافت نشده | مسیر کشف، دسترسی و ارزش صفحه |
| Crawled – currently not indexed | صفحه دریافت شده، ولی انتخاب نشده | کیفیت، تکرار، رندر و نیت |
| Excluded by noindex | دستور منع ایندکس مشاهده شده | عمدی یا ناخواسته بودن دستور |
| Blocked by robots.txt | خزش محدود شده | قاعدهٔ فایل و هدف صفحه |
| Alternate page with proper canonical | نسخهٔ دیگری معرفی شده | درست بودن صفحهٔ اصلی |
| Server error یا Soft 404 | مشکل دریافت یا معنای پاسخ | وضعیت سرور و محتوای واقعی |
نام و تفسیر وضعیت‌ها را با مستندات گزارش Page indexing تطبیق دهید. جدول بالا راهنمای شروع است؛ یک برچسب به‌تنهایی علت نهایی را ثابت نمی‌کند. برای هر وضعیت، نمونهٔ همان صفحه و خروجی واقعی را ببینید. اصلاح یک URL نمونه میتواند به تشخیص خطای مشترک قالب کمک کند، اما پیش از تعمیم، چند نمونهٔ دیگر را هم بررسی کنید.
صفحه کشف شده ولی هنوز خزیده نشده است
ابتدا ببینید URL از کجا معرفی شده: لینک داخلی، sitemap یا لینک بیرونی. صفحه‌ای که فقط در فایل نقشهٔ سایت وجود دارد و از بخش مرتبط سایت لینک ندارد، مسیر کاربری ضعیفی هم دارد. برای یک مقالهٔ تازه، از صفحهٔ موضوعی و دو راهنمای مرتبط لینک طبیعی بدهید. انکر باید موضوع مقصد را روشن کند. افزودن لینک در متن بی‌ارتباط یا فهرست عظیم فوتر، جای معماری موضوعی خوب را نمی‌گیرد.
دسترسی سرور را نیز بررسی کنید. کندی یا خطا میتواند دریافت صفحات را دشوار کند. اگر سایت کوچک است، سریع نتیجه نگیرید که حتماً مسئلهٔ پیچیدهٔ بودجهٔ خزش دارید. ابتدا موارد ساده و قابل مشاهده را کنترل کنید: پاسخ پایدار، مسیر داخلی و محتوای ارزشمند. برای آدرس‌های بسیار زیاد و پارامترهای بی‌نهایت، لازم است معماری تولید URL را بازبینی کنید. تشخیص را با داده انجام دهید، نه با تکرار یک اصطلاح عمومی.
صفحه خزیده شده ولی برای ایندکس انتخاب نشده است
در این حالت فقط ارسال دوبارهٔ URL معمولاً پرسش اصلی را پاسخ نمی‌دهد. محتوای صفحه را از دید کاربر بررسی کنید: آیا پاسخ مستقلی دارد؟ آیا تقریباً همان متن یک صفحهٔ دیگر است؟ آیا بخش اصلی در نتیجهٔ رندرشده وجود دارد؟ آیا صفحه با عنوان جذاب باز می‌شود ولی فقط چند جملهٔ عمومی دارد؟ اصلاح باید به مسئلهٔ مشاهده‌شده مربوط باشد، نه اینکه تعداد کلمات را بدون افزودن ارزش افزایش دهید.
برای یک فروشگاه، توضیح یکسان روی ده‌ها محصول یا صفحهٔ فیلتر بدون نیاز مستقل میتواند به بازبینی محتوا نیاز داشته باشد. برای خدمات، چند صفحهٔ شهری با تفاوت فقط در نام شهر ممکن است پاسخ جداگانهٔ معنادار نسازند. به جای افزودن پاراگراف تکراری، تفاوت واقعی خدمت، فرایند، نمونهٔ معتبر یا پاسخ به پرسش خریدار را ارائه کنید. اگر صفحه ارزش مستقل ندارد، ادغام آن با یک راهنمای کامل‌تر را بررسی کنید.
noindex ناخواسته و تنظیمات محیط آزمایش
اگر صفحهٔ مهم دستور noindex دارد، ابتدا منبع دستور را پیدا کنید: قالب، افزونه، تنظیم نوشته، هدر سرور یا محیط انتشار. حذف یک گزینه در پنل زمانی کافی است که خروجی واقعی هم تغییر کند. در سایت‌های دارای کش یا CDN، نسخهٔ قدیمی ممکن است مدتی باقی بماند. برای تأیید، همان URL را دوباره دریافت کنید و دستور متا و هدر پاسخ را بررسی کنید. تغییر را با تاریخ در گزارش ثبت کنید.
اگر دستور عمدی است، آن را صرفاً برای سبزشدن گزارش حذف نکنید. برای صفحهٔ ورود یا بخش خصوصی، مسئلهٔ حفاظت از داده جدا از ایندکس است و به کنترل دسترسی نیاز دارد. برای صفحات تکراری، سیاست canonical یا حذف نیز میتواند مطرح باشد. هر نوع صفحه را با هدف خودش بررسی کنید. داشتن صفحههای عمداً خارج از ایندکس، لزوماً نشانهٔ خرابی سایت نیست.
robots.txt و دستورهای متناقض
یک فایل robots.txt ممکن است مسیر مقاله، محصول یا فایل مورد نیاز رندر را ناخواسته محدود کند. قواعد را همراه URL نمونه بررسی کنید و از تغییر سراسری بدون شناخت اثر آن پرهیز کنید. فایل دسترسی خزنده را مدیریت می‌کند؛ به معنای محافظت از دادهٔ محرمانه نیست. اگر می‌خواهید خزنده دستور داخل صفحه را بخواند، رابطهٔ اجازهٔ خزش و دستور ایندکس باید سازگار باشد. شرح رسمی این تفاوت در راهنمای robots.txt آمده است.
پیش از انتشار تغییر، چند URL از هر نوع صفحه را تست کنید. ممکن است قاعده‌ای که یک مسیر کم‌ارزش را می‌بندد، محصول‌های مهم را هم شامل شود. پس از تغییر، نتیجهٔ واقعی و وضعیت ابزار بازرسی را ثبت کنید. برای تیم، نام قاعده، آدرس آسیب‌دیده و رفتار مورد انتظار را بنویسید. گزارش «robots مشکل دارد» بدون نمونهٔ قابل تکرار، احتمال اصلاح اشتباه را بالا می‌برد.
canonical اشتباه یا انتخاب نسخهٔ دیگر
نسخهٔ جایگزین با canonical درست، الزاماً خطا نیست. اما اگر صفحهٔ مستقل به خانه، زبان دیگر یا محصول نامرتبط اشاره کند، باید منطق تولید canonical اصلاح شود. لینک داخلی، sitemap و نسخهٔ معرفی‌شده را با هم مقایسه کنید. شرح روش‌های معرفی صفحهٔ اصلی در مستندات canonical گوگل موجود است. تصمیم را بر اساس کارکرد صفحه بگیرید، نه صرفاً نام یک وضعیت در گزارش.
برای مثال، یک پارامتر مرتب‌سازی ممکن است نسخهٔ مستقل برای جست‌وجو لازم نداشته باشد، ولی یک صفحهٔ دسته با نیاز مشخص میتواند محتوای خودش را داشته باشد. اگر همهٔ URLهای دارای پارامتر را به خانه معرفی کنید، این تفاوت از بین می‌رود. ابتدا الگوی تولید آدرس و نیاز واقعی را مشخص کنید. سپس سیاست ثابت برای نسخهٔ اصلی بنویسید تا توسعه‌دهنده، نویسنده و مسئول انتشار یک رفتار مشترک داشته باشند.
خطای سرور، Soft 404 و ریدایرکت نامرتبط
صفحهٔ موجودی که گاهی پاسخ ۵۰۰ می‌دهد، باید از نظر سرویس و ظرفیت بررسی شود. صفحه‌ای که حذف شده ولی متن «چیزی پیدا نشد» را با ۲۰۰ می‌فرستد نیز معنای پاسخ درستی ندارد. انتقال همهٔ صفحات حذف‌شده به خانه، لزوماً جایگزین مناسبی نیست. اگر مقصد مرتبط و معادل دارید، انتقال را مطابق همان تصمیم اجرا کنید. اگر ندارید، وضعیت حذف را درست اعلام کنید.
برای گزارش فنی، زمان، URL، پاسخ و محتوای دریافتی را ثبت کنید. اگر خطا فقط در یک ساعت یا لوکیشن دیده شده، همان محدودیت مشاهده را بیان کنید. نتیجهٔ یک درخواست موفق ثابت نمی‌کند سرویس همیشه پایدار است. راهنمای عیب‌یابی خزش برای بررسی دسترسی و پاسخ سرور نقطهٔ شروع مناسبی است. در سایت خودتان، شواهد را از لاگ و ابزار بازرسی تکمیل کنید.
چه زمانی درخواست ایندکس بدهیم؟
پس از رفع مانع و کنترل خروجی، می‌توانید برای صفحهٔ مهم از درخواست ایندکس استفاده کنید. درخواست، تضمین حضور در نتایج یا زمان معین نیست. برای چندین URL، نقشهٔ سایت و مسیر لینک داخلی را منظم نگه دارید و درخواست‌های تکراری را جای برنامهٔ اصلاح قرار ندهید. اگر صفحه هنوز noindex، خطای سرور یا محتوای ناقص دارد، درخواست دوباره دلیل اصلی را رفع نمی‌کند.
درخواست و تاریخ اصلاح را در یک ردیف ثبت کنید. سپس در بازبینی بعدی، همان URL را بررسی کنید و مشخص کنید آیا گوگل نسخهٔ جدید را دیده است یا خیر. تغییر یکبارهٔ URL، عنوان، محتوا و سیاست ایندکس، پیگیری نتیجه را دشوار می‌کند. یک فرض قابل آزمون و اصلاح مشخص داشته باشید. اگر وضعیت بعد از اصلاح تغییر نکرد، شواهد تازه را بخوانید و تشخیص را بازبینی کنید.
قالب گزارش برای ارجاع مشکل به تیم
برای هر مورد، URL نهایی، نوع صفحه، وضعیت مورد انتظار، وضعیت مشاهده‌شده، تاریخ بازرسی، شاهد، مسئول و معیار پذیرش را بنویسید. نمونه: «سه صفحهٔ محصول فعال، canonical صفحهٔ خانه دارند؛ انتظار داریم هر محصول معتبر نسخهٔ اصلی خودش را معرفی کند؛ پس از اصلاح، پنج نمونه و یک محصول تازه کنترل شود». چنین تسکی برای تیم قابل اجراست و نتیجه‌اش هم قابل تأیید است.
در پایان هفته، موارد اصلاح‌شده، باقی‌مانده و نیازمند تحقیق را جدا گزارش کنید. صفحه‌ای که خروجی فنی‌اش سالم شده اما هنوز ایندکس نشده، با صفحه‌ای که مانع فنی‌اش پابرجاست یک وضعیت ندارد. این تفکیک از وعدهٔ اشتباه و تکرار کار جلوگیری می‌کند. برای ادامهٔ ممیزی، مقالهٔ سئو تکنیکال سایت را بخوانید و از امکانات آریا سئو برای مدیریت بررسی‌ها استفاده کنید.
بازبینی را با همان مجموعهٔ URLهای نمونه انجام دهید تا قبل و بعد قابل مقایسه باشند. نمونه‌ها و تاریخ‌ها را نگه دارید و مواردی که هنوز شواهد کافی ندارند جدا علامت بزنید. این روش از اعلام زودهنگام رفع کامل مشکل جلوگیری می‌کند.
پرسش‌های متداول
صفحهٔ تازه باید همان روز ایندکس شود؟
خیر؛ زمان ثابت و تضمینشدهای وجود ندارد. کیفیت، کشف و دسترسی را بررسی کنید و وضعیت URL را از گزارش رسمی بخوانید.
زیادکردن متن مشکل ایندکس را حل می‌کند؟
فقط زمانی که پاسخ مستقل و مفیدتر ایجاد کند ممکن است بخشی از اصلاح باشد. افزودن جمله‌های تکراری مانع سرور، noindex یا canonical را رفع نمی‌کند.
چرا ابزار بررسی می‌گوید صفحه سالم است ولی گوگل ایندکس نکرده؟
بررسی فنی فعلی با تصمیم ایندکس گوگل یکسان نیست. تاریخ آخرین دریافت، نسخهٔ اصلی و ارزش محتوا را هم بررسی کنید.
آیا باید همهٔ وضعیتهای خارج از ایندکس را صفر کنیم؟
خیر. ابتدا صفحههای مهمی را که باید ایندکس شوند جدا کنید. برای صفحات خصوصی یا تکراری، وضعیت خارج از ایندکس میتواند عمدی و درست باشد.
پرسش‌های متداول
خیر؛ زمان ثابت و تضمینشدهای وجود ندارد. کیفیت، کشف و دسترسی را بررسی کنید و وضعیت URL را از گزارش رسمی بخوانید.
فقط زمانی که پاسخ مستقل و مفیدتر ایجاد کند ممکن است بخشی از اصلاح باشد. افزودن جمله‌های تکراری مانع سرور، noindex یا canonical را رفع نمی‌کند.
بررسی فنی فعلی با تصمیم ایندکس گوگل یکسان نیست. تاریخ آخرین دریافت، نسخهٔ اصلی و ارزش محتوا را هم بررسی کنید.
خیر. ابتدا صفحههای مهمی را که باید ایندکس شوند جدا کنید. برای صفحات خصوصی یا تکراری، وضعیت خارج از ایندکس میتواند عمدی و درست باشد.
