فرض کنید ظاهر سایت شرکتی را تأیید کرده‌اید، اما تنظیمات محیط آزمایشی هنوز روی نسخه اصلی باقی مانده‌اند. مشتری سایت را باز میکند، ولی موتور جست‌وجو اجازه بررسی صفحات خدمات را ندارد. بررسی سئوی فنی سایت پیش از انتشار، چنین خطاهایی را آشکار میکند و برای تحویل فنی معیار مشخصی میدهد.
۱. سئوی فنی سایت را از دسترسی ربات‌ها شروع کنید
خزش یعنی ربات بتواند صفحه را دریافت و بررسی کند. ایندکس یعنی موتور جست‌وجو صفحه را در فهرست خود نگه دارد. دسترسی به صفحه، لزوماً به معنای ایندکس آن نیست. تمرکز این راهنما بر پذیرش فنی انتشار است، نه تولید محتوا یا آموزش جامع سرعت.
اما دو تنظیم متفاوت را نباید با هم اشتباه گرفت. فایل robots.txt دسترسی خزنده را کنترل میکند؛ دستور noindex از موتور جست‌وجو می‌خواهد صفحه را ایندکس نکند. مسدودکردن خزش، روش قابل‌اتکایی برای حذف آدرس از نتایج نیست. حتی ممکن است ربات نتواند دستور noindex داخل صفحه را بخواند.
برای شروع، صفحه اصلی، یک صفحه خدمت و یک مقاله را انتخاب کنید. از تیم فنی بخواهید قواعد robots.txt، متای robots و هدر X-Robots-Tag را برای این نمونه‌ها بررسی کند. فقط صفحاتی که باید در جست‌وجو دیده شوند، باید از noindex ناخواسته خالی باشند.
همچنین محیط آزمایشی را با احراز هویت محافظت کنید؛ robots.txt جای قفل ورود را نمی‌گیرد. در برنامه انتشار، حذف محافظت از نسخه اصلی و بازبینی تنظیمات را ثبت کنید. برای شناخت دقیق‌تر این تفاوت‌ها، مستندات خزش و ایندکس گوگل مرجع مناسبی است.
معیار قبولی: صفحات عمومی هدف بدون ورود باز شوند و دستور ناخواسته‌ای برای مسدودکردن خزش یا ایندکس نداشته باشند. این تأیید فقط مانع فنی را کنار می‌زند؛ ایندکس را تضمین نمیکند.
۲ و ۳. HTTPS، نسخه اصلی دامنه و پاسخ آدرسها را آزمایش کنید
در بررسی دوم، نسخه اصلی دامنه را مشخص کنید: با www یا بدون آن. گواهی امنیتی باید معتبر باشد و مرورگر تصاویر، فونت‌ها و فایل‌های ضروری را از HTTPS دریافت کند. نسخه‌های دیگر باید مستقیم به نسخه منتخب برسند، بدون حلقه یا زنجیره انتقال غیرضروری.
برای مثال، آدرس HTTP یک خدمت را باز کنید و مقصد نهایی را ببینید. انتقال به صفحه اصلی کافی نیست؛ کاربر باید به همان خدمت روی نسخه امن برسد. تیم فنی میتواند مسیر انتقال و وضعیت منابع را در ابزارهای مرورگر ثبت کند.
بررسی سوم سئوی فنی سایت به پاسخ آدرسها مربوط است. صفحات معتبر باید پاسخ ۲۰۰ بدهند. آدرس واقعاً ناموجود معمولاً پاسخ ۴۰۴ می‌خواهد؛ برای محتوایی که عمداً و برای همیشه حذف کرده‌اید، پاسخ ۴۱۰ هم مناسب است. خطاهای سرور در مسیرهای اصلی را پیش از انتشار رفع کنید.
اما نمایش پیام «یافت نشد» با پاسخ ۲۰۰، رفتار درستی برای صفحه حذف‌شده خدمات نیست. انتقال همه آدرس‌های ناموجود به صفحه اصلی هم جایگزین مناسبی ندارد. چنین انتقالی کاربر را به مقصد نامرتبط می‌برد و وضعیت واقعی آدرس را پنهان میکند.
در بازطراحی، فهرست آدرس‌های قبلی و مقصد مرتبط هرکدام را تهیه کنید. برای انتقال دائمی، ریدایرکت دائمی مناسب مانند ۳۰۱ یا ۳۰۸ به کار ببرید. اگر جایگزین مرتبط ندارید، پاسخ حذف مناسب را نگه دارید. گزارش تحویل باید پاسخ آدرس‌های مهم و مسیر انتقال نسخه‌های دامنه را نشان دهد.
۴ و ۵. آدرس مرجع و نقشه سایت را با هم تطبیق دهید
بررسی چهارم به canonical مربوط است؛ نشانه‌ای که نسخه مرجع یک صفحه را معرفی میکند. مقصد آن باید درست، قابل‌دسترسی و قابل‌ایندکس باشد. نسخه اصلی هر صفحه معمولاً canonical خودارجاع دارد؛ یعنی آدرس خودش را معرفی میکند.
برای مثال، یک خطای قالب ممکن است canonical همه صفحات خدمات را به صفحه اصلی ببرد. در این حالت، صفحات مستقل پیام نادرستی درباره نسخه مرجع می‌فرستند. canonical دستور قطعی نیست، اما ناسازگاری آن میتواند انتخاب نسخه مناسب را دشوار کند.
در بررسی پنجم، نقشه سایت XML را روی دامنه نهایی باز کنید. این فایل باید فقط آدرس‌های مرجع، قابل‌ایندکس و دارای پاسخ موفق را فهرست کند. آدرس محیط آزمایشی، صفحه حذف‌شده یا مسیر ریدایرکت‌شده نباید در آن بماند.
بنابراین آدرس لینکهای داخلی، canonical و نقشه سایت را کنار هم مقایسه کنید. اگر منو به یک نسخه لینک بدهد و نقشه نسخه دیگری را معرفی کند، نشانه‌های متناقض دارید. حضور در نقشه سایت هم به‌تنهایی ایندکس را تضمین نمیکند.
برای پذیرش این بخش از سئوی فنی سایت، چند نمونه از هر قالب را تطبیق دهید. صفحه خدمت، مقاله و صفحه دسته‌بندی ممکن است تنظیمات متفاوتی داشته باشند. در سایت چندزبانه، هماهنگی hreflang با canonical را هم بررسی کنید؛ نسخه‌های زبانی مستقل نباید همگی به یک زبان canonical شوند.
۶. محتوای اصلی و مسیر رسیدن به خدمات را بررسی کنید
بررسی ششم می‌پرسد خزنده واقعاً چه محتوایی دریافت میکند. عنوان صفحه، تیتر اصلی، توضیح خدمت و لینکهای مهم باید در خروجی رندرشده حضور داشته باشند. منظور، خروجی پس از پردازش صفحه است؛ نه صرفاً تصویری که مدیر سایت در مرورگر می‌بیند.
اما استفاده از جاوااسکریپت به‌خودی‌خود مانع سئو نیست. مسئله این است که خزنده بتواند محتوا و مسیرهای سایت را دریافت و پردازش کند. محتوایی که فقط پس از کلیک یا تعامل کاربر بارگذاری می‌کنید، بررسی ویژه می‌خواهد.
لینکهای ناوبری و خدمات را با عنصر a و href معتبر پیاده کنید. دکمه‌ای که فقط با اجرای یک رویداد صفحه را عوض میکند، جایگزین مطمئنی برای لینک نیست. هیچ خدمت مهمی نباید فقط از جست‌وجوی داخلی یا نقشه XML قابل‌کشف باشد.
به همین دلیل، از تیم فنی خروجی رندرشده قالب‌های اصلی را بخواهید. پس از انتشار عمومی، آزمون زنده URL Inspection به بررسی دسترسی و رندر نمونه‌ها کمک میکند. نتیجه این آزمون، تأیید حضور صفحه در نتایج جست‌وجو نیست.
معیار قبولی: از صفحه اصلی تا خدمات، مسیر لینک قابل‌خزش وجود داشته باشد. عنوان صفحه، تیتر و متن اصلی خدمت نیز در خروجی رندرشده حاضر باشند. در سئو سایت شرکتی، این کنترل را برای خدمات اصلی انجام دهید؛ سالم‌بودن صفحه اصلی به‌تنهایی کافی نیست.
۷. نسخه موبایل را از نظر محتوا و دسترسی تأیید کنید
در بررسی هفتم، فقط کوچک‌شدن ظاهر را تأیید نکنید. محتوای اصلی، لینکهای خدمات و دستورهای ایندکس نسخه موبایل باید با دسکتاپ سازگار باشند. این بخش از سئوی فنی سایت را روی گوشی واقعی هم آزمایش کنید.
برای مثال، حذف توضیحات خدمات برای خلوت‌شدن صفحه با قراردادن همان توضیحات در یک بخش بازشونده تفاوت دارد. در حالت دوم، محتوا باید واقعاً در خروجی صفحه موجود باشد. اگر سایت متن را فقط پس از لمس از سرور می‌گیرد، دسترسی خزنده را جداگانه بررسی کنید.
منوی خدمات را باز کنید، بخش‌های بازشونده را لمس کنید و پنجره‌های مزاحم را ببندید. آیا می‌توانید به صفحه خدمت برسید و راه تماس را پیدا کنید؟ این آزمون را روی صفحه داخلی هم تکرار کنید؛ رفتار منو ممکن است بین قالب‌ها فرق کند.
با این حال، کنترل تجربه کاربر را با کنترل ایندکس یکی ندانید. پوشیده‌شدن شماره تماس یا دشواری ارسال فرم لزوماً خطای ایندکس نیست، اما مانع پذیرش کاربردی سایت است. معیار قبولی این است که کاربر موبایل خدمت را بشناسد، به صفحه مربوط برسد و راه تماس را بدون مانع پیدا کند.
۸. سرعت را با صفحه واقعی بسنجید، نه فقط صفحه اصلی
بررسی هشتم را با تصاویر، فونت‌ها و کدهای نهایی انجام دهید. صفحه اصلی، یک خدمت و یک مقاله را در شرایط مشابه آزمایش کنید. نسخه‌ای با تصاویر موقت و بدون ابزارهای نهایی، مبنای مناسبی برای پذیرش عملکرد نیست.
برای تفسیر نتیجه، سه شاخص را بشناسید. LCP زمان نمایش بزرگ‌ترین بخش محتوای قابل‌دیدن را نشان میدهد. INP پاسخ‌گویی صفحه به تعامل کاربر را می‌سنجد و CLS میزان جابه‌جایی ناخواسته چیدمان را بیان میکند. راهنمای شاخص‌های Core Web Vitals جزئیات این معیارها را توضیح میدهد.
اما داده آزمایشگاهی با تجربه کاربران واقعی یکی نیست. سایت تازه ممکن است هنوز داده میدانی کافی نداشته باشد. INP واقعی هم از یک آزمایش ساده بارگذاری به دست نمی‌آید. شرایط دستگاه، شبکه و تعامل کاربران روی تجربه آن‌ها اثر می‌گذارد.
به‌جای شرط امتیاز کامل، مشکل قابل‌مشاهده را ثبت کنید: تصویر اصلی سنگین، جابه‌جایی فرم یا کدهای غیرضروری. برای هر مشکل، مسئول اصلاح تعیین کنید. برای انتخاب روش اصلاح، راهکارهای بهبود سرعت لود شدن سایت میتواند نقطه شروع باشد.
بنابراین در تست سئو تکنیکال، نتیجه ابزار را کنار آزمون عملی بگذارید. شرایط شبکه کاربران ایران و تأخیر دریافت منابع بیرونی را هم لحاظ کنید. معیار پذیرش، رفع موانع جدی عملکرد و ثبت اولویت مشکلات باقی‌مانده است. سئوی فنی سایت با یک امتیاز سبز تأیید نمیشود.
برگه تأیید انتشار را با تیم فنی تکمیل کنید
این چک لیست سئو قبل از راه اندازی را به برگه تحویل تبدیل کنید. برای هر ردیف، آدرس واقعی و مدرک آزمون بخواهید؛ عبارت «بررسی شد» کافی نیست. جدول زیر قالبی ساده برای ثبت همان هشت بررسی است.
بررسی | آدرس نمونه | نتیجه | مدرک آزمون | مسئول اصلاح |
|---|---|---|---|---|
۱. دسترسی و ایندکس | صفحه اصلی | ثبت شود | قواعد و هدرها | نام مسئول |
۲. HTTPS و دامنه | نسخه‌های دامنه | ثبت شود | مسیر انتقال | نام مسئول |
۳. پاسخ آدرسها | خدمت و آدرس ناموجود | ثبت شود | کد پاسخ | نام مسئول |
۴. canonical | یک صفحه از هر قالب | ثبت شود | آدرس مرجع | نام مسئول |
۵. نقشه سایت | نقشه XML نهایی | ثبت شود | گزارش تطبیق آدرسها | نام مسئول |
۶. رندر و لینک‌ها | صفحه خدمت | ثبت شود | خروجی رندرشده | نام مسئول |
۷. موبایل | صفحه خدمت | ثبت شود | گزارش آزمون گوشی | نام مسئول |
۸. عملکرد | اصلی، خدمت و مقاله | ثبت شود | گزارش همراه شرایط آزمون | نام مسئول |
ابتدا کنترلها را در محیط پیش‌انتشار انجام دهید. بلافاصله پس از انتشار، موارد وابسته به دامنه و دسترسی عمومی را دوباره آزمایش کنید. noindex ناخواسته، قطع دسترسی عمومی، حلقه ریدایرکت و خطای سرور مسیرهای اصلی، مانع تأیید انتشار هستند.
همچنین مالکیت Search Console را در حساب تحت کنترل کسب‌وکار نگه دارید. ارسال نقشه سایت و بررسی ایندکس سایت پس از انتشار باید مسئول مشخص داشته باشد. در تحویل خدمات طراحی سایت شرکتی، فایل نتایج این آزمون‌ها را مطالبه کنید.
اگر هنوز درباره مسئولیت تیم توافق ندارید، پرسش‌های کلیدی از شرکت‌های طراحی وب به تنظیم جلسه تحویل کمک میکند. قدم بعدی روشن است: آدرس نمونه‌ها، مسئولان و زمان بازآزمایی را مشخص کنید. تأیید سئوی فنی سایت را از وعده رتبه یا زمان قطعی ایندکس جدا نگه دارید.
پرسش‌های پرتکرار
۴آیا نصب افزونه سئو برای سایت شرکتی کافی است؟
افزونه میتواند تنظیماتی مثل نقشه سایت و متای robots را سادهتر کند، اما درستی خروجی را تضمین نمیکند. خطای سرور، لینکهای غیرقابلخزش یا تنظیم اشتباه قالب همچنان به بررسی فنی نیاز دارد.
آیا سئوی فنی را میتوان قبل از عمومیشدن سایت بررسی کرد؟
بخش زیادی از کنترلها در محیط آزمایشی با دسترسی مجاز انجام میشود. بااینحال، گواهی دامنه اصلی، ریدایرکتها و دسترسی عمومی خزنده باید پس از انتشار نیز دوباره آزموده شوند.
چرا سایت تازه با وجود ثبت نقشه سایت ایندکس نمیشود؟
نقشه سایت به کشف آدرسها کمک میکند، اما دستور ایندکس نیست. ابتدا وضعیت دسترسی و گزارش همان آدرس را بررسی کنید؛ اگر مانع فنی وجود نداشت، کیفیت و تمایز محتوای صفحه نیز باید ارزیابی شود.
مسئول بررسی سئوی فنی، طراح سایت است یا متخصص سئو؟
متخصص سئو معمولاً نیازمندیها و خطاها را مشخص میکند و تیم توسعه اصلاحات فنی را انجام میدهد. مدیر پروژه باید مسئول تأیید نهایی و مدرک موردنیاز برای هر بررسی را پیش از تحویل روشن کند.
