گوگل سرچ کنسول به شما امکان میدهد هرگونه مشکلی را که گوگل هنگام خزش (Crawl) و تلاش برای ایندکس (Index) وبسایت شما در نتایج جستجو با آن مواجه میشود، شناسایی، عیبیابی و برطرف کنید. این ابزار همچنین دیدی کلی از این موضوع به شما میدهد که کدام صفحات رتبه خوبی دارند و گوگل کدام صفحات را نادیده گرفته است.
هنگامی که گوگل سایت شما را میخزد، به این معنی است که صفحات شما در حال کشف و بررسی هستند تا مشخص شود آیا اطلاعات آنها ارزش نمایهسازی را دارد یا خیر. ایندکس شدن به این معنی است که آن صفحات توسط خزندهی گوگل («Googlebot») تحلیل شده و در سرورهای نمایه ذخیره شدهاند، که این کار باعث میشود واجد شرایط نمایش در پرسوجوهای موتور جستجو باشند.
اگر خیلی فرد فنیای نیستید، ممکن است برخی از خطاهایی که در آنجا با آنها مواجه میشوید، شما را سردرگم کند. ما میخواستیم کار را کمی آسانتر کنیم، بنابراین این مجموعه نکات مفید را گردآوری کردیم تا شما را در طول مسیر راهنمایی کنیم.
همچنین به بررسی گزارشهای «کاربری موبایل» (Mobile Usability) و «هستهی حیاتی وب» (Core Web Vitals) خواهیم پرداخت.
شروع کار با سرچ کنسول
اگر هنوز تأیید مالکیت دامنه را انجام ندادهاید، باید مطمئن شوید که مالکیت وبسایت خود را در Google Search Console تأیید کردهاید. ما این مرحله را بهشدت توصیه میکنیم، زیرا به شما اجازه میدهد تمام زیردامنههایی را که زیرمجموعه سایت اصلی شما هستند، مشاهده کنید.
حتماً تمام نسخههای دامنه خود را تأیید کنید. این موارد شامل موارد زیر میشود:
http://yourdomain.com
https://yourdomain.com
http://www.yourdomain.com
https://www.yourdomain.com
و همچنین هر زیردامنهی بدون `www` دیگر، مانند:
blog.yourdomain.com
info.yourdomain.com
و موارد مشابه.
گوگل هر یک از این نسخهها را بهعنوان یک وبسایت جداگانه در نظر میگیرد؛ بنابراین اگر هر نسخه را تأیید نکنید، احتمال زیادی وجود دارد که برخی اطلاعات مهم را از دست بدهید.
—
گزارش Index Coverage
پس از اینکه وبسایت خود را تأیید کردید، به Property یا داراییای بروید که میخواهید کار را با آن شروع کنید.
**انتخاب Property در Google Search Console**
من توصیه میکنم ابتدا روی نسخه اصلی وبسایت خود تمرکز کنید؛ یعنی همان نسخهای که هنگام باز کردن وبسایت در مرورگر خود مشاهده میکنید. البته در نهایت، بهتر است تمام نسخهها را بررسی کنید.
**نکته:** بسیاری از سایتها کاربران را از یک نسخه به نسخهای دیگر هدایت میکنند؛ بنابراین احتمال زیادی وجود دارد که همین نسخه، تنها نسخهای باشد که گوگل بتواند آن را بخزد و ایندکس کند. در نتیجه، بیشتر مشکلاتی که باید عیبیابی کنید، در همین نسخه دیده خواهد شد.
داشبوردی مشاهده خواهید کرد که عملکرد روندی شما در نتایج جستجو، پوشش ایندکس و بهبودها را نشان میدهد. در گوشه بالا سمت راست نمودار **Index coverage** روی گزینه **OPEN REPORT** کلیک کنید.
**گزارش Indexing در Google Search Console**
اینجا جایی است که میتوانید وارد بررسی عمیق تمام مشکلات فنی شوید؛ مشکلاتی که ممکن است مانع از رتبه گرفتن بهتر وبسایت شما در نتایج جستجو شوند. چهار نوع وضعیت یا مشکل وجود دارد:
– **Error**: خطا
– **Valid with warnings**: معتبر همراه با هشدار
– **Valid**: معتبر
– **Excluded**: حذفشده یا مستثنیشده
فهرست خطاها در Google Search Console
در بخش زیر، هر یک از مشکلات احتمالیای را که ممکن است در این قسمت ببینید، با زبان ساده توضیح میدهیم و میگوییم برای رفع آنها چه کاری باید انجام دهید. این فهرست از مستندات رسمی گوگل گرفته شده است و ما قویاً توصیه میکنیم آن را نیز مطالعه کنید.
وقتی فکر میکنید مشکل را حل کردهاید، باید از طریق روند رفع مشکل که داخل خود ابزار تعبیه شده است، گوگل را مطلع کنید. مراحل انجام این کار را در بخشهای پایانی مقاله توضیح دادهایم.
—
فهرست خطاهای Google Search Console
اگر خزنده گوگل، یعنی **Googlebot**، هنگام تلاش برای خزش سایت شما با مشکلی روبهرو شود و نتواند یکی از صفحات وبسایت شما را درک کند، آن را رها کرده و به سراغ صفحه بعدی میرود. این یعنی صفحه شما ایندکس نخواهد شد و برای جستجوکنندگان قابل مشاهده نخواهد بود؛ موضوعی که تأثیر زیادی بر عملکرد شما در جستجو دارد.
برخی از این خطاها عبارتاند از:
– خطای سرور **Server Error (5xx)**
– خطای ریدایرکت **Redirect Error**
– مسدود شده توسط فایل **robots.txt**
– علامتگذاریشده با **noindex**
– خطای **Soft 404**
– درخواست غیرمجاز **Unauthorized request (401)**
– پیدا نشد **Not Found (404)**
– مشکل خزش **Crawl Issue**
تمرکز روی این بخش، نقطه شروع بسیار خوبی است.
—
نحوه رفع خطای سرور Server Error (5xx)
سرور شما هنگام درخواست صفحه، یک خطای سطح ۵۰۰ برگردانده است.
خطای ۵۰۰ به این معناست که مشکلی در سرور وبسایت رخ داده که باعث شده نتواند درخواست شما را انجام دهد. در این مورد، مشکلی در سرور باعث شده گوگل نتواند صفحه را بارگذاری کند.
ابتدا صفحه را در مرورگر خود بررسی کنید و ببینید آیا میتوانید آن را باز کنید یا نه. اگر صفحه برای شما باز میشود، احتمال زیادی وجود دارد که مشکل خودبهخود برطرف شده باشد؛ اما همچنان باید این موضوع را تأیید کنید.
به تیم IT یا شرکت هاستینگ خود ایمیل بزنید و بپرسید آیا سرور در روزهای اخیر دچار قطعی شده است یا خیر، یا آیا تنظیماتی وجود دارد که ممکن است مانع دسترسی Googlebot و سایر خزندهها به سایت شود.
—
نحوه رفع خطای ریدایرکت Redirect Error
URL دچار خطای ریدایرکت شده است. این خطا میتواند یکی از حالتهای زیر باشد:
– زنجیره ریدایرکت بیش از حد طولانی است.
– ریدایرکت وارد یک حلقه بیپایان شده است.
– URL ریدایرکت در نهایت از حداکثر طول مجاز URL عبور کرده است.
– در زنجیره ریدایرکت، یک URL نامعتبر یا خالی وجود دارد.
به زبان ساده، این یعنی ریدایرکت شما درست کار نمیکند. باید آن را اصلاح کنید.
یک سناریوی رایج این است که URL اصلی شما چند بار تغییر کرده و در نتیجه، ریدایرکتهایی ایجاد شدهاند که خودشان به ریدایرکتهای دیگر منتقل میشوند. برای مثال:
http://yourdomain.com
به این آدرس ریدایرکت میشود:
http://www.yourdomain.com
و سپس این آدرس به آدرس زیر ریدایرکت میشود:
https://www.yourdomain.com
گوگل باید حجم بسیار زیادی از محتوا را بخزد، بنابراین دوست ندارد زمان و انرژی خود را صرف خزش چنین لینکهایی کند. برای حل این مشکل، مطمئن شوید که ریدایرکت شما مستقیماً به URL نهایی میرود و تمام مراحل میانی حذف شدهاند.
—
URL ارسالشده توسط robots.txt مسدود شده است
Submitted URL blocked by robots.txt
شما این صفحه را برای ایندکس شدن ارسال کردهاید، اما صفحه توسط فایل `robots.txt` مسدود شده است. صفحه خود را با استفاده از ابزار تست `robots.txt` آزمایش کنید.
در فایل `robots.txt` شما یک خط کد وجود دارد که به گوگل میگوید اجازه خزش این صفحه را ندارد؛ در حالی که شما با ارسال آن برای ایندکس شدن، از گوگل خواستهاید دقیقاً همین کار را انجام دهد.
اگر واقعاً میخواهید این صفحه ایندکس شود، آن خط را در فایل `robots.txt` پیدا کرده و حذف کنید.
اگر نمیخواهید صفحه ایندکس شود، فایل `sitemap.xml` خود را بررسی کنید تا ببینید آیا URL موردنظر در آن فهرست شده است یا نه. اگر وجود دارد، آن را حذف کنید. گاهی افزونههای وردپرس صفحاتی را وارد فایل سایتمپ شما میکنند که نباید آنجا باشند.
—
URL ارسالشده با noindex علامتگذاری شده است
Submitted URL marked ‘noindex’
شما این صفحه را برای ایندکس شدن ارسال کردهاید، اما صفحه دارای دستور `noindex` است؛ این دستور ممکن است در یک متاتگ یا در پاسخ HTTP قرار داشته باشد.
اگر میخواهید این صفحه ایندکس شود، باید آن تگ یا پاسخ HTTP را حذف کنید.
شما در حال ارسال سیگنالهای متناقض به گوگل هستید:
«من را ایندکس کن… نه، نکن!»
کد منبع صفحه خود را بررسی کنید و به دنبال کلمه noindex بگردید. اگر آن را دیدید، وارد سیستم مدیریت محتوای خودتان، یعنی CMS، شوید و به دنبال تنظیمی بگردید که این مورد را حذف کند؛ یا راهی پیدا کنید تا کد صفحه را مستقیماً تغییر دهید.
همچنین این امکان وجود دارد که یک صفحه از طریق پاسخ هدر HTTP و با استفاده از X-Robots-Tag روی حالت noindex قرار گرفته باشد. تشخیص این مورد کمی دشوارتر است، مخصوصاً اگر با ابزارهای توسعهدهنده مرورگر راحت نباشید.
URL ارسالشده به نظر یک Soft 404 است
Submitted URL seems to be a Soft 404
شما این صفحه را برای ایندکس شدن ارسال کردهاید، اما سرور پاسخی داده که به نظر میرسد یک Soft 404 باشد.
اینها صفحاتی هستند که از نظر گوگل شبیه صفحات خراب یا ناموجود به نظر میرسند، اما در واقع پاسخ استاندارد 404 Not Found را برنمیگردانند. این مشکل معمولاً به دو شکل ایجاد میشود:
– شما یک صفحه دستهبندی دارید که در آن دستهبندی هیچ محتوایی وجود ندارد؛ مثل یک قفسه خالی در فروشگاه.
– قالب (Theme) وبسایت شما بهصورت خودکار صفحاتی ایجاد میکند که اساساً نباید وجود داشته باشند.
برای حل این مشکل باید یکی از کارهای زیر را انجام دهید:
– این صفحات را به یک صفحه واقعی **404** تبدیل کنید.
– آنها را به مکان جدیدشان **ریدایرکت** کنید.
– یا با **محتوای واقعی** آنها را پر کنید.
URL ارسالشده پاسخ **Unauthorized request (401)** برمیگرداند
Submitted URL returns unauthorized request (401)
شما این صفحه را برای ایندکس شدن ارسال کردهاید، اما گوگل پاسخ **401 (عدم دسترسی مجاز)** دریافت کرده است.
یا باید محدودیت دسترسی این صفحه را حذف کنید، یا به **Googlebot** اجازه دهید با تأیید هویت خود به صفحه دسترسی پیدا کند.
این هشدار معمولاً زمانی ایجاد میشود که گوگل تلاش میکند صفحهای را بخزد که فقط برای **کاربران واردشده (Logged-in users)** قابل دسترسی است. شما نمیخواهید گوگل منابع خود را صرف خزش چنین URLهایی کند، بنابراین بهتر است در سایت خود جایی را پیدا کنید که گوگل این لینک را از آنجا کشف کرده و آن را حذف کنید.
از آنجا که این صفحه بهعنوان **Submitted** ثبت شده، احتمالاً در **sitemap** شما قرار دارد؛ بنابراین ابتدا سایتمپ خود را بررسی کنید.
URL ارسالشده پیدا نشد (404)
Submitted URL not found (404)
شما یک URL که وجود ندارد را برای ایندکس شدن ارسال کردهاید.
اگر صفحهای را از وبسایت خود حذف کنید اما آن را از **sitemap** حذف نکنید، احتمالاً با این خطا روبهرو خواهید شد. این مشکل با **نگهداری و بهروزرسانی منظم فایل sitemap** قابل پیشگیری است.
برای بررسی دقیقتر نحوه رفع این خطا، مقاله ما درباره **رفع خطاهای 404 در وبسایت** را مطالعه کنید.
URL ارسالشده دارای مشکل خزش (Crawl Issue) است
Submitted URL has crawl issue
شما این صفحه را برای ایندکس شدن ارسال کردهاید، اما گوگل با یک خطای نامشخص در خزش مواجه شده که در هیچیک از دستهبندیهای دیگر قرار نمیگیرد. بهتر است صفحه خود را با استفاده از ابزار **URL Inspection** بررسی و اشکالزدایی کنید.
در این حالت چیزی مانع از آن شده که گوگل بتواند محتوای صفحه شما را **بهطور کامل دانلود و رندر** کند. سعی کنید از ابزار **Fetch as Google** استفاده کنید و ببینید آیا تفاوتی بین چیزی که گوگل رندر میکند و چیزی که شما در مرورگر خود میبینید وجود دارد یا نه.
اگر صفحه شما برای بارگذاری محتوا بهشدت به **JavaScript** وابسته است، ممکن است مشکل از همینجا باشد. بیشتر موتورهای جستجو هنوز جاوااسکریپت را نادیده میگیرند و گوگل هم هنوز در این زمینه کاملاً بینقص نیست.
**زمان بارگذاری طولانی صفحه** و **منابع مسدودشده** نیز میتوانند از دلایل احتمالی باشند.
لیست هشدارهای Google Search Console
هشدارها به اندازه خطاها جدی نیستند، اما همچنان نیاز به توجه دارند. گوگل ممکن است محتوای موجود در این بخش را ایندکس کند یا نکند، اما اگر هشدارهایی که Google Search Console نشان میدهد را برطرف کنید، احتمال ایندکس شدن محتوا و حتی بهبود رتبه شما افزایش پیدا میکند.
Indexed, though blocked by robots.txt
ایندکس شده، اما توسط robots.txt مسدود شده است
صفحه ایندکس شده، با وجود اینکه توسط **robots.txt** مسدود شده است.
فایل **robots.txt** مانند یک پلیس راهنمایی برای موتورهای جستجو عمل میکند. این فایل اجازه میدهد برخی خزندهها در سایت شما حرکت کنند و برخی دیگر را مسدود میکند. شما میتوانید خزندهها را در سطح دامنه یا حتی در سطح یک صفحه خاص مسدود کنید.
متأسفانه این هشدار خاص چیزی است که ما **خیلی زیاد** میبینیم. معمولاً زمانی اتفاق میافتد که کسی میخواهد یک **ربات مخرب** را مسدود کند اما یک قانون بیش از حد سختگیرانه در robots.txt قرار میدهد.
Blocked By Robots
مسدود شده توسط robots.txt
حتی با اینکه وبسایت همچنان در نتایج جستجو باقی مانده بود، اسنیپت نمایشدادهشده چندان مناسب نبود؛ زیرا گوگل نمیتوانست **Title Tag**، **Meta Description** یا محتوای صفحه را ببیند.
پس چطور این مشکل را برطرف میکنید؟ بیشتر اوقات، این هشدار زمانی رخ میدهد که هر دو مورد زیر وجود داشته باشند:
– یک دستور `disallow` در فایل `robots.txt`
– یک متاتگ `noindex` در HTML صفحه
شما از دستور `noindex` استفاده کردهاید تا به موتورهای جستجو بگویید یک صفحه نباید ایندکس شود، اما همزمان دسترسی خزندهها به این صفحات را در فایل `robots.txt` مسدود کردهاید. اگر خزندههای موتور جستجو نتوانند به این URLها دسترسی داشته باشند، نمیتوانند دستور `noindex` را ببینند.
برای حذف این URLها از ایندکس و رفع هشدار **Indexed, though blocked by robots.txt**، باید دستور `disallow` مربوط به این URLها را از فایل `robots.txt` حذف کنید. پس از آن، خزندهها میتوانند دستور `noindex` را ببینند و این صفحات را از ایندکس حذف کنند.
—
لیست URLهای معتبر در Google Search Console
این بخش درباره قسمت سالم سایت شما اطلاعات میدهد. گوگل با موفقیت صفحات فهرستشده در اینجا را خزیده و ایندکس کرده است. اگرچه این موارد مشکل محسوب نمیشوند، اما در ادامه بهصورت خلاصه توضیح میدهیم که هر وضعیت چه معنایی دارد.
Submitted and indexed
ارسالشده و ایندکسشده
شما URL را برای ایندکس شدن ارسال کردهاید و آن URL ایندکس شده است.
شما میخواستید صفحه ایندکس شود، بنابراین آن را به گوگل معرفی کردید و گوگل هم آن را پذیرفته است. به چیزی که میخواستید رسیدهاید؛ پس میتوانید یک لیوان شامپاین برای خودتان بریزید و جشن بگیرید!
Indexed, not submitted in sitemap
ایندکسشده، اما در سایتمپ ارسال نشده است
URL توسط گوگل کشف و ایندکس شده است.
گوگل این صفحات را پیدا کرده و تصمیم گرفته آنها را ایندکس کند، اما شما کار را تا جایی که میتوانستید برایش آسان نکردهاید. گوگل و سایر موتورهای جستجو ترجیح میدهند محتوایی را که میخواهید ایندکس شود، از طریق قرار دادن آن در **sitemap** به آنها معرفی کنید.
انجام این کار میتواند بهطور بالقوه دفعات خزش محتوای شما توسط گوگل را افزایش دهد؛ موضوعی که ممکن است به رتبه بهتر و ترافیک بیشتر منجر شود.
Indexed; consider marking as canonical
ایندکسشده؛ بهتر است بهعنوان Canonical مشخص شود
URL ایندکس شده است. از آنجا که این URL نسخههای تکراری دارد، توصیه میکنیم این URL را بهصورت صریح بهعنوان نسخه **canonical** مشخص کنید.
یک URL تکراری نمونهای از صفحهای است که با چند شکل مختلف قابل دسترسی است، در حالی که در واقع همان یک صفحه است. نمونههای رایج شامل حالتی است که یک صفحه هم با اسلش پایانی و هم بدون آن قابل دسترسی باشد، یا در انتهای URL پسوند فایل داشته باشد.
برای مثال:
yoursite.com/index.html
yoursite.com
هر دو به یک صفحه منتهی میشوند.
این موارد برای سئو مضر هستند، زیرا اعتباری را که یک صفحه از طریق بکلینکهای خارجی به دست میآورد، بین دو نسخه تقسیم میکنند. همچنین موتور جستجو را مجبور میکنند منابع خود را برای خزش چند URL مربوط به یک صفحه واحد هدر دهد و حتی میتوانند گزارشهای آنالیتیکس شما را نیز شلوغ و نامنظم کنند.
تگ **canonical** یک خط کد در HTML شماست که به موتورهای جستجو میگوید کدام نسخه از URL را باید در اولویت قرار دهند و تمام سیگنالهای لینک را روی همان نسخه متمرکز میکند. استفاده از این تگ میتواند بسیار مفید باشد و بهتر است آن را در نظر بگیرید.
—
URLهای حذفشده در Google Search Console
اینها صفحاتی هستند که گوگل آنها را کشف کرده، اما تصمیم گرفته است ایندکس نکند. در بیشتر موارد، اینها صفحاتی هستند که شما صراحتاً به گوگل گفتهاید ایندکس نکند. برخی دیگر صفحاتی هستند که شاید واقعاً بخواهید ایندکس شوند، اما گوگل آنها را نادیده گرفته، چون ارزش کافی برای ایندکس شدن در آنها تشخیص نداده است.
Blocked by ‘noindex’ tag
مسدود شده توسط تگ `noindex`
هنگامی که گوگل تلاش کرد صفحه را ایندکس کند، با دستور `noindex` مواجه شد و بنابراین آن را ایندکس نکرد. اگر نمیخواهید صفحه ایندکس شود، این کار را درست انجام دادهاید. اگر میخواهید این صفحه ایندکس شود، باید دستور `noindex` را حذف کنید.
این مورد کاملاً ساده است. اگر واقعاً میخواستید این صفحه ایندکس شود، گوگل دقیقاً به شما میگوید باید چه کاری انجام دهید.
اگر نمیخواستید صفحه ایندکس شود، نیازی به انجام کاری نیست؛ اما شاید بهتر باشد در وهله اول با حذف لینکهای داخلی به آن صفحه، از خزش آن توسط گوگل جلوگیری کنید. این کار باعث میشود موتورهای جستجو منابع خود را روی صفحهای که نباید برای آن وقت بگذارند هدر ندهند و بیشتر روی صفحاتی تمرکز کنند که اهمیت دارند.
Blocked by page removal tool
مسدود شده توسط ابزار حذف صفحه
این صفحه در حال حاضر بهدلیل یک درخواست حذف URL مسدود شده است.
شخصی در شرکت شما مستقیماً از گوگل خواسته است که این صفحه را با استفاده از ابزار حذف صفحه حذف کند. این وضعیت موقتی است؛ بنابراین اگر میخواهید صفحه همچنان مسدود بماند، بهتر است صفحه را حذف کنید تا خطای **404** برگرداند، یا برای دسترسی به آن الزام ورود ایجاد کنید.
در غیر این صورت، ممکن است گوگل دوباره تصمیم بگیرد آن را ایندکس کند.
Blocked by robots.txt
مسدود شده توسط `robots.txt`
این صفحه از طریق فایل `robots.txt` برای Googlebot مسدود شده است.
اگر صفحهای در نتایج جستجو ایندکس شده باشد، اما ناگهان با فایل `robots.txt` مسدود شود، گوگل معمولاً آن صفحه را برای مدتی در ایندکس نگه میدارد. دلیلش این است که بسیاری از صفحات بهصورت تصادفی مسدود میشوند و گوگل دستور `noindex` را بهترین سیگنال برای تشخیص این موضوع میداند که آیا میخواهید محتوا حذف شود یا نه.
اگر این مسدودسازی بیش از حد طول بکشد، گوگل صفحه را حذف خواهد کرد. احتمالاً دلیل آن این است که اگر گوگل نتواند صفحه را بخزد، نمیتواند اسنیپتهای مفیدی برای سایت شما ایجاد کند؛ و این موضوع برای هیچکس خوب نیست.
Blocked due to unauthorized request (401)
مسدود شده بهدلیل درخواست غیرمجاز **(401)**
این صفحه بهدلیل درخواست احراز هویت، یعنی پاسخ **401**، برای Googlebot مسدود شده است. اگر میخواهید Googlebot بتواند این صفحه را بخزد، یا باید الزامات احراز هویت را حذف کنید، یا با تأیید هویت Googlebot اجازه دهید به صفحات شما دسترسی پیدا کند.
یک اشتباه رایج این است که هنگام ساخت سایت، به صفحات موجود در سایت آزمایشی یا استیجینگ لینک داده شود، مثل:
staging.yoursite.com
beta.yoursite.com
اما پس از آنلاین شدن سایت در محیط اصلی، فراموش شود این لینکها بهروزرسانی شوند.
سایت خود را برای پیدا کردن این URLها جستجو کنید و آنها را اصلاح کنید. اگر سایت شما صفحات زیادی دارد، ممکن است برای انجام این کار به کمک تیم IT نیاز داشته باشید. ابزارهای خزش مانند **Screaming Frog SEO Spider** میتوانند به شما کمک کنند سایت خود را بهصورت گسترده اسکن کنید.
Crawl anomaly
ناهنجاری در خزش (Crawl anomaly)
هنگام دریافت (Fetch) این URL، یک ناهنجاری نامشخص رخ داده است. این میتواند به معنای کد پاسخ سطح 4xx یا 5xx باشد.
این مشکل ممکن است نشانهای از وجود مشکلی طولانیمدت در سرور شما باشد. بررسی کنید که آیا صفحه در مرورگر شما قابل دسترسی است یا خیر و از ابزار **URL Inspection** استفاده کنید. شاید بخواهید با شرکت هاستینگ خود تماس بگیرید تا تأیید کنید که مشکل جدی در پایداری سایت شما وجود ندارد.
در تشخیص این مشکل در وبسایتهای مختلف، متوجه شدهایم که URLهای مورد نظر اغلب این ویژگیها را دارند:
* بخشی از یک زنجیره ریدایرکت هستند.
* صفحهای هستند که به صفحهای دیگر ریدایرکت میشود و آن صفحه خطای 404 برمیگرداند.
* صفحهای هستند که دیگر وجود ندارد و خطای 404 برمیگرداند.
اگر در ریدایرکتهای خود وضعیت عجیبی میبینید، باید آن را پاکسازی کنید. مطمئن شوید که ریدایرکت فقط یک مرحله دارد و صفحهای که URL شما به آن اشاره میکند، بهدرستی بارگذاری شده و پاسخ 200 برمیگرداند. پس از رفع مشکل، حتماً دوباره از طریق ابزار **Fetch as Google** اقدام کنید تا محتوای شما دوباره خزیده و در نهایت ایندکس شود.
اگر صفحه خطای 404 برمیگرداند، مطمئن شوید که مشکل از سرعت صفحه یا سرور نیست.
خزیده شده – در حال حاضر ایندکس نشده است (Crawled – currently not indexed)
صفحه توسط گوگل خزیده شده، اما ایندکس نشده است. ممکن است در آینده ایندکس شود یا نشود؛ نیازی به ارسال مجدد این URL برای خزش نیست.
اگر این وضعیت را میبینید، محتوای خود را بهدقت بررسی کنید. آیا به پرسش کاربر پاسخ میدهد؟ آیا محتوا دقیق است؟ آیا تجربه کاربری خوبی به کاربران ارائه میدهید؟ آیا به منابع معتبر لینک دادهاید؟ آیا کس دیگری به این صفحه لینک داده است؟
حتماً با استفاده از **دادههای ساختاریافته (Structured Data)**، چارچوب دقیقی از تمام محتوای صفحهای که نیاز به ایندکس شدن دارد، ارائه دهید. این کار به موتورهای جستجو اجازه میدهد که نه تنها محتوای شما را ایندکس کنند، بلکه در پرسوجوهای آینده و احتمالاً به عنوان «اسنیپتهای ویژه» (Featured Snippets) نمایش داده شود.
بهینهسازی صفحه ممکن است شانس ایندکس شدن آن توسط گوگل را در خزش بعدی افزایش دهد.
کشفشده – در حال حاضر ایندکس نشده است (Discovered – currently not indexed)
صفحه توسط گوگل پیدا شده، اما هنوز خزیده نشده است.
با وجود اینکه گوگل URL را کشف کرده، اما احساس نکرده است که آنقدر مهم باشد که وقت خود را صرف خزیدن آن کند. اگر میخواهید این صفحه ترافیک ارگانیک دریافت کند، به فکر لینک دادن بیشتر به آن از داخل وبسایت خود باشید. حتماً این محتوا را برای دیگران تبلیغ کنید، به این امید که بتوانید از وبسایتهای خارجی بکلینک بگیرید. لینکهای خارجی به محتوای شما، سیگنالی برای گوگل است که صفحه باارزش است و معتبر در نظر گرفته میشود، که این موضوع شانس ایندکس شدن آن را افزایش میدهد.
صفحه جایگزین با تگ کنونیکال مناسب (Alternate page with proper canonical tag)
این صفحه نسخه تکراریِ صفحهای است که گوگل آن را به عنوان نسخه اصلی (canonical) میشناسد و بهدرستی به آن صفحه اصلی اشاره میکند؛ بنابراین در اینجا کار خاصی برای انجام دادن ندارید!
همانطور که ابزار میگوید، واقعاً کاری برای انجام دادن نیست. اگر از اینکه یک صفحه از طریق بیش از یک URL قابل دسترسی است اذیت میشوید، ببینید آیا راهی برای یکپارچهسازی وجود دارد یا خیر.
محتوای تکراری بدون تگ کنونیکالِ تعیینشده توسط کاربر
این صفحه نسخههای تکراری دارد که هیچکدام به عنوان `canonical` علامتگذاری نشدهاند. ما فکر میکنیم این صفحه، نسخه اصلی (canonical) نیست. شما باید بهطور صریح تگ کنونیکال را برای این صفحه مشخص کنید.
گوگل در حال حدس زدن این است که کدام صفحه را میخواهید ایندکس کند. اجازه ندهید حدس بزند. شما میتوانید با استفاده از تگ `canonical` بهطور صریح به گوگل بگویید که کدام نسخه از یک صفحه باید ایندکس شود.
صفحه غیر HTML تکراری (Duplicate non-HTML page)
یک صفحه غیر HTML (مثلاً فایل PDF) کپی صفحهای است که گوگل آن را به عنوان `canonical` علامتگذاری کرده است.
گوگل فایلی PDF در سایت شما پیدا کرده که حاوی همان اطلاعات یک صفحه HTML معمولی است، بنابراین انتخاب کرده که فقط نسخه HTML را ایندکس کند. بهطور کلی، این همان چیزی است که میخواهید اتفاق بیفتد، بنابراین مگر اینکه به دلیلی ترجیح دهید از نسخه PDF استفاده کنند، نیازی به اقدام خاصی نیست.
تکراری، گوگل کنونیکال متفاوتی نسبت به انتخاب کاربر انتخاب کرده است
Duplicate, Google chose different canonical than user
این URL برای مجموعهای از صفحات به عنوان `canonical` علامتگذاری شده، اما گوگل فکر میکند URL دیگری گزینه بهتری برای کنونیکال است.
گوگل در مورد اینکه کدام نسخه از یک صفحه را باید ایندکس کند، با شما موافق نیست. بهترین کاری که میتوانید انجام دهید این است که مطمئن شوید تگهای `canonical` را در تمام صفحات تکراری دارید، این تگها با هم سازگار هستند و شما فقط به نسخه کنونیکال خود به صورت داخلی لینک میدهید. سعی کنید از ارسال سیگنالهای متناقض خودداری کنید.
ما دیدهایم که این اتفاق زمانی میافتد که یک وبسایت نسخهای از صفحه را به عنوان کنونیکال مشخص میکند، اما سپس کاربر را به نسخه متفاوتی ریدایرکت میکند. از آنجا که گوگل نمیتواند به نسخهای که شما مشخص کردهاید دسترسی پیدا کند، فرض میکند که شاید اشتباه کردهاید و دستور شما را نادیده میگیرد.
پیدا نشد Not found (404)
این صفحه هنگام درخواست، خطای 404 برگردانده است. URL توسط گوگل بدون هیچ درخواست صریحی برای خزیدن، کشف شده است.
خطاهای 404 زمانی رخ میدهند که گوگل سعی میکند یک لینک یا URLای را که قبلاً ایندکس شده، به صفحهای که دیگر وجود ندارد، بخزد. بسیاری از خطاهای 404 در وب زمانی ایجاد میشوند که وبسایتی لینکهای خود را تغییر میدهد، اما فراموش میکند ریدایرکتهایی از نسخه قدیمی به URL جدید تنظیم کند.
اگر جایگزینی برای صفحهای که خطای 404 ایجاد میکند در وبسایت شما وجود دارد، باید یک ریدایرکت 301 دائمی از URL قدیمی به URL جدید ایجاد کنید. این کار باعث میشود گوگل و کاربران شما صفحه 404 را نبینند و لینک شکسته را تجربه نکنند. این کار همچنین میتواند به شما کمک کند تا اکثر ترافیک جستجویی که به صفحه قدیمی هدایت میشده را حفظ کنید.
اگر صفحه دیگر وجود ندارد، اجازه دهید URL همچنان خطای 404 برگرداند، اما سعی کنید تمام لینکهایی که به آن اشاره میکنند را حذف کنید. هیچکس لینکهای شکسته را دوست ندارد.
صفحه بهدلیل شکایت قانونی حذف شد
Page removed because of legal complaint
صفحه بهدلیل یک شکایت قانونی از ایندکس حذف شده است.
اگر وبسایت شما هک شده و به کدهای مخرب آلوده شده باشد، احتمال زیادی وجود دارد که تعداد زیادی از این مشکلات را در گزارشهای خود ببینید. هکرها عاشق ساختن صفحاتی برای دانلود غیرقانونی تورنت فیلم و داروهای تجویزی هستند که بخشهای حقوقی شرکتهای بزرگ آنها را جستجو کرده و علیه آنها شکایت میکنند.
اگر یکی از این موارد را دریافت کردید، بلافاصله مطالب دارای حق چاپ (Copyright) را حذف کنید و مطمئن شوید وبسایت شما هک نشده است. اطمینان حاصل کنید که تمام افزونهها بهروز هستند، رمزهای عبور شما امن هستند و از آخرین نسخه نرمافزار CMS خود استفاده میکنید.
صفحه دارای ریدایرکت (Page with redirect)
این URL یک ریدایرکت است و بنابراین به ایندکس اضافه نشده است.
گوگل فقط URLهایی را ایندکس میکند که وضعیت موفقیت 200 را برمیگردانند. اگر این اعلان را میبینید، به این معنی است که URL یک کد وضعیت ریدایرکت (مانند 301 یا 302) برمیگرداند. این موضوع باعث میشود که واجد شرایط برای ایندکس شدن نباشد.
برای حل این مشکل، باید تعیین کنید که آیا مشکل این است که خود URL ریدایرکت میشود، یا مشکل این است که شما گوگل را هدایت میکنید تا یک URL ریدایرکتشونده را بخزد. اگر مشکل این است که URL ریدایرکت میشود، حذف ریدایرکت را در نظر بگیرید.
اگر مشکل این است که شما گوگل را هدایت میکنید تا یک URL ریدایرکتشونده را بخزد، اینکه این مشکل را در کدام بخش از گزارشهای خود پیدا میکنید، تأثیر زیادی بر نحوه پیگیری رفع آن خواهد داشت.
* **اگر در بخش “All submitted pages” است:**
این یعنی صفحه دارای ریدایرکت در فایل `sitemap.xml` ارسالی شما پیدا شده است. گنجاندن یک URL ریدایرکتشونده در سایتمپ ارسالی ممکن است مشکل اصلی باشد، نه اینکه خودِ URL ریدایرکت میشود. این میتواند نتیجه ریدایرکتی باشد که قبل از انتشار (Unpublish) یک صفحه که دیگر نیازی به آن نبوده، ایجاد شده است. میتوانید این وضعیت را با Unpublish کردن صفحه در CMS خود و حذف URL از `sitemap.xml` اصلاح کنید. عمل Unpublish کردن اغلب برای حذف صفحه از فایل سایتمپ کافی است، اما CMS و وبسایت شما ممکن است رفتار متفاوتی داشته باشند، بنابراین باید بررسی کنید.
* **اگر فقط در بخش “Unsubmitted pages” است:**
این یعنی گوگل URL را هنگام خزیدن در لینکهای وبسایت شما یا لینکهای وبسایت خارجی پیدا کرده است. در خارج از سایت، کار خاصی نمیتوانید انجام دهید. از نظر داخلی، ممکن است بتوانید اقداماتی انجام دهید.
اگر هایپرلینکهایی در وبسایت خود دارید که به URL ریدایرکتشده اشاره میکنند، باید جایگزینی آن هایپرلینکها با URLای که وضعیت 200 برمیگرداند را در نظر بگیرید. در مورد ریدایرکت، این معمولاً همان URL مقصد است. هدف شما باید این باشد که فقط به URLهای دارای وضعیت 200 در وبسایت خود لینک دهید.
زمان اعتبارسنجی (When to validate)
فقط در صورتی باید درخواست اعتبارسنجی ارسال کنید که تشخیص دهید مشکل ناشی از ریدایرکت بودن URL بوده و برای حذف آن اقدام کردهاید تا URL وضعیت 200 را برگرداند.
اگر تشخیص دادید که مشکل اصلی این بوده که شما گوگل را هدایت میکردید تا یک URL ریدایرکتشونده را بخزد، باید طبق روشی که در بالا ذکر شد اقدام به رفع آن کنید، اما از ارسال درخواست اعتبارسنجی خودداری کنید.
در صف انتظار برای خزش (Queued for crawling)
صفحه در صف خزش قرار دارد؛ چند روز دیگر بررسی کنید تا ببینید خزیده شده است یا خیر.
این خبر خوبی است! انتظار داشته باشید که محتوای خود را بهزودی در نتایج جستجو ایندکس شده ببینید. بروید یک کیسه پاپکورن در مایکروویو بگذارید و کمی بعد دوباره سر بزنید. از این زمانِ استراحت برای پاکسازی تمام مشکلات آزاردهنده دیگری که در گزارش «پوشش ایندکس» شناسایی کردهاید، استفاده کنید.
خطای Soft 404
درخواست صفحه، پاسخی را برمیگرداند که ما تصور میکنیم یک Soft 404 است.
از نظر گوگل، این صفحات پوستهای از خودِ گذشتهشان هستند. بازماندههای چیزی مفید که زمانی وجود داشته، اما دیگر وجود ندارد. شما باید اینها را به صفحات 404 تبدیل کنید یا شروع به پر کردن آنها با محتوای مفید کنید.
URL ارسالشده حذف شد (Submitted URL dropped)
شما این صفحه را برای ایندکس ارسال کردهاید، اما به دلیلی نامشخص از ایندکس حذف شده است.
توضیح این مشکل بسیار مبهم است، بنابراین گفتن اینکه دقیقاً چه کاری باید انجام دهید دشوار است. بهترین حدس ما این است که گوگل به محتوای شما نگاه کرده، مدتی آن را امتحان کرده و سپس تصمیم گرفته که دیگر آن را در ایندکس خود شامل نکند.
صفحه را بررسی و کیفیت کلی آن را نقد کنید. آیا صفحه «کممحتوا» (Thin) است؟ قدیمی است؟ نادرست است؟ کند بارگذاری میشود؟ سالهاست که نادیده گرفته شده است؟ آیا رقبای شما چیزی بسیار بهتر از آن منتشر کردهاند؟
سعی کنید محتوا را تازه و بهبود ببخشید و چند لینک جدید به صفحه بگیرید. این ممکن است منجر به ایندکس شدن مجدد صفحه شود.
Duplicate, Submitted URL not selected as canonical
تکراری، URL ارسالشده به عنوان کنونیکال انتخاب نشده است
این URL یکی از مجموعه URLهای تکراری بدون تگ کنونیکالِ تعیینشده توسط کاربر است. شما بهطور صریح خواستهاید که این URL ایندکس شود، اما چون تکراری است و گوگل فکر میکند URL دیگری گزینه بهتری برای کنونیکال است، گوگل این URL را ایندکس نکرده است. در عوض، ما نسخهای که به عنوان کنونیکال انتخاب کردیم را ایندکس کردیم.
گوگل URLای را خزیده که شما بهطور صریح از آن خواستهاید، اما سپس شما به گوگل گفتهاید که یک نسخه تکراری از همان صفحه، در واقع نسخهای است که باید ایندکس شود و به آن توجه شود.
تصمیم بگیرید کدام نسخه را میخواهید ایندکس شود، آن را به عنوان `canonical` تنظیم کنید و سپس هنگام لینک دادن به صفحهای از این مجموعه تکراری، هم به صورت داخلی در وبسایت خود و هم در خارج از سایت، آن نسخه را در اولویت قرار دهید.
نحوه کار با گزارش Mobile Usability
با توجه به اینکه بخش هرچه بیشتری از ترافیک وب و جستجوهای روزانه از طریق دستگاههای موبایل انجام میشود، گوگل و سایر موتورهای جستجو هنگام تعیین رتبه صفحات، تمرکز بیشتری بر اهمیت **قابلیت استفاده در موبایل** یا **Mobile Usability** داشتهاند.
گزارش **Mobile Usability** در Google Search Console به شما کمک میکند مشکلات مربوط به سازگاری با موبایل را سریع شناسایی کنید؛ مشکلاتی که میتوانند به تجربه کاربری کاربران شما آسیب بزنند و مانع از دریافت ترافیک ارگانیک بیشتر برای وبسایتتان شوند.
در بخش زیر، برخی از رایجترین مشکلاتی را که در این گزارش شناسایی میشوند بررسی میکنیم و توضیح میدهیم چگونه میتوانید برای رفع آنها اقدام کنید.
زمانی که صفحه شما از پلاگینهای ناسازگار استفاده میکند
صفحه شامل پلاگینهایی مانند **Flash** است که توسط بیشتر مرورگرهای موبایل پشتیبانی نمیشوند. توصیه میکنیم ظاهر، حس بصری و انیمیشنهای صفحه را با استفاده از فناوریهای مدرن وب طراحی کنید.
در سال ۲۰۱۷، شرکت Adobe اعلام کرد که تا پایان سال ۲۰۲۰ پشتیبانی از Flash را متوقف خواهد کرد. این یکی از آخرین میخها بر تابوت Flash بود؛ فناوریای که با موبایل سازگار نبود و مشکلات امنیتی زیادی داشت. امروزه فناوریهای باز وب بهتری وجود دارند که نسبت به Flash سریعتر و از نظر مصرف انرژی بهینهتر هستند.
برای رفع این مشکل، باید عنصر Flash خود را با یک راهکار مدرن مانند **HTML5** جایگزین کنید یا آن محتوا را بهطور کامل حذف کنید.
Viewport not set
Viewport تنظیم نشده است
صفحه ویژگی **viewport** را تعریف نکرده است؛ ویژگیای که به مرورگرها میگوید چگونه ابعاد و مقیاس صفحه را متناسب با اندازه صفحهنمایش تنظیم کنند. از آنجا که بازدیدکنندگان سایت شما از دستگاههای مختلف با اندازه صفحهنمایش متفاوت استفاده میکنند — از مانیتورهای بزرگ دسکتاپ گرفته تا تبلتها و گوشیهای هوشمند کوچک — صفحات شما باید با استفاده از متاتگ **meta viewport** یک viewport مشخص کنند.
**Viewport** روشی فنی است که مرورگر از طریق آن متوجه میشود چگونه تصاویر و سایر عناصر وبسایت شما را بهدرستی مقیاسبندی کند تا در همه دستگاهها ظاهر خوبی داشته باشند. مگر اینکه با HTML آشنا باشید، احتمالاً برای این کار به کمک یک توسعهدهنده نیاز خواهید داشت. اگر میخواهید خودتان آن را امتحان کنید، این راهنما ممکن است مفید باشد.
Viewport not set to “device-width”
Viewport روی `device-width` تنظیم نشده است
صفحه یک ویژگی viewport با عرض ثابت تعریف کرده است؛ یعنی نمیتواند خود را با اندازههای مختلف صفحهنمایش تطبیق دهد. برای رفع این خطا، برای صفحات سایت خود از طراحی واکنشگرا یا **Responsive Design** استفاده کنید و viewport را طوری تنظیم کنید که با عرض دستگاه هماهنگ باشد و متناسب با آن مقیاسبندی شود.
در روزهای ابتدایی طراحی واکنشگرا، برخی توسعهدهندگان ترجیح میدادند وبسایت را برای تجربههای موبایلی کمی دستکاری کنند، بهجای اینکه سایت را کاملاً واکنشگرا بسازند. viewport با عرض ثابت روش خوبی برای انجام این کار بود، اما با ورود دستگاههای موبایل بیشتر و بیشتر به بازار، این راهکار جذابیت کمتری پیدا کرده است.
گوگل اکنون تجربههای وب واکنشگرا را ترجیح میدهد. اگر این مشکل را مشاهده میکنید، احتمالاً برخی از کاربران موبایل خود را کلافه کردهاید و شاید مقداری از ترافیک ارگانیک را هم از دست داده باشید. ممکن است زمان آن رسیده باشد که با یک آژانس همکاری کنید یا یک توسعهدهنده استخدام کنید تا وبسایت شما را واکنشگرا کند.
Content wider than screen
محتوا عریضتر از صفحهنمایش است
برای دیدن کلمات و تصاویر روی صفحه، اسکرول افقی لازم است. این اتفاق زمانی رخ میدهد که صفحات از مقادیر مطلق در اعلانهای CSS استفاده میکنند، یا از تصاویری بهره میبرند که برای نمایش در یک عرض مشخص مرورگر، مثلاً **980px**، طراحی شدهاند.
برای رفع این خطا، مطمئن شوید صفحات از مقادیر نسبی برای عرض و موقعیت عناصر CSS استفاده میکنند و تصاویر نیز قابلیت مقیاسپذیری دارند.
این مشکل معمولاً زمانی رخ میدهد که یک تصویر یا عنصر خاص در صفحه شما برای دستگاههای موبایل بهدرستی اندازهگیری نمیشود. در وردپرس، این مشکل معمولاً وقتی ایجاد میشود که به یک تصویر کپشن داده شده باشد یا از افزونهای برای تولید عنصری استفاده شده باشد که بهصورت بومی در قالب شما وجود ندارد.
راه ساده برای رفع این مشکل این است که تصویر یا عنصری را که در موبایل بهدرستی اندازهگیری نمیشود، حذف کنید. راه درستتر این است که کد خود را تغییر دهید تا آن عنصر واکنشگرا شود.
Text too small to read
متن برای خواندن خیلی کوچک است
اندازه فونت صفحه آنقدر کوچک است که خوانا نیست و بازدیدکنندگان موبایل مجبور میشوند برای خواندن، با دو انگشت صفحه را بزرگنمایی کنند یا اصطلاحاً **pinch to zoom** انجام دهند. پس از تعیین viewport برای صفحات وب خود، اندازه فونتها را طوری تنظیم کنید که درون viewport بهدرستی مقیاسبندی شوند.
به زبان ساده، خواندن وبسایت شما روی دستگاههای موبایل بیش از حد دشوار است. برای تجربه مستقیم این مشکل، کافی است صفحه مورد نظر را روی یک گوشی هوشمند باز کنید و خودتان آن را ببینید.
طبق گفته گوگل، یک قانون کلی خوب این است که صفحه در دستگاه موبایل در هر خط بیش از **۷۰ تا ۸۰ کاراکتر**، یعنی حدود **۸ تا ۱۰ کلمه**، نمایش ندهد. اگر بیشتر از این مقدار میبینید، بهتر است از یک آژانس یا توسعهدهنده بخواهید کد شما را اصلاح کند.
Clickable elements too close together
عناصر قابل کلیک بیش از حد به هم نزدیک هستند
این گزارش URLهایی را نشان میدهد که در آنها عناصر لمسی، مانند دکمهها و لینکهای ناوبری، آنقدر به هم نزدیکاند که کاربر موبایل نمیتواند بهراحتی با انگشت خود روی عنصر مورد نظر ضربه بزند، بدون اینکه همزمان روی عنصر کناری هم ضربه بزند.
برای رفع این خطاها، مطمئن شوید اندازه و فاصله دکمهها و لینکهای ناوبری بهدرستی تنظیم شده و برای بازدیدکنندگان موبایل مناسب است.
تا به حال وارد یک وبسایت غیرواکنشگرا شدهاید که لینکهای آن آنقدر کوچک باشند که استفاده از آن تقریباً **غیرممکن** باشد؟ این مشکل دقیقاً درباره همین موضوع است. برای مشاهده مستقیم مشکل، صفحه را روی یک دستگاه موبایل باز کنید و مثل یکی از مشتریان خود در سایت کلیک کنید. اگر جابهجایی از یک صفحه به صفحه دیگر دشوار است و قبل از کلیک مجبورید صفحه را بزرگنمایی کنید، مطمئن باشید مشکلی وجود دارد.
گوگل توصیه میکند عناصر قابل کلیک اندازه لمسی هدفی حدود **۴۸ پیکسل** داشته باشند؛ این مقدار معمولاً حدود یکسوم عرض صفحه یا تقریباً اندازه بخش نرم نوک انگشت یک فرد است. بهعنوان یک راهکار ساده، لینکهای متنی کوچک را با دکمههای بزرگتر جایگزین کنید.
نحوه کار با گزارش Core Web Vitals
مهم است که هر مشکلی را که ممکن است در توانایی گوگل برای خزش و رتبهبندی وبسایت شما اختلال ایجاد کند، شناسایی و برطرف کنید؛ اما گوگل همچنین این موضوع را در نظر میگیرد که آیا وبسایت شما تجربه کاربری خوبی ارائه میدهد یا نه.
گزارش **Core Web Vitals** در Google Search Console بهطور ویژه روی **سرعت صفحه** تمرکز دارد. این گزارش روی معیارهای کلیدی سرعت صفحه تمرکز میکند که کیفیت تجربه کاربری را اندازهگیری میکنند؛ بنابراین میتوانید فرصتهای بهبود را بهراحتی شناسایی کرده و تغییرات لازم را در سایت خود اعمال کنید.
برای تمام URLهای سایت شما، این گزارش سه معیار را نمایش میدهد:
– **LCP**
– **FID**
– **CLS**
و همچنین یک وضعیت برای هرکدام نشان میدهد:
– **Poor**: ضعیف
– **Needs Improvement**: نیازمند بهبود
– **Good**: خوب
در ادامه، پارامترهای گوگل برای تعیین وضعیت هر معیار آمده است.
**نمودار Core Web Vitals گوگل**
بیایید هر یک از این سه معیار و روش بهبود آنها را بررسی کنیم.
—
Largest Contentful Paint (LCP)
**Largest Contentful Paint** یا **LCP** یعنی مدت زمانی که طول میکشد تا بزرگترین عنصر محتوایی صفحه پس از باز شدن URL به کاربر نمایش داده شود.
First Input Delay (FID)
**First Input Delay** یا **FID** یعنی مدت زمانی که طول میکشد تا مرورگر به تعامل کاربر، مانند کلیک روی یک لینک، پاسخ دهد.
Cumulative Layout Shift (CLS)
**Cumulative Layout Shift** یا **CLS** معیاری است برای سنجش اینکه چقدر چیدمان سایت شما بهطور غیرمنتظره تغییر میکند؛ تغییری که منجر به تجربه کاربری ضعیف میشود.
Largest Contentful Paint (LCP)
**Largest Contentful Paint** یا **LCP** به مدتزمانی اشاره دارد که طول میکشد تا بزرگترین عنصر محتوایی صفحه، پس از باز شدن صفحه، به کاربر نمایش داده شود. اگر عنصر اصلی صفحه در یک بازه زمانی معقول، یعنی **کمتر از ۲.۵ ثانیه**، بارگذاری نشود، این موضوع به تجربه کاربری ضعیف منجر میشود؛ زیرا کاربر میبیند که چیزی روی صفحه ظاهر نمیشود.
First Input Delay (FID)
**First Input Delay** یا **FID** معیاری است برای اندازهگیری اینکه مرورگر چه مدت طول میکشد تا به تعامل کاربر، مانند کلیک روی یک لینک و موارد مشابه، پاسخ دهد. این معیار مهم است، چون بهطور مستقیم نشان میدهد وبسایت شما چقدر **پاسخگو** است. اگر عناصر تعاملی یک صفحه خیلی دیر واکنش نشان دهند، کاربر به احتمال زیاد کلافه و ناراضی میشود.
Cumulative Layout Shift (CLS)
**Cumulative Layout Shift** یا **CLS** معیاری است برای سنجش اینکه در مرحله بارگذاری، چیدمان سایت شما چند بار بهطور غیرمنتظره تغییر میکند. CLS اهمیت دارد، چون تغییرات ناگهانی در چیدمان صفحه، درست زمانی که کاربر در حال تعامل با صفحه است، میتواند بسیار آزاردهنده باشد و تجربه کاربری ضعیفی ایجاد کند.
بهبود Core Web Vitals
یک راه ساده برای بررسی این معیارها در سطح هر صفحه و شناسایی سریع راهحلها، استفاده از **Chrome DevTools** است.
بعد از اینکه در **Google Search Console** صفحهای را که مشکل دارد شناسایی کردید، به URL همان صفحه بروید و کلیدهای زیر را فشار دهید:
– در **Windows**:
`Control + Shift + C`
– در **Mac**:
`Command + Shift + C`
یا بهصورت جایگزین، میتوانید روی هرجای صفحه راستکلیک کرده و گزینه **Inspect** را انتخاب کنید.
از آنجا، باید به گزینه منوی **Lighthouse** بروید.
**ابزارهای توسعهدهنده Chrome**
Lighthouse صفحه را بررسی میکند و یک گزارش تولید میکند که عملکرد صفحه را از **100** امتیازدهی میکند. در این گزارش، علاوه بر سایر معیارهای مفید سرعت صفحه، اندازهگیریهای مربوط به **LCP**، **FID** و **CLS** را نیز خواهید دید.
**امتیاز عملکرد Lighthouse**
بهترین بخش **Google Lighthouse** این است که توصیههای **قابل اجرا** برای بهبود معیارهای بالا ارائه میدهد، همراه با **Estimated Savings** یا میزان صرفهجویی تخمینی.
**فرصتهای بهبود در گزارش Performance**
در صورت امکان، با توسعهدهنده خود همکاری کنید تا تغییرات پیشنهادی را پیادهسازی کند.
چگونه به گوگل بگویید که یک مشکل سایت را برطرف کردهاید؟
وقتی در حال بررسی هر مشکل هستید، متوجه میشوید که با کلیک روی URL یک صفحه، یک پنل جدید در سمت راست صفحهنمایش شما باز میشود.
**عیبیابی مشکلات در Google Search Console**
این فهرست را مرور کنید و مطمئن شوید از آنچه میبینید راضی هستید. گوگل این لینکها را بیدلیل اینجا قرار نداده؛ آنها میخواهند شما از آنها استفاده کنید.
اگر هنوز مطمئن هستید که مشکل برطرف شده، میتوانید با کلیک روی **VALIDATE FIX** فرآیند را کامل کنید.
**اعتبارسنجی رفع مشکل در Google Search Console**
در این مرحله، یک ایمیل از گوگل دریافت خواهید کرد که به شما اطلاع میدهد فرآیند اعتبارسنجی آغاز شده است. این فرآیند بسته به تعداد مشکلاتی که گوگل باید دوباره بخزد، ممکن است **چند روز تا چند هفته** طول بکشد.
اگر مشکل برطرف شده باشد، احتمال زیادی وجود دارد که محتوای شما ایندکس شود و در نتایج جستجوی گوگل نمایش داده شوید. این یعنی شانس بیشتری برای جذب **ترافیک جستجوی ارگانیک** به سایتتان خواهید داشت. فوقالعاده است! شما یک ابرقهرمان سئو هستید!