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

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

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

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

لایه اول: آیا سایت در دسترس است؟

قبل از هر ابزار سئو، سرور باید پاسخ دهد. نسخه‌های اصلی دامنه را آزمایش کنید:

  • http://domain
  • http://www.domain
  • https://domain
  • https://www.domain

یکی باید نسخه نهایی باشد و بقیه با یک ریدایرکت دائمی به آن برسند. زنجیره، loop و تفاوت مقصد در صفحات داخلی را بررسی کنید. گواهی SSL باید معتبر و شامل hostnameهای لازم باشد.

گزارش uptime و log سرور می‌تواند خطاهایی را نشان دهد که مرور دستی نمی‌بیند. خطاهای 5xx، timeout و محدودیت فایروال برای crawlerها مستقیماً دسترسی را مختل می‌کنند. اگر سایت برای IP یا کشور خاص باز است، باید مطمئن شوید Googlebot واقعی مسدود نیست.

لایه‌های سئو تکنیکال از سرور تا تجربه صفحه

لایه دوم: ربات‌ها چه اجازه‌ای دارند؟

فایل robots.txt را باز کنید و قواعد را با مسیر صفحات مهم تطبیق دهید. مسدود کردن کل سایت در محیط آزمایشی رایج است و گاهی پس از انتشار باقی می‌ماند. همچنین meta robots و هدر X-Robots-Tag را بررسی کنید.

تفاوت مهم:

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

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

لایه سوم: sitemap چه چیزی اعلام می‌کند؟

نقشه XML باید فقط URLهای canonical، قابل ایندکس و دارای پاسخ 200 را شامل شود. وجود ریدایرکت، 404، noindex یا نسخه‌های پارامتری در sitemap سیگنال‌های متناقض می‌فرستد.

موارد بررسی:

  • sitemap در robots.txt معرفی شده است.
  • تاریخ lastmod فقط هنگام تغییر واقعی به‌روز می‌شود.
  • تعداد URL با وضعیت واقعی سایت هماهنگ است.
  • sitemapهای جدا برای نوع محتوا در سایت بزرگ وجود دارند.
  • Search Console فایل را با موفقیت خوانده است.

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

لایه چهارم: canonical و نسخه‌های تکراری

هر صفحه منحصربه‌فرد معمولاً canonical خودارجاع دارد. این موارد را کنترل کنید:

  • HTTP در برابر HTTPS
  • www در برابر بدون www
  • اسلش انتهایی
  • حروف بزرگ و کوچک، در سیستم‌های حساس
  • پارامترهای کمپین و مرتب‌سازی
  • نسخه چاپ، AMP قدیمی یا queryهای فیلتر

Canonical یک hint است، نه دستور قطعی. اگر صفحه A به B canonical شود ولی sitemap و لینک‌های داخلی همچنان A را تقویت کنند، سیگنال‌ها متناقض‌اند. ریدایرکت، canonical، sitemap و لینک داخلی باید نسخه واحدی را نشان دهند.

لایه پنجم: کدهای پاسخ HTTP

وضعیت‌ها را براساس نوع صفحه تفسیر کنید:

  • 200: صفحه موفق و قابل دریافت
  • 301/308: انتقال دائمی
  • 302/307: انتقال موقت
  • 404: محتوا پیدا نشد
  • 410: محتوا عمداً حذف شده
  • 429: درخواست بیش از حد
  • 5xx: خطای سرور

Soft 404 زمانی رخ می‌دهد که صفحه ظاهراً 200 است ولی محتوای «پیدا نشد» یا صفحه بسیار بی‌ارزش نشان می‌دهد. ریدایرکت همه URLهای حذف‌شده به صفحه اصلی نیز می‌تواند چنین سیگنالی ایجاد کند. نزدیک‌ترین جایگزین واقعی را انتخاب کنید؛ اگر وجود ندارد، پاسخ حذف مناسب‌تر است.

لایه ششم: معماری و عمق کلیک

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

بررسی کنید:

  • صفحه یتیم وجود ندارد.
  • دسته‌ها حلقه یا بن‌بست نمی‌سازند.
  • لینک‌ها <a href> استاندارد هستند.
  • anchor مقصد را توصیف می‌کند.
  • صفحات کم‌ارزش لینک‌های گسترده دریافت نمی‌کنند.
  • صفحه‌بندی به محصولات یا مقالات عمیق دسترسی می‌دهد.

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

لایه هفتم: ریدایرکت‌ها

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

خطاهای رایج:

  • loop میان HTTP و HTTPS
  • زنجیره ناشی از چند مهاجرت
  • مقصد نامرتبط
  • ریدایرکت موقت برای انتقال دائمی
  • حذف پارامتر یا زبان ضروری
  • مقصدی که خود 404 یا noindex است

پیش از اعمال انبوه، نمونه‌ها و الگوهای URL را روی محیط آزمایشی بررسی کنید.

لایه هشتم: جاوااسکریپت و رندر

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

موارد حساس:

  • لینک‌هایی که href ندارند
  • محتوایی که پس از تعامل کاربر بارگذاری می‌شود
  • خطای API هنگام رندر
  • canonical متفاوت در HTML اولیه و DOM
  • title و meta description تولیدشده دیرهنگام
  • infinite scroll بدون pagination قابل crawl

در سایت خدماتی، server-side rendering یا خروجی HTML پایدار معمولاً پیچیدگی را کاهش می‌دهد. در اپلیکیشن‌های بزرگ باید راه‌حل متناسب با framework انتخاب شود.

لایه نهم: نسخه موبایل و برابری محتوا

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

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

لایه دهم: Core Web Vitals و عملکرد واقعی

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

اولویت‌های رایج:

  • بهینه‌سازی تصویر hero و تعیین ابعاد
  • کاهش JavaScript غیرضروری
  • preload منابع حیاتی با احتیاط
  • بهبود پاسخ سرور و کش
  • جلوگیری از تزریق دیرهنگام بنر و فونت
  • کاهش اسکریپت‌های تبلیغاتی و ابزارهای سنگین

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

لایه یازدهم: داده ساختاریافته

Schema به موتور جستجو کمک می‌کند نوع اطلاعات را بهتر تشخیص دهد، اما جای محتوای واقعی را نمی‌گیرد. انواع متناسب را انتخاب کنید: Article، Product، Breadcrumb، Organization یا انواع تخصصی مورد پشتیبانی.

قواعد:

  • داده با محتوای قابل مشاهده یکسان باشد.
  • review یا rating ساختگی اضافه نشود.
  • خطاها با validator بررسی شوند.
  • پس از تغییر قالب چند URL نمونه آزمایش شوند.
  • انتظار نمایش rich result تضمین‌شده نباشد.

لایه دوازدهم: hreflang در سایت چندزبانه

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

سایت تک‌زبانه نیازی به hreflang ندارد. اضافه کردن markup اضافی بدون مسئله واقعی ارزش ایجاد نمی‌کند.

لایه سیزدهم: امنیت و محتوای ناخواسته

Security Issues و Manual Actions سرچ کنسول را بررسی کنید. هک وردپرس ممکن است هزاران صفحه اسپم، ریدایرکت یا لینک مخفی بسازد. جستجوی site:، log و crawl داخلی می‌توانند URLهای ناشناخته را آشکار کنند.

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

اولویت‌بندی یافته‌های audit

هر مشکل را با چهار معیار بسنجید:

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

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

چه زمانی دوباره crawl کنیم؟

پس از اصلاح قالب یا قانون گسترده، crawl کامل یا نمونه‌گیری ساختاریافته انجام دهید. برای تغییر کوچک روی یک صفحه، URL Inspection و آزمون مستقیم کافی است. تاریخ، URLهای تست، نتیجه قبل و بعد و فرد مسئول را ثبت کنید.

اصلاح فنی بدون QA می‌تواند مشکل تازه بسازد. به‌ویژه تغییر canonical، ریدایرکت، robots و noindex باید قبل و بعد از انتشار کنترل شود.

جمع‌بندی

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

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

پرسش‌های متداول

آیا سئو تکنیکال فقط برای سایت بزرگ است؟

خیر. حتی سایت کوچک ممکن است با noindex، canonical یا خطای سرور کاملاً از نتایج خارج شود. پیچیدگی audit با اندازه سایت تغییر می‌کند.

آیا نمره ۱۰۰ PageSpeed لازم است؟

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

sitemap باعث ایندکس شدن می‌شود؟

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

canonical و redirect چه تفاوتی دارند؟

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

audit فنی هر چند وقت تکرار شود؟

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

منابع اصلی برای بررسی بیشتر