وقتی یک سایت ورودی ارگانیک کمی دارد، معمولاً اولین واکنش این است که «مقاله بیشتری منتشر کنیم»، «بک‌لینک بخریم» یا «روی چند کلمه کلیدی کار کنیم».
اما اگر مشکل اصلی سایت جای دیگری باشد، این کارها ممکن است فقط هزینه و زمان بیشتری مصرف کنند.
ممکن است صفحات مهم اصلاً درست Index نشده باشند، چند URL برای یک موضوع با هم رقابت کنند، Canonicalها اشتباه باشند، لینک‌سازی داخلی صفحات اصلی را ضعیف کرده باشد یا Search Intent صفحه با چیزی که کاربر جستجو می‌کند هم‌خوانی نداشته باشد.
اینجاست که SEO Audit معنا پیدا می‌کند: قبل از اینکه تصمیم بگیریم چه چیزی باید ساخته شود، ابتدا بفهمیم وضعیت فعلی سایت چیست و کدام مسئله واقعاً اولویت دارد.
SEO Audit قرار نیست فقط یک لیست بلند از خطاها تحویل دهد؛ باید مشخص کند کدام مشکل مهم‌تر است، چرا مهم است و قدم بعدی دقیقاً چیست.
SEO Audit چیست؟
SEO Audit یا ممیزی سئو، بررسی ساختاریافته وضعیت یک سایت از دید Search است.
هدف Audit این نیست که فقط یک امتیاز کلی به سایت بدهد. هدف این است که مشکلات، ریسک‌ها و فرصت‌های SEO شناسایی شوند و به یک Backlog قابل اجرا تبدیل شوند.
بسته به نوع سایت، یک Audit می‌تواند بخش‌هایی مثل Crawl و Indexation، معماری URL، Canonical، Sitemap، Robots، Technical SEO، محتوای صفحات، Search Intent، Internal Linking، Structured Data، Core Web Vitals و داده‌های Search Console را بررسی کند.
برای بعضی سایت‌ها مشکل اصلی Technical است. برای بعضی دیگر Technical تقریباً سالم است اما صفحات اصلی محتوای ضعیفی دارند. در پروژه‌ای دیگر شاید سایت اصلاً معماری مشخصی برای Services و Content نداشته باشد.
به همین دلیل Audit خوب باید قبل از نسخه‌پیچی، وضعیت واقعی همان سایت را بررسی کند.
SEO Audit چه فرقی با گزارش ابزارهای سئو دارد؟
اجرای یک Crawler یا گرفتن گزارش از یک ابزار می‌تواند بخشی از Audit باشد، اما خود Audit نیست.
ابزار می‌تواند بگوید ۷۰ صفحه Meta Description ندارند، چند Redirect Chain وجود دارد یا تعدادی H1 تکراری هستند. اما هنوز باید مشخص شود کدام‌یک از این موارد واقعاً روی صفحات مهم اثر دارند.
برای مثال نبود Meta Description الزاماً یک Critical Error نیست. Google می‌تواند Snippet را براساس محتوای صفحه و Query تولید کند. در مقابل، یک Canonical اشتباه روی صفحه‌ای که باید ورودی تجاری بگیرد می‌تواند اولویت بسیار بالاتری داشته باشد.
Audit حرفه‌ای یعنی داده ابزارها با Context سایت ترکیب شود:
- کدام صفحات برای کسب‌وکار مهم‌اند؟
- کدام URLها باید Index شوند و کدام‌ها نباید؟
- کدام مشکلات روی Templateهای بزرگ اثر می‌گذارند؟
- چه چیزی جلوی Crawl یا Index صفحه اصلی درآمدی را گرفته است؟
- چه چیزی فقط یک Warning کم‌اهمیت است؟
بدون این مرحله، خروجی خیلی راحت تبدیل به فایل بزرگی می‌شود که صدها Issue دارد اما تیم نمی‌داند از کجا شروع کند.
چه زمانی SEO Audit لازم است؟
ممکن است هر سایتی در مقاطع مختلف به Audit نیاز داشته باشد، اما بعضی شرایط نیاز به بررسی جدی‌تر را واضح‌تر می‌کنند.
- سایت تازه تحویل گرفته شده و سابقه SEO آن مشخص نیست.
- ورودی یا Impression افت کرده و دلیل آن روشن نیست.
- تعداد زیادی صفحه وجود دارد اما صفحات مهم رشد نمی‌کنند.
- سایت Redesign یا Migration شده است.
- URLها، دسته‌بندی‌ها یا ساختار سایت تغییر کرده‌اند.
- محتوای زیادی تولید شده اما رشد Search متناسب نیست.
- چند تیم یا پیمانکار قبلاً روی سایت کار کرده‌اند و تصمیم‌های قبلی مستند نیستند.
- قبل از شروع قرارداد ماهانه SEO می‌خواهید Baseline واقعی داشته باشید.
اگر هنوز دقیقاً نمی‌دانید مشکل کجاست، شروع از SEO Audit و نقشه اولویت‌ها معمولاً منطقی‌تر از خرید یک Package عمومی است.
چک‌لیست SEO Audit از کجا شروع می‌شود؟
Audit خوب از Crawl شروع می‌شود، اما فقط به Crawl ختم نمی‌شود.
اول باید مشخص شود Search Engine چه URLهایی را پیدا می‌کند، چه URLهایی Index می‌شوند و آیا این وضعیت با چیزی که کسب‌وکار انتظار دارد هماهنگ است یا نه.
بعد از آن باید از سطح Technical به ساختار صفحات، Content و داده Performance رفت.
برای اینکه Audit قابل اجرا باشد، بهتر است هر Issue با سه سؤال ثبت شود:
- مشکل دقیقاً چیست؟
- روی کدام URL یا Template اثر دارد؟
- اولویت اصلاح آن نسبت به سایر مشکلات چقدر است؟
۱. Crawl و دسترسی موتور جستجو
اگر Googlebot نتواند یک URL مهم را به‌درستی دریافت کند، بسیاری از بهینه‌سازی‌های بعدی بی‌اثر می‌شوند.
در این بخش باید بررسی شود:
- صفحات مهم HTTP 200 برمی‌گردانند یا نه.
- Redirectهای غیرضروری یا Chain وجود دارد یا نه.
- URLهای مهم ناخواسته در Robots.txt Block نشده‌اند.
- Meta Robots یا X-Robots-Tag به‌اشتباه noindex نیست.
- صفحات مهم پشت Login یا محدودیت غیرضروری قرار ندارند.
- Soft 404 یا Error Pageهایی که 200 می‌دهند وجود ندارند.
- Crawl روی URLهای کم‌ارزش مثل Filterهای بی‌نهایت هدر نمی‌رود.
برای URLهای حساس، URL Inspection در Search Console کمک می‌کند ببینید Google صفحه را چگونه مشاهده کرده و آیا مانعی برای Crawling یا Indexing گزارش شده است.
۲. Indexation؛ چه چیزی باید در گوگل باشد؟
تعداد بیشتر صفحات Index شده الزاماً نشانه بهتر بودن SEO نیست.
یک سایت ممکن است هزاران URL Index داشته باشد، اما بخش زیادی از آن‌ها Filter، Search Result داخلی، Tag ضعیف، Pagination بی‌ارزش یا نسخه تکراری صفحات باشند.
در Audit باید مشخص شود:
- کدام URLها باید Index شوند.
- کدام URLها نباید Index شوند.
- صفحات مهمی که Index نیستند کدام‌اند.
- صفحاتی که بدون ارزش کافی Index شده‌اند کدام‌اند.
- آیا Index Coverage با معماری واقعی سایت هماهنگ است.
این بخش را نباید فقط با دستور site: بررسی کرد. Search Console، Sitemap، Crawl و نمونه‌برداری از URLهای اصلی تصویر دقیق‌تری می‌دهند.
۳. Sitemap و Robots.txt
XML Sitemap باید فهرستی تمیز از URLهایی باشد که واقعاً می‌خواهید Search Engine آن‌ها را بشناسد.
وجود URLهای Redirect، 404، noindex یا Duplicate داخل Sitemap معمولاً نشانه ضعف در مدیریت URLهاست.
در Audit بررسی کنید:
- Sitemap قابل دسترسی است.
- فقط URLهای Canonical و قابل Index داخل آن هستند.
- URLهای قدیمی یا حذف‌شده باقی نمانده‌اند.
- lastmod فقط در صورت Update واقعی تغییر می‌کند.
- Robots.txt با سیاست Indexation سایت تضاد ندارد.
Google توصیه می‌کند Sitemap برای اطلاع‌رسانی درباره URLهای سایت استفاده شود، اما Sitemap جایگزین لینک‌سازی داخلی و معماری قابل Crawl نیست.
۴. Canonical و صفحات تکراری
Canonical یکی از بخش‌هایی است که خطای کوچک در آن می‌تواند اثر بزرگی روی Indexation داشته باشد.
Google از Canonicalization برای انتخاب URL نماینده میان صفحات Duplicate یا بسیار مشابه استفاده می‌کند. Redirect، Sitemap و rel="canonical" از سیگنال‌هایی هستند که می‌توانند در این انتخاب نقش داشته باشند.
در Audit باید بررسی شود:
- صفحات اصلی Self-canonical صحیح دارند.
- Canonical به URL اشتباه، Redirect یا 404 اشاره نمی‌کند.
- Template سایت Canonical همه صفحات را به یک URL مشترک نمی‌زند.
- HTTP/HTTPS، www/non-www یا Slash Variation کنترل شده است.
- Filter و Sort Pageها Strategy مشخص دارند.
- نسخه‌های مشابه بی‌دلیل با هم رقابت نمی‌کنند.
نکته مهم این است که Canonical یک Hint قوی است، نه دستور مطلق؛ Google ممکن است URL دیگری را Canonical انتخاب کند. اگر Google-selected canonical با انتخاب شما متفاوت است، باید دلیل آن را بررسی کرد.
۵. معماری سایت و ساختار URLها
SEO Audit فقط درباره Tagها نیست. معماری اطلاعات مشخص می‌کند صفحات مهم چقدر راحت توسط کاربر و Crawler پیدا می‌شوند.
برای یک سایت خدماتی باید بتوان مسیر منطقی‌ای مثل این را دید:
صفحه اصلی → دسته خدمت → صفحه خدمت → مقاله‌های مرتبط
اگر صفحه‌ای که برای کسب‌وکار مهم است فقط از یک لینک مخفی در Footer قابل دسترسی باشد، ارزش معماری آن با صفحه‌ای که در مسیر اصلی سایت قرار دارد یکسان نیست.
در این بخش بررسی کنید:
- Hierarchy صفحات روشن است.
- صفحات درآمدی در عمق غیرضروری قرار ندارند.
- URLها قابل فهم و پایدار هستند.
- Category و Tagهای مشابه بی‌دلیل ایجاد نشده‌اند.
- Breadcrumb با ساختار واقعی سایت هماهنگ است.
۶. سئو داخلی صفحات مهم
بعد از Technical Foundation باید خود صفحات را بررسی کرد.
یک صفحه ممکن است کاملاً Crawl و Index شود، اما هنوز برای Query هدف صفحه خوبی نباشد.
برای صفحات مهم موارد زیر را بررسی کنید:
- Title موضوع و Intent صفحه را درست منتقل می‌کند.
- فقط یک H1 اصلی وجود دارد.
- Headingها ساختار منطقی دارند.
- Intro سریع وارد مسئله می‌شود.
- محتوا سؤال‌های اصلی کاربر را پاسخ می‌دهد.
- صفحه با صفحات دیگر سایت Cannibalization ایجاد نمی‌کند.
- CTA با Intent صفحه هماهنگ است.
- تصاویر Alt مناسب و Dimensions واقعی دارند.
این همان جایی است که تعریف پایه سئو و نقش آن در کسب‌وکار وارد عمل می‌شود: هدف صرفاً حضور صفحه در Index نیست؛ باید صفحه مناسبی برای نیاز مناسب وجود داشته باشد.
۷. Search Intent و Cannibalization
یکی از اشتباهات رایج این است که برای هر Keyword Variation یک URL مستقل ساخته شود.
مثلاً سایت ممکن است هم صفحه «خدمات سئو»، هم «سئو سایت»، هم «بهینه‌سازی سایت» و هم چند مقاله بسیار مشابه داشته باشد، درحالی‌که همه تقریباً یک Intent را هدف می‌گیرند.
در Audit باید Queryها و صفحات کنار هم دیده شوند.
اگر چند URL برای یک نیاز یکسان رقابت می‌کنند، ممکن است نیاز به Merge، Reposition، Canonical یا بازطراحی معماری محتوا باشد.
از طرف دیگر، اگر یک صفحه سعی می‌کند چند Intent کاملاً متفاوت را همزمان پوشش دهد، ممکن است لازم باشد موضوع‌ها جدا شوند.
۸. کیفیت و Originality محتوا
SEO Audit خوب فقط تعداد کلمات را اندازه نمی‌گیرد.
محتوا باید از نظر مفید بودن، کامل بودن، تجربه واقعی و ارزش اضافه بررسی شود.
Google در راهنمای People-first Content پیشنهاد می‌کند از خودتان بپرسید آیا محتوا اطلاعات، تحقیق یا تحلیل Original ارائه می‌کند و آیا کاربر بعد از خواندن آن احساس می‌کند برای رسیدن به هدفش اطلاعات کافی گرفته است.
در Audit محتوا، دنبال این موارد باشید:
- صفحات Thin یا بسیار سطحی.
- صفحات Duplicate یا Near-duplicate.
- مقاله‌هایی که صرفاً نتایج دیگران را خلاصه کرده‌اند.
- محتوای قدیمی با Factهای منقضی.
- صفحات بدون هدف Search مشخص.
- محتوایی که برای Keyword ساخته شده اما برای کاربر ارزش واقعی ندارد.
مقاله «محتوای یونیک واقعاً یعنی چه؟» دقیق‌تر توضیح می‌دهد چرا عبور از Plagiarism Checker به‌تنهایی معیار کیفیت محتوا نیست.
۹. لینک‌سازی داخلی و Orphan Pages
Internal Linking هم به کاربر کمک می‌کند مسیر بعدی را پیدا کند و هم ارتباط موضوعی صفحات را روشن‌تر می‌کند.
در Audit باید حداقل این موارد بررسی شوند:
- صفحات مهم چند لینک داخلی دریافت می‌کنند.
- آیا Anchor Text توصیفی و طبیعی است.
- صفحات Orphan وجود دارند یا نه.
- لینک‌های داخلی شکسته وجود دارند یا نه.
- مقاله‌های Cluster به Pillar یا Service Page مرتبط وصل‌اند یا نه.
- صفحات قدیمی به محتوای جدید لینک می‌دهند یا نه.
برای سایت خدماتی، معماری لینک بهتر است تصادفی نباشد. Service Pageها، Pillarها و Cluster Content باید ارتباط مشخصی داشته باشند.
۱۰. Structured Data و Search Appearance
Structured Data به Google کمک می‌کند بعضی اطلاعات صفحه را ساختاریافته‌تر درک کند، اما Markup اشتباه یا نامعتبر می‌تواند باعث شود Rich Result موردنظر نمایش داده نشود.
در Audit باید Schema براساس نوع صفحه بررسی شود؛ مثلاً Article برای مقاله، BreadcrumbList برای Breadcrumb و سایر Typeها فقط زمانی که واقعاً با محتوای صفحه سازگارند.
کارهای مهم:
- JSON-LD از نظر Syntax معتبر باشد.
- داده Markup با محتوای قابل مشاهده صفحه تضاد نداشته باشد.
- Propertyهای لازم و توصیه‌شده بررسی شوند.
- Rich Results Test برای صفحات نمونه اجرا شود.
- Search Console برای Invalid Itemهای جدید مانیتور شود.
وجود Schema به‌تنهایی تضمین نمی‌کند Rich Result نمایش داده شود؛ Eligibility و انتخاب نهایی همچنان به Google بستگی دارد.
۱۱. Mobile و Page Experience
Audit فنی نباید فقط روی Desktop انجام شود.
صفحات باید روی Mobile قابل استفاده باشند، محتوای اصلی واضح دیده شود و Interactionهای مهم به‌درستی کار کنند.
Google برای Page Experience توصیه می‌کند فقط روی یک Signal یا یک Score متمرکز نشوید و تجربه کلی صفحه را بررسی کنید.
مواردی که ارزش بررسی دارند:
- نمایش صحیح محتوا روی Mobile.
- HTTPS.
- نبود Interstitial مزاحم.
- واضح بودن محتوای اصلی.
- Core Web Vitals.
- عدم Overflow افقی.
- قابل استفاده بودن Navigation و Formها.
گرفتن نمره ۱۰۰ در یک ابزار Performance هدف نهایی SEO نیست. مسئله این است که مشکلات واقعی تجربه و Rendering شناسایی شوند.
۱۲. Core Web Vitals و Performance
Core Web Vitals بخشی از Page Experience هستند و بهتر است با داده واقعی کاربر در صورت وجود بررسی شوند.
در Audit می‌توان LCP، INP و CLS را برای Templateهای اصلی بررسی کرد و سپس مشخص کرد مشکل از کجا می‌آید.
مثلاً:
- LCP ضعیف ممکن است از تصویر Hero، Server Response یا Rendering سنگین باشد.
- CLS می‌تواند از تصویر بدون Dimensions یا Componentهایی که بعداً وارد Layout می‌شوند ایجاد شود.
- INP ضعیف می‌تواند به JavaScript سنگین یا Main Thread طولانی مرتبط باشد.
مهم است که Audit فقط Metric را گزارش نکند؛ باید Root Cause احتمالی و اقدام بعدی مشخص باشد.
۱۳. Search Console؛ داده واقعی قبل از حدس
اگر Search Console داده کافی دارد، Audit بدون بررسی آن ناقص است.
Performance Report می‌تواند نشان دهد:
- کدام صفحات Impression می‌گیرند اما CTR پایین دارند.
- کدام Queryها صفحه مناسب ندارند.
- کدام صفحات قبلاً رشد داشته‌اند و افت کرده‌اند.
- آیا یک Query بین چند URL تقسیم شده است.
- کدام صفحات در آستانه Page 1 هستند.
Search Console همچنین برای بررسی Indexing، Sitemap و URLهای نمونه کاربرد دارد.
اما داده باید با بازه زمانی و Context درست تفسیر شود. کاهش Click همیشه به معنی Technical Error نیست؛ Seasonality، تغییر Demand، Competition یا تغییر Search Interface هم می‌توانند اثر داشته باشند.
۱۴. بک‌لینک‌ها در SEO Audit چه نقشی دارند؟
Backlink Audit می‌تواند بخشی از بررسی باشد، اما نباید تمام Audit را به تعداد لینک‌ها تقلیل داد.
بسته به پروژه می‌توان مواردی مثل Domainهای لینک‌دهنده، Relevance، صفحات مقصد، Anchor Distribution و لینک‌های از دست‌رفته را بررسی کرد.
هدف این نیست که هر لینک ضعیفی را «سمی» اعلام کنیم. قبل از هر اقدام باید Context، الگوی لینک‌سازی و سابقه سایت بررسی شود.
برای بسیاری از سایت‌ها، اصلاح Technical و Content قبل از افزایش بودجه Off-page اولویت بیشتری دارد.
خروجی یک SEO Audit خوب باید چه شکلی باشد؟
یک فایل صدصفحه‌ای بدون اولویت‌بندی الزاماً Audit خوبی نیست.
خروجی باید قابل تبدیل به اجرا باشد.
برای هر Issue بهتر است این اطلاعات وجود داشته باشند:
- عنوان مشکل.
- شرح کوتاه و قابل فهم.
- URL یا Templateهای متاثر.
- Evidence یا نمونه.
- Impact احتمالی.
- اولویت.
- مسئول اجرا؛ SEO، Developer، Content یا Design.
- اقدام پیشنهادی.
- روش QA بعد از اصلاح.
به‌جای اینکه همه چیز Critical باشد، می‌توان مشکلات را به چند سطح تقسیم کرد:
- P0: مانع جدی Crawl، Index یا عملکرد صفحات حیاتی.
- P1: مشکل مهم با اثر قابل توجه که باید در Sprintهای نزدیک حل شود.
- P2: بهبود با اولویت متوسط.
- P3: Optimization و Cleanup کم‌ریسک.
این مدل باعث می‌شود تیم بداند فردا صبح از کجا شروع کند.
SEO Audit چه چیزهایی را نباید وعده دهد؟
Audit نمی‌تواند رتبه یک Google را تضمین کند.
همچنین نباید هر Warning ابزار را به‌عنوان «خطای بحرانی SEO» بفروشد.
چند نشانه خروجی ضعیف:
- صدها Issue بدون Priority.
- تمرکز افراطی روی Keyword Density.
- وعده رتبه تضمینی بعد از اصلاح Audit.
- نبود نمونه URL و Evidence.
- پیشنهادهای Generic که برای هر سایتی قابل استفاده‌اند.
- ندیدن Search Console و صفحات اصلی کسب‌وکار.
- یکسان دانستن Warning ابزار با Business Impact.
بعد از SEO Audit چه کار کنیم؟
Audit پایان کار نیست؛ نقطه تصمیم‌گیری است.
بعد از Audit باید Backlog ساخته شود و کارها براساس Dependency مرتب شوند.
مثلاً اگر Template دسته‌بندی Canonical اشتباه دارد، منطقی نیست قبل از اصلاح آن ده‌ها Category Content جدید منتشر شود.
یا اگر صفحات Service اصلی هنوز ساختار ضعیفی دارند، شاید اصلاح همان صفحات قبل از تولید ۳۰ مقاله جدید بازده بیشتری داشته باشد.
در بعضی پروژه‌ها تیم داخلی می‌تواند Backlog را اجرا کند. در بعضی دیگر بخشی از کار به Developer، Content Team یا تیم خدمات SEO و رشد ویرینو سپرده می‌شود.
هزینه اجرای این موارد هم بسته به Scope متفاوت است؛ به همین دلیل در راهنمای هزینه سئو سایت در ۱۴۰۵ بین Audit، اجرای موردی و مدیریت مستمر SEO تفکیک کرده‌ایم.
چک‌لیست کوتاه SEO Audit
اگر بخواهیم کل Audit را به یک Checklist فشرده تبدیل کنیم، حداقل این موارد باید بررسی شوند:
- Crawlability و Status Codeها.
- Robots.txt و Meta Robots.
- Indexation صفحات مهم.
- XML Sitemap.
- Canonical و Duplicate URLها.
- Redirectها و 404ها.
- معماری سایت و URL Structure.
- Title، H1 و Heading Structure.
- Search Intent و Cannibalization.
- کیفیت و تازگی محتوا.
- Internal Linking و Orphan Pages.
- Structured Data.
- Mobile Experience.
- Core Web Vitals.
- Search Console Performance.
- Backlink Profile در صورت نیاز.
- اولویت‌بندی و Backlog اجرایی.
این لیست نقطه شروع است، نه قالب ثابت برای همه سایت‌ها. فروشگاه، SaaS، سایت خدماتی و Publisher هرکدام مسائل متفاوتی دارند.
جمع‌بندی
SEO Audit یعنی قبل از اینکه منابع بیشتری وارد SEO کنیم، بفهمیم سایت الان کجاست.
یک Audit حرفه‌ای باید Technical، Content، Architecture، Internal Links و داده واقعی Search را کنار هم بگذارد و در نهایت یک لیست اولویت‌بندی‌شده از اقدام‌ها تحویل دهد.
مهم‌ترین تفاوت Audit خوب با گزارش خودکار ابزارها این است که همه Issueها را هم‌ارزش نمی‌بیند.
اگر یک مشکل جلوی Index شدن صفحه درآمدی را گرفته است، باید قبل از Warningهای ظاهری کم‌اهمیت حل شود. اگر Technical سالم است اما صفحه Search Intent را پاسخ نمی‌دهد، تولید بک‌لینک بیشتر مسئله اصلی را حل نمی‌کند.
هدف SEO Audit پیدا کردن بیشترین تعداد خطا نیست؛ پیدا کردن کمترین تعداد اقدام مهمی است که بیشترین مانع را از مسیر رشد سایت برمی‌دارند.
