چک لیست سئو تکنیکال؛ راهنمای کامل بررسی فنی سایت

ممکن است سایت در مرورگر کاملاً سالم به نظر برسد، اما یک تنظیم اشتباه در robots.txt، تگ noindex، ریدایرکت یا پاسخ سرور مسیر گوگل به صفحات مهم را ببندد. چک لیست سئو تکنیکال کمک می‌کند این موانع پنهان را پیش از کاهش ایندکس، افت بازدید یا اتلاف زمان پیدا کنید.

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

بررسی فنی سایت را از کجا شروع کنیم؟

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

یک چک‌لیست فنی مفید فقط نام robots.txt، سایت‌مپ، canonical، سرعت و خطاهای 404 را ردیف نمی‌کند. برای هر مورد باید روش بررسی، وضعیت سالم، اثر احتمالی خطا و اقدام بعدی مشخص باشد.

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

مشکلات شناسایی‌شده را می‌توان در سه سطح قرار داد:

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

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

پیش از ممیزی، صفحات هدف برای ایندکس را مشخص کنید

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

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

۱. انواع صفحات سایت را فهرست کنید

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

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

برای هر گروه یکی از این چهار تصمیم را ثبت کنید:

1. صفحه باید باقی بماند و ایندکس شود.
2. صفحه باید باقی بماند اما ایندکس نشود.
3. صفحه جایگزین مرتبط دارد و باید منتقل شود.
4. صفحه دیگر لازم نیست و جایگزین واقعی نیز ندارد.

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

۲. از هر قالب چند URL نمونه انتخاب کنید

بررسی یک URL نمی‌تواند سلامت کل سایت را ثابت کند. ممکن است صفحه اصلی سالم باشد، اما همه محصولات به‌دلیل تنظیم مشترک قالب دارای canonical اشتباه باشند.

از هر قالب اصلی چند نمونه انتخاب کنید:

• یک صفحه سالم و پربازدید؛
• یک صفحه جدید؛
• یک صفحه قدیمی؛
• یک صفحه کم‌ترافیک؛
• یک صفحه مشکوک به خطا.

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

۳. گستره مشکل را تعیین کنید

پیش از اصلاح مشخص کنید خطا در چه سطحی رخ داده است:

• فقط یک URL؛
• یک نوع صفحه یا قالب؛
• یک پوشه مشخص؛
• یا تمام سایت.

فرض کنید فقط یک مقاله به‌اشتباه noindex شده است. حذف سراسری noindex از تمام سایت می‌تواند صفحات خصوصی یا کم‌ارزش را نیز وارد ایندکس کند.

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

دسترسی گوگل و پاسخ سرور را بررسی کنید

پس از تعیین صفحات هدف، باید مطمئن شوید Googlebot امکان دسترسی به آن‌ها را دارد و سرور نیز پاسخی متناسب با وضعیت واقعی هر صفحه ارائه می‌کند.

۱. URLهای مهم را با URL Inspection آزمایش کنید

ابزار URL Inspection در Google Search Console دو نوع اطلاعات ارائه می‌دهد: وضعیت آخرین نسخه‌ای که گوگل پردازش کرده و آزمایش زنده نسخه فعلی صفحه.

برای هر URL نمونه این موارد را کنترل کنید:

• آیا URL برای گوگل شناخته شده است؟
• آیا خزش آن مجاز بوده است؟
• آخرین خزش چه زمانی انجام شده است؟
• canonical اعلام‌شده و انتخاب‌شده چیست؟
• آیا آزمایش زنده می‌تواند صفحه را دریافت کند؟
• آیا منابع اصلی هنگام رندر بارگذاری می‌شوند؟
• آیا محتوای رندرشده کامل است؟

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

مثبت‌بودن Live Test تضمین نمی‌کند که URL حتماً ایندکس شود. آزمایش زنده نمی‌تواند انتخاب نهایی canonical یا همه دلایل ایندکس‌نشدن را پیش‌بینی کند. پس از اصلاح، نسخه زنده را آزمایش کنید و سپس منتظر خزش و پردازش مجدد بمانید.

۲. فایل robots.txt را از نظر مسدودسازی ناخواسته کنترل کنید

فایل robots.txt مشخص می‌کند خزنده‌ها کدام مسیرها یا فایل‌ها را درخواست نکنند. یک دستور اشتباه و سراسری می‌تواند بخش بزرگی از سایت یا منابع ضروری آن را مسدود کند.

این موارد را بررسی کنید:

• آیا پوشه مهمی با Disallow مسدود شده است؟
• آیا فایل‌های CSS و JavaScript لازم برای رندر در دسترس‌اند؟
• آیا تنظیمات محیط آزمایشی وارد سایت اصلی شده‌اند؟
• آیا فایل robots.txt بدون خطای سرور باز می‌شود؟
• آیا دستور مخصوص یک ربات، ناخواسته Googlebot را نیز محدود کرده است؟

درج آدرس سایت‌مپ در robots.txt مفید است، اما الزامی نیست. سایت‌مپ را می‌توان مستقیماً در Search Console نیز ثبت کرد؛ بنابراین نبود دستور Sitemap به‌تنهایی نشانه خرابی robots.txt محسوب نمی‌شود.

robots.txt ابزار قطعی حذف یک صفحه وب از نتایج نیست. ممکن است URL مسدودشده از طریق لینک‌ها شناخته شود، اما گوگل نتواند محتوای آن را بخواند. برای جلوگیری از ایندکس باید noindex برای خزنده قابل مشاهده باشد؛ اگر صفحه هم‌زمان در robots.txt مسدود شود، گوگل ممکن است دستور noindex را نبیند. جزئیات این تفاوت در راهنمای robots.txt و noindex آمده است.

پس از مشاهده مسدودسازی ناخواسته، ابتدا گستره آن را مشخص کنید و تغییر را روی چند URL نمونه آزمایش کنید. ویرایش عجولانه یک دستور سراسری ممکن است مشکل بزرگ‌تری ایجاد کند.

۳. کد وضعیت HTTP را با وضعیت واقعی صفحه تطبیق دهید

ظاهر صفحه در مرورگر همیشه کد واقعی پاسخ سرور را نشان نمی‌دهد. ممکن است صفحه پیام «یافت نشد» نمایش دهد، اما همچنان پاسخ 200 ارسال کند.

وضعیت مناسب به سرنوشت صفحه بستگی دارد:

• صفحه موجود و سالم باید پاسخ موفق متناسب دریافت کند.
• صفحه منتقل‌شده باید به مقصد مرتبط هدایت شود.
• صفحه حذف‌شده بدون جایگزین معمولاً باید 404 یا 410 بدهد.
• خطای موقت سرور نباید برای مدت طولانی ادامه پیدا کند.
• صفحه خالی یا خطامانند نباید پاسخ موفق گمراه‌کننده ارسال کند.

Soft 404 زمانی رخ می‌دهد که پاسخ سرور موفق است، اما محتوای صفحه برای گوگل شبیه صفحه حذف‌شده، خالی یا خطا به نظر می‌رسد.

خطاهای 5xx و پاسخ 429 می‌توانند باعث کاهش موقت سرعت خزش شوند. اگر خطاهای سرور ادامه پیدا کنند، URLهای قبلاً ایندکس‌شده نیز ممکن است به‌مرور از ایندکس خارج شوند.

دو صفحه حذف‌شده را در نظر بگیرید:

• صفحه اول نسخه جدید و کاملاً مرتبطی دارد؛ انتقال دائمی به نسخه جدید منطقی است.
• صفحه دوم جایگزین واقعی ندارد؛ ریدایرکت آن به صفحه اصلی مقصد نامرتبطی می‌سازد و پاسخ 404 یا 410 می‌تواند تصمیم صحیح‌تری باشد.

هر خطای 404 را بدون بررسی به صفحه اصلی ریدایرکت نکنید.

۴. خطاهای هاست، DNS و محدودیت دسترسی را بررسی کنید

اینکه صفحه برای مدیر سایت باز می‌شود، ثابت نمی‌کند Googlebot نیز همیشه به آن دسترسی دارد.

موارد زیر را کنترل کنید:

• قطعی‌های کوتاه و تکرارشونده؛
• افزایش خطا در ساعات پرمصرف؛
• پرشدن پردازنده، حافظه یا تعداد پردازش‌ها؛
• خطاهای DNS؛
• زمان انتظار طولانی سرور؛
• مسدودشدن ربات‌های گوگل توسط فایروال یا افزونه امنیتی؛
• خطاهای CDN یا پراکسی؛
• پاسخ متفاوت برای کاربر و خزنده.

وضعیت سالم یعنی URLهای مهم در زمان‌های مختلف پاسخ پایدار و قابل دریافت داشته باشند. اگر خطا فقط هنگام افزایش مصرف منابع رخ می‌دهد، گزارش‌های هاست و لاگ خطا را کنار Crawl Stats و URL Inspection بررسی کنید.

در هاست‌های کم‌ظرفیت، رفع خطاهای 5xx و 429 از بهبودهای جزئی ظاهر یا امتیاز سرعت مهم‌تر است.

۵. لینک‌های قابل خزش و صفحات یتیم را پیدا کنید

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

برای صفحات مهم بررسی کنید:

• آیا از منو، دسته یا صفحات مرتبط قابل دسترسی‌اند؟
• آیا لینک با عنصر استاندارد a و ویژگی href ساخته شده است؟
• آیا لینک فقط پس از کلیک یا اجرای یک رویداد اسکریپتی ایجاد می‌شود؟
• آیا لینک شکسته به URL حذف‌شده وجود دارد؟
• آیا صفحه در عمق بسیار زیادی از ساختار سایت قرار گرفته است؟
• آیا فقط از طریق سایت‌مپ قابل کشف است؟
• آیا لینک‌ها به نسخه canonical صفحه اشاره می‌کنند؟

گوگل معمولاً لینک‌های ساخته‌شده با عنصر a و مقصد واقعی href را مطمئن‌تر استخراج می‌کند و نمی‌تواند به‌طور قابل اتکا همه لینک‌های ساخته‌شده صرفاً با رویدادهای اسکریپتی را پردازش کند.

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

سیگنال‌های ایندکس و نسخه اصلی را هماهنگ کنید

robots، noindex، canonical، سایت‌مپ، ریدایرکت و لینک‌های داخلی نباید درباره یک URL پیام‌های متناقض ارسال کنند.

ممکن است یک صفحه در سایت‌مپ باشد اما noindex داشته باشد، یا canonical آن به نسخه‌ای اشاره کند که هیچ لینک داخلی به آن نمی‌رسد. وجود جداگانه هر تنظیم کافی نیست؛ هماهنگی آن‌ها اهمیت دارد.

۱. meta robots و X-Robots-Tag را بررسی کنید

دستورهای کنترل ایندکس می‌توانند در کد HTML یا هدر HTTP ارسال شوند.

در صفحات نمونه کنترل کنید:

• آیا صفحه مهم noindex ناخواسته دارد؟
• آیا افزونه یا قالب، دستور سراسری روی یک نوع صفحه قرار داده است؟
• آیا تنظیم محیط آزمایشی به نسخه اصلی منتقل شده است؟
• آیا صفحه noindex همچنان در سایت‌مپ قرار دارد؟
• آیا صفحه برای مشاهده دستور noindex قابل خزش است؟
• آیا هدر HTTP دستور متفاوتی از meta robots ارسال می‌کند؟

X-Robots-Tag یک هدر HTTP است و می‌تواند برای انواع پاسخ‌ها استفاده شود. این روش به‌ویژه برای PDF، تصویر و فایل‌های غیر HTML کاربرد دارد؛ زیرا امکان قرار دادن meta robots داخل آن‌ها وجود ندارد.

وضعیت سالم زمانی است که دستورهای HTML و هدر HTTP با تصمیم ایندکس صفحه هماهنگ باشند. پس از اصلاح، هدر پاسخ و نسخه رندرشده را دوباره بررسی کنید.

۲. canonical اعلام‌شده و انتخاب‌شده را مقایسه کنید

canonical مشخص می‌کند سایت کدام URL را میان نسخه‌های مشابه ترجیح می‌دهد، اما انتخاب نهایی همچنان با گوگل است.

این موارد را کنترل کنید:

• canonical به URL معتبر و قابل ایندکس اشاره می‌کند؛
• مقصد canonical خطا یا ریدایرکت نیست؛
• canonical به صفحه نامرتبط فرستاده نشده است؛
• سایت‌مپ و لینک‌های داخلی همان نسخه را تقویت می‌کنند؛
• HTTPS و دامنه اصلی به‌صورت یکدست استفاده می‌شوند؛
• URLهای پارامتری بدون دلیل به‌عنوان نسخه اصلی معرفی نشده‌اند؛
• canonical اعلام‌شده با canonical انتخاب‌شده گوگل مقایسه شده است.

نبود self-canonical در صفحه‌ای که نسخه مشابهی ندارد، همیشه به معنی خطای قطعی نیست؛ بااین‌حال گوگل استفاده از canonical خودارجاع را توصیه می‌کند. در صورت استفاده، باید با سایر سیگنال‌ها هماهنگ باشد. راهنمای انتخاب URL اصلی نیز بر پرهیز از معرفی URLهای متفاوت در روش‌های مختلف canonicalization تأکید می‌کند.

فرض کنید یک محصول از چهار URL قابل دسترسی است: HTTP، HTTPS، دامنه دارای www و URL دارای پارامتر رهگیری. اگر canonical نسخه HTTPS بدون www را معرفی کند، اما سایت‌مپ و لینک‌های داخلی به نسخه www اشاره کنند، سیگنال‌ها متناقض‌اند. اصلاح فقط تگ canonical کافی نیست؛ همه مسیرها باید یک نسخه را تقویت کنند.

۳. سایت‌مپ XML را پاک‌سازی کنید

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

سایت‌مپ مناسب بهتر است شامل URLهایی باشد که:

• پاسخ موفق می‌دهند؛
• اجازه ایندکس دارند؛
• نسخه مطلوب یا canonical هستند؛
• ریدایرکت نمی‌شوند؛
• محتوای واقعی دارند؛
• با دامنه و پروتکل اصلی سایت هماهنگ‌اند.

URLهای noindex، خطادار، ریدایرکت‌شده، غیر canonical، آزمایشی یا خصوصی را بدون دلیل در سایت‌مپ نگه ندارید.

از URL کامل و مطلق استفاده کنید. هر فایل سایت‌مپ حداکثر ۵۰ هزار URL یا ۵۰ مگابایت حجم فشرده‌نشده دارد؛ سایت‌های بزرگ‌تر باید فایل را تقسیم کنند.

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

۴. ریدایرکت‌ها، حلقه‌ها و زنجیره‌ها را کنترل کنید

ریدایرکت باید کاربر و موتور جست‌وجو را مستقیم به مرتبط‌ترین مقصد موجود هدایت کند.

این موارد را بسنجید:

• انتقال دائمی برای جابه‌جایی دائمی استفاده شده است؛
• انتقال موقت واقعاً موقتی است؛
• مقصد از نظر موضوعی با URL قبلی ارتباط دارد؛
• حلقه ریدایرکت وجود ندارد؛
• زنجیره انتقال غیرضروری ایجاد نشده است؛
• HTTP مستقیماً به مقصد نهایی HTTPS می‌رود؛
• نسخه www و بدون www به یک دامنه اصلی می‌رسند؛
• لینک‌های داخلی بعد از انتقال به مقصد نهایی به‌روزرسانی شده‌اند.

ریدایرکت‌های دائمی مانند 301 و 308 سیگنالی برای انتخاب مقصد به‌عنوان canonical هستند، درحالی‌که ریدایرکت‌های موقت معمولاً با هدف حفظ URL مبدأ استفاده می‌شوند. ریدایرکت سمت سرور نیز نسبت به ریدایرکت JavaScript قابل اتکاتر است؛ چون مشاهده ریدایرکت JavaScript به رندر موفق وابسته است.

اگر URL قدیمی ابتدا به نسخه HTTP جدید، سپس به HTTPS و بعد به نسخه بدون www منتقل می‌شود، زنجیره را کوتاه کنید و URL اولیه را مستقیماً به مقصد نهایی بفرستید.

۵. URLهای تکراری و پارامتری را شناسایی کنید

یک محتوا ممکن است از چند آدرس در دسترس باشد:

• پارامترهای رهگیری؛
• فیلتر و مرتب‌سازی؛
• نسخه چاپی؛
• حروف بزرگ و کوچک؛
• اسلش پایانی متفاوت؛
• HTTP و HTTPS؛
• www و بدون www؛
• شناسه نشست؛
• آرشیوهای مشابه.

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

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

رندر JavaScript و نسخه موبایل را آزمایش کنید

ممکن است گوگل پاسخ اولیه صفحه را دریافت کند، اما محتوای اصلی فقط پس از اجرای JavaScript ساخته شود. به همین دلیل بررسی HTML اولیه همیشه کافی نیست.

۱. محتوای رندرشده را با صفحه واقعی مقایسه کنید

گوگل برنامه‌های مبتنی بر JavaScript را در سه مرحله اصلی خزش، رندر و ایندکس پردازش می‌کند.

در صفحه رندرشده این عناصر را کنترل کنید:

• عنوان و محتوای اصلی؛
• لینک‌های داخلی؛
• تصاویر؛
• فهرست محصولات یا مطالب؛
• داده‌های ساختاریافته؛
• محتوای بارگذاری‌شده پس از اسکرول؛
• درخواست‌های ناموفق؛
• خطاهای JavaScript.

وضعیت سالم زمانی است که محتوای ضروری بدون کلیک، تایپ یا تعامل اجباری کاربر در خروجی رندرشده دیده شود.

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

۲. نسخه موبایل و دسکتاپ را مقایسه کنید

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

این موارد را مقایسه کنید:

• متن و محتوای اصلی؛
• هدینگ‌ها؛
• لینک‌های داخلی؛
• تصاویر و متن جایگزین؛
• داده‌های ساختاریافته؛
• canonical؛
• meta robots؛
• قیمت، موجودی یا مشخصات محصول؛
• محتوای داخل تب و آکاردئون.

طراحی دو نسخه می‌تواند متفاوت باشد، اما هدف و اطلاعات اصلی صفحه باید حفظ شوند. محتوای مهم را به تعاملی وابسته نکنید که Googlebot قادر به انجام آن نیست.

برای بررسی از URL Inspection، Lighthouse و آزمایش واقعی روی چند دستگاه و اندازه صفحه استفاده کنید. در صورت مشاهده اختلاف، ابتدا نسخه موبایل را با تصمیم ایندکس صفحه هماهنگ کنید.

۳. منابع CSS، JavaScript و تصاویر ضروری را بررسی کنید

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

به این موارد توجه کنید:

• پاسخ 404 یا 5xx فایل‌های ضروری؛
• مسدودبودن منابع مهم در robots.txt؛
• خطای CORS؛
• منابع خارجی حذف‌شده یا ناپایدار؛
• بارگذاری تنبل نادرست؛
• تصاویر یا متن‌هایی که فقط پس از تعامل ظاهر می‌شوند؛
• درخواست‌هایی که پیش از تکمیل رندر متوقف می‌شوند.

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

سرعت، امنیت و تجربه صفحه را ارزیابی کنید

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

۱. HTTPS و محتوای ترکیبی را بررسی کنید

تمام صفحات اصلی باید از HTTPS معتبر استفاده کنند و نسخه HTTP به مقصد نهایی امن منتقل شود.

موارد مهم عبارت‌اند از:

• اعتبار و تاریخ گواهی SSL؛
• پوشش زیردامنه‌های لازم؛
• انتقال مستقیم HTTP به HTTPS؛
• منابع HTTP در صفحه HTTPS؛
• لینک‌های داخلی قدیمی؛
• canonicalهای HTTP؛
• URLهای HTTP در سایت‌مپ؛
• خطاهای تمدید گواهی.

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

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

۲. داده میدانی و آزمایشگاهی را جداگانه تحلیل کنید

ابزارهای سرعت معمولاً دو نوع داده ارائه می‌کنند:

• داده میدانی از تجربه واقعی کاربران؛
• داده آزمایشگاهی در یک محیط شبیه‌سازی‌شده.

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

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

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

۳. معیارهای Core Web Vitals را بسنجید

براساس مستندات بررسی‌شده تا مرداد ۱۴۰۵، معیارهای اصلی Core Web Vitals عبارت‌اند از:

• LCP برای سرعت نمایش محتوای اصلی؛
• INP برای پاسخ‌گویی صفحه به تعامل؛
• CLS برای ثبات بصری.

طبق معیارهای Core Web Vitals، وضعیت خوب در صدک ۷۵ تجربه کاربران با این حدود سنجیده می‌شود:

• LCP حداکثر ۲٫۵ ثانیه؛
• INP حداکثر ۲۰۰ میلی‌ثانیه؛
• CLS حداکثر ۰٫۱.

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

برای LCP، پاسخ سرور، تصویر اصلی، فونت‌ها و منابع مسدودکننده رندر را بررسی کنید. برای INP، اجرای سنگین JavaScript و پردازش رویدادها اهمیت دارد. برای CLS نیز تصاویر بدون ابعاد مشخص و عناصر دیرهنگام از عوامل رایج‌اند.

امتیاز ۱۰۰ یک آزمایش سرعت به‌تنهایی سلامت فنی سایت را ثابت نمی‌کند. رفع noindex ناخواسته، خطای سرور یا canonical اشتباه باید پیش از افزایش جزئی امتیاز آزمایشگاهی انجام شود.

موارد تخصصی را فقط در سایت‌های نیازمند بررسی کنید

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

۱. داده‌های ساختاریافته

ابتدا بررسی کنید نوع داده ساختاریافته با محتوای واقعی صفحه تناسب دارد یا نه. سپس این موارد را بسنجید:

• اطلاعات نشانه‌گذاری‌شده برای کاربر قابل مشاهده است؛
• مقادیر نادرست، ساختگی یا قدیمی نیستند؛
• ویژگی‌های الزامی نوع انتخاب‌شده کامل‌اند؛
• داده در نسخه موبایل نیز وجود دارد؛
• صفحه برای Googlebot قابل دسترسی است؛
• خطاهای Rich Results Test رفع شده‌اند.

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

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

۲. بودجه خزش و تحلیل لاگ

بودجه خزش بیشتر برای سایت‌های بزرگ، پرتغییر یا دارای URLهای بسیار زیاد اهمیت دارد.

راهنمای فعلی گوگل عمدتاً این گروه‌ها را مخاطب قرار می‌دهد:

• سایت‌های دارای حدود یک میلیون صفحه یا بیشتر با تغییرات منظم؛
• سایت‌های دارای حدود ۱۰ هزار صفحه یا بیشتر با تغییرات روزانه سریع؛
• سایت‌هایی که بخش بزرگی از URLهایشان در وضعیت «کشف‌شده، فعلاً ایندکس‌نشده» قرار دارد.

این اعداد تقریبی‌اند و مرز قطعی محسوب نمی‌شوند. برای بسیاری از سایت‌های کوچک، سایت‌مپ به‌روز و بررسی گزارش Page Indexing کافی است.

اگر مشکل واقعی بودجه خزش دارید، URLهای پارامتری، خطاهای سرور، پاسخ‌های تکراری، سرعت خزش و رفتار Googlebot در لاگ سرور را بررسی کنید.

۳. hreflang و صفحات چندنسخه‌ای

hreflang فقط برای سایت‌هایی کاربرد دارد که نسخه‌های زبانی یا منطقه‌ای متفاوت از محتوای مشابه ارائه می‌کنند.

در این سایت‌ها بررسی کنید:

• کد زبان و منطقه صحیح است؛
• صفحات به‌صورت متقابل یکدیگر را معرفی می‌کنند؛
• URL مقصد قابل ایندکس است؛
• canonical و hreflang با هم تعارض ندارند؛
• نسخه‌های ناموجود یا ریدایرکت‌شده معرفی نشده‌اند.

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

مشکلات فنی سئو را چگونه اولویت‌بندی کنیم؟

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

اولویت حیاتی

مشکلی حیاتی است که:

• Googlebot را از صفحات مهم دور نگه می‌دارد؛
• تعداد زیادی صفحه مهم را noindex کرده است؛
• پاسخ سرور نامعتبر یا ناپایدار ایجاد می‌کند؛
• canonical یا ریدایرکت اشتباه را روی یک قالب کامل اعمال کرده است؛
• محتوای اصلی را پس از رندر پنهان می‌کند؛
• نسخه اصلی دامنه یا پروتکل را به‌هم ریخته است.

اولویت مهم

مشکل مهم معمولاً مانع کامل حضور صفحه نیست، اما می‌تواند سیگنال‌ها یا تجربه کاربران را در مقیاس قابل‌توجهی ضعیف کند؛ مانند:

• لینک‌های شکسته در تعداد زیادی صفحه؛
• زنجیره‌های ریدایرکت؛
• URLهای تکراری گسترده؛
• ناسازگاری سایت‌مپ و canonical؛
• Core Web Vitals ضعیف در یک قالب اصلی؛
• صفحات مهم با عمق دسترسی زیاد؛
• منابع رندر ناپایدار.

اولویت تکمیلی

مشکلات تکمیلی معمولاً بعد از موارد حیاتی و مهم اصلاح می‌شوند؛ مانند:

• کاهش جزئی حجم یک فایل؛
• پاک‌سازی چند URL کم‌اهمیت؛
• رفع هشدار غیرحیاتی داده ساختاریافته؛
• اصلاح محدود یک صفحه کم‌ترافیک.

برای تعیین اولویت هر خطا به چهار سؤال پاسخ دهید:

1. آیا مانع حضور صفحه مهم در گوگل است؟
2. چند URL یا کاربر را تحت تأثیر قرار می‌دهد؟
3. اصلاح اشتباه آن چه ریسکی دارد؟
4. آیا به تیم فنی، نسخه پشتیبان یا انتشار کنترل‌شده نیاز دارد؟

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

نتایج ممیزی را ثبت و پس از اصلاح اعتبارسنجی کنید

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

برای هر مشکل این اطلاعات را نگه دارید:

• URL یا قالب درگیر؛
• وضعیت فعلی؛
• گستره مشکل؛
• شدت؛
• علت احتمالی؛
• اقدام پیشنهادی؛
• مسئول اجرا؛
• تاریخ تغییر؛
• ابزار بررسی مجدد؛
• نتیجه نهایی.

برای اعتبارسنجی اصلاحات این مراحل را انجام دهید:

1. وضعیت اولیه و URLهای درگیر را ثبت کنید.
2. پیش از تغییرات پرریسک نسخه پشتیبان بگیرید.
3. اصلاح را ابتدا روی نمونه محدودی آزمایش کنید.
4. پاسخ زنده URL را بعد از انتشار بررسی کنید.
5. رندر و منابع ضروری را دوباره بسنجید.
6. canonical، robots و کد وضعیت را کنترل کنید.
7. در صورت نیاز Live Test را در URL Inspection اجرا کنید.
8. تغییر گزارش‌های Search Console را در بازه بعدی زیر نظر بگیرید.
9. نتیجه نهایی را در همان فهرست ممیزی ثبت کنید.

تغییر روی سایت به معنی مشاهده فوری آن توسط گوگل نیست. صفحه باید دوباره خزیده و پردازش شود؛ بنابراین میان «اصلاح انجام‌شده» و «تغییر وضعیت در گزارش گوگل» تفاوت بگذارید.

تغییرات سراسری robots.txt، noindex، canonical، ساختار URL و ریدایرکت را بدون آزمایش محدود و برنامه بازگشت منتشر نکنید. اصلاح اشتباه این موارد ممکن است از مشکل اولیه گسترده‌تر باشد.

سخن پایانی

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

پس از هر تغییر، فقط به پیام موفق ابزار یا ظاهر سالم صفحه اکتفا نکنید. پاسخ سرور، رندر، canonical، robots و گزارش‌های بعدی را دوباره بررسی و نتیجه را ثبت کنید. این رویکرد احتمال اصلاحات سراسری اشتباه و بازگشت دوباره مشکلات را کاهش می‌دهد.

سؤالات متداول

۱. سئو تکنیکال سایت هر چند وقت یک‌بار بررسی شود؟

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

در یک سایت کوچک و کم‌تغییر، کنترل دوره‌ای گزارش‌های اصلی Search Console و اجرای ممیزی بعد از تغییرات مهم می‌تواند کافی باشد.

۲. آیا ثبت URL در سایت‌مپ باعث ایندکس‌شدن آن می‌شود؟

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

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

۳. تفاوت robots.txt و noindex چیست؟

robots.txt دسترسی خزنده به مسیر یا URL را مدیریت می‌کند، اما noindex به موتور جست‌وجو می‌گوید محتوا در نتایج نمایش داده نشود.

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

۴. آیا همه صفحات 404 باید ریدایرکت شوند؟

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

ریدایرکت همه صفحات حذف‌شده به صفحه اصلی مقصد نامرتبطی ایجاد می‌کند و می‌تواند به‌عنوان Soft 404 تشخیص داده شود.

۵. آیا امتیاز ۱۰۰ در PageSpeed برای سئو ضروری است؟

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

تمرکز اصلی باید روی مشکلات واقعی کاربران، داده میدانی و معیارهای Core Web Vitals باشد. خطاهایی مانند noindex ناخواسته، پاسخ ناموفق سرور و canonical اشتباه نیز پیش از افزایش جزئی امتیاز آزمایشگاهی اولویت دارند.

۶. بودجه خزش برای چه سایت‌هایی اهمیت بیشتری دارد؟

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

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