سئو تکنیکال چیست؟ راهنمای کامل بهینه‌سازی فنی و عیب‌یابی سایت

سئو تکنیکال یا Technical SEO مجموعه‌ای از بررسی‌ها و بهینه‌سازی‌های فنی است که کمک می‌کند موتورهای جستجو بتوانند URLهای مهم سایت را پیدا کنند، Crawl کنند، محتوای آن‌ها را به‌درستی Render کنند و در صورت مناسب بودن برای Index پردازش کنند.

اما هدف Technical SEO گرفتن امتیاز ۱۰۰ از ابزارهای Audit نیست. ممکن است سایتی ده‌ها Warning جزئی داشته باشد و صفحات مهم آن بدون مشکل در Search حضور داشته باشند؛ در مقابل، یک Canonical اشتباه، Noindex ناخواسته یا Redirect نادرست می‌تواند یک صفحه تجاری مهم را عملاً از نتایج خارج کند.

بنابراین سئو فنی را بهتر است به‌عنوان یک مسیر عیب‌یابی ببینیم:

Discovery → Crawl → Render → Index → Canonicalization → Architecture → Performance → Validation → Monitoring

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

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

Crawlability، Indexability و Ranking را با هم اشتباه نگیرید

بخش زیادی از خطاهای تحلیل Technical SEO از جایی شروع می‌شود که Crawl، Index و Ranking به‌عنوان یک مفهوم در نظر گرفته می‌شوند.

در حالی که این‌ها سه مرحله متفاوت هستند.

Discovery؛ موتور جستجو ابتدا باید URL را پیدا کند

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

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

Crawlability؛ آیا ربات می‌تواند URL را دریافت کند؟

Crawlability یعنی موتور جستجو بتواند URL را درخواست و Response آن را دریافت کند.

Robots.txt، مشکلات DNS، محدودیت‌های Server، خطاهای 5xx، Redirect Loop یا بعضی تنظیمات امنیتی می‌توانند روی Crawl تأثیر بگذارند.

اما قابل Crawl بودن به معنی Index شدن نیست.

Indexability؛ آیا URL شرایط ورود به Index را دارد؟

URL ممکن است با Status Code 200 در دسترس باشد و کاملاً Crawl شود، اما به دلایلی وارد Index نشود یا URL دیگری به‌عنوان Canonical آن انتخاب شود.

برای مثال:

• صفحه دارای Meta Robots با مقدار noindex است.
• Canonical آن به URL دیگری اشاره می‌کند.
• محتوا Duplicate یا بسیار مشابه URL دیگری تشخیص داده شده است.
• صفحه کیفیت یا ارزش کافی برای Index شدن ندارد.
• Google URL دیگری را Canonical انتخاب کرده است.

پس دریافت پاسخ 200 فقط به این معنی نیست که «همه چیز درست است».

Ranking؛ Index شدن تضمین رتبه نیست

حتی اگر URL Crawl و Index شود، هنوز مرحله Ranking باقی مانده است.

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

به همین دلیل Technical SEO معمولاً شرط لازم برای عملکرد مناسب صفحات است، نه تضمین‌کننده رتبه.

به‌صورت خلاصه:

Crawlable ≠ Indexed ≠ Ranking

همچنین مشکلات مربوط به عنوان، Heading، محتوا و Search Intent بیشتر وارد حوزه On-Page SEO می‌شوند. مهم است در Audit فنی، مشکل Content را با مشکل Crawl یا Index اشتباه نگیریم.

کنترل Crawl و Index؛ از Robots.txt تا Canonical و Status Code

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

Robots.txt، Noindex و Sitemap چه تفاوتی دارند؟

این سه ابزار کاربردهای متفاوتی دارند و نباید جای یکدیگر استفاده شوند.

ابزار	کاربرد اصلی	نکته مهم
robots.txt	کنترل Crawl برخی مسیرها توسط Crawlerها	ابزار مستقیمی برای حذف URL از Index نیست
Meta Robots / X-Robots-Tag	کنترل Index و نحوه نمایش Resource	برای خوانده شدن noindex، Crawler باید بتواند Resource را Crawl کند
XML Sitemap	معرفی URLهای مهم و کمک به Discovery	وجود URL در Sitemap تضمین Crawl یا Index نیست

Robots.txt دقیقاً چه کاری انجام می‌دهد؟

فایل robots.txt بیشتر برای مدیریت دسترسی Crawlerها به مسیرهای سایت استفاده می‌شود.

یکی از اشتباهات رایج این است که تصور کنیم:

Disallow در robots.txt = Noindex

این برداشت درست نیست.

اگر هدف شما این است که یک صفحه قابل دسترس باشد اما در Search نمایش داده نشود، معمولاً Meta Robots با دستور noindex یا در Resourceهای غیر HTML، X-Robots-Tag ابزار مناسب‌تری است.

نکته مهم‌تر اینکه اگر URL را با robots.txt از Crawl مسدود کنید، Crawler ممکن است اصلاً نتواند Meta Robots موجود در همان صفحه را ببیند.

به همین دلیل ترکیب تصادفی robots.txt و noindex یکی از خطاهای رایج Technical SEO است.

Meta Robots و X-Robots-Tag

برای یک صفحه HTML می‌توان از Meta Robots استفاده کرد. برای مثال، noindex به موتور جستجو اعلام می‌کند این Resource نباید در نتایج نمایش داده شود.

X-Robots-Tag همین نوع کنترل را در HTTP Header فراهم می‌کند و برای فایل‌هایی مانند PDF نیز کاربرد دارد؛ یعنی Resourceهایی که الزاماً HTML و تگ Meta ندارند.

قبل از اعمال noindex روی Template، دسته‌بندی یا گروه بزرگی از URLها باید دقیقاً بررسی شود که چه صفحاتی تحت تأثیر قرار می‌گیرند. یک تنظیم اشتباه در CMS می‌تواند تعداد زیادی URL مهم را از Index خارج کند.

XML Sitemap چه نقشی دارد؟

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

اما Sitemap دستور Index نیست.

قرار دادن یک URL در XML Sitemap به معنی این نیست که Google حتماً آن را Crawl یا Index خواهد کرد.

در Sitemap بهتر است URLهای اصلی و قابل Index قرار بگیرند؛ نه صفحاتی که Redirect می‌شوند، 404 هستند، noindex شده‌اند یا Canonical آن‌ها به مقصد دیگری اشاره می‌کند.

وجود Sitemap سالم نیز جایگزین معماری مناسب و Internal Linking نمی‌شود.

HTTP Status Codeها در Technical SEO چه معنایی دارند؟

Status Code یکی از اولین سیگنال‌هایی است که Crawler هنگام درخواست URL دریافت می‌کند. بنابراین قبل از تحلیل محتوا یا Meta Data باید مطمئن شوید Response فنی URL منطقی است.

Status	معنا	کاربرد و اثر عملی
200	Success	محتوا برای پردازش ارسال می‌شود، اما Index شدن همچنان تضمین نیست
301	Permanent Redirect	برای انتقال دائمی URL و ارسال سیگنال قوی به مقصد جدید
302	Temporary Redirect	برای تغییر موقت؛ مقصد به‌عنوان سیگنال ضعیف‌تری برای جایگزینی URL در نظر گرفته می‌شود
404	Not Found	URL موردنظر وجود ندارد و در صورت Index بودن، به‌مرور از Index خارج می‌شود
410	Gone	به‌صورت معنایی اعلام می‌کند Resource عمداً و دائماً حذف شده است
5xx	Server Error	خطای Server؛ تکرار گسترده یا طولانی آن می‌تواند Crawl را کاهش دهد

200 همیشه خبر خوب نیست

فرض کنید URL محصول حذف‌شده همچنان Status 200 برمی‌گرداند اما داخل صفحه پیام «محصول پیدا نشد» نمایش داده می‌شود.

در این حالت Server می‌گوید Resource موفقیت‌آمیز است، در حالی که محتوای صفحه می‌گوید Resource وجود ندارد. چنین وضعیتی می‌تواند به Soft 404 منجر شود.

بنابراین هنگام Audit فقط ظاهر صفحه را نگاه نکنید؛ Status واقعی HTTP را نیز بررسی کنید.

301 و 302 را بر اساس واقعیت تغییر انتخاب کنید

اگر URL برای همیشه به مقصد دیگری منتقل شده، 301 معمولاً انتخاب منطقی است. اگر تغییر واقعاً موقتی است، 302 کاربرد دارد.

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

مثلاً فرض کنید:

/old-seo-page/

به:

/new-seo-page/

با 301 Redirect شده است.

اگر صدها لینک داخلی هنوز به URL قدیمی اشاره کنند، کاربر و Crawler دائماً یک Hop اضافه طی می‌کنند. Redirect باید برای درخواست‌های قدیمی باقی بماند، اما Internal Linkها بهتر است به مقصد نهایی اصلاح شوند.

Redirect Chain و Redirect Loop

Redirect Chain زمانی ایجاد می‌شود که URL A به B و B به C هدایت شود.

یک Redirect اضافه الزاماً بحران SEO نیست، اما Chainهای طولانی Crawl و عیب‌یابی را پیچیده‌تر می‌کنند و بهتر است در لینک‌های داخلی و Migrationها مقصد نهایی مستقیماً استفاده شود.

Redirect Loop جدی‌تر است؛ مثلاً A به B و B دوباره به A Redirect می‌شود. در این حالت کاربر و Crawler عملاً به مقصد قابل استفاده‌ای نمی‌رسند.

404 یا 410؛ کدام بهتر است؟

اگر URL وجود ندارد، هر دو Status به موتور جستجو نشان می‌دهند Resource در دسترس نیست. انتخاب بین آن‌ها بهتر است بر اساس معنای واقعی وضعیت انجام شود.

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

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

خطاهای 5xx را در اولویت بالا بررسی کنید

خطاهای 500، 502 یا 503 نشان‌دهنده مشکل سمت Server یا زیرساخت هستند.

اگر تعداد زیادی URL مهم مرتباً 5xx برگردانند، فقط کاربران آسیب نمی‌بینند؛ Crawler نیز ممکن است سرعت Crawl را کاهش دهد.

به همین دلیل در یک Technical Audit، خطای گسترده Server معمولاً اولویت بسیار بیشتری از یک Warning کوچک در Meta Description دارد.

Canonical چیست و چه زمانی استفاده می‌شود؟

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

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

اما Canonical یک Hint است؛ یعنی موتور جستجو می‌تواند بر اساس مجموعه سیگنال‌ها URL دیگری را به‌عنوان Canonical انتخاب کند.

Canonical با Redirect چه تفاوتی دارد؟

Redirect کاربر و Crawler را از URL اول به URL دیگری منتقل می‌کند. URL مبدا دیگر صفحه مستقلی برای مصرف‌کننده نیست.

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

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

Canonical اشتباه چگونه یک صفحه مهم را تحت تأثیر قرار می‌دهد؟

فرض کنید صفحه اصلی یک خدمت این URL است:

/seo-service/

صفحه Status 200 دارد، در Sitemap قرار گرفته و لینک‌های داخلی نیز به آن اشاره می‌کنند.

اما در Head صفحه به اشتباه این Canonical قرار گرفته است:

rel="canonical" href="/another-page/"

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

در چنین شرایطی افزایش محتوا یا تغییر Heading قبل از اصلاح Canonical، مشکل اصلی را هدف نمی‌گیرد.

همین منطق نشان می‌دهد چرا در یک استراتژی SEO باید مشکلات بر اساس اثر واقعی آن‌ها اولویت‌بندی شوند، نه تعداد Errorهایی که یک ابزار نمایش می‌دهد.

معماری سایت، Rendering و Performance؛ لایه‌هایی که معمولاً نادیده گرفته می‌شوند

Internal Linking از دید Technical SEO

لینک داخلی فقط برای انتقال Anchor Text یا ارتباط موضوعی استفاده نمی‌شود. Internal Linking یکی از مسیرهای اصلی Discovery و Crawl صفحات سایت است.

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

Crawl Depth

Crawl Depth به‌صورت ساده نشان می‌دهد برای رسیدن از نقطه شروع معماری، مثلاً Homepage، به یک URL چند مرحله لینک لازم است.

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

Orphan Page

Orphan Page صفحه‌ای است که لینک داخلی قابل Crawl مناسبی از سایر صفحات سایت دریافت نمی‌کند.

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

در Audit، URLهای موجود در Sitemap، Analytics، Search Console یا دیتابیس را با URLهای پیدا شده در Crawl مقایسه کنید تا صفحات احتمالی Orphan مشخص شوند.

به Redirect و URLهای خراب لینک داخلی ندهید

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

همچنین لینک‌های داخلی به 404 یا 410 باید بررسی شوند؛ زیرا هم تجربه کاربر را خراب می‌کنند و هم مسیر Crawl بی‌فایده ایجاد می‌کنند.

URL Structure

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

مشکلات مهم‌تر زمانی ایجاد می‌شوند که یک محتوا از تعداد زیادی URL مختلف قابل دسترسی باشد یا Parameterها، Session IDها و Filterها بدون کنترل URLهای بسیار زیادی تولید کنند.

Pagination

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

Pagination نباید باعث شود صفحات بعدی از معماری سایت قطع شوند یا تمام آن‌ها بدون بررسی به صفحه اول Canonical شوند.

هر URL Pagination باید بر اساس نقشی که در Discovery و دسترسی به محتوا دارد بررسی شود.

Faceted Navigation و Parameter URLها

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

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

مشکل اصلی خود Filter نیست؛ باید مشخص شود کدام ترکیب‌ها ارزش Search دارند، کدام‌ها فقط برای UX هستند و برای Crawl، Canonical و Index هر گروه چه سیاستی وجود دارد.

JavaScript SEO و مشکل Rendering

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

در چنین شرایطی ممکن است در Browser خودتان صفحه کاملاً طبیعی دیده شود، اما محتوای Renderشده برای Crawler ناقص باشد.

مواردی که باید بررسی شوند عبارت‌اند از:

• محتوای اصلی صفحه
• Internal Linkها
• Title و Meta Data
• Canonical
• Structured Data
• محتوای Lazy-loaded

برای عیب‌یابی، فقط View Source کافی نیست. باید تفاوت HTML اولیه و DOM نهایی و همچنین نسخه Renderشده‌ای که ابزار Inspection مشاهده می‌کند بررسی شود.

اگر یک JavaScript Application با Status غیر 200 پاسخ دهد، نباید فرض کنید موتور جستجو حتماً JavaScript آن صفحه را اجرا خواهد کرد. Response صحیح Server همچنان اهمیت دارد.

Mobile-first Indexing چه تغییری در Audit ایجاد می‌کند؟

نسخه موبایل فقط نسخه فرعی سایت نیست. Google برای Indexing و Ranking از نسخه موبایلی محتوای سایت استفاده می‌کند.

به همین دلیل باید مطمئن شوید محتوای اصلی، Internal Linkها، Meta Data و اطلاعات مهم در Mobile نیز در دسترس هستند.

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

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

HTTPS

سایت عمومی باید به‌صورت امن روی HTTPS ارائه شود. در Audit بررسی کنید نسخه‌های HTTP به HTTPS منتقل می‌شوند، Mixed Content مهم وجود ندارد و نسخه‌های مختلف Protocol باعث ایجاد Duplicate URL نشده‌اند.

HTTPS را نباید به‌عنوان «ترفند افزایش رتبه» دید؛ در وب امروز بخشی از زیرساخت سالم و امن سایت است.

Core Web Vitals و Performance

Performance فقط به این معنی نیست که یک ابزار به سایت عدد ۹۰ یا ۱۰۰ بدهد.

Core Web Vitals فعلی سه جنبه مهم تجربه واقعی کاربر را بررسی می‌کنند:

• LCP یا Largest Contentful Paint: سرعت نمایش محتوای اصلی؛ مقدار پیشنهادی خوب تا ۲.۵ ثانیه است.
• INP یا Interaction to Next Paint: پاسخ‌گویی صفحه به تعامل کاربر؛ مقدار پیشنهادی خوب ۲۰۰ میلی‌ثانیه یا کمتر است.
• CLS یا Cumulative Layout Shift: ثبات بصری صفحه؛ مقدار پیشنهادی خوب ۰.۱ یا کمتر است.

این معیارها معمولاً در صدک ۷۵ تجربه کاربران ارزیابی می‌شوند.

اما بهبود Core Web Vitals به‌تنهایی رتبه را تضمین نمی‌کند. Performance را باید هم به‌عنوان بخشی از تجربه کاربر و هم به‌عنوان یکی از لایه‌های کیفیت فنی بررسی کرد.

همچنین داده‌های آزمایشگاهی و داده کاربران واقعی یکسان نیستند. برای جزئیات بیشتر درباره تصاویر، Cache، JavaScript، Server و معیارهای عملکرد می‌توانید راهنمای بهینه‌سازی سرعت سایت و Core Web Vitals را ببینید.

Structured Data

Structured Data به موتور جستجو کمک می‌کند نوع و ساختار بعضی اطلاعات صفحه را بهتر درک کند و در موارد پشتیبانی‌شده می‌تواند صفحه را واجد شرایط برخی Search Featureها کند.

اما دو نکته مهم وجود دارد:

اول اینکه Structured Data باید با محتوای واقعی قابل مشاهده صفحه هماهنگ باشد.

دوم اینکه Valid بودن Schema یا واجد شرایط بودن صفحه، نمایش Rich Result را تضمین نمی‌کند.

در Audit باید Syntax، نوع Schema، داده‌های ضروری و تطابق آن با محتوای صفحه بررسی شود.

International SEO

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

در چنین سایت‌هایی باید ساختار URL، Canonical و hreflang هماهنگ باشند و هر نسخه زبانی واقعاً محتوای مناسب همان مخاطب را ارائه دهد.

Canonical اشتباه میان زبان‌ها یا hreflangهایی که به URL Redirect یا غیرقابل Index اشاره می‌کنند می‌توانند سیگنال‌های متناقض ایجاد کنند.

Workflow عملی Technical SEO Audit و اولویت‌بندی مشکلات

یک Audit خوب از اجرای ده‌ها ابزار مختلف شروع نمی‌شود. ابتدا باید سؤال مشخصی داشته باشید:

آیا صفحات مهم سایت می‌توانند پیدا، Crawl، Render و Index شوند و آیا سیگنال‌های فنی آن‌ها با هدف سایت هماهنگ است؟

مرحله ۱: صفحات مهم و وضعیت Index را مشخص کنید

قبل از Crawl، فهرست Money Pageها و صفحات مهم را مشخص کنید؛ مثلاً صفحات خدمات، دسته‌بندی‌های اصلی، محصولات مهم و مقالاتی که ورودی یا ارزش تجاری دارند.

سپس بررسی کنید:

• آیا URL در Google دیده می‌شود؟
• آخرین Crawl چه زمانی بوده است؟
• Google چه Canonicalی برای آن انتخاب کرده است؟
• آیا دلیل مشخصی برای Excluded شدن وجود دارد؟

این مرحله کمک می‌کند Audit از ابتدا روی URLهای باارزش متمرکز شود.

مرحله ۲: سایت را Crawl کنید

یک Crawler مناسب می‌تواند نمایی از معماری واقعی سایت ارائه دهد.

در این مرحله به دنبال مواردی مانند این باشید:

• URLهای 3xx
• 4xx و 5xx
• Canonicalها
• Noindexها
• Crawl Depth
• Internal Linkها
• Pagination
• Duplicateها
• صفحات کم‌لینک

اما هر موردی که Crawler با رنگ قرمز نشان می‌دهد الزاماً مشکل نیست. Context URL را بررسی کنید.

مرحله ۳: Status Codeها و Redirectها را بررسی کنید

ابتدا خطاهای Server، Redirect Loopها، Redirect Chainهای غیرضروری و لینک داخلی به URLهای قدیمی را جدا کنید.

Money Pageای که 5xx می‌دهد اولویت بسیار بیشتری از یک صفحه آرشیوی کم‌اهمیت با Title طولانی دارد.

مرحله ۴: Robots، Noindex، Sitemap و Canonical را کنار هم ببینید

این تنظیمات نباید جداگانه تحلیل شوند.

برای URL مهم بررسی کنید:

• robots.txt اجازه Crawl می‌دهد؟
• Meta Robots یا X-Robots-Tag مانع Index نیست؟
• Canonical به مقصد درست اشاره می‌کند؟
• URL در Sitemap مناسب قرار دارد؟
• Google Selected Canonical با انتظار شما یکسان است؟

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

مرحله ۵: Internal Linking و Architecture را بررسی کنید

صفحات مهم باید مسیر Crawl منطقی داشته باشند.

Orphan Pageها، Crawl Depth غیرمنطقی، لینک‌های شکسته، لینک داخلی به Redirect و تولید بی‌رویه URL از Filterها را بررسی کنید.

مرحله ۶: Rendering را تست کنید

اگر سایت به JavaScript وابسته است، چند Template مهم را از نظر Render بررسی کنید.

صفحه محصول، دسته‌بندی، خدمات و مقاله را فقط در Browser نگاه نکنید؛ ببینید محتوای اصلی، لینک‌ها، Canonical و Structured Data پس از Rendering نیز قابل دسترسی هستند.

مرحله ۷: Mobile و Performance را بررسی کنید

صفحات اصلی را روی Mobile واقعی و با داده Field در صورت وجود بررسی کنید.

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

مرحله ۸: Structured Data را Validate کنید

Schemaهای مورد استفاده را بررسی کنید و Errorهای واقعی را از Warningهای اختیاری جدا کنید.

Markup باید با نوع صفحه و محتوای قابل مشاهده همخوان باشد.

مرحله ۹: بعد از اصلاح دوباره Crawl و Validate کنید

رفع مشکل بدون Verification کامل نیست.

پس از تغییر Redirect، Canonical، Robots یا Template دوباره URL را Crawl و Inspect کنید تا مطمئن شوید مشکل جدیدی ایجاد نشده است.

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

همه Errorها ارزش یکسان ندارند.

برای اولویت‌بندی می‌توانید چهار سؤال بپرسید:

1. آیا مشکل مانع Crawl، Render یا Index صفحه مهم شده است؟
2. چند URL تحت تأثیر هستند؟
3. ارزش تجاری یا Organic آن URLها چقدر است؟
4. ریسک و هزینه اصلاح چقدر است؟

برای مثال:

Canonical اشتباه روی صفحه اصلی یک خدمت مهم معمولاً باید زودتر از Warning جزئی Structured Data روی یک مقاله کم‌ترافیک بررسی شود.

یا اگر Template محصولات سایت به‌اشتباه noindex شده باشد، مسئله بسیار مهم‌تر از بهینه نبودن چند Meta Description است.

هدف Technical SEO کاهش Error Count نیست؛ هدف حذف موانعی است که بیشترین اثر را روی Discovery، Crawl، Index و تجربه کاربران دارند.

Log Analysis چه زمانی مفید می‌شود؟

Crawler به شما می‌گوید سایت از دید لینک‌های داخلی چگونه ساخته شده است؛ Server Log نشان می‌دهد Crawlerها در عمل چه URLهایی را درخواست کرده‌اند.

Log Analysis به‌خصوص در سایت‌های بزرگ می‌تواند نشان دهد:

• Googlebot بیشتر کدام بخش‌ها را Crawl می‌کند؟
• صفحات مهم چند وقت یک‌بار درخواست می‌شوند؟
• چه مقدار Crawl روی Parameterها یا URLهای کم‌ارزش مصرف می‌شود؟
• Googlebot با چه 4xx یا 5xxهایی روبه‌رو شده است؟
• بعد از Migration آیا URLهای جدید Crawl می‌شوند؟

برای سایت کوچک لازم نیست Technical SEO را از Server Log شروع کنید. Log Analysis زمانی ارزش بیشتری دارد که سؤال مشخصی درباره رفتار واقعی Crawler داشته باشید.

Migration و Redesign؛ جایی که خطاهای فنی می‌توانند گسترده شوند

هنگام تغییر دامنه، URL Structure، CMS یا طراحی سایت، Technical SEO اهمیت بیشتری پیدا می‌کند.

قبل از Migration بهتر است URLهای قدیمی به مقصد مناسب Map شوند.

پس از انتقال نیز باید موارد زیر بررسی شوند:

• 301 از URL قدیمی به مقصد مرتبط
• Canonicalهای نسخه جدید
• Internal Linkهای جدید
• XML Sitemap
• robots.txt و noindexهای موقت
• hreflang در سایت‌های بین‌المللی
• 404 و 5xxهای غیرمنتظره
• Index شدن تدریجی URLهای جدید

یکی از اشتباهات خطرناک این است که محیط Staging برای جلوگیری از Index شدن noindex شود و همان تنظیم پس از Launch روی نسخه Production باقی بماند.

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

چک‌لیست Technical SEO

• URLهای مهم Status 200 صحیح دارند.
• خطای گسترده 5xx وجود ندارد.
• Redirect Loop وجود ندارد.
• Redirect Chainهای غیرضروری اصلاح شده‌اند.
• لینک‌های داخلی مستقیماً به URL نهایی اشاره می‌کنند.
• robots.txt مسیر مهمی را ناخواسته مسدود نکرده است.
• صفحات مهم noindex نیستند.
• X-Robots-Tag ناخواسته وجود ندارد.
• XML Sitemap فقط URLهای مناسب و قابل Index را شامل می‌شود.
• Canonical صفحات مهم صحیح است.
• Google Selected Canonical برای URLهای مهم بررسی شده است.
• Orphan Pageهای مهم شناسایی شده‌اند.
• Crawl Depth صفحات مهم منطقی است.
• لینک داخلی به 404 و 410 بررسی شده است.
• Parameter URLها و Faceted Navigation کنترل شده‌اند.
• Pagination با معماری سایت هماهنگ است.
• محتوا و لینک‌های مهم پس از JavaScript Rendering قابل مشاهده‌اند.
• نسخه Mobile محتوای اصلی را در اختیار دارد.
• HTTPS و Redirect نسخه HTTP درست هستند.
• LCP، INP و CLS صفحات مهم بررسی شده‌اند.
• Structured Data با محتوای واقعی صفحه هماهنگ است.
• پس از تغییرات مهم دوباره Crawl و Validation انجام شده است.

برای سایت‌های WordPress بخشی از این خطاها ممکن است از تنظیمات CMS، افزونه SEO، Archiveها، Canonicalها یا Templateها ایجاد شوند. در چنین شرایطی راهنمای سئو وردپرس و تنظیمات فنی آن می‌تواند مکمل بررسی Technical SEO باشد.

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

آیا هر خطای ابزارهای SEO باید برطرف شود؟

خیر. ابزارها معمولاً بر اساس Ruleهای عمومی Warning ایجاد می‌کنند. ابتدا بررسی کنید مشکل روی Crawl، Index، Ranking Potential یا تجربه کاربر چه اثری دارد و چه URLهایی را درگیر کرده است.

آیا گرفتن امتیاز ۱۰۰ در ابزار Audit هدف Technical SEO است؟

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

آیا قرار دادن URL در Sitemap باعث Index شدن آن می‌شود؟

خیر. Sitemap به Discovery و Crawl بهتر URLها کمک می‌کند، اما موتور جستجو تضمینی برای Crawl یا Index تمام URLهای Sitemap ارائه نمی‌دهد.

آیا robots.txt برای Noindex کردن صفحات مناسب است؟

robots.txt اساساً Crawl را کنترل می‌کند. اگر لازم است موتور جستجو noindex را ببیند، باید بتواند صفحه را Crawl کند. برای کنترل Index معمولاً Meta Robots یا X-Robots-Tag ابزار مرتبط‌تری هستند.

چرا صفحه‌ای با Status 200 ممکن است Index نشود؟

200 فقط نشان می‌دهد Server درخواست را با موفقیت پاسخ داده است. Noindex، Canonical، Duplicate Content، کیفیت صفحه و تصمیم سیستم Indexing همچنان می‌توانند باعث شوند URL در Index قرار نگیرد.

آیا Canonical همان Redirect است؟

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

آیا بهبود Core Web Vitals باعث افزایش قطعی رتبه می‌شود؟

خیر. LCP، INP و CLS معیارهای مهم تجربه کاربر و کیفیت Performance هستند، اما Ranking به عوامل زیادی وابسته است. بهبود این معیارها را باید بخشی از کیفیت کلی سایت دانست، نه فرمول تضمینی رتبه.

از کدام بخش Technical SEO Audit شروع کنیم؟

از صفحات مهم و وضعیت Index آن‌ها شروع کنید. سپس Crawl، Status Code، Robots، Canonical، Sitemap، Internal Linking، Rendering و Performance را مرحله‌به‌مرحله بررسی کنید. این روش معمولاً مفیدتر از بررسی تصادفی صدها Warning است.

چه زمانی Audit فنی تخصصی لازم است؟

اگر صفحات مهم Index نمی‌شوند، Google Canonical غیرمنتظره انتخاب می‌کند، بعد از Migration ترافیک افت کرده، Crawl Errorهای گسترده دارید یا بین Search Console، Sitemap و وضعیت واقعی سایت تناقض وجود دارد، Audit فنی می‌تواند محل اصلی مشکل را مشخص کند.

اگر بعد از بررسی Crawl، Index، Canonical، Redirect، Rendering و Performance هنوز مشخص نیست افت یا مشکل سایت از کدام لایه ایجاد شده، بهتر است به‌جای اصلاح پراکنده Warningها، مسئله به‌صورت یک Audit فنی بررسی و بر اساس اثر واقعی هر مشکل اولویت‌بندی شود.

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