سئو تکنیکال چیست؟ چک‌لیست ۱۸ مورد Technical SEO

وقتی یک سایت رشد نمی‌کند، خیلی وقت‌ها اولین پیشنهاد این است که محتوای بیشتری منتشر شود یا بودجه Link Building بالا برود.

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

ممکن است Googlebot نتواند بخشی از سایت را درست Crawl کند، صفحات مهم Canonical اشتباه داشته باشند، JavaScript محتوای اصلی را دیر یا ناقص Render کند، Redirect Chain ایجاد شده باشد یا URLهای فیلترشده هزاران صفحه کم‌ارزش بسازند.

اینجاست که سئو تکنیکال یا Technical SEO اهمیت پیدا می‌کند.

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

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

Technical SEO مجموعه اقدام‌هایی است که کمک می‌کنند موتور جستجو بتواند سایت را به‌درستی Crawl، Render، Index و درک کند.

موضوعات Technical SEO معمولاً به زیرساخت سایت مربوط‌اند: Status Code، Robots، Sitemap، Canonical، Rendering، Redirect، Structured Data، Mobile Experience، Core Web Vitals، معماری URL و مدیریت Duplicateها.

این بخش با On-page SEO تفاوت دارد.

در سئو داخلی بیشتر روی خود صفحه، Intent، Title، Heading، Content و Internal Linking تمرکز می‌کنیم. در Technical SEO سؤال این است که آیا زیرساخت سایت اجازه می‌دهد همان صفحه به‌درستی توسط Search Engine پردازش شود یا نه.

برای مثال ممکن است بهترین مقاله دنیا را نوشته باشید اما اگر URL آن noindex باشد، در Search ظاهر نمی‌شود.

چرا Technical SEO باید قبل از Link Building بررسی شود؟

Backlink می‌تواند به Discovery، Authority و رقابت کمک کند، اما مشکل Crawl یا Indexation را به‌طور جادویی حل نمی‌کند.

اگر صفحه اصلی خدمت به URL دیگری Canonical شده، خرید لینک برای آن URL تصمیم درستی نیست.

اگر سایت هزاران URL تکراری از Filter تولید می‌کند، بخشی از Crawl روی صفحات کم‌ارزش مصرف می‌شود.

اگر Redirect Chain دارید، Link Equity و تجربه کاربر بین چند Hop بی‌دلیل عبور می‌کنند.

بنابراین قبل از Off-page، حداقل باید مطمئن شویم Foundation فنی سایت سالم است.

۱. مطمئن شوید صفحات مهم قابل Crawl هستند

اولین سؤال ساده است: Googlebot اصلاً می‌تواند URLهای مهم را دریافت کند؟

Server پاسخ معتبر می‌دهد.
Firewall یا CDN به‌اشتباه Googlebot را Block نمی‌کند.
Robots.txt مسیر مهم را مسدود نکرده است.
صفحه پشت Login یا IP Restriction غیرضروری نیست.
Resourceهای لازم برای Rendering بی‌دلیل Block نشده‌اند.

برای نمونه URLهای مهم، URL Inspection در Search Console و بررسی Server Log می‌توانند تصویر واقعی‌تری از Crawl بدهند.

۲. Status Codeها باید معنی درست داشته باشند

HTTP Status Code فقط یک عدد فنی نیست؛ به Crawler می‌گوید چه اتفاقی برای URL افتاده است.

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

یکی از مشکلات رایج Soft 404 است؛ یعنی صفحه‌ای که عملاً محتوایی ندارد اما هنوز Status 200 می‌دهد.

Google در مستندات Crawl تأکید می‌کند که Status Code روی نحوه پردازش URL اثر دارد و حتی Rendering JavaScript برای پاسخ‌های non-200 ممکن است انجام نشود.

۳. robots.txt را با noindex اشتباه نگیرید

robots.txt برای کنترل Crawling استفاده می‌شود، نه برای حذف قطعی URL از Index.

اگر URL قبلاً شناخته شده باشد، Block کردن Crawl الزاماً به معنی حذف فوری آن از Search نیست.

برای اینکه صفحه Index نشود، معمولاً باید Crawler بتواند صفحه را دریافت کند و Directiveهایی مثل noindex را ببیند.

robots.txt باید هدف مشخص داشته باشد: جلوگیری از Crawl مسیرهایی که واقعاً لازم نیست Crawler روی آن‌ها وقت بگذارد.

۴. XML Sitemap باید تمیز باشد

Sitemap قرار نیست آرشیو تمام URLهایی باشد که سایت در طول عمرش ساخته است.

URL باید Canonical باشد.
قابل Index باشد.
Status 200 داشته باشد.
واقعاً بخواهید در Search حضور داشته باشد.

قرار دادن Redirect، 404، noindex و Duplicate داخل Sitemap سیگنال‌های متناقض ایجاد می‌کند.

۵. Indexation را با تعداد صفحه بیشتر اشتباه نگیرید

هدف SEO این نیست که Google بیشترین تعداد URL ممکن را Index کند. هدف این است که URLهای درست Index شوند.

صفحات مهمی که باید Index باشند اما نیستند.
صفحات کم‌ارزشی که نباید Index باشند اما هستند.
صفحاتی که وضعیت آن‌ها مبهم یا Duplicate است.

اگر هنوز وضعیت Indexation روشن نیست، SEO Audit نقطه شروع مناسب‌تری است.

۶. Canonical را روی صفحات مهم بررسی کنید

Canonical به Google کمک می‌کند میان URLهای مشابه، نسخه ترجیحی را تشخیص دهد.

صفحات مستقل Self-canonical صحیح دارند.
Canonical به Redirect یا 404 اشاره نمی‌کند.
Template سایت همه صفحات را به Home canonical نکرده است.
Canonical بین HTTP/HTTPS یا www/non-www متناقض نیست.
Sitemap و Internal Link به نسخه Canonical اشاره می‌کنند.

یک خطای Canonical روی صفحه مهم می‌تواند تمام برنامه Content و Link Building آن URL را زیر سؤال ببرد.

۷. Duplicate URLها را جدی بگیرید

Duplicate Content همیشه به معنی Penalty نیست، اما URLهای تکراری می‌توانند Crawl و سیگنال‌های سایت را پیچیده کنند.

نسخه با و بدون Slash.
پارامترهای Tracking.
Sort و Filter.
Print Version.
HTTP و HTTPS.
www و non-www.
صفحات Tag یا Archive بسیار مشابه.

هدف این است که هر Intent اصلی یک URL روشن و پایدار داشته باشد.

۸. Redirectها باید کوتاه و هدفمند باشند

وقتی URL تغییر می‌کند، Redirect دائمی معمولاً بهترین راه انتقال کاربر و Crawler به مقصد جدید است.

A → B → C → D

اگر مقصد واقعی D است، بهتر است A مستقیماً به D برود. Redirect Loop هم باید سریع پیدا و اصلاح شود.

۹. JavaScript Rendering را تست کنید

Google سال‌هاست JavaScript را Render می‌کند، اما این به معنی آن نیست که هر معماری JavaScript بدون بررسی SEO است.

Main Content بعد از Render وجود دارد.
Internal Linkها Anchor واقعی دارند.
Canonical قبل و بعد از Render متناقض نیست.
Meta Robots با JavaScript تغییر خطرناک نمی‌کند.
non-200 Response مانع Rendering نشده است.

Google در مستندات اخیر روی Canonical و noindex در صفحات JavaScript جزئیات بیشتری اضافه کرده است؛ بنابراین این بخش باید در Auditهای جدید جدی گرفته شود.

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

حتی اگر URL از نظر فنی Crawlable باشد، معماری ضعیف می‌تواند آن را از مسیر طبیعی سایت خارج کند.

Home → Service Category → Service Page → Supporting Content

صفحه‌ای که فقط از Sitemap قابل پیدا شدن است اما هیچ Internal Link طبیعی ندارد، عملاً در معماری سایت حضور ضعیفی دارد.

۱۱. URL Structure باید پایدار باشد

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

/services/seo-services

از /page?id=8723&cat=41 واضح‌تر است.

مهم‌تر از زیبایی URL، ثبات آن است. تغییر مداوم Slugها بدون Redirect درست می‌تواند History و لینک‌های قدیمی را از بین ببرد.

۱۲. Mobile نسخه فرعی سایت نیست

در Review فنی بررسی کنید:

Main Content روی Mobile کامل است.
Navigation قابل استفاده است.
CTAها خارج از Viewport نیستند.
Horizontal Overflow وجود ندارد.
تصاویر و جدول‌ها Layout را نمی‌شکنند.
Interactive Elementها قابل استفاده‌اند.

۱۳. HTTPS و Redirect نسخه‌ها باید تمیز باشد

تمام نسخه‌های سایت باید به یک نسخه اصلی برسند: HTTP/HTTPS و www/non-www نباید چهار نسخه مستقل بسازند.

یک نسخه Canonical انتخاب کنید و بقیه را با Redirect دائمی به آن برسانید. Mixed Content و Certificate Error هم باید اصلاح شوند.

۱۴. Core Web Vitals را با نمره ۱۰۰ اشتباه نگیرید

Google در حال حاضر Core Web Vitals را بخشی از Page Experience می‌داند و از LCP، INP و CLS برای ارزیابی تجربه واقعی کاربر استفاده می‌شود.

اما خود Google صریحاً می‌گوید گرفتن Score خوب تضمین رتبه بالا نیست و تلاش برای Perfect Score صرفاً برای SEO ممکن است بهترین استفاده از زمان نباشد.

LCP بد: Hero Image، Server Response یا Render Path.
CLS بد: Image بدون Dimensions یا Componentهای دیرهنگام.
INP بد: JavaScript سنگین یا Main Thread طولانی.

۱۵. Structured Data باید واقعی و معتبر باشد

Schema به Search Engine کمک می‌کند نوع و ساختار اطلاعات صفحه را بهتر بفهمد.

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

Google فهرست مشخصی از Structured Dataهای پشتیبانی‌شده دارد و این فهرست در طول زمان تغییر می‌کند.

۱۶. Hreflang برای سایت چندزبانه باید درست پیاده‌سازی شود

URL مقصد 404 نباشد.
Reference دوطرفه باشد.
Language Code معتبر باشد.
Canonical و Hreflang با هم تضاد نداشته باشند.
نسخه Language دیگری Redirect نشود.

فروشگاه‌ها و سایت‌های فیلترمحور می‌توانند با ترکیب Filterها هزاران یا میلیون‌ها URL بسازند.

رنگ + سایز + برند + قیمت + Sort

کدام Filterها Search Demand واقعی دارند.
کدام URLها باید Index شوند.
کدام‌ها فقط برای UX هستند.
Navigation چگونه Crawl کنترل می‌شود.

Google برای Faceted Navigation راهنمای جداگانه دارد؛ این موضوع در سایت‌های بزرگ یکی از بخش‌های مهم Technical SEO است.

۱۸. Search Console و Logها را برای Debug استفاده کنید

Technical SEO فقط Checklist نیست؛ Debugging است.

Search Console می‌تواند برای Indexing، Sitemap، Core Web Vitals، Structured Data و URL Inspection استفاده شود. Server Log هم نشان می‌دهد Botها در عمل کدام URLها را Crawl کرده‌اند.

Googlebot وقتش را کجا مصرف می‌کند.
کدام URLهای مهم کم Crawl می‌شوند.
آیا Error Rate بالا رفته است.
بعد از Deploy رفتار Crawl تغییر کرده یا نه.

کدام مشکلات قبل از لینک‌سازی P0 هستند؟

همه خطاهای Technical اهمیت یکسان ندارند.

صفحه مهم قابل Crawl نیست.
صفحه مهم noindex است.
Canonical به URL اشتباه اشاره می‌کند.
URL اصلی 4xx یا 5xx می‌دهد.
Redirect Loop یا Chain شدید وجود دارد.
Main Content بعد از Rendering در دسترس نیست.
Migration بدون Redirect Mapping انجام شده است.
نسخه Mobile محتوای اصلی را ندارد.

این همان منطقی است که در SEO Audit استفاده می‌شود: Priority مهم‌تر از تعداد Issueهاست.

Technical SEO چه چیزهایی نیست؟

سبز کردن تمام چراغ‌های Plugin.
گرفتن Score 100 در PageSpeed.
ساخت XML Sitemap و تمام.
اضافه کردن Schema به همه صفحات.
نوشتن robots.txt طولانی.

Technical SEO یعنی زیرساخت Search سایت با Architecture واقعی کسب‌وکار هماهنگ باشد.

برای یک سایت کوچک هم Technical SEO لازم است؟

بله، اما Scope متفاوت است.

Status Code درست داشته باشد.
Canonical سالم باشد.
Sitemap تمیز باشد.
Indexation کنترل شود.
Mobile و Performance قابل قبول باشند.

استفاده از Enterprise Checklist روی سایت کوچک فقط Noise ایجاد می‌کند.

بعد از Technical SEO چه کار کنیم؟

اصلاح سئو داخلی صفحات
ساخت Content Cluster
بهبود صفحات Service
Internal Linking
Link Building
Digital PR

اگر نمی‌دانید مشکل اصلی Technical است یا Content، از خدمات SEO و رشد ویرینو یا Audit ساختاریافته شروع کنید تا Backlog براساس Impact واقعی ساخته شود.

چک‌لیست نهایی Technical SEO

Crawlability صفحات مهم.
HTTP Status Code صحیح.
robots.txt بدون Block اشتباه.
XML Sitemap تمیز.
Indexation کنترل‌شده.
Canonical صحیح.
Duplicate URL Management.
Redirect بدون Chain و Loop.
JavaScript Rendering سالم.
Site Architecture منطقی.
URL Structure پایدار.
Mobile Content کامل.
HTTPS و Host Redirect صحیح.
Core Web Vitals.
Structured Data معتبر.
Hreflang صحیح در سایت چندزبانه.
Faceted Navigation کنترل‌شده.
Search Console و Log-based Debugging.

جمع‌بندی

سئو تکنیکال قرار نیست سایت را با تنظیمات پیچیده‌تر کند؛ قرار است موانع فنی بین محتوای خوب و Search Engine را حذف کند.

قبل از Link Building باید مطمئن شوید صفحات اصلی Crawlable، Indexable، Canonical و پایدار هستند.

بعد از آن، Technical SEO وارد مرحله Optimization می‌شود: Performance، Rendering، Structured Data، Architecture و Crawl Efficiency.

Google در اکتبر ۲۰۲۶ مسیر آموزشی رسمی جداگانه‌ای برای Technical SEO منتشر کرده که تمرکز آن روی Crawl Directives، Indexing Debugging، Rendering و Infrastructure است.

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

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