آموزش سرچ کنسول گوگل؛ از تأیید سایت تا عیب‌یابی ایندکس

یک صفحه تازه منتشر کرده‌اید، اما با جست‌وجوی نام آن در گوگل چیزی پیدا نمی‌کنید. پیش از آنکه چند بار پشت سر هم دکمه «درخواست ایندکس» را بزنید، باید بدانید گوگل اصلاً صفحه را دیده است یا نه، توانسته آن را بخزد یا نه و کدام نشانی را نسخه اصلی می‌داند. این آموزش سرچ کنسول گوگل یک مسیر عملی برای همین تشخیص است: افزودن سایت، تأیید مالکیت، معرفی نقشه سایت و بررسی یک URL مشخص.

Search Console ابزار رایگان گوگل برای پایش و عیب‌یابی حضور سایت در جست‌وجو است؛ برای اینکه سایت اصولاً بتواند در Google Search دیده شود، داشتن حساب سرچ کنسول الزامی نیست. مزیت ابزار این است که به جای حدس‌زدن، داده‌ای درباره خزش، ایندکس و عملکرد در اختیار مالک سایت می‌گذارد. معرفی رسمی Search Console را نیز ببینید.

۱. قبل از ثبت سایت، Property درست را انتخاب کنید

در Search Console هر سایت یا بخش قابل مدیریت آن یک Property است. دو انتخاب رایج برای وب‌سایت، Domain و URL-prefix هستند. Domain با نام دامنه، نسخه‌های http و https و زیردامنه‌های آن را یکجا پوشش می‌دهد؛ تأیید آن از طریق DNS انجام می‌شود. URL-prefix فقط نشانی‌هایی را در بر می‌گیرد که با پیشوند دقیقی مانند https://example.com/ شروع می‌شوند. اگر نسخه www یا پروتکل دیگری دارید، این تفاوت مهم است. جزئیات و مثال‌های پوشش هر نوع در راهنمای رسمی افزودن Property آمده است.

کدام گزینه برای سایت من مناسب‌تر است؟

اگر کنترل تنظیمات DNS دامنه را دارید و می‌خواهید همه زیردامنه‌ها و نسخه‌های پروتکل را در یک نمای کلی ببینید، Domain انتخاب مناسبی است. اگر تنها به یک نشانی مشخص دسترسی دارید یا می‌خواهید داده بخش خاصی از سایت را جدا کنید، URL-prefix را با همان پروتکل، میزبان و مسیر واقعی وارد کنید. برای مثال، https://example.com/ با http://example.com/ یکی نیست. پیش از انتخاب، نسخه نهایی سایت را در مرورگر باز کنید و ببینید تغییر مسیر به کدام نشانی ختم می‌شود.

از منوی انتخاب Property گزینه افزودن سایت را باز کنید، نوع Property را برگزینید و مقدار دقیق دامنه یا پیشوند را بنویسید. افزودن Property به‌خودی‌خود رتبه یا وضعیت سایت را تغییر نمی‌دهد؛ فقط امکان مشاهده و مدیریت داده‌های مربوط به آن را فراهم می‌کند. اگر شخص دیگری مالک تأییدشده سایت است، به‌جای ساخت روش تأیید تکراری می‌توانید از او دسترسی مناسب بخواهید.

۲. مالکیت سایت را بدون حذف توکن‌های قبلی تأیید کنید

تأیید مالکیت برای این است که داده‌های حساس سایت در اختیار فرد نامرتبط قرار نگیرد. در Domain Property معمولاً رکورد DNS که خود سرچ کنسول ارائه می‌کند در مدیریت دامنه ثبت می‌شود. برای URL-prefix بسته به امکانات سایت، روش‌هایی مانند فایل HTML یا meta tag نیز وجود دارد. مقدار تأیید را از صفحه همان Property بگیرید؛ رشته نمونه اینترنتی یا توکن سایت دیگر کاربردی ندارد. راهنمای رسمی تأیید مالکیت مراحل هر روش را توضیح می‌دهد.

اگر از روش فایل HTML استفاده می‌کنید، فایل داده‌شده را با نام و محتوای اصلی در مسیر درخواستی قرار دهید و مطمئن شوید کاربر بدون ورود هم می‌تواند آن را باز کند. برای meta tag، تگ را در بخش head صفحه‌ای بگذارید که سرچ کنسول مشخص کرده است. برای DNS، رکورد را دقیقاً مطابق اطلاعات صادرشده ثبت کنید و در صورت ناموفق بودن تأیید، به زمان انتشار تغییرات DNS توجه کنید. هیچ توکن تأیید فعلیِ مالک دیگر را برای افزودن توکن خود پاک نکنید؛ حذف آن می‌تواند دسترسی او را مختل کند.

پس از موفقیت، روش تأیید را حفظ کنید. Search Console به‌طور دوره‌ای باقی‌ماندن توکن را بررسی می‌کند. اگر فایل، تگ یا رکورد DNS از سایت برداشته شود، تأیید مالکیت ممکن است بعداً از بین برود. این نکته هنگام تعویض قالب سایت یا مهاجرت هاست بسیار کاربردی است.

۳. نقشه سایت را معرفی کنید، نه اینکه آن را با تضمین ایندکس اشتباه بگیرید

نقشه سایت فایلی در سایت شماست که URLهای مهم را به گوگل معرفی می‌کند. پیش از ثبت، نشانی واقعی فایل، مانند https://example.com/sitemap.xml، را در یک مرورگر بدون نیاز به ورود باز کنید. روی برخی پلتفرم‌ها مسیر یا ساختار نقشه سایت متفاوت است؛ آن را حدس نزنید و از تنظیمات یا مستندات همان پلتفرم بردارید. در گزارش Sitemaps، نشانی فایل را در بخش افزودن نقشه سایت وارد و Submit را انتخاب کنید. این کار فایل را به گوگل آپلود نمی‌کند؛ فقط محل آن را اعلام می‌کند. راهنمای رسمی گزارش Sitemaps.

پس از ثبت، وضعیت خواندن فایل و خطاهای احتمالی را ببینید. اگر «Couldn't fetch» یا خطای ساختار فایل می‌بینید، اول دسترسی عمومی، پاسخ سرور، نشانی دقیق فایل و قالب آن را بررسی کنید. اگر وضعیت Success است، تنها می‌دانید گوگل فایل را خوانده است؛ هنوز نمی‌دانید همه صفحه‌های درون آن خزیده یا ایندکس شده‌اند. برای این پرسش از گزارش Page indexing و بازرسی URLهای مهم استفاده کنید. گوگل تصریح می‌کند که حتی کشف URL در sitemap تضمین خزش یا ایندکس نیست.

برای سایتی کوچک که همه صفحه‌های آن از طریق پیوندهای داخلی قابل رسیدن‌اند، sitemap همیشه ضروری نیست؛ اما برای سایت تازه، بزرگ یا دارای URLهای زیاد می‌تواند به کشف نشانی‌ها کمک کند. نقشه سایت را با نسخه canonical و قابل دسترس صفحه‌ها هماهنگ نگه دارید. درج URL حذف‌شده، تغییرمسیر داده یا نسخه‌ای که قرار نیست ایندکس شود، عیب‌یابی را دشوارتر می‌کند.

۴. یک URL را با URL Inspection بررسی کنید

حالا یک صفحه مهم، مثلاً مقاله جدیدتان، انتخاب کنید و نشانی کامل آن را در کادر بالای Search Console برای URL Inspection وارد کنید. نشانی باید به Property انتخاب‌شده تعلق داشته باشد. ابزار ابتدا اطلاعاتی را نشان می‌دهد که گوگل از آخرین بررسی ذخیره کرده است؛ این اطلاعات لزوماً وضعیت همین لحظه سرور نیست. وضعیت کلی، زمان و نتیجه خزش، امکان ایندکس و نشانی canonical انتخابی گوگل را بخوانید. مستندات URL Inspection معنای هر بخش را شرح می‌دهد.

گزارش ایندکس‌شده را با آزمون زنده قاطی نکنید

اگر صفحه را همین امروز اصلاح کرده‌اید، از Test live URL برای بررسی وضعیت کنونی دسترسی و خزش استفاده کنید. آزمون زنده نشان می‌دهد صفحه اکنون قابل دریافت هست یا نه؛ به‌تنهایی ثابت نمی‌کند نسخه جدید در فهرست جست‌وجو ثبت شده است. در مقابل، گزارش ایندکس‌شده درباره چیزی است که گوگل پیش‌تر پردازش کرده. این تمایز جلوی یک نتیجه‌گیری اشتباه را می‌گیرد: «آزمون زنده موفق بود، پس همین حالا در نتایج دیده می‌شوم».

عبارت «URL is on Google» نیز به معنی تضمین نمایش برای هر جست‌وجو نیست. اگر ابزار می‌گوید URL روی گوگل نیست، جزئیات Page indexing را باز کنید و علت را بخوانید. اگر canonical انتخاب‌شده URL دیگری است، نخست بررسی کنید آیا این انتخاب برای صفحه تکراری یا جایگزین منطقی است یا خیر. هر URL غیرایندکس‌شده خطا نیست؛ بعضی نسخه‌های تکراری، تغییرمسیرها یا صفحه‌های عمداً کنار گذاشته‌شده نباید مستقل ایندکس شوند.

۵. علت ایندکس‌نشدن را به اقدام مشخص تبدیل کنید

گزارش Page indexing وضعیت جمعی صفحه‌ها را به تفکیک علت نشان می‌دهد. از جدول «Why pages aren’t indexed» روی یک علت کلیک کنید، چند URL نمونه را ببینید و یکی از آنها را در URL Inspection باز کنید. سپس مسئله را با هدف آن صفحه بسنجید: آیا واقعاً می‌خواهید همین URL نسخه اصلی و قابل نمایش باشد؟ طبق راهنمای گزارش Page indexing انتظار ایندکس صددرصد URLهای سایت منطقی نیست؛ هدف، ایندکس نسخه‌های canonical صفحه‌های مهم است.

• صفحه در دسترس نیست: URL را بدون ورود باز کنید، پاسخ سرور و مسیر تغییرمسیر را بررسی کنید و سپس آزمون زنده بگیرید.
• خزش یا ایندکس با دستور سایت محدود شده: تنظیمات robots و noindex را با نیت انتشار صفحه تطبیق دهید؛ تنها وقتی صفحه باید عمومی باشد مانع را بردارید.
• نسخه جایگزین یا تکراری است: canonical اعلام‌شده سایت و canonical انتخابی گوگل را مقایسه کنید؛ ممکن است عدم ایندکس نسخه دوم کاملاً درست باشد.
• صفحه کشف شده اما هنوز پردازش نشده: ابتدا پیوند داخلی، دسترسی سرور و ارزش محتوای صفحه را بررسی کنید؛ درخواست‌های پیاپی جای اصلاح مسئله را نمی‌گیرد.

این فهرست تشخیص قطعی از راه دور نیست. وضعیت و توضیح خود Search Console، پاسخ واقعی URL و پیکربندی سایت را کنار هم بخوانید. اگر مشکل چند صفحه را درگیر کرده، قبل از ویرایش گسترده یک نمونه را اصلاح و آزمایش کنید. سپس برای مسئله‌ای که برطرف شده، در صورت وجود گزینه مناسب از Validate fix استفاده کنید؛ این دکمه نیز جایگزین رفع علت نیست.

۶. درخواست بازخزش را در زمان درست بفرستید

وقتی صفحه‌ای تازه منتشر شده یا یک مشکل واقعی آن را برطرف کرده‌اید، پس از اطمینان از دسترسی و وضعیت مطلوب، می‌توانید در URL Inspection درخواست ایندکس بدهید. برای مجموعه زیادی از URLها، sitemap ابزار مناسب‌تری برای معرفی نشانی‌هاست. راهنمای رسمی درخواست بازخزش این دو مسیر را از هم جدا می‌کند. درخواست، دستور فوری به موتور جست‌وجو نیست و نتیجه یا زمان مشخصی را تضمین نمی‌کند.

اگر صفحه محتوای کم‌ارزش، نسخه تکراری یا پاسخ خطا دارد، تکرار Request indexing کمکی به رفع آن نمی‌کند. اول صفحه را از دید بازدیدکننده و ربات قابل دسترس کنید، محتوای اصلی و پیوندهای داخلی آن را بررسی کنید و بعد درخواست بدهید. برای یادگیری ساختار پایه صفحه و لینک‌های داخلی، راهنمای ساخت اولین وب‌سایت را بخوانید. برای تفاوت راهنمای سئوی فنی با ادعاهای میان‌بُر درباره نمایش در قابلیت‌های هوش مصنوعی جست‌وجو، مقاله سئو برای AI Overviews مکمل این بحث است.

چک‌لیست کوتاه برای یک صفحه تازه

1. Property درست را انتخاب و مالکیت را با روشی که کنترلش را دارید تأیید کنید.
2. نشانی نهایی و عمومی صفحه را باز کنید؛ مطمئن شوید تغییرمسیر ناخواسته یا خطای سرور ندارد.
3. اگر sitemap دارید، فایل واقعی را در Sitemaps ثبت و وضعیت خواندنش را بررسی کنید.
4. URL را در URL Inspection وارد کنید و وضعیت ایندکس‌شده، جزئیات خزش و canonical را بخوانید.
5. در صورت تغییر تازه، آزمون زنده بگیرید؛ نتیجه آن را با ایندکس‌شدن اشتباه نگیرید.
6. اگر مانعی وجود دارد، علت همان URL را اصلاح کنید؛ سپس در صورت لزوم درخواست بازخزش بدهید.
7. بعداً گزارش Page indexing را دوباره بررسی کنید، نه اینکه موفقیت فوری را فرض کنید.

پرسش‌های متداول

آیا سرچ کنسول شرط دیده‌شدن سایت در گوگل است؟

خیر. گوگل می‌تواند سایت را بدون ثبت در Search Console پیدا کند. این ابزار برای فهم بهتر وضعیت جست‌وجو و عیب‌یابی در اختیار مالک سایت است.

آیا Success بودن sitemap یعنی همه URLها ایندکس شده‌اند؟

خیر. Success به خوانده‌شدن فایل مربوط است. برای وضعیت هر URL مهم از URL Inspection و برای نمای کلی از Page indexing استفاده کنید.

چرا آزمون زنده موفق است ولی URL هنوز در گوگل نیست؟

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

چند بار درخواست ایندکس بدهم؟

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

جمع‌بندی و گام بعدی

سرچ کنسول زمانی بیشترین ارزش را دارد که از آن برای پرسیدن سؤال درست استفاده کنید: آیا گوگل این URL را کشف کرده، آیا توانسته آن را بخزد، آیا نسخه اصلی همین نشانی است و آیا کنار گذاشتن آن عمداً یا به دلیل مانع قابل اصلاح رخ داده؟ افزودن Property و sitemap فقط آغاز مسیرند. تصمیم بعدی را بر اساس داده همان URL و هدف واقعی صفحه بگیرید، نه بر اساس وعده ایندکس فوری.

یک URL مهم سایت خود را در URL Inspection بررسی کنید، نتیجه را با گزارش Page indexing مقایسه کنید و فقط مانع واقعی را اصلاح کنید.