Search Console چیست؟
Google Search Console یا بهاختصار GSC سرویسی از Google است که اطلاعات مرتبط با حضور سایت در Google Search را در اختیار مالک یا مدیر سایت قرار میدهد. Search Console به شما کمک میکند عملکرد ارگانیک سایت را اندازهگیری کنید، مشکلات Crawl و Indexing را بررسی کنید، Sitemap را به Google معرفی کنید و هشدارهای مهم فنی یا امنیتی را ببینید.
Search Console ابزار «بهینهسازی خودکار رتبه» نیست. اضافهکردن سایت به آن نیز باعث نمیشود صفحات بهصورت تضمینی ایندکس یا رتبهبندی شوند. Google بسیاری از URLهای وب را بدون ثبت دستی پیدا میکند؛ ارزش Search Console در این است که وضعیت سایت را شفافتر میکند و برای تشخیص مشکل داده قابل استفاده میدهد.
چه کسانی نیاز دارند؟
تقریباً هر کسی که مسئولیت دیدهشدن یک سایت در Google را دارد از Search Console سود میبرد: مدیر سایت، متخصص SEO، تولیدکننده محتوا، توسعهدهنده، مدیر فروشگاه اینترنتی و حتی صاحب کسبوکاری که میخواهد بداند کاربران از چه جستجوهایی وارد سایت میشوند. سطح استفاده متفاوت است؛ یک مدیر محتوا بیشتر با Queries و Pages کار میکند، در حالی که توسعهدهنده ممکن است URL Inspection، Page Indexing و Crawl Stats را بیشتر بررسی کند.
چه کاری انجام نمیدهد؟
Search Console جایگزین ابزار Analytics، Log Analyzer، Crawler تخصصی یا Rank Tracker کامل نیست. دادههای آن بخشی از تصویر را نشان میدهند. برای مثال Search Console میگوید کاربر قبل از ورود از چه Queryای آمده و نتیجه سایت در Google چه Performanceای داشته است، اما رفتار کامل کاربر بعد از ورود به سایت موضوع ابزارهای Analytics است.
تفاوت با Analytics
Search Console و Google Analytics دو سؤال متفاوت را پاسخ میدهند. Search Console روی اتفاقاتی تمرکز دارد که در Google Search و مسیر رسیدن کاربر به سایت رخ میدهند؛ Analytics بیشتر رفتار کاربر پس از ورود به سایت را اندازهگیری میکند. به همین دلیل انتظار نداشته باشید تعداد Click در Search Console دقیقاً با Session یا User در Analytics برابر باشد.
| ابزار | تمرکز اصلی | نمونه داده |
|---|---|---|
| Search Console | حضور در Google Search | Click، Impression، Query، Position |
| Google Analytics | رفتار داخل سایت | Session، User، Event، Conversion |
| استفاده ترکیبی | مسیر کاملتر کاربر | کشف در Search تا رفتار داخل سایت |
برای تحلیل SEO بهتر است این دو منبع را رقیب هم نبینید. Search Console میتواند نشان دهد یک صفحه Impression زیادی گرفته ولی CTR آن پایین است؛ Analytics میتواند بعد از ورود کاربر نشان دهد آیا همان صفحه تعامل و Conversion مناسبی دارد یا خیر.
ثبت سایت
برای شروع به یک حساب Google نیاز دارید. سپس در Search Console یک Property اضافه میکنید و مالکیت آن را تأیید میکنید. Property محدودهای از سایت است که دادههای آن را میبینید. انتخاب نوع Property مهم است، چون تعیین میکند چه URLهایی داخل همان مجموعه قرار میگیرند.
Domain یا URL Prefix
Domain Property معمولاً بهترین نمای کلی را از یک دامنه میدهد، چون پروتکلها و Subdomainهای مختلف دامنه را در یک Property پوشش میدهد. تأیید مالکیت Domain Property با DNS انجام میشود. اگر سایت شما نسخههای مختلفی مانند www، بدون www یا Subdomain دارد، این روش دید جامعتری ایجاد میکند.
URL-prefix Property فقط URLهایی را پوشش میدهد که با Prefix مشخصشده شروع میشوند. پروتکل و Host اهمیت دارند؛ برای نمونه https://example.com/ با http://example.com/ یا https://www.example.com/ یک Prefix یکسان نیست. مزیت URL-prefix این است که روشهای Verification بیشتری مانند HTML file یا HTML tag میتواند در دسترس باشد.
| نوع Property | محدوده | مناسب برای |
|---|---|---|
| Domain | دامنه و Subdomainها | دید کلی سایت |
| URL Prefix | Prefix دقیق URL | بخش یا نسخه مشخص |
| هر دو | نمای کلی + تحلیل جزئی | پروژههای حرفهای |
تأیید مالکیت
در Domain Property معمولاً Google یک رکورد DNS در اختیار شما قرار میدهد که باید در DNS Provider دامنه ثبت شود. انتشار DNS ممکن است فوری نباشد، بنابراین اگر Verification در لحظه اول انجام نشد به معنی اشتباهبودن تنظیمات نیست. در URL-prefix بسته به شرایط میتوانید از DNS، HTML file، HTML tag یا روشهای پشتیبانیشده دیگر استفاده کنید.
توکن Verification را مانند یک مجوز دسترسی جدی بگیرید. اگر کاربری دیگر نباید Owner باشد، فقط حذف او از فهرست Users همیشه کافی نیست؛ باید بررسی شود Verification Token قدیمی همچنان روی سایت یا DNS باقی نمانده باشد.
شروع کار با پنل
پس از Verification، بهتر است قبل از تحلیل عددها یک نقشه ذهنی از Search Console بسازید: Performance برای دادههای جستجو، URL Inspection برای یک URL مشخص، Indexing برای وضعیت کشف و ایندکس، Experience برای گزارشهای تجربه صفحه، و بخشهای امنیتی و تنظیمات برای کنترل دسترسی و مشکلات جدی سایت.
ویدئوی آموزش عملی
ویدیوی نهایی این آموزش از دو منبع منتخب تشکیل میشود: یک Walkthrough عملی و جدید از محیط Google Search Console و یک آموزش رسمی Google Search Central درباره تحلیل Performance. ترکیب این دو باعث میشود هم جای ابزارها و Workflow پنل را بهصورت تصویری ببینید و هم از همان ابتدا متوجه شوید هدف اصلی فقط پیدا کردن منوها نیست؛ باید دادههای Search را به سؤال، تشخیص و اقدام SEO تبدیل کنید.
[PLACEHOLDER VIDEO — آموزش Google Search Console از صفر تا صد | MERGED VIDEO]
پس از مشاهده ویدئو، ادامه مقاله هر بخش را با جزئیات بیشتر باز میکند: معنی Metricها، روش Filter کردن داده، تشخیص مشکل Indexing، استفاده درست از URL Inspection و ساخت یک Routine عملی برای بررسی سایت. بنابراین ویدئو نقش نقشه اولیه را دارد و متن مقاله نقش مرجع اجرایی و عیبیابی را تکمیل میکند.
تحلیل Performance
Performance Report مهمترین بخش Search Console برای تحلیل حضور سایت در نتایج جستجو است. در نمای Search Results معمولاً چهار Metric اصلی را میبینید: Click، Impression، Average CTR و Average Position. هیچکدام بهتنهایی کافی نیستند؛ تحلیل درست از رابطه آنها با Query، Page، Country، Device، Search Appearance و بازه زمانی به دست میآید.
Click و Impression
Click نشان میدهد چند بار کاربر از یک نتیجه Google به سایت رسیده است. Impression بیانگر نمایش نتیجه سایت در شرایطی است که طبق قواعد گزارش Google یک Impression محسوب میشود. افزایش Impression همیشه به معنی افزایش Click نیست؛ ممکن است صفحه برای Queryهای بیشتری ظاهر شود ولی هنوز Position یا جذابیت Snippet برای گرفتن Click کافی نباشد.
CTR
CTR یا Click-through Rate از نسبت Click به Impression محاسبه میشود. CTR را نباید با یک عدد ثابت «خوب» یا «بد» ارزیابی کرد. Position، نوع Query، Brand بودن جستجو، وجود Featureهای SERP، نوع Device و Intent روی CTR اثر دارند. بهترین مقایسه معمولاً مقایسه همان Page یا Query با گذشته خودش و گروه مشابه است.
Average Position
Average Position میانگین موقعیت گزارششده برای بالاترین نتیجه متعلق به Property در Impressionهای ثبتشده است و نباید آن را معادل «رتبه ثابت صفحه» در نظر گرفت. Search Result برای کاربران، دستگاهها، مکانها و Queryهای مختلف میتواند متفاوت باشد. بنابراین تغییر جزئی Position را بدون بررسی Click و Impression تفسیر نکنید.
Query و Page
تب Queries نشان میدهد کاربران با چه عبارتهایی سایت را دیده یا روی آن کلیک کردهاند. Pages عملکرد را از زاویه URL بررسی میکند. تحلیل حرفهای زمانی شکل میگیرد که این دو را به هم متصل کنید: ابتدا یک Page را انتخاب کنید، سپس Queryهای همان Page را ببینید؛ یا یک Query مهم را Filter کنید و ببینید کدام صفحات برای آن ظاهر میشوند.
اگر برای یک Query چند URL مختلف بهطور مداوم نمایش میگیرند، فوراً آن را Cannibalization قطعی اعلام نکنید. ابتدا Intent، نوع صفحات، بازه زمانی و Search Appearance را بررسی کنید. گاهی چند URL برای زیرموضوعهای متفاوت یک Query کاملاً طبیعی است.
Filter و Compare
قدرت اصلی Performance Report در Filter و Compare است. مقایسه 28 روز اخیر با دوره قبل، مقایسه سالبهسال یا Filter کردن یک Directory میتواند الگوهایی را آشکار کند که در نمودار کلی سایت دیده نمیشوند. برای سایتهای بزرگ، Regex نیز امکان ساخت Filterهای گروهی دقیقتر را فراهم میکند.
مثلاً برای بررسی مقالات یک بخش میتوانید بهجای نگاهکردن به کل Property، فقط URLهای همان مسیر را جدا کنید. هدف Filter کردن «کمکردن داده» نیست؛ هدف این است که یک سؤال مشخص داشته باشید و فقط داده مرتبط با همان سؤال را ببینید.
تبدیل داده به تصمیم
گزارش Performance زمانی ارزشمند میشود که برای هر الگو یک اقدام منطقی تعریف کنید. بهجای اینکه هر هفته فقط Total Click را یادداشت کنید، صفحات را به گروههای قابل تصمیم تقسیم کنید.
| الگو | برداشت اولیه | اقدام بعدی |
|---|---|---|
| Impression بالا، CTR پایین | فرصت بهبود Snippet یا Intent | Query و Position را بررسی کنید |
| Position بهتر، Click ثابت | ممکن است تقاضا یا CTR محدود باشد | Impression و SERP را مقایسه کنید |
| Click و Impression هر دو افت کرده | افت Visibility یا Demand محتمل است | Page/Query/Date را Segment کنید |
| Impression رشد کرده، Click رشد نکرده | ورود به Queryهای جدید | Queryهای جدید و Intent را بررسی کنید |
فرصتهای محتوایی
یکی از کاربردهای مفید Search Console پیدا کردن Queryهایی است که صفحه برای آنها Visibility دارد اما پاسخ آن هنوز کامل نیست. اگر Query با موضوع اصلی صفحه همراستا است، میتوان بخشی از محتوا را دقیقتر کرد. اگر Query Intent متفاوتی دارد، بهتر است بهجای متورمکردن همان صفحه، یک Cluster مستقل ساخته شود.
افت ورودی
برای تحلیل افت، ابتدا مشخص کنید افت Site-wide است یا محدود به چند Page. سپس Search Type، Device، Country و Query را جدا کنید. افت Click بدون افت Impression با افت همزمان هر دو Metric معنای یکسان ندارد. همچنین پیش از نتیجهگیری درباره Penalty یا Core Update، وضعیت Manual Actions، Indexing و خطاهای فنی را بررسی کنید.
URL Inspection
URL Inspection برای بررسی یک URL مشخص طراحی شده است. این ابزار به شما میگوید Google درباره نسخه Indexed یک صفحه چه اطلاعاتی دارد و امکان Test Live URL را برای بررسی نسخه فعلی صفحه فراهم میکند. تفاوت این دو دیدگاه بسیار مهم است: داده Indexed ممکن است مربوط به آخرین Crawl باشد، اما Live Test وضعیت قابل دسترسبودن URL در همین لحظه را بررسی میکند.
چه چیزهایی را ببینیم؟
هنگام عیبیابی، فقط جمله بالای Report را نخوانید. بخشهای مربوط به Crawl Allowed، Page Fetch، Indexing Allowed و Canonical را بررسی کنید. اگر Page Fetch موفق نیست، مشکل دسترسی یا پاسخ Server میتواند مطرح باشد. اگر Indexing Allowed برابر No است، باید Directiveهایی مانند noindex را بررسی کنید. اگر Google-selected Canonical با انتظار شما متفاوت است، موضوع Duplicate و Canonicalization اهمیت پیدا میکند.
Test Live URL
Live Test پاسخ میدهد که Google در زمان تست میتواند URL را دریافت کند یا خیر. این تست برای بررسی اصلاح یک مشکل بسیار مفید است؛ مثلاً وقتی robots.txt، noindex یا خطای Server را رفع کردهاید. با این حال موفق بودن Live Test تضمین نمیکند صفحه حتماً ایندکس شود؛ فقط بخشی از شرایط فنی قابل بررسی را تأیید میکند.
Request Indexing
Request Indexing برای درخواست Crawl مجدد یک URL مشخص مفید است، بهخصوص پس از انتشار یا اصلاح مهم. این دکمه میانبری برای اجبار Google به Index نیست. ارسال تکراری درخواست برای یک URL جای حل مشکل Quality، Internal Linking، Canonical یا دسترسی Crawl را نمیگیرد.
Page Indexing
Page Indexing نمای کلیتری از وضعیت URLهای شناختهشده سایت ارائه میدهد. مهمترین اشتباه این است که همه URLهای Not indexed را «خطا» فرض کنیم. بخشی از URLها طبیعی است که ایندکس نشوند؛ Redirectها، Duplicateها، URLهای دارای noindex یا صفحاتی که Canonical آنها URL دیگری است میتوانند عمداً خارج از Index باشند.
اول Intent را مشخص کنید
قبل از رفع هر Status بپرسید: «آیا این URL باید در Google ایندکس شود؟» اگر پاسخ خیر است، Not indexed بودن لزوماً مشکل نیست. اگر پاسخ بله است، تازه باید دلیل را بررسی کنید. این سؤال ساده از صرف ساعتها وقت روی URLهایی که اصولاً نباید Index شوند جلوگیری میکند.
مسیر تشخیص
برای URL مهمی که ایندکس نشده، ترتیب زیر منطقی است:
- URL را با URL Inspection بررسی کنید.
- مطمئن شوید Crawl مجاز است و Page Fetch موفق انجام میشود.
- noindex و Canonical را بررسی کنید.
- Status دقیق Page Indexing را بخوانید.
- Internal Link و حضور URL در Sitemap را بررسی کنید.
- اگر مشکل اصلاح شده، Validation یا Request مناسب را استفاده کنید.
موضوع Indexing جزئیات زیادی دارد و نباید همه Statusها در این Pillar تکرار شوند. برای عیبیابی عمیقتر میتوانید از مقاله ایندکس نشدن سایت در گوگل؛ علت و راهحل استفاده کنید که مالک تخصصی این موضوع در ساختار DJH.ir است.
ثبت Sitemap
XML Sitemap فهرستی از URLهایی است که میخواهید Google از وجود آنها مطلع باشد. Sitemap تضمین Indexing نیست؛ به Discovery و Crawl کمک میکند و مخصوصاً برای سایتهای بزرگ، سایتهای جدید یا ساختارهایی که برخی صفحات Internal Link کمتری دارند مفید است.
ارسال Sitemap
در Sitemaps Report آدرس Sitemap را ثبت میکنید و وضعیت آخرین پردازش آن را میبینید. Statusهایی مانند Success، Couldn’t fetch یا وجود Error کمک میکنند بفهمید Google فایل را خوانده است یا نه. اگر فایل Fetch نمیشود، آدرس، HTTP Status، دسترسی Server و مسدود نبودن Sitemap را بررسی کنید.
Sitemap چه چیزی ثابت نمیکند؟
وجود URL در Sitemap به معنی Crawl یا Index قطعی نیست. حتی Sitemap موفق نیز ممکن است شامل URLهایی باشد که Google آنها را Duplicate، کمارزش یا نامناسب برای Index تشخیص میدهد. بنابراین Sitemap Report را با Page Indexing و URL Inspection کنار هم بخوانید.
تجربه و سلامت فنی
Search Console چند گزارش برای مشاهده کیفیت فنی و تجربه صفحه ارائه میدهد. این گزارشها جای تست مستقیم یا ابزارهای توسعه را نمیگیرند، اما برای پیدا کردن الگوهای Site-wide مفید هستند.
Core Web Vitals
Core Web Vitals Report URLها را بر اساس داده میدانی و گروههای مشابه دستهبندی میکند. Metricهای اصلی فعلی شامل LCP برای Loading، INP برای Responsiveness و CLS برای Visual Stability هستند. اگر گروهی از URLها وضعیت Poor یا Need improvement دارد، ابتدا الگوی Template مشترک را پیدا کنید؛ ممکن است اصلاح یک Theme، Component یا Script روی تعداد زیادی صفحه اثر بگذارد.
برای توضیح تخصصیتر این شاخصها و روش تحلیل آنها، مقاله تأثیر Core Web Vitals بر عملکرد سایت و SEO مکمل مستقیم این بخش است.
HTTPS
HTTPS Report برای بررسی وضعیت HTTPS URLهای ایندکسشده استفاده میشود. اگر مشکلات گسترده HTTPS مشاهده کردید، فقط خود Report را نگاه نکنید؛ Certificate، Redirectها، Server availability و Page Indexing میتوانند در تشخیص ریشه مشکل نقش داشته باشند.
گزارش Links
Links Report اطلاعاتی درباره لینکهای داخلی و خارجی شناختهشده برای Google ارائه میدهد. این گزارش برای دید کلی مفید است، اما Database جامع Backlink نیست و نباید نبود یک لینک در Report را به معنی «Google این لینک را نمیشناسد» یا «لینک بیاثر است» تفسیر کرد.
Internal Links
Internal Links به شما کمک میکنند ساختار اهمیت صفحات را بررسی کنید. اگر صفحهای استراتژیک تقریباً هیچ لینک داخلی ندارد، ممکن است Navigation و Architecture محتوا نیاز به اصلاح داشته باشد. هدف افزایش مصنوعی تعداد لینک نیست؛ لینک باید از صفحات مرتبط و با Anchor طبیعی ساخته شود.
External Links
در بخش External Links میتوانید نمونههایی از Top linked pages و Linking sites را ببینید. برای تحلیل عمیق Link Profile معمولاً ابزارهای دیگر نیز لازم میشوند، اما Search Console مزیت مهمی دارد: داده مستقیماً از سیستم Google میآید و برای بررسی سریع برخی الگوها کاربردی است.
امنیت و Manual Action
دو بخش مهم Search Console را نباید با هم اشتباه گرفت. Manual Actions به اقدام دستی Google در ارتباط با نقض سیاستهای Search اشاره دارد؛ Security Issues درباره نشانههای Hack، Malware، Phishing یا رفتارهایی است که میتواند برای کاربر خطرناک باشد.
Manual Actions
اگر Manual Action وجود داشته باشد، باید نوع مشکل را دقیق بخوانید، علت را واقعاً برطرف کنید و سپس در صورت امکان Request Review ارسال کنید. حذف ظاهری یک نشانه بدون اصلاح Root Cause راهحل پایداری نیست. نبود Manual Action نیز به این معنی نیست که سایت هیچ مشکل Ranking یا Quality ندارد؛ فقط یعنی Manual Action گزارششدهای برای Property مشاهده نمیشود.
Security Issues
Security Issue اولویت فوری دارد. اگر سایت Hack شده یا محتوای مخرب ارائه میکند، قبل از هر Optimization سئو باید امنیت و پاکسازی سایت انجام شود. Passwordها، Pluginها، Themeها، Server، User Accountها و فایلهای آلوده باید بررسی شوند و بعد از رفع مشکل، Validation مناسب انجام شود.
Crawl Stats و تنظیمات
Crawl Stats Report بیشتر برای کاربران فنی و سایتهای نسبتاً بزرگ ارزش دارد. این گزارش کمک میکند رفتار Crawl Google را از زاویه تعداد Requestها، پاسخ Host، File type و Response بررسی کنید. هدف آن پیدا کردن مشکل Serving و الگوهای Crawl است، نه تلاش برای «زیادکردن Crawl» به هر قیمت.
چه زمانی مفید است؟
اگر Server Error، افزایش غیرعادی Response Time یا افت Crawl روی سایت بزرگ دارید، Crawl Stats میتواند سرنخ بدهد. در سایت کوچک و سالم، بررسی روزانه آن معمولاً ارزش زیادی ندارد. این Report باید کنار Log Server و وضعیت Hosting تفسیر شود.
Users و Permissions
در Settings میتوانید Ownerها، Userها و سطح دسترسی را مدیریت کنید. اصل Least Privilege را رعایت کنید: هر فرد فقط دسترسی لازم برای وظیفه خودش داشته باشد. هنگام پایان همکاری، علاوه بر حذف Access، Tokenهای Verification قدیمی را نیز بررسی کنید تا کاربر نتواند دوباره Ownership را بازیابی کند.
حذف موقت نتایج
بخش Removals برای زمانی است که لازم است نمایش یک URL یا محتوای مشخص را با سرعت بیشتری از نتایج Google Search پنهان کنید. نکته مهم این است که این ابزار را نباید با حذف دائمی از ایندکس اشتباه گرفت. درخواست Removal یک راهحل مدیریتی موقت است؛ اگر URL همچنان قابل Crawl و Index باشد، بدون اصلاح وضعیت اصلی صفحه ممکن است دوباره در نتایج ظاهر شود.
چه زمانی استفاده کنیم؟
سناریوی مناسب میتواند انتشار تصادفی یک صفحه، نمایش اطلاعاتی باشد که باید فوراً از Search پنهان شود، یا زمانی که پس از حذف محتوا میخواهید حضور آن در نتایج سریعتر کنترل شود. برای حذف دائمی باید علت در خود سایت اصلاح شود؛ برای مثال URL پاسخ مناسب بدهد، دسترسی آن محدود شود یا در سناریوی درست از دستور noindex استفاده شود.
Removals همچنین جایگزین robots.txt نیست. robots.txt اساساً Crawl را مدیریت میکند و نباید بهعنوان روش مطمئن حذف یک URL از Index استفاده شود. قبل از هر اقدام مشخص کنید هدف شما «جلوگیری از Crawl»، «جلوگیری از Index» یا «پنهانکردن سریع نتیجه موجود» است؛ این سه مسئله راهحل یکسان ندارند.
Enhancements
همه Propertyها مجموعه یکسانی از گزارشهای Enhancements را نمیبینند. Search Console این گزارشها را براساس قابلیتها و Structured Dataهایی که Google روی صفحات سایت تشخیص میدهد نمایش میدهد. بنابراین نبودن یک گزارش لزوماً نشانه خطا نیست؛ ممکن است آن نوع داده یا قابلیت اصلاً در سایت وجود نداشته باشد یا داده کافی برای گزارش فراهم نشده باشد.
چطور گزارش را بخوانیم؟
در گزارشهای Enhancement باید بین Error، Warning و وضعیت معتبر تفاوت بگذارید. هر هشدار الزاماً باعث حذف صفحه از نتایج عادی نمیشود و هر Structured Data معتبر نیز نمایش Rich Result را تضمین نمیکند. کاربرد Search Console در اینجا تشخیص وضعیت فنی و Eligibility است، نه وعده شکل خاصی از نمایش در SERP.
اگر خطایی روی گروهی از صفحات تکرار میشود، ابتدا Template مشترک آنها را پیدا کنید. در WordPress ممکن است یک Theme، Plugin یا Template Builder یک Markup مشابه را در صدها URL تولید کرده باشد. اصلاح Root Cause در Template بسیار مؤثرتر از دستکاری جداگانه هر URL است.
فیلتر پیشرفته با Regex
وقتی تعداد Queryها و URLها زیاد میشود، Filterهای ساده دیگر برای تحلیل کافی نیستند. Regular Expression یا Regex اجازه میدهد چند الگو را در یک Filter ترکیب کنید و مجموعه دقیقتری از دادهها بسازید. این قابلیت مخصوصاً برای دستهبندی Intent، Brand/Non-brand، الگوهای URL و گروههای محتوایی مفید است.
تحلیل Queryها
فرض کنید میخواهید Queryهای پرسشی را جدا کنید. بهجای جستجوی تکتک کلمات، میتوانید الگوهایی برای «چگونه»، «چرا»، «چیست» و شکلهای مشابه بسازید. یا برای تحلیل Brand، مجموعه شکلهای مختلف نام برند را در یک Pattern قرار دهید. نتیجه این کار یک Segment تحلیلی است که میتوانید Click، Impression، CTR و Position آن را با دوره دیگر مقایسه کنید.
تحلیل URLها
Regex برای معماری سایت نیز کاربرد دارد. اگر URLهای Blog، Product و Category الگوی مشخصی دارند، میتوانید Performance هر گروه را مستقل بررسی کنید. این روش بهخصوص زمانی ارزشمند است که کل سایت افت نکرده و فقط یک Template یا Content Type دچار تغییر شده باشد.
Regex را با هدف مشخص استفاده کنید. Pattern پیچیدهای که معلوم نیست چه URLهایی را Match میکند میتواند تحلیل را خراب کند. ابتدا با یک نمونه کوچک نتیجه Filter را بررسی کنید و بعد از اطمینان، مقایسه و نتیجهگیری انجام دهید.
محدودیت دادهها
یکی از تفاوتهای کاربر مبتدی و تحلیلگر حرفهای Search Console این است که تحلیلگر محدودیت داده را هم در نتیجهگیری لحاظ میکند. Search Console قرار نیست Log کامل موتور جستجو یا فهرست بینقص همه URLهای شناختهشده Google باشد. بعضی گزارشها نمونهای از URLها را نشان میدهند، دادههای جدید ممکن است هنوز Preliminary باشند و شیوه Aggregation نیز روی عددی که میبینید اثر میگذارد.
Property و Page
در Performance، داده میتواند براساس Property یا Page تجمیع شود. اگر چند URL از یک Property برای یک Query ظاهر شوند، شیوه شمارش در سطح Property با زمانی که داده را براساس Page میبینید یکسان نیست. به همین دلیل نباید بدون توجه به Dimension، اعداد Chart و Table را مکانیکی با هم مقایسه کنید.
Position رتبه ثابت نیست
Average Position میانگین موقعیت گزارششده در مجموعه Impressionهاست و نباید آن را «رتبه قطعی امروز» تفسیر کرد. Device، Location، Query، Search Appearance و شکل SERP میتوانند زمینه مشاهده را تغییر دهند. برای تصمیمگیری، Trend چند هفتهای یک Segment مشخص معمولاً از خیرهشدن به یک عدد روزانه مفیدتر است.
داده کم یا تازه
Property تازه ممکن است فوراً داده کامل نداشته باشد. همچنین کمبود داده در یک Report لزوماً به معنی خرابی سایت نیست. برای نمونه Core Web Vitals به Field Data واقعی متکی است و همه URLها الزاماً داده کافی برای حضور در گزارش ندارند. قبل از رفع مشکلی که شاید وجود ندارد، ابتدا ماهیت Report و شرط تولید داده آن را بشناسید.
پیدا کردن فرصت رشد
Search Console زمانی ارزش واقعی خود را نشان میدهد که از گزارشگیری به ساخت فرضیه برسید. بهجای سؤال کلی «چطور ورودی را زیاد کنم؟» یک Segment مشخص انتخاب کنید و بپرسید چه چیزی در داده تغییر کرده و کدام اقدام قابل آزمایش است.
Impression بالا، CTR پایین
ابتدا Query یا Pageهایی را پیدا کنید که Impression قابل توجه دارند اما نسبت Click به نمایش آنها نسبت به گذشته یا صفحات مشابه ضعیف شده است. بعد Search Intent، عنوان صفحه، Snippet، نوع نتایج SERP و Position را بررسی کنید. CTR پایین بهتنهایی ثابت نمیکند Title بد است؛ ممکن است Position پایینتر آمده باشد یا SERP بهشدت با Video، Image یا Featureهای دیگر اشغال شده باشد.
Position رو به بهبود
صفحهای که برای مجموعهای از Queryهای مرتبط بهتدریج Position بهتری میگیرد اما هنوز Click کمی دارد، میتواند Candidate خوبی برای بهروزرسانی باشد. قبل از افزودن متن، بررسی کنید آیا صفحه واقعاً Intent آن Queryها را کامل پاسخ میدهد، بخش مهمی کم دارد، Internal Link کافی دریافت میکند و عنوان آن با موضوع واقعی صفحه هماهنگ است.
افت یک گروه محتوا
اگر افت فقط در یک Directory یا نوع محتوا دیده میشود، مشکل را Site-wide فرض نکنید. URLها را Segment کنید، دوره قبل و بعد را مقایسه کنید و سپس Indexing، Template، Internal Links و تغییرات فنی همان گروه را بررسی کنید. این رویکرد دامنه جستجو برای Root Cause را بسیار کوچکتر میکند.
راهنمای سریع گزارشها
اگر هنگام کار با Search Console نمیدانید از کدام Report شروع کنید، سؤال خود را به یک مسئله مشخص تبدیل کنید. جدول زیر نقطه شروع مناسب برای متداولترین نیازها را نشان میدهد.
| نیاز | بخش مناسب | اولین بررسی |
|---|---|---|
| پیدا کردن Queryهای ورودی | Performance | Queries و Date |
| بررسی یک URL | URL Inspection | Index status و Crawl |
| بررسی ایندکس کل سایت | Page Indexing | Reasons و Trend |
| بررسی Sitemap | Sitemaps | Status و URL discovery |
| تحلیل افت کلیک | Performance | Compare و Segment |
| بررسی Crawl | Crawl Stats | Host status و Responses |
| مشکل تجربه صفحه | Core Web Vitals | URL groups و Metrics |
| جریمه دستی | Manual Actions | Issue details |
| هک یا محتوای خطرناک | Security Issues | Detected issues |
| بررسی لینکها | Links | Top pages/sites/text |
این جدول ابزار تشخیص نهایی نیست؛ فقط نقطه شروع را مشخص میکند. در مسائل واقعی معمولاً باید دو یا چند Report را کنار هم قرار دهید. برای مثال افت Traffic ممکن است در Performance دیده شود، اما علت آن را در Page Indexing، Manual Actions، Security Issues یا حتی تغییرات خارج از Search Console پیدا کنید.
عیبیابی با Search Console
بهترین روش استفاده از Search Console، تبدیل هر مشکل به یک مسیر Diagnostic مشخص است. بهجای حرکت تصادفی بین گزارشها، ابتدا Symptom را تعریف کنید و سپس Report مناسب را انتخاب کنید.
صفحه در Google نیست
- URL Inspection را باز کنید.
- وضعیت Indexed و Live را مقایسه کنید.
- Crawl، Fetch، noindex و Canonical را بررسی کنید.
- Page Indexing Status را بخوانید.
- Sitemap و Internal Links را بررسی کنید.
- پس از اصلاح واقعی، Request Indexing یا Validation را انجام دهید.
ورودی ناگهان افت کرده
- Performance را روی بازه افت Compare کنید.
- افت را بر اساس Page و Query تفکیک کنید.
- Device، Country و Search Type را بررسی کنید.
- Page Indexing و URL Inspection صفحات اصلی را کنترل کنید.
- Manual Actions و Security Issues را بررسی کنید.
- اگر Server یا Crawl مشکوک است، Crawl Stats را ببینید.
Impression هست، Click نیست
ابتدا Position و Query Intent را بررسی کنید. اگر Position پایین است، مسئله اصلی احتمالاً فقط Title نیست. اگر Position مناسب ولی CTR ضعیف است، عنوان، Description، نوع Result و تطابق Intent را بررسی کنید. همچنین Search Featureهای SERP میتوانند رفتار CTR را تغییر دهند.
Sitemap خطا دارد
اگر وضعیت Couldn’t fetch است، خود URL Sitemap را در Browser و ابزارهای HTTP بررسی کنید، Status Code را ببینید و مطمئن شوید فایل برای Google قابل دسترس است. سپس URL Sitemap را با URL Inspection و Live Test نیز میتوان بررسی کرد. اگر Sitemap خوانده میشود ولی برخی URLها Index نمیشوند، مسئله دیگر «Fetch شدن Sitemap» نیست و باید روی URLهای فردی تمرکز کنید.
روتین بررسی سایت
Search Console زمانی مفیدتر میشود که بهجای چککردن وسواسی روزانه، یک Routine متناسب با اندازه و حساسیت سایت داشته باشید. سایت خبری بزرگ با وبسایت شرکتی کوچک نیاز یکسانی ندارد.
| تناوب | چه چیزی بررسی شود | هدف |
|---|---|---|
| روزانه یا هنگام هشدار | Security، Manual Action، افت شدید | واکنش سریع |
| هفتگی | Performance، Indexing مهم | تشخیص روند |
| ماهانه | Query/Page، CWV، Links | تصمیم محتوایی و فنی |
چکلیست هفتگی
- Click و Impression دوره اخیر را با دوره قبل مقایسه کنید.
- بزرگترین صفحات برنده و بازنده را پیدا کنید.
- Queryهای جدید و افتکرده را بررسی کنید.
- URLهای مهم Not indexed را فقط در صورت نیاز بررسی کنید.
- هشدارهای جدید Search Console را بخوانید.
چکلیست ماهانه
- صفحات دارای Impression بالا و CTR قابل بهبود را پیدا کنید.
- Queryهایی را که نیاز به Content Update دارند جدا کنید.
- Core Web Vitals را در سطح Template بررسی کنید.
- Internal Linkهای صفحات مهم را بازبینی کنید.
- Users و Permissionهای غیرضروری را حذف کنید.
نکته مهم این است که Alert-driven باشید، نه Number-driven. تغییر کوچک یک Metric بدون Context لزوماً نیازمند اقدام نیست. تصمیم باید بر اساس Trend، Segment و اهمیت Business Page گرفته شود.
امکانات پیشرفته
بعد از تسلط بر گزارشهای اصلی، Search Console مسیرهای پیشرفتهتری نیز دارد. همه سایتها به آنها نیاز ندارند، اما دانستن وجودشان برای پروژههای بزرگ یا تحلیلهای تخصصی مفید است.
Discover و News
اگر Property داده کافی و شرایط لازم داشته باشد، Performance Reportهای مربوط به Google Discover یا Google News ممکن است نمایش داده شوند. نبود این Reportها لزوماً Error نیست؛ معمولاً فقط Property واجد داده قابل گزارش نبوده است.
API و Export
برای تحلیلهای تکرارشونده یا حجم داده بیشتر میتوان از Search Console API و روشهای Export استفاده کرد. این مرحله برای شروع لازم نیست. ابتدا باید بتوانید همان سؤالها را در UI درست تعریف کنید؛ Automation یک تحلیل اشتباه فقط باعث میشود اشتباه را سریعتر تکرار کنید.
Migration و Change of Address
هنگام انتقال دامنه، Search Console یکی از ابزارهای مهم Monitoring است. Change of Address برای سناریوهای مشخص تغییر دامنه استفاده میشود و جای Redirect صحیح، Canonical، Sitemap و نگهداری Redirectهای قدیمی را نمیگیرد. Migration باید بهعنوان پروژه فنی مستقل برنامهریزی شود.
مسیر یادگیری پیشنهادی
برای یادگیری Search Console لازم نیست همه Reportها را همزمان حفظ کنید. این ترتیب باعث میشود هر مرحله روی مرحله قبل بنا شود:
- Property و Verification را یاد بگیرید.
- Click، Impression، CTR و Position را درک کنید.
- Query، Page، Filter و Compare را تمرین کنید.
- URL Inspection را روی چند صفحه واقعی اجرا کنید.
- Page Indexing و Sitemap را کنار هم بررسی کنید.
- Core Web Vitals، Links و Security Reports را یاد بگیرید.
- برای افت Traffic یک Diagnostic Workflow بسازید.
- در پایان Routine هفتگی و ماهانه خود را تعریف کنید.
اگر هنوز مفاهیم پایه SEO برایتان مبهم است، مقاله آموزش سئو SEO صفر تا صد میتواند Parent آموزشی مناسبی برای درک نقش Search Console در استراتژی کلی SEO باشد.
سوالات متداول
پرسشهای زیر ابهامهایی را پوشش میدهند که معمولاً هنگام شروع یا عیبیابی Search Console ایجاد میشوند.
آیا Google Search Console رایگان است؟
بله، Search Console سرویس رایگان Google برای بررسی حضور سایت در Google Search است. برای استفاده باید مالکیت Property را تأیید کنید.
آیا ثبت سایت در Search Console برای ایندکس شدن ضروری است؟
خیر. Google میتواند بسیاری از صفحات را بدون ثبت دستی پیدا کند. Search Console بیشتر برای Monitoring، عیبیابی و ارائه اطلاعات مستقیم درباره Search مفید است.
Domain Property بهتر است یا URL Prefix؟
برای دید جامع روی دامنه معمولاً Domain Property مناسبتر است و با DNS تأیید میشود. URL Prefix وقتی مفید است که فقط یک نسخه یا بخش مشخص سایت را جداگانه بررسی کنید.
چرا آمار Search Console با Google Analytics فرق دارد؟
چون دو ابزار چیزهای متفاوتی را اندازهگیری میکنند. Search Console روی عملکرد در Google Search تمرکز دارد و Analytics رفتار کاربر داخل سایت را ثبت میکند.
CTR خوب در Search Console چند درصد است؟
عدد ثابت و جهانی وجود ندارد. Position، نوع Query، Brand، Device و شکل SERP روی CTR اثر دارند؛ مقایسه با گذشته همان Query یا Page معمولاً معنادارتر است.
Average Position همان رتبه دقیق صفحه است؟
خیر. Average Position یک میانگین گزارششده از موقعیت نتایج در Impressionهای مختلف است و میتواند با کاربر، Query، Location و Device تغییر کند.
آیا Request Indexing باعث ایندکس قطعی میشود؟
خیر. این گزینه درخواست Crawl و بررسی مجدد URL را ارسال میکند، اما تضمینی برای Index شدن نیست. مشکل فنی، Canonical، Quality یا سایر عوامل باید جداگانه حل شوند.
آیا Sitemap ایندکس صفحات را تضمین میکند؟
خیر. Sitemap به کشف URLها کمک میکند، اما Google درباره Crawl و Index هر URL جداگانه تصمیم میگیرد.
چرا URL Inspection میگوید Live Test موفق است ولی صفحه ایندکس نیست؟
Live Test فقط بخشی از شرایط دسترسی فعلی URL را بررسی میکند. موفق بودن Fetch و اجازه Indexing بهتنهایی تضمین نمیکند Google صفحه را برای Index انتخاب کند.
آیا همه صفحات Not indexed مشکل دارند؟
خیر. Redirect، Duplicate، noindex و URLهایی با Canonical دیگر ممکن است عمداً Index نشوند. ابتدا مشخص کنید آیا آن URL اصولاً باید در Google باشد یا خیر.
چند وقت یکبار Search Console را بررسی کنیم؟
برای بسیاری از سایتها بررسی هفتگی Performance و خطاهای مهم کافی است و گزارشهای عمیقتر را میتوان ماهانه دید. هشدارهای امنیتی یا افت شدید باید سریعتر بررسی شوند.
Manual Action با Security Issue چه تفاوتی دارد؟
Manual Action معمولاً به نقض سیاستهای Search مربوط است؛ Security Issue نشانه Hack، Malware، Phishing یا خطر برای کاربر است. هر دو جدیاند اما مسیر رفع متفاوتی دارند.
نتیجهگیری
Google Search Console زمانی ارزش واقعی پیدا میکند که از مرحله «دیدن گزارشها» عبور کنید و برای هر داده یک سؤال مشخص داشته باشید. Performance به شما میگوید سایت چگونه در Search دیده و کلیک میشود؛ URL Inspection وضعیت یک صفحه مشخص را باز میکند؛ Page Indexing الگوهای Index را نشان میدهد؛ Sitemap به Discovery کمک میکند و گزارشهای Core Web Vitals، Security و Crawl Stats بخشهای فنی تصویر را کامل میکنند.
برای شروع، لازم نیست همه منوها را حفظ کنید. ابتدا Property را درست ثبت کنید، Metricهای Performance را یاد بگیرید و چند Page واقعی را با Query و URL Inspection تحلیل کنید. بعد سراغ Indexing، Sitemap و Troubleshooting بروید. مهمترین مهارت این است که بدانید «کدام Report برای کدام سؤال مناسب است» و بعد از دیدن نتیجه چه قدمی بردارید.
اگر Search Console نشان میدهد سایت مشکل Indexing یا افت شدید دارد، عجله برای Request Indexing یا تغییر تصادفی محتوا معمولاً بهترین پاسخ نیست. ابتدا Root Cause را با داده مشخص کنید، سپس اصلاح را انجام دهید و نتیجه را دوباره Verify کنید. همین الگوی تشخیص → اصلاح → اعتبارسنجی، Search Console را از یک Dashboard ساده به ابزار واقعی مدیریت SEO تبدیل میکند.
