پرش به محتوا
سئو

سئو تکنیکال

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

  • کنترل خزش
  • ایندکس‌پذیری صفحه‌ها
  • canonical و نسخه‌های تکراری
معرفی خدمت

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

سئو تکنیکال (Technical SEO) بخشی از سئو است که با کد، سرور و ساختار سایت سروکار دارد، نه با متن صفحه‌ها. سؤال اصلی آن ساده است: آیا گوگل می‌تواند به صفحه‌های مهم برسد، محتوای آن‌ها را کامل ببیند و نسخه درست هر صفحه را در نتایج نشان دهد؟

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

چالش‌ها

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

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

  • در گزارش صفحه‌های سرچ کنسول، آدرس‌های زیادی با وضعیت «Crawled - currently not indexed» یا «Discovered - currently not indexed» مانده‌اند.

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

  • بعد از تغییر قالب یا انتقال سایت، آدرس‌های قدیمی خطای 404 می‌دهند یا از چند ریدایرکت پشت سر هم عبور می‌کنند.

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

  • محتوای اصلی صفحه با جاوااسکریپت ساخته می‌شود و در HTML اولیه وجود ندارد.

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

آنچه انجام می‌شود

این خدمت شامل چه مواردی است؟

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

  • کنترل خزش

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

  • ایندکس‌پذیری صفحه‌ها

    بررسی متاتگ robots و هدر X-Robots-Tag و یافتن علت هر وضعیت در گزارش صفحه‌های سرچ کنسول.

  • canonical و نسخه‌های تکراری

    یکدست کردن نسخه‌های http و https، با و بدون www و اسلش پایانی، و تعیین نسخه مرجع هر صفحه.

  • کدهای وضعیت و ریدایرکت

    رفع خطاهای 404 مهم، تبدیل زنجیره‌ها و حلقه‌های ریدایرکت به یک انتقال مستقیم و استفاده درست از 301 و 302.

  • نقشه سایت XML

    ساخت نقشه‌ای که فقط آدرس‌های قابل‌ایندکس و canonical را شامل شود و ثبت آن در سرچ کنسول.

  • Core Web Vitals

    تحلیل LCP، INP و CLS با داده کاربران واقعی و رفع علت‌ها در تصاویر، فونت‌ها، اسکریپت‌ها و سرور.

  • رندر و جاوااسکریپت

    اطمینان از اینکه محتوا، لینک‌ها و متادیتا در HTML رندرشده برای گوگل در دسترس‌اند.

  • داده ساختاریافته

    پیاده‌سازی و اعتبارسنجی Schema.org با قالب JSON-LD متناسب با نوع صفحه، مثل Organization، Product یا Article.

خزش، ایندکس و رتبه: سه مرحله جدا

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

هر ابزار فنی روی یکی از این مراحل اثر می‌گذارد و نباید به‌جای دیگری به کار برود:

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

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

Core Web Vitals در عمل: LCP، INP و CLS

گوگل تجربه کاربری صفحه را با سه شاخص می‌سنجد. LCP (Largest Contentful Paint) زمان نمایش بزرگ‌ترین عنصر محتوایی در دید اول است. INP (Interaction to Next Paint) که از سال ۲۰۲۴ جایگزین FID شد، سرعت پاسخ صفحه به کلیک، لمس و تایپ کاربر را در طول کل بازدید می‌سنجد. CLS (Cumulative Layout Shift) میزان جابه‌جایی ناخواسته عناصر هنگام بارگذاری را نشان می‌دهد.

ملاک گوگل داده میدانی کاربران واقعی است که در گزارش Core Web Vitals سرچ کنسول و بخش بالای PageSpeed Insights دیده می‌شود، نه فقط نمره آزمایشگاهی Lighthouse. به همین دلیل گاهی نمره آزمایشگاهی بالاست اما سرچ کنسول مشکل گزارش می‌کند، یا برعکس.

علت‌هایی که در کار فنی بیشتر با آن‌ها روبه‌رو می‌شویم:

  • تصویر اصلی بالای صفحه که دیر کشف می‌شود، حجم زیادی دارد یا به‌اشتباه lazy-load شده است
  • اسکریپت‌های سنگین شخص ثالث مثل چت آنلاین، ابزارهای تحلیلی و پیکسل‌های تبلیغاتی که رشته اصلی مرورگر را اشغال می‌کنند
  • تصاویر، بنرها و جایگاه‌های تبلیغ بدون ابعاد مشخص، و فونت‌هایی که هنگام بارگذاری چیدمان را تغییر می‌دهند
  • پاسخ کند سرور (TTFB) به‌دلیل هاست ضعیف، نبود کش یا کوئری‌های سنگین پایگاه داده

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

سایت‌های جاوااسکریپتی و مسئله رندر

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

در بررسی فنی، HTML اولیه را با نسخه رندرشده در URL Inspection مقایسه می‌کنیم و این موارد را می‌سنجیم:

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

راه‌حل معمول، رندر سمت سرور (SSR) یا تولید ایستا (SSG) برای صفحه‌هایی است که باید ایندکس شوند. اگر سایت در حال بازسازی است، این تصمیم باید پیش از شروع توسعه گرفته شود، نه بعد از انتشار.

اشتباهاتی که خودشان مشکل فنی می‌سازند

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

  • انتشار نسخه آزمایشی (Staging) بدون محافظت که ایندکس می‌شود، یا برعکس، منتقل شدن تنظیم noindex نسخه آزمایشی به سایت اصلی
  • قرار دادن همه آدرس‌ها، از جمله صفحه‌های ریدایرکت‌شده و noindex، در نقشه سایت
  • مسدود کردن فایل‌های CSS و JS در robots.txt که مانع رندر درست صفحه برای گوگل می‌شود
  • ریدایرکت همه آدرس‌های حذف‌شده به صفحه اصلی، به‌جای مرتبط‌ترین صفحه جایگزین
  • افزودن داده ساختاریافته برای اطلاعاتی که در خود صفحه به کاربر نمایش داده نمی‌شود
  • کپی کردن دستورهای قدیمی مثل Host در robots.txt که گوگل از آن پشتیبانی نمی‌کند

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

عوامل مؤثر بر هزینه و زمان کار فنی

برآورد کار فنی بدون دیدن سایت ممکن نیست، چون حجم آن به ماهیت مشکلات بستگی دارد. عوامل اصلی:

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

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

مراحل کار

روند اجرای پروژه

  1. 01

    خزش و تشخیص اولیه

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

  2. 02

    یافتن علت ریشه‌ای

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

  3. 03

    نوشتن تیکت‌های اجرایی

    هر تغییر با شرح دقیق، آدرس‌های نمونه و معیار پذیرش نوشته می‌شود تا برنامه‌نویس بدون ابهام اجرا کند.

  4. 04

    آزمون روی نسخه آزمایشی

    در صورت امکان، تغییرات ابتدا روی Staging اعمال و از نظر رندر، ریدایرکت و ایندکس‌پذیری آزموده می‌شوند.

  5. 05

    انتشار و بررسی آدرس‌های کلیدی

    پس از انتشار، نقشه سایت به‌روز و آدرس‌های مهم با URL Inspection بررسی می‌شوند.

  6. 06

    راستی‌آزمایی در سرچ کنسول

    تغییر وضعیت صفحه‌ها و Core Web Vitals در دوره‌های بعدی دنبال می‌شود تا از رفع واقعی مشکل مطمئن شویم.

مخاطبان این خدمت

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

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

انواع کسب‌وکار
  • فروشگاه‌های اینترنتی بزرگ
  • سایت‌های ساخته‌شده با React
  • سایت‌های خبری و محتوایی
  • پلتفرم‌های آگهی و فهرست
  • سایت‌های وردپرسی قدیمی

چه زمانی سراغ این خدمت بیایید؟

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

در پایان چه چیزی دریافت می‌کنید؟

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

فهرست تحویلی — سئو تکنیکال

4 مورد
  • فهرست تیکت‌های فنی

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

  • فایل‌های پیکربندی

    نسخه نهایی robots.txt، ساختار نقشه سایت و قواعد ریدایرکت، همراه با توضیح کاربرد هر بخش.

  • کدهای داده ساختاریافته

    قطعه‌های JSON-LD برای هر نوع صفحه به همراه نتیجه اعتبارسنجی در Rich Results Test.

  • گزارش پیش و پس از تغییرات

    مقایسه وضعیت ایندکس، خطاهای خزش و Core Web Vitals قبل و بعد از اجرای تغییرات.

پرسش و پاسخ

سؤال‌های متداول

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

سئو تکنیکال با سئو داخلی چه فرقی دارد؟
سئو تکنیکال به زیرساخت می‌پردازد: دسترسی ربات، ایندکس، سرعت، کد و سرور. سئو داخلی روی محتوای هر صفحه کار می‌کند: عنوان، سرتیترها، متن و لینک‌ها. این دو مکمل هم‌اند و در مواردی مثل داده ساختاریافته کمی هم‌پوشانی دارند.
چرا صفحه‌ای که ایراد فنی ندارد ایندکس نمی‌شود؟
ایندکس نشدن همیشه مشکل فنی نیست. گوگل ممکن است صفحه را دیده باشد اما آن را کم‌ارزش یا بسیار شبیه صفحه‌های دیگر بداند و نگه ندارد. در این حالت راه‌حل در بهبود محتوا و لینک‌دهی داخلی است، نه در تنظیمات فنی.
آیا گرفتن نمره کامل در PageSpeed Insights لازم است؟
خیر. نمره آزمایشگاهی ابزاری برای عیب‌یابی است و خودش عامل رتبه نیست. آنچه اهمیت دارد وضعیت شاخص‌های Core Web Vitals برای کاربران واقعی است؛ دنبال کردن نمره کامل گاهی به حذف امکانات مفید سایت منجر می‌شود.
آیا سایت فارسی به hreflang نیاز دارد؟
اگر سایت فقط یک نسخه فارسی دارد، نه. hreflang برای سایت‌هایی است که از یک صفحه نسخه‌های زبانی یا منطقه‌ای متفاوت دارند، مثلاً فارسی و انگلیسی؛ در آن صورت باید دوطرفه و دقیق پیاده‌سازی شود.
آیا برای اجرای تغییرات به برنامه‌نویس سایت نیاز است؟
برای بیشتر تغییرات فنی، دسترسی به کد و پنل مدیریت یا همکاری با کسی که این دسترسی را دارد لازم است. اگر برنامه‌نویس خودتان را دارید، تغییرات مستند و پس از اجرا بررسی می‌شوند.
شروع همکاری

برای شروع سئو تکنیکال، درباره پروژه‌تان صحبت کنیم

اطلاعات اولیه پروژه را ارسال کنید تا نیازها و شرایط آن بررسی شود.