Google مستندات SEO جاوااسکریپت خود را با رهنمودهای جدید درباره آدرسهای کانونیکال برای صفحات رندر شده با جاوااسکریپت بهروزرسانی کرد. آدرسهای کانونیکال را قبل و بعد از رندر یکسان نگه دارید.
تعیین canonical هم پیش از رندر و هم پس از رندر انجام میشود.
تضاد سیگنالهای canonical بین HTML خام و خروجی جاوااسکریپت میتواند منجر به نتایج شاخصگذاری غیرمنتظره شود.
Google توصیه میکند که آدرس canonical را در HTML اصلی بهگونهای تنظیم کنید که با آدرسی که جاوااسکریپت رندر میکند، مطابقت داشته باشد.
Google مستندات SEO جاوااسکریپت خود را با رهنمودهای جدید دربارهٔ مدیریت آدرسهای canonical برای سایتهای رندر شده با جاوااسکریپت بهروزرسانی کرد.
بهروزرسانی مستندات همچنین شامل راهنماییهای مرتبط با بهترین شیوههای Google برای ادغام URLهای تکراری میشود.
چهجدید
مستندات بهروزرسانیشده روی یک مسألهٔ زمانی خاص برای سایتهای جاوااسکریپت تمرکز دارد: فرآیند canonical میتواند دو بار در طول پردازشهای Google انجام شود.
Google سیگنالهای canonical را یکبار هنگام اولین خزیدهسازی HTML خام بررسی میکند و سپس پس از رندر جاوااسکریپت دوباره ارزیابی میکند. اگر در HTML خام شما یک آدرس canonical وجود داشته باشد و جاوااسکریپت آدرس دیگری تنظیم کند، ممکن است Google سیگنالهای متضاد دریافت کند.
در مستندات ذکر شده است که افزودن تگهای canonical از طریق جاوااسکریپت پشتیبانی میشود اما توصیه نمیشود. وقتی جاوااسکریپت آدرس canonical را تنظیم میکند، Google میتواند آن را در زمان رندر شناسایی کند، اما پیادهسازیهای نادرست میتوانند منجر به بروز مشکلات شوند.
وجود چندین تگ canonical یا تغییر تگ canonical موجود در طول رندر میتواند به نتایج شاخصگذاری غیرمنتظره منجر شود.
مرتبط: چه اتفاقی میافتد وقتی Google آدرس canonical نادرست را انتخاب میکند؟
بهترین روشها
Google دو روش برتر را بسته به معماری سایت شما توصیه میکند.
روش پیشنهادی این است که آدرس canonical را در پاسخ HTML خام طوری تنظیم کنید که با آدرسی که جاوااسکریپت در نهایت رندر میکند، همخوانی داشته باشد. این کار سیگنالهای سازگار را برای Google قبل و بعد از رندر فراهم میکند.
اگر جاوااسکریپت مجبور باشد آدرس canonical متفاوتی تنظیم کند، Google توصیه میکند که تگ canonical را از HTML اولیه حذف کنید. این کار میتواند از بروز سیگنالهای متضاد بین مرحلهٔ خزش و رندر جلوگیری کند.
مستندات همچنین به توسعهدهندگان یادآوری میکند که پس از رندر، فقط یک تگ canonical در هر صفحه وجود داشته باشد.
همچنین ببینید: Google بیانیهای دربارهٔ پشتیبانی از canonicalهای بیندامنه منتشر کرد
اهمیت این موضوع
این راهنمایی به یک نکتهٔ ظریف میپردازد که هنگام مدیریت سایتهای رندر شده با جاوااسکریپت به سادگی قابلدستزدن است.
فاصله زمانی بین مرحلهٔ خزیدن Google بر روی HTML خام و مرحلهٔ رندر جاوااسکریپت، فرصتی را برای اختلاف سیگنالهای canonical ایجاد میکند.
اگر از فریمورکهایی مانند React، Vue یا Angular که مسیربندی و ساختار صفحه را در سمت کلاینت مدیریت میکنند، استفاده میکنید، بررسی نحوهٔ پیادهسازی تگهای canonical ضروری است. ببینید آیا پاسخ سرور شما شامل تگ canonical است و آیا جاوااسکریپت آن را تغییر میدهد.
در بسیاری از موارد، راهحل این است که پیادهسازیهای canonical سمت سرور و سمت کلاینت را هماهنگ کنید تا سیگنال یکسانی در هر دو مرحلهٔ پردازش Google ارسال شود.
همچنین ببینید: Google نحوهٔ تأیید مشکلات ایندکسگذاری ناشی از جاوااسکریپت را نشان میدهد
نگاه به آینده
بهروزرسانی این مستندات رفتارهایی را روشن میکند که پیش از این ممکن بود واضح نباشند. این تغییر نحوهٔ پردازش تگهای canonical توسط Google را تغییر نمیدهد.
اگر در گزارش ایندکسگذاری صفحه در کنسول جستجو، انتخاب canonical غیرمنتظرهای مشاهده میکنید، عدم تطابق بین HTML خام و تگهای canonical رندر شده را بررسی کنید. ابزار بازبینی URL هر دو نسخهٔ HTML خام و رندر شده را نشان میدهد، که امکان مقایسهٔ پیادهسازیهای canonical در هر دو فاز را فراهم میکند.
تقسیم محتوای وبسایت به چند صفحه میتواند زمان بارگذاری صفحات را تسریع کند و دسترسی کاربران به محتوا را آسانتر سازد، بهویژه برای فهرستهای طولانی محصولات.
توسط کارکنان شاپیفای
یافتن آنچه نیاز دارید در یک وبسایت بزرگ نباید حس عبور از گلخاک را القا کند. ولی با صدها محصول، پست وبلاگ یا منبع برای مرور، ممکن است دشوار شود. اینجاست که صفحهبندی وارد میشود — روشی ساده اما قدرتمند برای شکستن بخشهای عظیم محتوا به قطعات قابل هضم و پسندیده برای کلیک. اسکرول بیپایان کمتر خواهد شد، زمان بارگذاری سریعتر و مسیر واضحتری برای کاربران که در نتایج حرکت میکنند.
صفحهبندی تنها برای بهبود کاربری مفید نیست — بهطور مستقیم بر این که موتورهای جستجو چگونه محتوای شما را پیدا و رتبهبندی میکنند تأثیر میگذارد. سازماندهی محتوا در صفحات کوچکتر و ساختار یافته، کشیدن و ایندکسگذاری سایت شما را برای موتورهای جستجو آسانتر میکند. برای کاربران، تجربهٔ روانتری معنا میدهد. در اینجا نحوهٔ تأثیر صفحهبندی بر سئو، روش پیادهسازی صحیح آن و زمان مناسب برای در نظر گرفتن جایگزینها آمده است.
صفحهبندی در سئو چیست؟
صفحهبندی حجم بالایی از محتوا را به بخشهای قابلمدیریت تقسیم میکند. در چاپ، به معنای شمارهگذاری صفحات است؛ در آنلاین، به معنای شکستن فهرستها یا اسناد به صفحات جداگانه، اغلب با کنترلهایی برای پرش بین آنها است. این شبیه بهورق زدن یک کتاب بهجای کشیدن یک اسکرول پیوسته است. بهعنوان مثال، صفحهبندی مجموعهٔ بزرگ محصولات یا نتایج جستجو، سایت شما را سریعتر بارگذاری میکند و ناوبری را آسان میسازد.
صفحهبندی در سراسر اینترنت حضور دارد — شاید واضحترین مثال آن در گوگل باشد. بهجای یک اسکرول بیپایان، گوگل محتوا را به صفحات نتایج موتور جستجو تقسیم میکند. محتوا بهصورت بلوکهای ۱۰ یا ۲۰ نتیجه ظاهر میشود. کاربران با کلیک بر روی «بعدی»، «قبلی» یا شمارهٔ صفحه مسیر را دنبال میکنند. در سایت تجارت الکترونیک خود میتوانید برای محصولات، نظرات مشتریان یا صفحات دستهبندی وبلاگ از صفحهبندی استفاده کنید.
نمایش تنها ۱۰، ۲۰ یا ۵۰ محصول در هر صفحه تجربه مرور را سریعتر و پاسخگوتر میکند. صفحهای با صدها محصول بهخصوص در دستگاههای موبایل بارگذاری کندتری دارد. سرور وب شما نیازی به بارگذاری تمام دادههای محصول بهصورت یکباره ندارد — استفادهٔ مؤثرتر از پهنای باند.
کدام نوع از سایتها بیشترین بهرهوری را از صفحهبندی دارند؟
هیچ مشکلی اساسی در اسکرول بیپایان وجود ندارد — این روش در دنیای موبایل‑اول ما استاندارد است. اما برخی سایتها، بهویژه آنهایی که مجموعههای محتوای وسیعی دارند، بهطور طبیعی برای صفحهبندی مناسباند:
سایتهای تجارت الکترونیک. فروشگاههای آنلاین از کسبوکارهای کوچک تا آمازون همگی از صفحهبندی استفاده میکنند. صفحات محصول وقتی کاربران میتوانند ۱۰ یا ۱۵ مورد را بهصورت گام به گام مرور کنند، راحتتر هضم میشوند، نه یک فید بیپایان. ناوبری آسانتر میتواند کاربران را تشویق کند زمان بیشتری را در سایت بگذرانند، که نشانگر کیفیت بالاتر محتوا برای موتورهای جستجوست.
وبلاگها و سایتهای خبری. اگر مقالات زیادی منتشر میکنید، صفحهٔ اصلی بهخوبی طراحی شده به همراه صفحهبندی واضح به کاربران امکان میدهد از یک صفحه به صفحهٔ دیگر حرکت کنند.
انجمنها و گالریها. سایتهایی که حجم زیادی از پستها و عکسها را میزبانی میکنند، برای تقسیم محتوا به چند صفحه مناسباند.
چگونه صفحهبندی بر سئو تأثیر میگذارد
صفحهبندی میتواند به سئو شما کمک کند یا به آن آسیب بزند، بسته به نحوهٔ تنظیم آن. در اینجا برخی از مواردی که باید از آنها اجتناب کنید اگر قصد صفحهبندی محتوا را دارید، آورده شده است:
تضعیف ارزش لینک. موتورهای جستجو از الگوریتمی برای ارزیابی اعتبار صفحه استفاده میکنند — صفحات با رتبه بالا ارزش لینک بیشتری دارند. وقتی این صفحات معتبر به محتوای صفحهبندیشده لینک میدهند، آن ارزش میتواند در میان چندین صفحه پخش شود و ممکن است قدرت کلی رتبهبندی سایت را تضعیف کند.
محتوای تکراری. محتوا تکراری یکی از رایجترین اشتباهات صفحهبندی است. صفحات صفحهبندیشده اغلب محتواهای مشابهی دارند، بهویژه در توصیف دستهها، سرصفحهها و پاورقیها. این تکرار میتواند موتورهای جستجو را دچار سردرگمی کند و باعث شود صفحات صفحهبندی بهعنوان تکراری شناخته شوند و احتمالاً در نتایج جستجو ارزششان کاهش یابد.
مشکلات بودجه خزیدن. گوگل برای هر سایت یک بودجهٔ خزیدن دارد که تعداد صفحاتی را که در یک جلسه میخزد محدود میکند. اگر خزنده زمان زیادی را صرف خزش ۱۰۰ URL صفحهبندیشده از یک دستهبندی محصول بکند، ممکن است این بودجه تمام شود و صفحات دیگر مانند پستهای جدید وبلاگ و محصولات جدید خزش نشوند.
از این مشکلات اجتناب کنید و پیشقدم خوبی برای استفادهٔ بهینه از صفحهبندی برداشتهاید. در ادامه برخی عناصر دیگر که هنگام پیادهسازی صفحهبندی برای سایت خود لازم است پرورش دهید، آمده است:
تجمیع ارزش لینک. بهدرستی صفحههای صفحهبندیشده را با استفاده از و لینک کنید تا به موتورهای جستجو درک بهتری از جریان محتوای شما بدهد. این کار سیگنالهای رتبهبندی را متمرکز میکند بهجای پراکندن اعتبار در میان چندین URL.
بهبود کارایی خزش. ساختار صفحهبندی تمیز به گوگل کمک میکند تا سایت شما را هوشمندانهتر خزش کند. وقتی خزندهها میدانند صفحات شما چگونه بهیکدیگر مرتبط هستند، محتوای ارزشمندتر مانند محصولات ویژه یا پستهای وبلاگ را در اولویت قرار میدهند که میتواند رتبهبندی کلی سایت را ارتقا دهد.
بهبود ایندکسگذاری و مرتبطسازی. وقتی هر صفحهٔ صفحهبندیشده شامل عناوین بهینهسازیشده، اسنیپتهای منحصربهفرد و نشانهگذاری ساختاری باشد، موتورهای جستجو میتوانند محتوای شما را بهتر ایندکس کنند و صفحات مرتبط را بالاتر در نتایج جستجو قرار دهند.
رتبه بالاتر در گوگل
از این چکلیست رایگان سئو برای بهینهسازی وبسایت و محتوای خود استفاده کنید. بیاموزید چگونه برای عبارات جستجوی مرتبط رتبه بگیرید تا بیشتر خریداران فروشگاه شما را در ابتدا ببینند.
دریافت چکلیست
بهترین روشها برای پیادهسازی صفحهبندی در سئو
به هر صفحه یک URL منحصربهفرد و قابل خزش اختصاص دهید
ساختار پیوندهای داخلی را تست کنید
از شناساگرهای قطعهٔ URL (Fragment) خودداری کنید
برچسبهای canonical را بهدرستی مدیریت کنید
عناوین و توضیحات متا را بهینه کنید
در اینجا نحوهای که صفحات مختلف میتوانند به سئو کمک کنند، نه آن را آسیبپذیر کنند، آورده شده است:
هر صفحه در یک توالی صفحهبندی باید URL منحصربهفرد خود را داشته باشد. دو روش متداول برای این کار وجود دارد: افزودن پارامترهای کوئری مانند ?page=5 به URL، یا افزودن مسیر دایرکتوری مانند /page/5 به URL.
در اینجا یک مثال از پارامتر کوئری آمده است: https://myshopifymegastore.com/catalog/products?page=5
پارامتر ?page=5 صفحه شمارهدار را منحصربهفرد میسازد.
ساختار لینکهای داخلی را تست کنید
پیوندهای داخلی برای تجربهٔ کاربری صفحهبندی مفید هستند زیرا دسترسی به محتوا را آسانتر میسازند:
1. اطمینان حاصل کنید که لینکهای «بعدی» و «قبلی» بهدرستی کار میکنند. پیوندهای متوالی را از یک صفحه به صفحهٔ بعد اضافه کنید تا برای کاربران و Googlebot راحت باشد مسیر را دنبال کنند.
2. لینکها به سایر شمارههای صفحه در سلسله. این کار به موتورهای جستجو امکان میدهد هر صفحه را بهراحتی کشف کنند. بدون لینکها، گوگل ممکن است صفحات در دستهبندی محصول شما را از دست بدهد و محصولات در صفحات عمیقتر ایندکس نشوند.
3. لینک به صفحهٔ اول در مجموعه از هر صفحه. وقتی به صفحهٔ ریشه (page=1) لینک میدهید، اعتبار آن را تقویت میکنید که باعث تجمیع ارزش لینک در جای موردنظر میشود.
از شناساگرهای قطعهٔ URL (Fragment) خودداری کنید
یک شناساگر قطعهٔ URL بخشی است که پس از نماد هشتگ (#) در آدرس URL میآید. موتورهای جستجو تمایل دارند آنها را نادیده بگیرند. هر محتوای مبتنی بر قطعهURL ایندکس نمیشود و بنابراین هرگز در نتایج جستجو ظاهر نمیشود.
در اینجا مثالی از یک قطعهURL که احتمالاً خزش نخواهد شد آورده شده است: https://www.deepdiscount.biz/deep‑vinyl‑sale/b230734?attn_pos=2&externalId=OsUHA#!?pagenum=2
بهدرستی برچسبهای canonical را مدیریت کنید
برچسب canonical (rel=”canonical”) به موتورهای جستجو میگوید کدام صفحه نسخهٔ ترجیحی است وقتی چند صفحه محتوای مشابه دارند.
در مورد نحوهٔ صحیح استفاده از برچسب canonical برخی سؤبهفهمیها وجود دارد، بنابراین توصیههای Google Search Central را جدی بگیرید. گوگل توصیه میکند صفحهٔ اول توالی صفحهبندی بهعنوان صفحهٔ canonical استفاده نشود. هر صفحه باید URL canonical خود را داشته باشد. این برچسبها بهعنوان canonicalهای خودارجاعی شناخته میشوند.
برای تنظیم این مورد، به بخش
هر صفحه وب بروید و برچسب canonical مناسب را وارد کنید. مثال:
عناوین و توصیفات غنی از کلیدواژهها در متاتگها — موجود در بخش Head صفحهٔ HTML — به گوگل میگویند صفحه دربارهٔ چه چیزی است. میتوانید توصیفات محتوای منحصربهفرد اضافه کنید تا محتوای ظاهراً مشابه، مثل پستهای وبلاگ و محصولات در یک دسته، متمایز شوند.
استفاده از متاتگها به این شکل ضرورتی فنی ندارد. طبق راهنمایی گوگل: «بهطور معمول، توصیه میکنیم به صفحات وب عناوین متمایزی بدهید تا آنها را متمایز کنید. اما صفحات در توالی صفحهبندی نیازی به رعایت این توصیه ندارند. میتوانید از عناوین و توصیفات یکسان برای تمام صفحات توالی استفاده کنید. گوگل سعی میکند صفحات توالی را تشخیص دهد و بر این اساس ایندکس کند.»
با این حال، استفاده از فیلد عنوان برای نشان دادن اینکه کدام صفحه در توالی نمایش داده میشود میتواند تجربهٔ کاربر را بهبود بخشد. برای مثال، اگر مقالهای در چند صفحه پخش شده باشد، میتوانید «قسمت ۲»، «قسمت ۳» و … را به عنوان پسوند به عنوان اضافه کنید تا نشان دهد کدام بخش از سری نمایش داده میشود.
جایگزینهای صفحهبندی
اسکرول بیپایان
دکمههای بارگذاری بیشتر
نمایش همه صفحهها
صفحهبندی تنها گزینهٔ شما برای مدیریت مجموعههای بزرگ محتوا نیست. بر اساس اهداف خاص و ترجیحات تجربهٔ کاربری، مناسبترین گزینه را برای سایت خود انتخاب کنید.
اسکرول بیپایان
اسکرول بیپایان بهمحض اینکه کاربر بهپایین صفحه اسکرول کند، محتوای بیشتری را بارگذاری میکند. این روش در سایتهای شبکههای اجتماعی مانند فیسبوک و اینستاگرام محبوب است.
اسکرول بیپایان زمانی مناسب است که بخواهید فعالیت مرور در سایت را تا حد امکان افزایش دهید. مشتریان، بهویژه در برنامههای موبایل، بهسوی حرکات مداوم سوایپ عادت دارند.
با این حال، یک عیب احتمالی وجود دارد. گوگل میتواند خزش کند، اما اسکرول نمیکند؛ بنابراین نمیتواند محتوا را بدون کلیک بر روی لینک دسترسی پیدا کند، که به معنی این است که محتوای اسکرول بیپایان ممکن است ایندکس نشود.
دکمههای بارگذاری بیشتر
دکمهٔ بارگذاری بیشتر شبیه اسکرول بیپایان است، اما کاربر باید بهصورت دستی روی دکمه کلیک کند تا محتوای بیشتری بارگذاری شود. این گزینه برای سناریوهایی مناسب است که کاربر ممکن است نخواهد همه محتوا را یکجا ببیند. همچنین بر روی موبایل کارایی خوبی دارد چون کاربر میتواند انگشت خود را در یک مکان ثابت نگه دارد. برای آسانتر کردن خزش روباتها، دکمهٔ بارگذاری بیشتر را بهعنوان یک لینک مناسب به URL جدید و قابل خزش تنظیم کنید.
نمایش همه صفحهها
صفحهٔ نمایش همه یک صفحهٔ تک است که شامل تمام محصولات یا آیتمهای یک دستهبندی میشود. این روش برای دستهبندیهای کوچک با تعداد محدود محصولات (مثلاً فروش ویژه با ۲۰ آیتم) بهترین گزینه است.
کاربران اغلب دوست دارند همه چیز را در یک نگاه ببینند. این گزینه برای سئو دوستانهترین است زیرا تمام محتوا در یک مکان است — بدون نگرانی از مشکلات صفحهبندی. اما برای مجموعههای بزرگ محتوا، نمایش همه میتواند سنگین باشد. زمان بارگذاری طولانی میشود و میتواند تجربهٔ کاربری را مختل کند که ممکن است رتبهبندیهای جستجو را تحتتأثیر قرار دهد.
پرسشهای متداول سئوی صفحهبندی
صفحهبندی در سئو چیست؟
صفحهبندی فهرستهای بزرگ محتوا را به چند صفحه تقسیم میکند. این ویژگی تجربهٔ کاربری است که برای اجتناب از مشکلات سئو، نیاز به تنظیم دقیق دارد.
چرا از صفحهبندی در سئو پرهیز کنیم؟
صفحهبندی بهخودی مشکل نیست — پیادهسازی نادرست است. برای سایتهای بزرگ، صفحهبندی مهم برای تجربهٔ کاربری است. اما اگر بهدرستی پیادهسازی نشود، مشکلاتی مانند محتوای تکراری، تضعیف ارزش لینک در میان چندین URL و هدر رفتن بودجهٔ خزیدن بهوجود میآید.
آیا صفحهبندی یا اسکرول بیپایان برای سئو بهتر است؟
برای یک فروشگاه بزرگ تجارت الکترونیک، صفحهبندی عمومًا گزینهٔ بهتر برای سئو است؛ زیرا به موتورهای جستجو لینکهای قابلخزش به هر صفحه میدهد. اسکرول بیپایان ممکن است گزینهٔ سئوی ضعیفی باشد چون برای نمایش محتوا به اقدام کاربر (اسکرول) وابسته است و خزندهها نمیتوانند آن را ببینند، که ایندکسگذاری تمام فهرست محصولات را دشوار میکند.
جان مولر از گوگل روشنگریای درباره سؤال مربوط به دامنههای عمومی سطحبالای مبتنی بر کلیدواژه و سئو ارائه میدهد.
جان مولر از گوگل به سؤال دربارهٔ اینکه آیا یک دامنهٔ عمومی سطحبالا (gTLD) حاوی کلیدواژه، مزیتی برای سئو دارد یا نه، پاسخ داد. پاسخ او در چارچوب یک دامنهٔ کلیدواژهای خاص بود، اما موضوع شامل پرسشهای گستردهتری دربارهٔ نحوهٔ ارزیابی دامنههای سطحبالا توسط گوگل میشود.
دامنههای عمومی سطحبالا (gTLDها)
دامنههای gTLD، دامنههایی هستند که دارای تمی مرتبط با یک موضوع یا هدف میباشند. شناختهشدهترین آنها .com است که عموماً برای مقاصد تجاری استفاده میشود و .org که معمولاً برای سازمانهای غیرانتفاعی به کار میرود.
در سال ۲۰۱۳، دسترسی به دامنههای gTLD مبتنی بر کلیدواژههای منحصربهفرد به سرعت گسترش یافت. امروزه صدها دامنهٔ gTLD وجود دارند که وبسایتها میتوانند با استفاده از آنها برند خود را بسازند و متمایز شوند.
آیا gTLDها ارزش سئویی دارند؟
کاربری که سؤال خود را در ردیت مطرح کرد، میخواست بداند آیا ثبت یک دامنهٔ .music gTLD ارزش سئویی دارد یا خیر. نسخهٔ .com این نام دامنه در دسترس نبود، اما نسخهٔ .music موجود بود.
سؤالی که مطرح کردند این بود:
«متوجه شدم دامنههای .music در دسترس هستند و کنجکاو هستم بدانم آیا این موضوع مرتبط است، در حال رشد است یا صنعت بهطور کلی به آن اهمیتی نمیدهد؟ آیا ارزش دارد دامنهتان را رزرو کنید تا دیگران نتوانند آن را داشته باشند، در صورتی که بهزودی به یک موضوع مهم تبدیل شود؟»
آ آیا gTLDها برای مقاصد سئو مفید هستند؟
جان مولر از گوگل پاسخ خود را به این سؤال که آیا gTLDها ارزش سئویی دارند محدود کرد و پاسخ او منفی بود.
او پاسخ داد:
«استفاده از یک دامنهٔ .music هیچ مزیت سئویی بهطور قطع ندارد.»
نکته جالب درباره سئو این است که معیار مرتبط بودن گوگل بر پایهٔ انسانهاست، در حالی که سئوکاران مفهوم مرتبط بودن را بر اساس آنچه گوگل بهعنوان مرتبط میداند مدلسازی میکنند.
بهینهسازی برای انسانها با gTLDها
نکتهای که در مورد سئو وجود دارد این است که سئو به معنای بهینهسازی برای موتورهای جستجو است. هنگام قدم گذاشتن در وب، بهراحتی میتوان از این موضوع غافل شد که هر وبسایتی نیز باید برای انسانها بهینهسازی شود. بهجز دامنههای اسپمدار که میتوانند برای سئو مشکلساز باشند، انتخاب یک TLD برای سئو اهمیتی ندارد، اما میتواند برای بهینهسازی انسانی مهم باشد.
بهینهسازی برای انسانها ایدهٔ خوبی است چون سیگنالهای تولیدشده توسط تعاملات انسانی با موتورهای جستجو و وبسایتها، سیگنالهایی هستند که گوگل بهصورت گسترده استفاده میکند تا بهتر متوجه منظور کاربران از پرسشهایشان شود و بفهمد چه نوع سایتهایی برای آن پرسشها انتظار میرود. برخی سیگنالهای تولیدشده توسط کاربران، مانند جستجو بر اساس نام برند، میتواند به گوگل بگوید که یک برند خاص محبوب است و با سرویس، محصول یا عبارت کلیدواژهای مشخصی مرتبط است (به پتنت جستجوی برند شدهٔ گوگل مراجعه کنید).
بازگشت به بهینهسازی برای انسانها، اگر یک gTLD خاص چیزی باشد که انسانها آن را با یک برند، محصول یا سرویس مرتبط میدانند، میتواند عاملی مفید برای جذابتر شدن سایت در چشم کاربران باشد.
من در گذشته با دامنههای مختلف gTLD آزمایش کردهام و دریافتم که میتوانم لینکها را به راحتی بیشتر به دامنههای .org نسبت به نسخههای .com یا .net بسازم. این نمونهای است از اینکه چگونه یک gTLD میتواند برای انسانها بهینهسازی شود و به موفقیت منجر گردد.
متوجه شدم که سایتهای مشارکتی کاملاً تجاری که بر دامنهٔ .org میبودند، رتبه خوبی گرفتند و تبدیل مناسبی داشتند. این رتبهبندی به دلیل .org بودن آنها نبود؛ بلکه به این دلیل بود که انسانها به سایتهایی که با این gTLD ساختهام، واکنش مثبت نشان دادند. برای مثال، ساختن لینک به آنها سادهتر بود. شک ندارم که کاربران کمی بیشتر به سایتهای مشارکتی من اعتماد کردند چون بر روی دامنهٔ .org ایجاد شده بودند.
بهینهسازی برای انسانها، بهینهسازی تبدیل است. این نکته بسیار مهم است.
بهینهسازی برای انسانها با gTLDهای مبتنی بر کلیدواژه
من هنوز با gTLDهای کلیدواژهای آزمایش نکردهام اما حدس میزنم آنچه در دامنههای .org تجربه کردم میتواند در یک gTLD مبتنی بر کلیدواژه نیز رخ دهد، چرا که یک gTLD معنادار میتواند احساسات مثبت یا ارتباطی را به انسانها منتقل کند. میتوانید این را «برندسازی» بنامید، اما من فکر میکنم واژهٔ «برندسازی» بسیار انتزاعی است. من ترجیح میدهم از عبارت بهینهسازی برای انسانها استفاده کنم چون در نهایت این همان هدف برندسازی است.
پس شاید زمان آن رسیده که از صحبتهای بیپایان دربارهٔ برندسازی دست بکشیم و بهجای آن دربارهٔ بهینهسازی برای انسانها صحبت کنیم. اگر آن شخص سؤال را از منظر بهینهسازی انسانی در نظر میگرفت، میتوانست خودشان به سؤال پاسخ دهند.
وقتی سئوکاران دربارهٔ مرتبط بودن صحبت میکنند، بهنظر میرسد عمدتاً به میزان مرتبط بودن یک موضوع برای گوگل اشاره دارند. مرتبط بودن برای گوگل، همان موضوعی بود که در ذهن شخصی که سؤال دربارهٔ دامنهٔ .music را مطرح کرده بود، قرار داشت و شاید دلیل این است که شما این مقاله را میخوانید.
در واقع، مرتبط بودن برای موتورهای جستجو همان هدف تمام بهینهسازی «نقش» است، نهچنین؟ تمرکز بر مرتبط بودن برای موتورهای جستجو، روش محدودی برای دستیابی به موفقیت است. برای مثال، من با تمرکز بر انسانها و استفاده از دامنههای .org راز را کشف کردم.
در نقطهای، اگر میخواهید بهصورت آنلاین موفق باشید، ممکن است مفید باشد که یک گام به عقب بردارید و بیشتر به این فکر کنید که محتوا، رنگها و gTLDها چقدر برای انسانها مرتبط هستند؛ شاید بفهمید که مرتبط بودن برای انسانها، راه را برای مرتبط بودن با موتورهای جستجو هموارتر میکند.
قطعی Cloudflare باعث بروز خطاهای 5xx در بسیاری از سایتها شده است. در ادامه میبینید گوگل چگونه با جهشهای کوتاه سرور برخورد میکند و در گزارشهای سئو چه نکاتی را باید دنبال کنید.
جهشهای کوتاه 5xx عمدتاً سرعت خزیدن گوگل را کاهش میدهند و اگر زمان فعالسازی بهسرعت بازگردد، معمولاً باعث کاهش دائمی رتبه نمیشوند.
گوگل میگوید مشکلات 5xx چندروزه میتوانند باعث کاهش رتبه شوند، اما صفحات معمولاً پس از ثبات سرورها دوباره باز میگردند.
اگر تگهای رضایت یا ردیابی تحت تأثیر قرار گرفته باشند، ممکن است خلل در گزارشهای GA4 و تبلیغات کلیکی (PPC) مشاهده کنید.
حادثهٔ Cloudflare باعث پاسخهای 5xx برای بسیاری از سایتها و برنامههای پشت شبکهٔ آن میشود که به این معنی است که کاربران و خزندهها ممکن است با همان خطاها مواجه شوند.
از منظر سئو، این نوع قطعی اغلب بدتر از آنچه به نظر میرسد به نظر میآید. انفجارهای کوتاهمدت خطاهای 5xx معمولاً ابتدا رفتار خزیدن را تحت تأثیر قرار میدهند، پیش از اینکه به رتبهبندی بلندمدت اثر بگذارد؛ اما جزئیات مهمی وجود دارد که شایستهٔ توجه است.
چیزی که احتمالاً میبینید
سایتهایی که به Cloudflare بهعنوان CDN یا پراکسی معکوس وابستهاند، ممکن است در حال حاضر صفحهٔ عمومی «خطای داخلی سرور 500» را نشان دهند یا بهکل بارگذاری نشوند. در عمل، تمام این دسته از پاسخها بهعنوان خطای سرور در نظر گرفته میشوند.
اگر Googlebot هنگام وقوع این اتفاق بهصورت همزمان خزیده شود، همان پاسخهای 5xx که کاربران میبینند را ثبت میکند. ممکن است فوراً در Search Console چیزی مشاهده نکنید، اما در چند روز آینده میتوانید افزایش در خطاهای سرور، کاهش در فعالیت خزیدن، یا هر دو را ببینید.
بهخاطر داشته باشید که دادههای Search Console به ندرت زمان واقعی هستند و معمولاً حدود ۴۸ ساعت تاخیر دارند. یک خط ثابت در GSC امروز میتواند نشاندهنده این باشد که گزارش هنوز بهروز نشده است. اگر نیاز دارید تأیید کنید که Googlebot در حال حاضر با خطاها مواجه است، باید لاگهای دسترسی خام سرور خود را بررسی کنید.
این میتواند حس اضطراری در رابطه با رتبهبندی ایجاد کند. درک اینکه گوگل در گذشته چگونه برخورد خود با مشکلات موقت سرور را توصیف کرده و نمایندگان گوگل امروز چه میگویند، میتواند مفید باشد.
چگونگی برخورد گوگل با جهشهای کوتاه 5xx
گوگل پاسخهای 5xx را بهعنوان نشانهای از بارگذاری بیش از حد یا عدم دسترسی سرور دستهبندی میکند. بر اساس مستندات Search Central گوگل درباره کدهای وضعیت HTTP، خطاهای 5xx و 429 باعث میشوند خزندهها بهطور موقت سرعت خود را کاهش دهند و URLهایی که بهصورت مستمر خطای سرور میدهند، در صورتی که مشکل حل نشود، میتوانند در نهایت از فهرست حذف شوند.
پست وبلاگی گوگل با عنوان «چگونه با زمانبندی توقف برنامهریزیشده سایت مقابله کنیم» راهنمایی مشابهی برای بازههای نگهداری ارائه میدهد؛ توصیه میکند برای توقف موقت از وضعیت 503 استفاده شود و تأکید میکند که پاسخهای 503 طولانیمدت میتوانند بهعنوان نشانهای از عدم دسترس بودن محتوا تعبیر شوند.
در یک پست اخیر در Bluesky، جان مولر، حامی جستجوی گوگل، همان پیام را به زبانی سادهتری تأیید کرد. مولر نوشت:
«خب. 5xx = سرعت خزیدن گوگل کم میشود، اما دوباره به حالت قبلی برمیگردد.»
او افزود:
«اگر بهمدت چند روز در وضعیت 5xx بماند، ممکن است برخی موارد از دست بروند، اما حتی در این صورت، آنها بهسرعت دوباره ظاهر میشوند.»
بهطور کلی، مستندات و نظرات مولر خطمشی نسبتاً واضحی را ترسیم میکنند.
توقف کوتاهمدت معمولاً مشکل جدی در رتبهبندی نیست. صفحات قبلاً فهرست شده معمولاً برای مدتی در فهرست باقی میمانند، حتی اگر بهصورت مختصر خطا را بازگردانند. وقتی دسترسی به حالت عادی برگردد، خزیدن دوباره سرعت میگیرد و نتایج جستجو عموماً تثبیت میشوند.
تصویر زمانی تغییر میکند که خطاهای سرور بهصورت الگو پدیدار شوند. اگر Googlebot برای مدت طولانی پاسخهای 5xx دریافت کند، میتواند URLها را بهطور مؤثر از دست رفته در نظر بگیرد. در این حالت، صفحات تا زمانی که خزندهها مجدداً پاسخهای پایدار و موفق دریافت کنند، ممکن است از فهرست حذف شوند و بازگرداندن آنها زمان بیشتری بخواهد.
نتیجهگیری عملی این است که یک حادثه زیرساختی تکباره عمدتاً نگرانی در حوزهٔ خزیدن و اطمینانپذیری است. مشکلات سئویی پایدار معمولاً زمانی ظاهر میشوند که خطاها بهمرور زمان پس از پایان اولیه قطعی ادامه یابند.
راهنماییهای تکمیلی گوگل درباره خطاهای 5xx را ببینید:
کاهش سرعت خزیدن Googlebot؟ مولر به خطاهای سرور اشاره میکند
چرا Google Search Console خطاهای سرور 5XX را گزارش میدهد
گوگل درباره تأثیر سئو کدهای وضعیت 503
فواصل گزارشگیری در تجزیهوتحلیل و تبلیغات کلیکی
برای بسیاری از سایتها، Cloudflare فقط جلوی صفحات HTML نیست؛ بنرهای رضایتنامه، مدیران تگ و اسکریپتهای شخص ثالث مورد استفاده برای تجزیهوتحلیل و تبلیغات نیز ممکن است به سرویسهایی که از طریق Cloudflare عبور میکنند وابسته باشند.
اگر پلتفرم مدیریت رضایت یا مدیر تگ شما در طول قطعی کند یا در دسترس نبود، این ممکن است بعدها بهصورت خلل در گزارشهای GA4 و پلتفرمهای تبلیغاتی ظاهر شود. رویدادهای رضایت ممکن است ارسال نشوند، تگها ممکن است زمانسنجی شوند و برخی نشستها یا تبدیلها ممکن است اصلاً ثبت نشوند.
افزودن یادداشتی دربارهٔ حادثهٔ امروز در تجزیهوتحلیلها و گزارشهای رسانهای و در نظر گرفتن آن بهعنوان یک خلل ردیابی، ایمنتر است تا پیش از واکنش با تغییرات پیشنهادی یا تغییرات بودجه بر پایهٔ چند ساعت دادههای پرنوسان، این نکته را مدنظر داشته باشید.
چه کاری باید انجام دهید اگر تحت تأثیر قرار گرفتید
اگر فکر میکنید در اثر قطعی امروز تحت تأثیر قرار گرفتهاید، ابتدا با اطمینان از اینکه مشکل واقعا به Cloudflare مرتبط است و نه به سرور اصلی یا کد برنامهتان، شروع کنید. مانیتورینگ زمان عملیاتی خود و هر پیام وضعیت از Cloudflare یا میزبان خود را بررسی کنید تا بدانید مهندسیتان را به کجا متمرکز کنید.
سپس زمانبندی را ثبت کنید. زمان اولین مشاهدهٔ خطاهای 5xx و زمانی که وضعیت به حالت عادی بازگشت را یادداشت کنید. افزودن یک یادداشت در تجزیهوتحلیلها، Search Console و گزارشهای رسانهای، توضیح هر افت ترافیک یا تبدیل را در مرور عملکردهای بعدی آسانتر میکند.
در روزهای آینده، به گزارش آمار خزیدن و پوشش ایندکس در Search Console، بههمراه لاگهای سرور خود، نگاهی داشته باشید. هدف این است که تأیید کنید فعالیت خزیدن پس از پایان حادثه به الگوی معمول خود بازگردد و نرخ خطاهای سرور به سطح عادی برگشت کند. اگر نمودارها ثابت شوند، میتوانید قطعی را بهعنوان یک رویداد محدود در نظر بگیرید.
اگر بهجای آن، پس از اعلام رفع مشکل توسط Cloudflare همچنان به مشاهدهٔ پاسخهای 5xx افزایشیافته ادامه دهید، بهتر است این وضعیت را بهعنوان یک مشکل خاص سایت در نظر بگیرید.
بهطور کلی نیازی به تغییر محتوا، لینک داخلی یا سئوی صفحهای صرفاً بهخاطر یک قطعی کوتاه Cloudflare ندارید. بازگرداندن پایداری اولویت است.
در نهایت، از فشار برای فشار دادن دکمهٔ «Validate Fix» در Search Console بهمحض بازگشت سایت بهصورت آنلاین خودداری کنید. اگر اعتبارسنجی را در حالی که اتصال هنوز ناپایدار است انجام دهید، بررسی شکست میخورد و باید منتظر بازنشانی دوره باشید. بهتر است تا زمانی که صفحهٔ وضعیت «Resolved» را برای ۲۴ ساعت کامل نشان دهد، صبر کنید و سپس اعتبارسنجی کنید.
همچنین ببینید: چگونه کشفپذیری، قابلیت خزیدن و رتبهبندی را بهبود دهیم
ابزارهای رشد تعطیلات 2025 و هوش مصنوعی برای صاحبان کسبوکارهای کوچک
نگاهی به آینده
پس از اینکه Cloudflare تحقیقات خود را بهپایان رساند، اصلیترین نکتهای که باید دنبال کنید این است که آیا معیارهای خزیدن، خطا و تبدیل شما به حالت عادی بازگشتهاند یا نه. اگر اینطور باشد، جهش 5xx صبح امروز احتمالاً بهعنوان یک یادداشت فرعی در گزارشهای شما باقی میماند و نه بهعنوان نقطهٔ عطفی در عملکرد ارگانیک یا پرداختی شما.
گوگل بخش پس از نام دامنهٔ URL را بهصورت حساس به حروف بزرگ و کوچک در نظر میگیرد. به همین دلیل میتواند هر دو domain.com/example و domain.com/EXAMPLE را ایندکس کند، اما domain.com/example و DOMAIN.com/example. را ادغام میکند.
این موضوع اهمیت دارد چون سیستمهای مدیریت محتوا معمولاً URLها را از عناوین صفحات میسازند و غالباً حروف بزرگ را حفظ میکنند، که منجر به سه مشکل برای بهینهسازی موتورهای جستجو میشود:
محتوای تکراری. اگر دو نسخهٔ URL همان محتوا را ارائه دهند، گوگل ممکن است هر دو را ایندکس کند.
پخش اعتبار لینک. URLهای حروف بزرگ به همراه لینکهای ورودی با حروف کوچک میتوانند اعتبار لینک را تقسیم کنند و رتبهٔ نسخهٔ اصلی را تحت تأثیر قرار دهند.
خطاهای داخلی. سایتهای میزبانیشده بر روی سرورهای لینوکس (مانند Shopify و اغلب WooCommerce) برای کاراکترهای حروف بزرگ URL، در صورتی که کاربر نسخهٔ حروف کوچک را وارد کند، صفحهٔ خطای ۴۰۴ نشان میدهند.
اکثریت خزندههای وب (و Search Console) فیلترهای حساس به حروف بزرگ و کوچک برای URL ارائه نمیدهند، بنابراین شناسایی این مشکل دشوار است. بهترین راه جلوگیری از آن این است که سرور خود را طوری تنظیم کنید که تمام نسخههای یک URL را به نسخهٔ پیشفرض دلخواه هدایت کند. برای مثال هر یک از اینها میتوانند به domain.com/url هدایت شوند:
domain.com/URL
domain.com/Url
domain.com/uRl
برخی سیستمهای مدیریت محتوا بهصورت خودکار هدایت میکنند، اما همیشه برای اطمینان باید بررسی کنید. سه نسخهٔ URL ذکر شده در بالا را در مرورگر خود وارد کنید. اگر همه به یک نسخه (معمولاً حروف کوچک) بارگذاری شوند، نیازی به اقدام دیگری نیست. اگر هرکدام منجر به صفحهٔ خطا شد، بلافاصله رفع کنید.
بسته به سیستم مدیریت محتوا، افزونهها و برنامهها میتوانند در تنظیم قوانین هدایت بینسایتی کمک کنند. راهنمای مهندس نرمافزار Brian Love توضیح میدهد که چگونه URLهای با حروف کوچک را اعمال کنیم.
انتخاب URLها
از نظر سئو، قانون خاصی برای URL وجود ندارد تا زمانی که تمام نسخهها به نسخهٔ موردنظر هدایت شوند. من URLهای با حروف کوچک را بهدلیل سادگی و سهولت در تنظیم هدایتهای بینسایتی ترجیح میدهم، هرچند برخی کاربران به دلایل خوانایی، برندسازی و عملکرد بهتر تبلیغات، URLهای حروف بزرگ را میپسندند.
ثبات URLهای بینسایتی بهتنهایی باعث افزایش چشمگیر در رتبهبندی نمیشود، اما به گوگل کمک میکند ساختار سایت شما را بهتر درک کند، قابلیت خزیدن را ارتقا دهد و واضحتر نشان دهد چه محتواهایی ایندکس شدهاند.
