سئو تکنیکال چیست؟ آموزش کامل سئو تکنیکال از خزش تا ایندکس

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

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

پاسخ کوتاه به سوال سئو تکنیکال چیست؟

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

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

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

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

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

سئو تکنیکال سه مانع اصلی را کاهش می‌دهد:

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

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

به شکل خلاصه درباره اهمیت سئو تکنیکال :

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

تفاوت سئو تکنیکال، داخلی و خارجی

سئو تکنیکال، سئو داخلی و  سئو خارجی سه بخش جدا اما مرتبط از یک فرایند بهینه‌سازی هستند.

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

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

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

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

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

کشف URL

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

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

خزش در صفحه

پس از کشف آدرس با همان(URL)، Googlebot یک درخواست HTTP به سرور ارسال می‌کند. در این مرحله، دسترسی خزنده، ظرفیت سرور، قوانین robots.txt و پاسخ HTTP اهمیت دارند.

پاسخ 200 نشان می‌دهد درخواست با موفقیت پردازش شده است. پاسخ‌های 3xx مسیر دیگری را معرفی می‌کنند و پاسخ‌های 4xx یا 5xx از نبود صفحه یا مشکل سرور خبر می‌دهند.

رندر محتوا

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

مسدودبودن فایل‌های ضروری، خطای JavaScript یا وابستگی محتوا به کلیک کاربر می‌تواند باعث شود نسخه‌ای که گوگل می‌بیند با نسخه قابل مشاهده برای کاربر تفاوت داشته باشد.

ایندکس محتوا

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

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

نمایش در نتایج

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

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

هر مشکل در کدام مرحله سئو تکنیکال ایجاد می‌شود؟

مرحله اول: کشف و دسترسی

Googlebot چگونه سایت را بررسی می‌کند؟

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

Googlebot با ابزارهایی مانند Screaming Frog یا Sitebulb یکسان نیست. ابزار سئو از بیرون سایت را شبیه‌سازی و گزارشی در اختیار شما قرار می‌دهد؛ اما Googlebot بخشی از فرایند واقعی جست‌وجوی گوگل است.

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

صفحات یتیم چگونه از مسیر کشف خارج می‌شوند؟

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

تمام صفحاتی که در Crawl دیده نمی‌شوند الزاماً یتیم نیستند. ابتدا باید فهرست URLهای ابزار خزنده با Sitemap، داده‌های Search Console، آنالیتیکس و در صورت امکان لاگ سرور مقایسه شود.

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

فایل robots.txt چه چیزی را کنترل می‌کند؟

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

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

در نظر داشته باشید که مسدودکردن هم‌زمان URL در robots.txt و قراردادن noindex روی همان صفحه می‌تواند نتیجه مورد انتظار را ایجاد نکند؛ زیرا خزنده اجازه ورود ندارد تا دستور را ببیند. پیش از تغییر این فایل، مسیرها و اثر قوانین را با دقت بررسی کنید.

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

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

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

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

Sitemap چه کمکی به کشف URLها می‌کند؟

Sitemap فهرستی از URLهای سایت را در اختیار موتور جست‌وجو قرار می‌دهد. این فایل به‌ویژه برای سایت‌های بزرگ با سایت‌هایی با URLهایی که از لینک‌های داخلی محدودتری برخوردارند مفید است.

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

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

مرحله دوم: پاسخ سرور و مدیریت URL

فایل htaccess چه نقشی در سئو تکنیکال دارد؟

فایل .htaccess در سرورهای Apache می‌تواند برای تعریف ریدایرکت، اجبار به بررسی نسخه HTTPS، تنظیم Cache، بازنویسی URL و بعضی پاسخ‌های سرور استفاده شود. در واقع این قایل زبان مشترک مدیر سایت و گوگل است و از طریق این فایل تغییرات و خواسته‌های خود را به گوگل اعلام می‌کنیم.

این فایل در تمام سایت‌ها یا سرورها وجود ندارد. برای مثال، Nginx از ساختار تنظیمات دیگری استفاده می‌کند. بنابراین نباید هر دستور پیشنهادی برای .htaccess را بدون شناخت زیرساخت اجرا کرد.

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

لینک شکسته چگونه ایجاد می‌شود؟

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

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

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

خطای ۴۰۴ چه معنایی دارد؟

کد 404 Not Found اعلام می‌کند منبع درخواستی در این نشانی پیدا نشده است. وجود تعدادی صفحه با پاسخ ۴۰۴ در یک سایت طبیعی است و به‌تنهایی جریمه عمومی برای دامنه ایجاد نمی‌کند.

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

در مقابل، Soft ۴۰۴ زمانی رخ می‌دهد که سرور پاسخ 200 برمی‌گرداند، اما صفحه یا بدون محتواست یا محتوا با جستجوی کاربر ارتباطی ندارد.

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

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

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

ریدایرکت ۳۰۱ چه زمانی انتخاب مناسبی است؟

ریدایرکت ۳۰۱ برای انتقال دائمی یک URL به مقصد جدید استفاده می‌شود. تغییر ساختار نشانی، ادغام صفحات، تغییر دامنه و انتقال دائمی HTTP به HTTPS از کاربردهای رایج آن هستند.

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

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

پاسخ ۴۱۰ چه زمانی استفاده می‌شود؟

410 Gone یک کد پاسخ HTTP است، نه نوعی ریدایرکت. این پاسخ نشان می‌دهد صفحه به‌صورت عمدی حذف شده و قرار نیست در همان نشانی نمایش داده شود.

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

استفاده از عبارت ریدایرکت ۴۱۰ در جست‌وجوی کاربران رایج است، اما از نظر فنی چیزی به مقصد دیگری منتقل نمی‌شود.

زنجیره ریدایرکت چگونه ایجاد می‌شود؟

زنجیره  ریدایکرت زمانی ایجاد می‌شود که URL اول به URL دوم و خود URL دوم به URL سوم منتقل شود:

A → B → C

گزارش این مشکل در اسکریمینگ فراگ از مسیر زیر قابل بررسی است:

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

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

مرحله سوم: رندر و تجربه کاربر از صفحه

JavaScript چه اثری بر خزش و رندر دارد؟

در صفحات JavaScriptمحور (منظور صفحاتی است که حرکات، افکت‌ها و استایل‌ها اضافه دارند) HTML اولیه ممکن است بخش محدودی از محتوا را داشته باشد و عناصر اصلی بعداً به DOM اضافه شوند. در این شرایط، مقایسه Source اولیه با DOM رندرشده اهمیت پیدا می‌کند.

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

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

سرعت سایت و Core Web Vitals

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

سه معیار اصلی Core Web Vitals عبارت‌اند از:

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

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

براساس راهنمای Web Vitals، محدوده مناسب شامل LCP حداکثر ۲٫۵ ثانیه، INP حداکثر ۲۰۰ میلی‌ثانیه و CLS حداکثر ۰٫۱ است. رسیدن به امتیاز کامل ابزار نباید جای هدف اصلی، یعنی تجربه سریع و پایدار کاربر، را بگیرد.

Mobile-first Indexing

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

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

محتوایی که فقط پس از تعامل کاربر بارگذاری می‌شود نیز ممکن است در اختیار گوگل قرار نگیرد. جزئیات هماهنگی نسخه‌ها در راهنمای Mobile-first Indexing آمده است.

AMP در حال حاضر چه جایگاهی دارد؟

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

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

HTTPS و امنیت اتصال با SSL

SSL ارتباط میان مرورگر و سرور را رمزگذاری می‌کند. در مهاجرت از HTTP به HTTPS، تمام URLهای قدیمی باید به معادل HTTPS خود هدایت شوند و منابع داخلی نیز با نسخه امن بارگذاری شوند.

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

Canonical، Sitemap، لینک‌های داخلی و تنظیمات ابزارهای تحلیلی نیز باید با نسخه HTTPS هماهنگ شوند. وجود هم‌زمان نسخه‌های قابل دسترسی HTTP و HTTPS می‌تواند مدیریت URLها را پیچیده کند.

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

چگونه ایندکس صفحات سایت را بررسی کنیم؟

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

گزارش Page Indexing در Search Console نمای کلی وضعیت URLها را نشان می‌دهد. URL Inspection نیز اطلاعات جزئی‌تری درباره آخرین خزش، دسترسی، Canonical اعلام‌شده و Canonical انتخابی گوگل  برای هر URL ارائه می‌کند.

محتوای تکراری چه مشکلی ایجاد می‌کند؟

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

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

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

تگ Canonical  چیست چه کاربردی دارد؟

تگ Canonical نسخه ترجیحی را میان صفحات تکراری یا بسیار مشابه معرفی می‌کند. این تگ یک سیگنال است، نه دستور قطعی به گوگل؛ بنابراین گوگل ممکن است با توجه به سایر نشانه‌ها URL دیگری را انتخاب کند. (این صفحات در سرچ کنسول تحت در قسمت PAGES  تحت گزارش Alternate page with proper canonical tag   در دسترس هستند)

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

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

کنیبالیزیشن چه ارتباطی با سئو تکنیکال دارد؟

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

ابتدا باید Intent یا هدف کابر از جستجو، محتوای صفحات، جایگاه آن‌ها در معماری سایت و عبارت‌هایی که برایشان Impression گرفته‌اند بررسی شود. سپس می‌توان میان حفظ، تفکیک، ادغام یا بازطراحی صفحات تصمیم گرفت.

زامبی پیج‌ چیست و با آن چه کنیم؟

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

پس از ارزیابی می‌توان صفحه را بهبود داد، با محتوای دیگری ادغام کرد، noindex کرد یا با پاسخ مناسب حذف کرد.

مرحله پنجم: درک محتوا توسط گوگل و بهینه‌سازی نرخ تبدیل

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

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

Structured Data محتوای ضعیف را به محتوای خوب تبدیل نمی‌کند و نمایش Rich Result را نیز تضمین نمی‌کند. اطلاعات نشانه‌گذاری‌شده باید با محتوای قابل مشاهده صفحه هماهنگ باشند.

اعتبار این داده‌های نشانه گذاری شده را می‌توان با Rich Results Test و Schema Markup Validator بررسی کرد. بااین‌حال، معتبر‌بودن آن فقط بخشی از کنترل است؛ تطابق داده با صفحه و رعایت دستورالعمل‌های نوع نتیجه نیز باید ارزیابی شود. راهنمای رسمی Structured Data جزئیات بیشتری ارائه می‌کند.

Hreflang چست و چه زمانی استفاده از آن لازم است؟

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

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

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

مرحله ششم: آنالیز سئو تکنیکال و اصلاح خطاها

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

هیچ ابزار سئو تکنیکالی به تنهایی تمام مشکلات سایت را نشان نمی‌دهد. ابزارها براساس منبع داده و نوع بررسی در چند گروه قرار می‌گیرند:

• Search Console برای داده‌های مستقیم گوگل؛
• خزنده سایت برای معماری، لینک‌ها و پاسخ URLها؛
• DevTools و ابزارهای رندر برای منابع و JavaScript؛
• PageSpeed Insights و Lighthouse برای عملکرد؛
• Rich Results Test برای داده ساختاریافته؛
• لاگ سرور برای مشاهده درخواست واقعی خزنده‌ها؛
• ابزارهای آنالیتیکس برای رفتار کاربران.

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

فرآیند آنالیز سئو تکنیکال

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

هدف از بررسی را مشخص کنید

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

مشکل تکنیکال  را با داده‌های موجود پیدا کنید

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

خطا را با ابزار دوم تأیید کنید

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

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

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

منطق ارزش و فایده را اجرا کنید

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

مسئول اجرا را مشخص کنید

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

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

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

مسئول سئو تکنیکال چه کسی است؟

سئو تکنیکال معمولاً یک مسئول واحد برای تمام مراحل ندارد. کارشناس سئو مسئله را شناسایی و اولویت‌بندی می‌کند، اما اجرای آن ممکن است میان چند نقش تقسیم شود:

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

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

چک‌لیست سئو تکنیکال

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

کشف URlها توسط گوگل

1. آیا صفحات مهم لینک داخلی قابل خزش دارند؟
2. آیا URLهای اصلی در Sitemap قرار گرفته‌اند؟
3. آیا صفحه یتیم باارزشی وجود دارد؟

دسترسی ربات‌ها به صفحات

4. آیا robots.txt مسیر مهمی را مسدود کرده است؟
5. آیا Googlebot می‌تواند منابع اصلی را دریافت کند؟
6. آیا دستور noindex ناخواسته وجود دارد؟

پاسخ سرور به درخواست

7. آیا صفحات قابل ایندکس پاسخ 200 دارند؟
8. آیا ریدایرکت‌ها مستقیماً به مقصد نهایی می‌رسند؟
9. آیا خطاهای 404، 410 و 5xx متناسب با وضعیت واقعی هستند؟
10. آیا حلقه یا زنجیره ریدایرکت وجود دارد؟

رندر صفحات

11. آیا محتوای اصلی در نسخه رندرشده دیده می‌شود؟
12. آیا لینک‌ها ساختار قابل خزش دارند؟
13. آیا فایل‌های JavaScript و CSS ضروری مسدود نیستند؟

ایندکس URLها

14. آیا صفحات مهم برای ایندکس واجد شرایط‌اند؟
15. آیا Canonical اعلام‌شده و انتخابی گوگل هماهنگ‌اند؟
16. آیا Sitemap فقط URLهای اصلی را شامل می‌شود؟

بررسی نسخه‌های تکراری

17. آیا پارامترها و فیلترها URLهای کم‌ارزش ایجاد کرده‌اند؟
18. آیا سیگنال‌های Canonical، Sitemap و لینک داخلی یک مقصد را معرفی می‌کنند؟
19. آیا ادغام یا تفکیک صفحات براساس Intent انجام شده است؟

ارزیابی تجربه صفحه

20. آیا نسخه موبایل محتوای اصلی را نمایش می‌دهد؟
21. آیا LCP، INP و CLS در داده میدانی بررسی شده‌اند؟
22. آیا Mixed Content یا منابع ناامن وجود دارد؟

درک محتوا

23. آیا داده‌های ساختاریافته با محتوای صفحه هماهنگ است؟
24. آیا نوع Schema با دستورالعمل‌های گوگل سازگار است؟
25. آیا Hreflangها متقابل و مربوط به نسخه‌های معادل‌اند؟

پایش مداوم

26. آیا مشکل با ابزار دوم تأیید شده است؟
27. آیا URLهای درگیر دسته‌بندی و اولویت‌بندی شده‌اند؟
28. آیا مسئول اجرا و معیار پذیرش مشخص است؟
29. آیا پس از اصلاح، Crawl و آزمایش مجدد انجام شده است؟

در نهایت، سئو تکنیکال را از کجا شروع کنیم؟

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

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

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

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

سؤال‌های کاربران دوره سئوپلاس درباره سئو تکنیکال

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

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

آیا سئوکار باید برنامه‌نویسی بداند؟

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

تفاوت Crawl و Index چیست؟

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

آیا robots.txt می‌تواند صفحه را از نتایج حذف کند؟

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

آیا خطای ۴۰۴ به رتبه کل سایت آسیب می‌زند؟

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

Canonical بهتر است یا ریدایرکت؟

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

هر چند وقت یک‌بار باید ممیزی فنی انجام دهیم؟

زمان ثابت و یکسانی برای تمام سایت‌ها وجود ندارد. اندازه سایت، سرعت انتشار، تغییرات فنی، مهاجرت و مشاهده افت می‌توانند زمان بررسی را تعیین کنند.

آیا AMP هنوز ضروری است؟

خیر. AMP الزام عمومی برای رتبه‌گیری نیست. انتخاب آن باید براساس نیاز فنی و تجربه کاربر انجام شود.

آیا امتیاز کامل PageSpeed باعث رتبه بهتر می‌شود؟

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

از کجا بفهمیم مشکل فنی رفع شده است؟

باید همان شاخصی را که مشکل را نشان داده بود دوباره بررسی کنید. پاسخ سرور، Crawl، HTML رندرشده، URL Inspection و داده‌های قبل و بعد می‌توانند اجرای اصلاح را تأیید کنند.

منابع