سئو تکنیکال چیست؟
Technical SEO بخشی از بهینهسازی موتور جستجو است که روی قابلیت دسترسی، پردازش و فهم فنی سایت توسط Crawlerها و Search Engineها تمرکز دارد. هدف اصلی آن این است که مانع فنی غیرضروری بین محتوای ارزشمند و موتور جستجو وجود نداشته باشد.
یک تعریف عملیتر این است: Technical SEO بررسی میکند آیا موتور جستجو میتواند URL درست را کشف کند، آن را با پاسخ Server مناسب دریافت کند، منابع لازم را ببیند، محتوای صفحه را Render کند، دستورهای Indexing را بفهمد و نسخه درست را بهعنوان Canonical انتخاب کند یا نه. اگر پاسخ یکی از این مراحل منفی باشد، باید قبل از هر اقدام تصادفی مشخص کنیم مشکل دقیقاً در کدام لایه قرار دارد.
چه چیزی Technical SEO نیست؟
Technical SEO با On-Page SEO، Content SEO و Off-Page SEO ارتباط نزدیک دارد، اما جای آنها را نمیگیرد. انتخاب Keyword، پاسخ به Search Intent، کیفیت محتوا، ساختار معنایی متن، Backlink و اعتبار موضوعی بخشهای دیگری از SEO هستند. در مقاله آموزش SEO از صفر تا صد تصویر کلی این حوزه را میبینید؛ مقاله فعلی فقط مالک لایه فنی آن است.
برای مثال، پایین بودن رتبه یک صفحه الزاماً Technical Problem نیست. اگر URL با پاسخ 200 قابل Crawl است، Render درست انجام میشود، noindex ندارد، Canonical صحیح است و صفحه در Index حضور دارد، ممکن است مسئله اصلی Content Quality، Search Intent یا رقابت باشد. یکی از مهمترین مهارتهای Technical SEO همین است که مشکل فنی را از مشکل غیر فنی جدا کند.
پیشنیازهای یادگیری
برای شروع Technical SEO لازم نیست Developer حرفهای باشید، اما چند مفهوم پایه سرعت یادگیری را بسیار بیشتر میکند. باید بدانید URL چیست، Browser و Server چگونه با HTTP ارتباط میگیرند، HTML چه نقشی دارد و تفاوت Source Page با چیزی که پس از اجرای JavaScript روی صفحه دیده میشود چیست. آشنایی مقدماتی با WordPress، Hosting و DNS نیز برای تشخیص مشکلات واقعی مفید است.
اگر این مفاهیم را هنوز عمیق نمیدانید، لازم نیست مطالعه مقاله را متوقف کنید. هرجا اصطلاحی مثل HTTP Status، Header، DOM یا Canonical استفاده میشود، هدف آن در همان Context توضیح داده خواهد شد. مسیر یادگیری مناسب از شناخت Crawl و Index شروع میشود و بعد به JavaScript، Log Analysis و معماریهای بزرگ میرسد؛ برعکس شروع کردن از ابزارهای پیشرفته معمولاً فقط تعداد Warningهای نامفهوم را بیشتر میکند.
مسیر یادگیری
یک Skill Graph ساده برای این حوزه چنین است: ابتدا HTML و HTTP را در حد خواندن Source و Response بشناسید؛ سپس Discovery، Crawl و Indexing را یاد بگیرید؛ بعد robots، Sitemap، Canonical و Redirect را تمرین کنید؛ در مرحله بعد JavaScript Rendering و Performance را اضافه کنید؛ و در نهایت سراغ Audit، Server Log و مسائل Enterprise بروید. این ترتیب باعث میشود هر مفهوم جدید روی پایه قبلی سوار شود و Technical SEO به مجموعهای از اصطلاحات جدا از هم تبدیل نشود.
گوگل سایت را چگونه میبیند؟
برای فهم Technical SEO لازم نیست الگوریتم Google را حدس بزنیم؛ کافی است Pipeline پایه را درست بفهمیم. از دید عملی، یک URL باید کشف شود، Crawl شود، در صورت نیاز Render شود، شرایط Indexing را داشته باشد، در کنار URLهای مشابه Canonicalize شود و در نهایت امکان Serving در نتایج را پیدا کند.
| مرحله | وظیفه | مشکل رایج |
|---|---|---|
| Discovery | پیدا کردن URL | صفحه یتیم یا لینکسازی ضعیف |
| Crawl | دریافت URL و منابع | robots.txt، خطای Server یا Loop |
| Render | ساخت محتوای قابل مشاهده | JavaScript یا Resource مسدود |
| Index | پردازش و ذخیره اطلاعات | noindex، کیفیت پایین یا Duplicate |
| Canonical | انتخاب نسخه نماینده | Signalهای متناقض |
| Serve | نمایش برای Query مناسب | Intent، کیفیت یا رقابت |
کشف و خزش
موتور جستجو باید ابتدا از وجود URL مطلع شود. Internal Linkها، Sitemap و Redirectها از مسیرهای مهم کشف URL هستند. اگر صفحهای هیچ لینک داخلی قابل Crawl نداشته باشد و در Sitemap هم نباشد، به یک Orphan Page نزدیک میشود؛ یعنی صفحهای که در معماری عملی سایت جای مشخصی ندارد.
Crawl به معنی دریافت URL است، نه ایندکس شدن آن. Googlebot ممکن است یک URL را بارها Crawl کند اما آن صفحه هرگز در Index باقی نماند. همین تفاوت پایه باعث میشود عبارت «Google صفحه را دیده، پس چرا ایندکس نشده؟» پاسخ سادهای نداشته باشد.
رندر صفحه
در سایتهای ساده، HTML اولیه ممکن است تقریباً تمام محتوای مهم را داشته باشد. در سایتهای JavaScript-heavy بخشی از محتوا، لینکها یا Metadata پس از اجرای JavaScript ساخته میشود. در چنین شرایطی Fetch موفق کافی نیست؛ باید بررسی شود خروجی Render شده واقعاً شامل محتوای اصلی، Linkهای مهم، Canonical و عناصر مورد انتظار هست یا نه.
برای تشخیص، Source HTML و Rendered DOM را با هم مقایسه کنید. اگر محتوای حیاتی فقط پس از Interaction کاربر مثل کلیک یا Scroll خاص ظاهر میشود، باید مطمئن شوید Crawler بدون آن Interaction نیز بتواند به محتوا دسترسی پیدا کند.
ایندکس و نمایش
Indexing مرحلهای است که موتور جستجو محتوا و Signalهای صفحه را پردازش میکند. حتی اگر Crawl و Render بدون خطا باشند، وجود noindex، Duplicate بودن محتوا، Canonicalization یا ارزیابیهای دیگر میتواند باعث شود URL موردنظر شما در Index انتخاب نشود.
همچنین Indexed بودن با Ranking یکی نیست. Index یعنی URL امکان حضور در Search را دارد؛ Ranking یعنی برای Query مشخص چقدر مناسب و رقابتی تشخیص داده میشود. این مرزبندی جلوی بسیاری از Fixهای اشتباه را میگیرد.
معماری سایت و URL
یک Site Architecture خوب فقط برای کاربر زیبا نیست؛ مسیرهای Crawl و رابطه صفحات را نیز روشن میکند. صفحه مهم باید از بخشهای منطقی سایت Link دریافت کند و برای رسیدن به آن وابسته به Search داخلی، JavaScript پیچیده یا URL مخفی نباشد.
مسیر خزش
برای صفحات مهم یک مسیر Internal Link قابل پیشبینی بسازید: Home یا Category → Pillar → Cluster → Article. این ساختار به موتور جستجو کمک میکند اهمیت نسبی صفحات و رابطه موضوعی آنها را بهتر بفهمد. در DJH نیز معماری محتوا بر مبنای Pillar → Cluster → Article → Related Articles طراحی میشود.
Depth نیز باید با اهمیت صفحه تناسب داشته باشد. قانون جادویی «همه صفحات باید حداکثر سه کلیک از Home فاصله داشته باشند» وجود ندارد، اما اگر صفحهای برای کسبوکار حیاتی است و فقط از مسیر پنج Filter، یک Pagination عمیق یا Search داخلی پیدا میشود، معماری آن نیاز به بازنگری دارد. مهمتر از عدد ثابت این است که Crawler بتواند از لینکهای HTML واقعی و معنیدار به صفحه برسد.
Anchor Text داخلی نیز بخشی از معماری است. لینک «آموزش Google Search Console» هم برای کاربر و هم برای موتور جستجو Context بیشتری از «اینجا کلیک کنید» میدهد. با این حال Anchor را برای Keyword exact-match به شکل مصنوعی تکرار نکنید؛ طبیعی بودن و ارتباط واقعی صفحه مبدا و مقصد مهمتر است.
لینکهای داخلی باید به URL نهایی اشاره کنند، نه URLی که ابتدا 301 یا 302 میشود. اگر هزاران Link داخلی ابتدا وارد Redirect شوند، هم تجربه کاربر و هم Crawl Efficiency ضعیفتر میشود. بعد از Migration یا تغییر Slug، Internal Linkهای مهم را به مقصد نهایی Update کنید.
صفحات یتیم
Orphan Page ممکن است در Sitemap باشد و حتی Index شود، اما از نظر معماری سایت اتصال طبیعی ندارد. برای صفحات ارزشمند، حضور در Sitemap جای Internal Link را نمیگیرد. اگر مقالهای واقعاً مهم است، باید از صفحات مرتبط و Parent مناسب به آن Link داده شود.
در Audit، فهرست URLهای Crawlشده را با Sitemap، Analytics یا Database مقایسه کنید. URLهایی که در Data Source وجود دارند اما Crawler داخلی آنها را پیدا نمیکند، Candidateهای خوبی برای بررسی Orphan بودن هستند.
ساختار URL
URL کوتاه و توصیفی مزیت مدیریتی و خوانایی دارد، اما نباید برای زیبایی ظاهری، Migration پرریسک ایجاد کنید. تغییر URL قدیمی و تثبیتشده فقط وقتی منطقی است که Benefit روشن داشته باشد و Redirect Mapping، Canonical، Sitemap و Internal Linkها همزمان مدیریت شوند.
از تولید بینهایت Variant برای Sort، Filter، Session، Tracking و Parameterهای کمارزش جلوگیری کنید. Faceted Navigation در فروشگاهها میتواند میلیونها ترکیب URL ایجاد کند؛ اینجا مسئله فقط Duplicate Content نیست، بلکه Crawl Space نیز ممکن است بیدلیل بزرگ شود.
کنترل خزش
کنترل Crawl به معنی بستن هر URL کمارزش نیست. قبل از اعمال Rule باید بدانید آیا هدف شما جلوگیری از Crawl، جلوگیری از Index، کاهش URLهای تکراری یا مدیریت منابع Server است؛ ابزار مناسب برای هرکدام متفاوت است.
فایل robots.txt
فایل robots.txt در Root سایت قرار میگیرد و به Crawlerهای سازگار میگوید کدام مسیرها را Crawl نکنند. یک نمونه بسیار ساده میتواند چنین باشد:
User-agent: *
Disallow: /private/
Allow: /این Rule فقط Crawl مسیر مشخصشده را محدود میکند. robots.txt ابزار مطمئنی برای حذف URL از Search نیست. اگر URL از جای دیگری Link داشته باشد، ممکن است موتور جستجو از وجود آن مطلع باشد ولی نتواند محتوای داخلش را ببیند.
همچنین فایلهای CSS و JavaScript لازم برای Render را بدون دلیل Block نکنید. اگر موتور جستجو برای درک Layout یا Content به Resource نیاز دارد، مسدود کردن آن میتواند Diagnosis را پیچیده کند.
بودجه خزش
Crawl Budget برای همه سایتها مسئله روزانه نیست. اگر سایت چند صد یا چند هزار URL سالم دارد، Server پاسخگو است و URL Explosion ندارید، معمولاً مشکل اصلی شما «بودجه خزش» نیست. این مفهوم برای سایتهای بسیار بزرگ، بسیار پویا یا سایتهایی با حجم عظیم URLهای کمارزش اهمیت بیشتری پیدا میکند.
بهجای وسواس روی Crawl Budget، ابتدا علتهای قابلکنترل را بررسی کنید: لینکهای شکسته، URL Parameterهای بینهایت، Calendarهای بدون انتها، Filterهای تکراری، Redirect Chain، 5xx، Slow Server و Sitemap آلوده به URLهای نامعتبر.
URLهای اضافی
اگر سیستم Faceted Navigation یا Search داخلی URLهای زیادی تولید میکند، قبل از Block کردن کورکورانه باید مشخص شود کدام Combination واقعاً Landing Page ارزشمند است. بعضی Filterها ممکن است Search Intent واقعی داشته باشند و برخی دیگر فقط Crawl Trap باشند. تصمیم باید مبتنی بر ارزش صفحه و معماری Indexing باشد.
کنترل ایندکس
سه ابزار بسیار رایج در Technical SEO—robots.txt، noindex و Canonical—کار یکسانی انجام نمیدهند. Sitemap نیز نقش چهارمی دارد. بسیاری از مشکلات Indexing از زمانی شروع میشوند که این ابزارها بهجای هم استفاده شوند یا Signalهای متناقض ایجاد کنند.
| ابزار | کنترل اصلی | کاربرد |
|---|---|---|
| robots.txt | Crawl | محدود کردن دسترسی Crawler |
| noindex | Index | حذف صفحه قابل Crawl از نتایج |
| Canonical | نسخه ترجیحی | Consolidation URLهای مشابه |
| Sitemap | Discovery | معرفی URLهای ترجیحی |
noindex و X-Robots
برای صفحه HTML میتوان از meta robots استفاده کرد:
<meta name="robots" content="noindex,follow">برای فایلها یا پاسخهایی که Meta HTML ندارند، `X-Robots-Tag` در HTTP Header قابل استفاده است. نکته حیاتی این است که Crawler باید بتواند صفحه را Crawl کند تا noindex را ببیند. ترکیب «Disallow در robots.txt + noindex داخل صفحه» ممکن است نتیجه مورد انتظار شما را ندهد، چون Crawler اصلاً به دستور noindex دسترسی پیدا نمیکند.
نقشه سایت XML
XML Sitemap فهرستی از URLهایی است که میخواهید موتور جستجو آنها را بهعنوان صفحات مطلوب سایت بشناسد. Sitemap برای Discovery مفید است، اما ایندکس را تضمین نمیکند. URL موجود در Sitemap باید در حالت ایدهآل پاسخ 200، محتوای قابل Index و Canonical سازگار داشته باشد.
یکی از خطاهای رایج این است که Sitemap شامل URLهای Redirect، 404، noindex یا Canonical به صفحات دیگر باشد. در چنین حالتی شما به موتور جستجو Signalهای متناقض میدهید: از یک طرف URL را در Sitemap بهعنوان Preferred معرفی میکنید و از طرف دیگر میگویید آن URL نهایی نیست.
Canonical
Canonicalization زمانی مهم میشود که محتوای یکسان یا بسیار مشابه از چند URL قابل دسترسی باشد. تگ Canonical ترجیح شما را اعلام میکند:
<link rel="canonical" href="https://example.com/preferred-page">اما Canonical یک دستور مطلق نیست. موتور جستجو Signalهای مختلف را کنار هم میگذارد و ممکن است URL دیگری را Representative انتخاب کند. Redirect دائم و `rel=”canonical”` Signalهای مهمی هستند و حضور URL در Sitemap نیز کمک میکند، اما Signalهای متناقض تصمیم را پیچیده میکنند.
برای هر URL مهم این سؤال را بپرسید: آیا Internal Link، Sitemap، Canonical، Redirect و نسخه HTTPS همگی به یک مقصد اشاره میکنند؟ هرچه پاسخ این سؤال روشنتر باشد، Canonicalization قابل پیشبینیتر خواهد بود.
اگر با وضعیتهایی مثل Duplicate، Crawled – currently not indexed یا Canonical غیرمنتظره مواجه هستید، راهنمای علت ایندکس نشدن سایت در گوگل برای Troubleshooting عمیقتر این مرحله مناسبتر است.
Status Code و Redirect
HTTP Status Code اولین پاسخ فنی Server به درخواست Crawler است. اگر Status اشتباه باشد، حتی محتوای صحیح نیز میتواند Signal نامناسبی تولید کند. به همین دلیل Technical Audit باید Response واقعی Server را بررسی کند، نه فقط چیزی که Browser ظاهراً نمایش میدهد.
| Status | معنی | تصمیم SEO |
|---|---|---|
| 200 | درخواست موفق | برای URL نهایی عادی |
| 301 / 308 | Redirect دائم | برای انتقال پایدار URL |
| 302 / 307 | Redirect موقت | وقتی تغییر واقعاً موقتی است |
| 404 / 410 | محتوا در دسترس نیست | برای URL حذفشده معتبر |
| 5xx | مشکل Server | نیازمند تشخیص فوری در حجم بالا |
Redirect دائم و موقت
وقتی URL برای همیشه عوض شده، Redirect دائم انتخاب طبیعی است. در Migrationها بهتر است هر URL قدیمی مستقیماً به نزدیکترین مقصد جدید خودش برود؛ هدایت صدها URL متفاوت به Home نه تجربه خوبی میسازد و نه Mapping معنایی دقیقی ایجاد میکند.
Redirect موقت برای سناریویی است که واقعاً انتظار دارید URL اصلی برگردد. انتخاب Status نباید صرفاً بر اساس عادت Plugin یا Server باشد؛ Intent انتقال باید مشخص باشد.
خطاهای 4xx و 5xx
404 همیشه «خطای SEO» نیست. اگر صفحهای واقعاً حذف شده و جایگزین ندارد، 404 یا 410 میتواند رفتار صحیح باشد. مشکل زمانی ایجاد میشود که URL مهم به اشتباه 404 شود، Navigation هنوز به آن Link دهد یا Sitemap آن را معرفی کند.
5xx در مقیاس گسترده حساستر است، چون نشان میدهد Server نتوانسته درخواست را درست پاسخ دهد. Spike خطاهای 5xx، Timeout یا DNS/Network Failure باید با Server Logs، Monitoring و Crawl Stats بررسی شود.
Chain و Loop
Redirect Chain زمانی است که A به B، B به C و C به D میرود. ممکن است Browser در نهایت مقصد را باز کند، اما این مسیر اضافه برای User و Crawler بیدلیل است. لینکهای داخلی و Mapping را تا حد ممکن مستقیماً به URL نهایی ببرید.
Redirect Loop بدتر است؛ A به B و B دوباره به A یا چرخه بزرگتری برمیگردد. این وضعیت باید در سطح Server، CDN، WordPress، HTTPS enforcement و Redirect Plugin بررسی شود.
در WordPress معمولاً چند لایه میتوانند همزمان Redirect ایجاد کنند: خود WordPress، افزونه SEO، افزونه Redirect، Cache/CDN و Web Server. اگر Loop یا مقصد غیرمنتظره دارید، Ruleها را از بیرونیترین لایه به داخل بررسی کنید و فقط یک Source of Truth برای هر Redirect نگه دارید. اضافه کردن یک Rule جدید روی Rule اشتباه قبلی معمولاً مشکل را پیچیدهتر میکند.
در Site Migration بهتر است قبل از انتشار، Mapping قدیم → جدید آماده باشد. سپس Redirect، Internal Link، Canonical و Sitemap همزمان به ساختار جدید اشاره کنند. اگر فقط Redirect را پیاده کنید ولی Site Map و لینکهای داخلی ماهها URL قدیمی را تبلیغ کنند، موتور جستجو Signalهای سازگار کمتری دریافت میکند.
JavaScript SEO
Google میتواند JavaScript را پردازش کند، اما این واقعیت به معنی «هر معماری JavaScript همیشه بدون مشکل ایندکس میشود» نیست. Technical SEO در سایتهای Client-side باید ببیند چه چیزی در HTML اولیه وجود دارد، چه چیزی پس از Render ساخته میشود و آیا محتوای اصلی بدون Interaction خاص قابل مشاهده است.
HTML و DOM رندرشده
برای یک URL مهم سه لایه را از هم جدا کنید: Response Server، Source HTML و Rendered DOM. اگر Title، Main Content، Internal Links یا Canonical در یکی از این لایهها تغییر میکنند، باید مطمئن شوید خروجی نهایی برای Crawler قابل دسترسی و پایدار است.
اگر Application فقط یک Shell خالی در HTML میفرستد و تمام محتوا بعداً از API میآید، Error در API، Timeout، blocked resource یا hydration مشکلدار میتواند باعث شود موتور جستجو محتوایی متفاوت از کاربر ببیند. برای صفحات Search-critical، SSR، Static Rendering یا روشهای Hybrid میتوانند Robustness بیشتری ایجاد کنند، اما انتخاب معماری باید با نیاز واقعی Product هماهنگ باشد.
در Audit یک SPA یا سایت React/Vue/Angular، صرفاً دیدن صفحه در Browser معمولی کافی نیست. JavaScript فعال، Cache گرم و Session کاربر ممکن است مشکلی را پنهان کنند. URL را در حالت Incognito، با Network throttling و در ابزارهای Rendering بررسی کنید و ببینید آیا Linkهای داخلی به شکل واقعی قابل Crawl تولید میشوند یا فقط با Event handler کار میکنند.
همچنین Metadata پویا را فراموش نکنید. Title، meta robots، canonical و Structured Data اگر پس از JavaScript تغییر میکنند، باید در خروجی Render نهایی پایدار باشند. دو نسخه متناقض—یکی در HTML اولیه و دیگری بعد از Render—Diagnosis را دشوار میکند و بهتر است تا حد امکان Signalهای حیاتی از ابتدا سازگار باشند.
Lazy Loading
Lazy Loading برای Performance مفید است، ولی محتوای مهم نباید فقط پس از Eventهایی بارگذاری شود که Crawler الزاماً انجام نمیدهد. Image یا Content باید بر اساس شرایط قابل تشخیص مثل Viewport و بدون نیاز به کلیک دستی کاربر قابل Load باشد.
تست Rendering
برای Diagnosis، خروجی Live URL و Crawled Page را در URL Inspection بررسی کنید و در کنار آن Browser DevTools را به کار بگیرید. اگر محتوای مورد انتظار در Rendered HTML دیده نمیشود، قبل از دستکاری Canonical یا Sitemap ابتدا مشکل Rendering را حل کنید.
عملکرد و تجربه صفحه
Performance یکی از اجزای Technical SEO است، نه کل آن. سایتی میتواند امتیاز Lighthouse خوبی داشته باشد ولی robots.txt اشتباه، Canonical متناقض یا Indexing Problem داشته باشد. به همین دلیل Performance باید بعد از اطمینان از Accessibility و Indexability در Context درست ارزیابی شود.
LCP، INP و CLS
Core Web Vitals فعلی سه Metric اصلی دارد: LCP برای سرعت نمایش محتوای اصلی، INP برای Responsiveness تعامل و CLS برای پایداری بصری. برای محدوده Good، هدفهای مرجع عبارتاند از LCP حداکثر 2.5 ثانیه، INP حداکثر 200 میلیثانیه و CLS حداکثر 0.1 در صدک 75 تجربه کاربران.
این Thresholdها هدفهای مفیدی هستند، اما نباید Metric chasing جای تشخیص واقعی را بگیرد. مثلاً یک LCP ضعیف میتواند از TTFB، Image Hero سنگین، CSS blocking، Font یا Rendering strategy ناشی شود. Fix باید Root Cause را هدف بگیرد.
Field و Lab Data
Lab Data برای Debug و تکرار تست بسیار مفید است؛ Field Data تجربه کاربران واقعی را نشان میدهد. اختلاف میان این دو طبیعی است. اگر Lab خوب ولی Field ضعیف است، Device، Network، Geography، Cache و Traffic distribution کاربران واقعی را بررسی کنید.
برای جزئیات بیشتر درباره این سه Metric و اثرشان روی تجربه و SEO، مقاله Core Web Vitals و SEO را بخوانید؛ در این Pillar فقط نقش آنها در Technical Audit را نگه میداریم.
موبایل و دسترسی
Google برای Indexing وب عمدتاً نسخه Mobile محتوا را مبنا قرار میدهد. بنابراین نسخه Mobile نباید نسخه ناقص Desktop باشد. Content، Internal Linkهای مهم، Structured Data، Robots Directives و Metadata اصلی باید در Mobile نیز در دسترس باشند.
Mobile-first Indexing
Responsive Design معمولاً مدیریت سادهتری دارد، اما اصل اساسی Technology خاص نیست: چیزی که کاربر و Crawler در Mobile میبینند باید محتوای اصلی و قابل استفاده باشد. پنهان کردن بخشهای حیاتی، حذف Linkهای مهم یا Load نکردن Content در Mobile میتواند فهم صفحه را ضعیف کند.
HTTPS و Server
HTTPS امروز باید حالت عادی سایت باشد. نسخههای HTTP و HTTPS را بهصورت جدا و متناقض رها نکنید؛ Redirect، Canonical، Sitemap و Internal Linkها باید مقصد امن نهایی را نشان دهند.
در کنار HTTPS، Availability Server را جدی بگیرید. Technical SEO بدون Server Monitoring ناقص است. اگر Host در زمان Crawl مرتب Timeout میدهد یا Rate Limit نامناسب Googlebot را میبندد، مشکل از Tag و Plugin حل نمیشود.
محتوای Mobile و Desktop نیز باید از نظر هدف اصلی هماهنگ باشد. لازم نیست هر عنصر تزئینی یکسان باشد، اما Text اصلی، Linkهای مهم، Image Altهای ضروری و Structured Data نباید فقط در Desktop وجود داشته باشند. همچنین اگر Mobile Version URL جداگانه دارید، رابطه Canonical و alternate باید با معماری International/Mobile سایت هماهنگ باشد.
برای Accessibility فنی نیز به موارد پایه توجه کنید: Navigation باید قابل استفاده باشد، Elementهای تعاملی نباید محتوای اصلی را پشت Interaction غیرضروری پنهان کنند و Layout نباید با بارگذاری دیرهنگام دائماً جابهجا شود. Accessibility و SEO دو حوزه یکسان نیستند، اما HTML معنایی و تجربه قابل استفاده معمولاً به Debug و فهم صفحه کمک میکنند.
داده ساختاریافته
Structured Data یا داده ساختاریافته به موتور جستجو کمک میکند نوع و رابطه برخی اطلاعات صفحه را واضحتر بفهمد. رایجترین روش پیادهسازی، JSON-LD است. اما Schema جای محتوای قابل مشاهده را نمیگیرد و داشتن Markup بهتنهایی نمایش Rich Result را تضمین نمیکند.
Structured Data چیست؟
فرض کنید صفحهای درباره یک محصول، مقاله، سازمان یا Breadcrumb است. Structured Data میتواند Propertyهای مشخصی درباره Entityهای موجود در صفحه ارائه کند. Markup باید با محتوای واقعی و قابل مشاهده هماهنگ باشد؛ اطلاعاتی که در صفحه وجود ندارد نباید فقط برای Rich Result به JSON-LD اضافه شود.
نمونه ساختاری بسیار کوتاه JSON-LD میتواند چنین شکلی داشته باشد:
{
"@context": "https://schema.org",
"@type": "Article",
"headline": "Example title"
}این فقط Skeleton مفهومی است و برای Production کافی نیست. Type و Propertyها باید بر اساس نوع واقعی صفحه، Plugin SEO و Structured Data موجود انتخاب شوند تا Duplicate یا Conflict ایجاد نشود.
تست و Validation
Syntax سالم اولین مرحله است. بعد باید بررسی کنید Markup با Policy نوع موردنظر سازگار است و اطلاعات آن با صفحه تناقض ندارد. Rich Results Test و Search Console میتوانند برای Typeهای پشتیبانیشده خطاها یا Warningهای مهم را نشان دهند.
ابزارهای Technical SEO
هیچ ابزار واحدی «حقیقت کامل سایت» را نشان نمیدهد. ابزار خوب باید برای یک سؤال مشخص استفاده شود. قبل از اجرای هر Crawler یا Report بپرسید دنبال چه Evidenceی هستید: URL کشف نمیشود؟ Server Status اشتباه است؟ Canonical متفاوت است؟ Render ناقص است؟ یا Index State مشکل دارد؟
| نیاز | ابزار | خروجی مهم |
|---|---|---|
| وضعیت URL در Google | Search Console | Index، Crawl، Canonical |
| خزش داخلی سایت | SEO Crawler | Status، Link، Metadata |
| Render و Network | DevTools | DOM، Request، Error |
| Performance | PageSpeed / Lighthouse | CWV و Diagnostics |
| درخواست واقعی Crawler | Server Logs | Bot activity و Errors |
Search Console
Google Search Console یکی از مهمترین منابع Evidence برای Technical SEO است، اما قرار نیست هر Report آن در این مقاله دوباره آموزش داده شود. URL Inspection، Page Indexing، Sitemaps، Crawl Stats و Core Web Vitals از بخشهای مهم برای Diagnosis هستند.
وقتی URL خاصی مشکل دارد، URL Inspection میتواند نشان دهد URL آخرینبار چگونه Crawl شده، Fetch موفق بوده یا نه، Indexing مجاز بوده یا نه و Canonical انتخابی Google چیست. برای آموزش کامل پنل و Reportها به آموزش Google Search Console از صفر تا صد مراجعه کنید.
Crawler و DevTools
یک SEO Crawler از دید Linkهای داخلی سایت حرکت میکند و برای پیدا کردن Broken Link، Redirect Chain، Duplicate Metadata، Canonical، noindex و Depth مفید است. DevTools نگاه متفاوتی میدهد: Network Request، Response Header، JavaScript Error و DOM نهایی را میبینید.
Server Logs
Server Log به شما میگوید Crawler واقعاً چه درخواستهایی فرستاده است؛ نه اینکه ابزار تصور میکند چه اتفاقی افتاده. در سایتهای بزرگ، Log Analysis برای تشخیص Crawl Pattern، URLهای پرتکرار، 404، 5xx و Crawl Waste بسیار ارزشمند است.
منتخب داریوش از یوتیوب
در این قسمت دو ویدئوی منتخب انگلیسی درباره آموزش Technical SEO از صفر تا صد از منابع مناسب یوتیوب در یک مسیر آموزشی واحد استفاده شدهاند. این ویدئوها با موتور و هوش مصنوعی اختصاصی سایت داریوش حقیقی دانلود، زیرنویس آنها به فارسی تبدیل و محتوای آموزشی آنها ترجمه شده است. برای نمایش یکپارچهتر، نسخههای منتخب پس از پردازش با یکدیگر ادغام شده و به یک فایل نهایی تبدیل میشوند.
منبع اول، ویدئوی How to perform a technical SEO audit از کانال رسمی Google Search Central با ارائه Martin Splitt است. تمرکز آن روی این است که Audit را به فهرست خطاهای Tool تبدیل نکنیم و هر Finding را با Context سایت، Impact و Priority بسنجیم. منبع دوم، Google Search Console Tutorial 2025 – How To Scale Traffic with GSC SEO از Patrick Rice است که بخشهای عملی Page Indexing، URL diagnosis، Sitemap و Crawl Stats را در محیط Search Console نشان میدهد.
با دیدن نسخه ادغامشده، ابتدا مدل درست فکر کردن در یک Technical SEO Audit را میبینید و سپس با Evidenceهای عملی Search Console آشنا میشوید. هدف این Resource این نیست که جای متن مقاله را بگیرد؛ بلکه قبل از ورود به Workflow Audit، تفاوت میان «گزارش Tool»، «نشانه فنی»، «Root Cause» و «Fix قابلتأیید» را ملموس میکند.
Technical SEO Audit
Audit حرفهای یعنی ساختن فهرست 300 Warning نیست. هدف Audit این است که بدانیم چه مشکلی وجود دارد، چه تعداد URL را درگیر کرده، چه Impactی دارد، Evidence ما چیست و Fix پیشنهادی چه Riskی ایجاد میکند. ابزار فقط Data Collector است؛ تصمیم نهایی به تحلیل نیاز دارد.
Scope را مشخص کنید
قبل از Crawl مشخص کنید Audit برای کل Domain است یا یک Template، Category، Subdomain، Locale یا مجموعه URL. اگر Scope روشن نباشد، Findingها قابل اندازهگیری نیستند. مثلاً 50 خطای Canonical در سایت 200 صفحهای بسیار متفاوت از 50 مورد در فروشگاه چندمیلیونی است.
Baseline نیز ثبت کنید: تعداد URLهای Indexable، Sitemap URLs، 4xx، 5xx، Redirectها، noindex، Canonicalهای غیرمنتظره و Metrics کلیدی. بدون Baseline بعداً نمیدانید Fix واقعاً بهتر شده یا فقط شکل Report عوض شده است.
از Crawl شروع کنید
Crawl داخلی به شما نقشه قابل مشاهده سایت را میدهد. موارد زیر را بررسی کنید:
- URLهای 200، 3xx، 4xx و 5xx
- صفحات بدون Internal Link یا با Depth غیرعادی
- Canonical و noindex
- Sitemap consistency
- Redirect Chain و Loop
- Duplicate Title یا Metadata بهعنوان Signal کمکی
- URL Parameter و Crawl Trap
بعد Crawl را با Search Console، Sitemap و در صورت امکان Server Logs مقایسه کنید. اختلاف Data Sourceها اغلب همان جایی است که Insight واقعی پیدا میشود.
مثلاً اگر Sitemap دههزار URL دارد ولی Crawler فقط هفتهزار URL را از لینکهای داخلی پیدا میکند، سههزار URL باقیمانده نیازمند دستهبندی هستند: آیا صفحات یتیماند؟ آیا فقط Variantهای قدیمیاند؟ آیا URLهای noindex یا Redirect هستند؟ همین اختلاف ساده میتواند بهجای دهها Warning پراکنده، یک مشکل معماری مشخص را آشکار کند.
در سایت WordPress نیز Crawl را فقط با Post و Page محدود نکنید. Archive، Tag، Author، Attachment، Pagination، Search Result، Feed و Parameterها را ببینید. قرار نیست همه این URLها Index شوند، اما باید بدانید چه چیزهایی تولید میشوند، کدامها Crawlable هستند و Policy سایت برای هر خانواده URL چیست.
Root Cause پیدا کنید
یکی از خطاهای رایج این است که Symptom را Fix کنیم. مثال: تعداد زیادی URL با Canonical غیرمنتظره دیده میشود. حذف Canonical و گذاشتن Self-canonical ممکن است فقط علامت را تغییر دهد. Root Cause شاید محتوای تقریباً یکسان، Internal Link به Variant اشتباه، Parameter، Redirect یا Template باشد.
برای هر Finding زنجیره زیر را بنویسید:
- Observation: دقیقاً چه چیزی دیده شده؟
- Evidence: کدام Data Source آن را تأیید میکند؟
- Hypothesis: علت احتمالی چیست؟
- Test: چگونه فرضیه را بررسی میکنیم؟
- Fix: کوچکترین اصلاح مؤثر چیست؟
- Verification: چه چیزی نشان میدهد مشکل حل شده؟
خطاها را اولویتبندی کنید
همه Warningها ارزش یکسان ندارند. برای اولویتبندی ساده میتوانید چهار عامل را در نظر بگیرید: Impact، Scope، Confidence و Risk/Cost.
| Issue | Impact | Priority |
|---|---|---|
| noindex روی Template اصلی | بسیار بالا | فوری |
| 5xx گسترده روی صفحات مهم | بسیار بالا | فوری |
| Redirect Chain داخلی | متوسط | برنامهریزیشده |
| یک Warning بدون اثر قابل اثبات | پایین | بررسی بعدی |
Priority بالا باید هم Impact واقعی و هم Confidence مناسب داشته باشد. Fix پرریسک با Evidence ضعیف میتواند بیشتر از مشکل اولیه آسیب ایجاد کند.
برای نمونه، noindex تصادفی روی Template محصول که هزاران Landing Page را حذف میکند یک Issue با Scope و Impact بسیار بالا است. در مقابل، نبودن چند meta description یکتا ممکن است ارزش بررسی داشته باشد اما معمولاً نباید قبل از مشکل Indexability حل شود. همین تفکیک باعث میشود تیم بهجای «بستن همه Errorهای Tool»، روی مسائلی کار کند که واقعاً مانع Search میشوند.
اگر چند تیم درگیر هستند، Owner هر Fix را مشخص کنید. مشکل Server ممکن است برای Hosting/DevOps باشد، Canonical Template برای Developer، Internal Link برای Content/SEO و Structured Data برای Theme یا Plugin. Audit خوب فقط مشکل را نامگذاری نمیکند؛ مسیر اجرای Fix را نیز روشن میکند.
سناریوی عملی Audit
فرض کنید Category مهمی در Search Console کاهش Index دارد. ابتدا بررسی میکنید URLها در Internal Crawl قابل کشف هستند یا نه. سپس Response Code، robots، noindex و Canonical را چک میکنید. اگر همه سالماند، Sample URLها را در URL Inspection میبینید و Google-selected canonical، last crawl و Render را مقایسه میکنید.
اگر Google Variant دیگری را Canonical انتخاب کرده، قبل از تغییر Tag بررسی میکنید آیا Templateها واقعاً محتوای مشابه دارند، Internal Linkها به کدام URL اشاره میکنند و Sitemap کدام نسخه را معرفی کرده است. این روند از Fix شتابزده جلوگیری میکند.
اصلاح و بررسی نتیجه
Technical SEO با اعمال Fix تمام نمیشود. هر تغییر باید Verification داشته باشد؛ در غیر این صورت فقط فرض کردهایم مشکل حل شده است. Verification در سطح Browser، Server، Crawler و Search Engine انجام میشود.
قبل از تغییر
تا حد امکان Evidence قبل از Fix را ذخیره کنید: Response Header، HTML، Screenshot یا Export Tool، Sample URL، Search Console status و Timestamp. این Baseline برای Regression، Rollback و مقایسه بعدی ارزشمند است.
اگر تغییر گسترده است، ابتدا روی نمونه محدود تست کنید. در Migration، Canonical rewrite، Redirect Rule یا robots change، تغییر کوچکتر امکان تشخیص خطا را بیشتر میکند.
یک نکته مهم در پروژههای فنی این است که همزمان چند متغیر بزرگ را تغییر ندهید. اگر Domain، CMS، URL Structure، Theme و Hosting را در یک روز عوض کنید، حتی اگر Search Performance افت کند تشخیص علت دشوار میشود. تا جای ممکن Migrationها را مرحلهبندی کنید و برای هر مرحله معیار موفقیت تعریف کنید.
برای Fixهای Template-level نیز Sample Set داشته باشید. چند URL از Categoryهای مختلف، صفحات قدیمی و جدید و حالتهای Edge Case را قبل و بعد از Deployment بررسی کنید. درست بودن یک URL نمونه تضمین نمیکند تمام Templateها بهدرستی Update شدهاند.
بعد از تغییر
یک Verification Loop عملی میتواند چنین باشد:
- URL نهایی را با HTTP Request بررسی کنید.
- Response Code و Headerهای مهم را Verify کنید.
- Source HTML و Rendered DOM را مقایسه کنید.
- robots، noindex و Canonical را بررسی کنید.
- Internal Link و Sitemap را با مقصد نهایی هماهنگ کنید.
- در Crawler دوباره همان Scope را تست کنید.
- برای URLهای مهم Search Console را بررسی کنید.
- زمان لازم برای Recrawl و Reprocessing را در نظر بگیرید.
انتظار نداشته باشید همه تغییرات فوراً در Index منعکس شوند. بعضی تغییرها به Recrawl و Reprocessing نیاز دارند. هدف Verification این است که مطمئن شویم Implementation فنی صحیح است و Evidence جدید به سمت نتیجه مطلوب حرکت میکند.
Regression Monitoring
مشکل Technical SEO میتواند با Update Theme، Plugin، CDN، Deployment یا Server Config دوباره برگردد. برای سایتهای مهم، Monitor ساده برای Status Code صفحات کلیدی، robots، Sitemap، Canonical Template و Uptime میتواند جلوی Regression طولانی را بگیرد.
در WordPress، تغییر SEO Plugin، Cache Plugin، Redirect Plugin، Theme یا تنظیمات Reading میتواند رفتار Indexing را تغییر دهد. بعد از Updateهای بزرگ، نمونه URLهای مهم را دوباره بررسی کنید.
چکلیست Technical SEO
برای اجرای Technical SEO Audit بهتر است بررسی سایت را با یک ترتیب ثابت انجام دهید تا مشکلات مهم میان گزارشهای مختلف گم نشوند. چکلیست زیر از دسترسی موتور جستجو و Crawl شروع میشود، سپس Indexing، Canonical، ساختار URL، Sitemap، عملکرد، دادههای ساختاریافته و در نهایت Verification را پوشش میدهد.
وجود خطا در هر ردیف الزاماً به معنی یک مشکل بحرانی نیست. اهمیت هر مورد باید بر اساس نوع صفحه، تعداد URLهای درگیر، تأثیر احتمالی بر Crawl و Indexing و هدف واقعی سایت تعیین شود.
دسترسی و Crawl
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| دسترسی Googlebot | صفحات مهم برای Googlebot قابل دسترسی باشند | بحرانی |
| robots.txt | مسیرهای مهم ناخواسته مسدود نشده باشند | بحرانی |
| Meta Robots | صفحات موردنظر برای ایندکس دارای noindex ناخواسته نباشند | بحرانی |
| X-Robots-Tag | HTTP Header مانع ایندکس صفحات مهم نشود | بحرانی |
| HTTP Status | URLهای اصلی پاسخ صحیح و مورد انتظار بدهند | بالا |
| خطاهای 4xx | لینکهای داخلی مهم به صفحات حذفشده منتهی نشوند | بالا |
| خطاهای 5xx | سرور هنگام Crawl پاسخ پایدار داشته باشد | بحرانی |
| Redirect Chain | زنجیرههای ریدایرکت غیرضروری حذف یا کوتاه شوند | متوسط |
| Redirect Loop | هیچ حلقه ریدایرکتی وجود نداشته باشد | بحرانی |
| Orphan Pages | صفحات مهم از مسیر لینکهای داخلی قابل کشف باشند | بالا |
ایندکس و Canonical
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| Page Indexing | صفحات مهم واجد شرایط ایندکس باشند | بحرانی |
| URL Inspection | وضعیت Crawl، Indexing و Canonical صفحات کلیدی بررسی شود | بالا |
| Canonical | Canonical به نسخه صحیح و قابل ایندکس اشاره کند | بحرانی |
| Self Canonical | صفحات مستقل در صورت نیاز Canonical صحیح به خود داشته باشند | متوسط |
| Canonical Conflict | Canonical با Redirect، Sitemap و Internal Linkها تناقض نداشته باشد | بالا |
| Duplicate URLs | نسخههای تکراری URL بدون دلیل قابل ایندکس نباشند | بالا |
| HTTP و HTTPS | نسخه اصلی HTTPS مشخص و نسخههای جایگزین مدیریت شده باشند | بالا |
| www و non-www | فقط نسخه ترجیحی بهصورت منسجم استفاده شود | بالا |
| Trailing Slash | سیاست URLها ثابت باشد و نسخههای ناخواسته ایجاد نشوند | متوسط |
| پارامترهای URL | پارامترها باعث تولید گسترده URLهای تکراری نشوند | متوسط |
XML Sitemap
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| وجود Sitemap | XML Sitemap معتبر و قابل دسترسی باشد | بالا |
| Sitemap در robots.txt | در صورت استفاده، آدرس Sitemap صحیح معرفی شده باشد | متوسط |
| Search Console | Sitemap صحیح در Search Console ثبت و قابل پردازش باشد | بالا |
| URLهای Sitemap | فقط URLهای Canonical و موردنظر برای ایندکس قرار گیرند | بالا |
| URL ریدایرکتشده | Redirect URLها از Sitemap حذف شوند | متوسط |
| URL دارای noindex | صفحات noindex در Sitemap قرار نگیرند | بالا |
| URL دارای خطای HTTP | صفحات 4xx و 5xx در Sitemap وجود نداشته باشند | بالا |
| تطابق Sitemap و Canonical | URL معرفیشده با نسخه Canonical هماهنگ باشد | بالا |
ساختار URL و لینکها
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| ساختار URL | URLها پایدار، قابل فهم و بدون پیچیدگی غیرضروری باشند | متوسط |
| Internal Links | صفحات مهم لینک داخلی کافی و مرتبط دریافت کنند | بالا |
| Broken Internal Links | لینک داخلی شکسته اصلاح یا حذف شود | بالا |
| Redirected Internal Links | در صورت امکان لینک داخلی مستقیماً به URL نهایی اشاره کند | متوسط |
| Crawl Depth | صفحات مهم بیش از حد در عمق معماری سایت قرار نگیرند | متوسط |
| Navigation | ساختار ناوبری مسیر کشف منطقی صفحات مهم را فراهم کند | بالا |
| Anchor Text | متن لینک داخلی توصیفی و مرتبط با مقصد باشد | متوسط |
Rendering و JavaScript
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| Rendered Content | محتوای اصلی پس از Rendering برای Google قابل مشاهده باشد | بحرانی |
| Rendered Links | لینکهای مهم در خروجی قابل پردازش صفحه وجود داشته باشند | بالا |
| Blocked Resources | فایلهای ضروری CSS و JavaScript ناخواسته مسدود نشده باشند | بالا |
| Client-side Content | وابستگی JavaScript مانع دسترسی به محتوای اصلی نشود | بالا |
| Rendered HTML | HTML مشاهدهشده توسط موتور جستجو با محتوای مورد انتظار سازگار باشد | بالا |
| JavaScript Errors | خطاهای مهم JS مانع تولید محتوا یا Navigation نشوند | بالا |
Performance و Core Web Vitals
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| LCP | Largest Contentful Paint بررسی و عناصر کند شناسایی شوند | بالا |
| INP | Interaction to Next Paint و پاسخگویی صفحه بررسی شود | بالا |
| CLS | جابجایی ناخواسته Layout کنترل شود | بالا |
| Mobile Performance | عملکرد واقعی صفحات مهم روی موبایل بررسی شود | بالا |
| Server Response | کندی Backend و پاسخ اولیه سرور بررسی شود | متوسط |
| Images | ابعاد، حجم و نحوه بارگذاری تصاویر بهینه باشد | متوسط |
| JavaScript Payload | اسکریپتهای سنگین و غیرضروری شناسایی شوند | متوسط |
| CSS Resources | CSS غیرضروری یا مسدودکننده Rendering بررسی شود | متوسط |
موبایل و HTTPS
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| Mobile Rendering | محتوا و قابلیتهای اصلی روی موبایل در دسترس باشند | بحرانی |
| Responsive Layout | صفحه در اندازههای مختلف بدون مشکل جدی نمایش داده شود | بالا |
| Mobile Content | محتوای مهم نسخه دسکتاپ در موبایل حذف نشده باشد | بالا |
| HTTPS | صفحات اصلی از HTTPS معتبر استفاده کنند | بحرانی |
| Mixed Content | منابع ناامن HTTP داخل صفحات HTTPS برطرف شوند | بالا |
| HTTPS Redirect | نسخه HTTP به مقصد HTTPS صحیح هدایت شود | بالا |
Structured Data
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| Schema Type | نوع Structured Data با محتوای واقعی صفحه مطابقت داشته باشد | متوسط |
| Syntax | Markup از نظر ساختاری معتبر باشد | بالا |
| Required Properties | ویژگیهای ضروری نوع مورد استفاده تکمیل شده باشند | متوسط |
| Visible Content | Markup اطلاعات گمراهکننده یا ناموجود در صفحه تولید نکند | بالا |
| Rich Results Test | صفحات واجد شرایط با ابزار مناسب بررسی شوند | متوسط |
| Search Console Enhancements | خطاها و هشدارهای مرتبط بررسی و اولویتبندی شوند | متوسط |
On-page فنی
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| Title | صفحات مهم Title قابل تشخیص و متناسب با محتوای خود داشته باشند | بالا |
| Meta Description | صفحات مهم توضیح مناسب و غیرتکراری داشته باشند | متوسط |
| Heading Structure | ساختار Headingها منطقی و متناسب با سلسلهمراتب محتوا باشد | متوسط |
| Duplicate Content | صفحات بسیار مشابه بدون Strategy مشخص کنترل شوند | بالا |
| Empty Pages | صفحات کممحتوا یا خالی ناخواسته شناسایی شوند | متوسط |
| Soft 404 | صفحاتی که ظاهراً موفقاند اما محتوای واقعی ندارند بررسی شوند | بالا |
سرور و Log
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| Server Stability | خطاهای موقت و قطعیهای مؤثر بر Crawl شناسایی شوند | بحرانی |
| Response Codes | الگوی پاسخ سرور برای Bot و User غیرعادی نباشد | بالا |
| Log Analysis | در Audit پیشرفته رفتار واقعی Crawlerها در Log بررسی شود | متوسط |
| Googlebot Requests | URLهای Crawlشده و الگوی درخواست Googlebot تحلیل شوند | متوسط |
| WAF / CDN | Firewall یا CDN بهاشتباه Crawler معتبر را مسدود نکند | بالا |
| DNS / Hosting | مشکلات زیرساختی مؤثر بر Availability بررسی شوند | بالا |
Verification پس از اصلاح
| بررسی | وضعیت مطلوب | اولویت |
|---|---|---|
| Re-crawl | پس از Fix سایت دوباره Crawl و نتیجه مقایسه شود | بحرانی |
| URL Inspection | URLهای نمونه بعد از اصلاح دوباره بررسی شوند | بالا |
| Live Test | در موارد لازم نسخه Live صفحه آزمایش شود | بالا |
| Canonical Verification | Canonical نهایی از HTML و ابزارهای تشخیصی کنترل شود | بالا |
| Redirect Verification | Redirectها تا مقصد نهایی دوباره آزمایش شوند | بالا |
| Sitemap Verification | URLهای اصلاحشده با Sitemap نهایی تطبیق داده شوند | متوسط |
| Regression Check | بررسی شود Fix باعث ایجاد مشکل جدید نشده باشد | بالا |
| Before / After | وضعیت قبل و بعد از Fix ثبت و مقایسه شود | متوسط |
اولویتبندی مشکلات
آخرین مرحله چکلیست، تبدیل یافتهها به برنامه اصلاح است. تعداد Errorهای یک ابزار بهتنهایی معیار مناسبی برای تعیین اولویت نیست؛ ابتدا باید مشخص شود هر مشکل چه URLهایی را درگیر کرده و چه اثری بر Crawl، Rendering، Indexing یا تجربه کاربر دارد.
| اولویت | معیار | اقدام |
|---|---|---|
| بحرانی | مانع Crawl، Rendering یا Indexing صفحات مهم میشود | بررسی و اصلاح فوری |
| بالا | بخش مهمی از سایت یا Templateهای اصلی را تحت تأثیر قرار میدهد | در ابتدای برنامه Fix |
| متوسط | مشکل واقعی است اما مانع اصلی دسترسی یا ایندکس نیست | پس از موارد پراثر |
| پایین | Impact محدود دارد یا بیشتر یک Optimization تکمیلی است | بعد از مشکلات اصلی |
قاعده عملی این است که Technical SEO Audit با پیدا کردن Error تمام نمیشود. چرخه کامل باید به شکل Crawl → Diagnose → Prioritize → Fix → Verify → Monitor اجرا شود. اگر اصلاحی انجام شده اما نتیجه آن با Crawl مجدد، Search Console یا ابزار مناسب بررسی نشده است، آن Task هنوز از نظر فنی بسته نشده محسوب میشود.
سوالات متداول
در این بخش به پرسشهایی پاسخ میدهیم که معمولاً بعد از یادگیری ساختار اصلی Technical SEO باقی میمانند.
سئو تکنیکال چیست؟
Technical SEO مجموعه اقداماتی است که دسترسی، Crawl، Render، Index، Canonicalization و سلامت فنی صفحات را برای موتور جستجو بهبود میدهد. این حوزه جای Content SEO یا Link Building را نمیگیرد.
Technical SEO با On-Page SEO چه تفاوتی دارد؟
Technical SEO روی زیرساخت و پردازش فنی سایت تمرکز دارد؛ On-Page SEO بیشتر به محتوای صفحه، ساختار معنایی، Heading، Intent و عناصر داخل صفحه مربوط است. این دو مکمل یکدیگرند.
آیا برای سئو تکنیکال باید برنامهنویسی بلد باشیم؟
برای شروع خیر، اما شناخت HTML، HTTP، Browser DevTools و مفاهیم پایه JavaScript کمک بزرگی است. در سطح پیشرفته، درک Server، Log و Code تشخیص Root Cause را سریعتر میکند.
آیا Sitemap باعث ایندکس شدن صفحه میشود؟
خیر. Sitemap به Discovery و معرفی URLهای ترجیحی کمک میکند، اما Indexing را تضمین نمیکند. صفحه همچنان باید Crawlable، Indexable و از نظر Canonical و Content مناسب باشد.
robots.txt با noindex چه تفاوتی دارد؟
robots.txt عمدتاً Crawl را محدود میکند، در حالی که noindex برای جلوگیری از حضور صفحه در Index است. برای اینکه Crawler دستور noindex را ببیند، صفحه نباید از همان Crawler در robots.txt مسدود شده باشد.
Canonical با Redirect چه فرقی دارد؟
Redirect کاربر و Crawler را به URL دیگری منتقل میکند، اما Canonical بدون اجبار به انتقال، نسخه ترجیحی میان URLهای مشابه را اعلام میکند. Canonical یک Signal است و موتور جستجو میتواند انتخاب متفاوتی داشته باشد.
Crawl Budget برای چه سایتهایی مهم است؟
بیشتر برای سایتهای بسیار بزرگ، بسیار پویا یا سایتهایی با Crawl Space عظیم اهمیت دارد. در سایتهای کوچک و متوسط معمولاً رفع Crawl Trap، خطای Server و ساختار لینک داخلی مهمتر از Optimization مصنوعی Crawl Budget است.
آیا Google محتوای JavaScript را ایندکس میکند؟
Google میتواند بسیاری از صفحات JavaScript را Render و Index کند، اما Rendering یک مرحله واقعی با محدودیتهای فنی است. محتوای اصلی و Linkها باید در Render قابل دسترسی باشند و به Interaction خاص کاربر وابسته نشوند.
آیا Structured Data باعث افزایش رتبه میشود؟
Structured Data به فهم بهتر برخی Entityها و Eligibility برای بعضی Search Features کمک میکند، اما تضمین افزایش رتبه یا نمایش Rich Result نیست. محتوای صفحه و Markup باید با هم سازگار باشند.
بعد از رفع مشکل Technical SEO چطور نتیجه را بررسی کنیم؟
Response، Header، Render، robots، Canonical و Internal Link را دوباره تست کنید، سپس Crawl مجدد و داده Search Console را بررسی کنید. Fix بدون Verification کامل نیست.
نتیجهگیری
Technical SEO را بهتر است نه بهعنوان مجموعهای از Checkboxها، بلکه بهعنوان یک سیستم تشخیصی ببینید. سؤال اصلی همیشه این است که URL در کدام مرحله دچار مشکل شده است: Discovery، Crawl، Render، Index، Canonicalization یا Serving؟ وقتی Layer مشکل مشخص شود، ابزار و Fix مناسب نیز بسیار واضحتر میشود.
robots.txt، Sitemap، Canonical، Redirect، Core Web Vitals، Structured Data و Search Console هرکدام فقط بخشی از این سیستم هستند. Sitemap ایندکس را تضمین نمیکند، robots.txt جای noindex نیست، Canonical دستور مطلق نیست، Schema نمایش Rich Result را تضمین نمیکند و Index شدن نیز به معنی رتبه خوب نیست.
برای کار عملی، یک Rule ساده را حفظ کنید: Evidence جمع کنید، Root Cause را پیدا کنید، کوچکترین Fix مؤثر را اعمال کنید و نتیجه را Verify کنید. اگر مشکل اصلی شما در Search Console یا Indexing است، قدم بعدی منطقی مطالعه آموزش Search Console و راهنمای مشکلات ایندکس DJH است؛ اگر Performance مسئله اصلی است، Core Web Vitals را بهصورت مستقل و عمیقتر بررسی کنید.
