راهنمای جامع عیب‌یابی مشکلات سئو مرتبط با جاوا اسکریپت

یاد بگیرید چطور مشکلات سئو در سایت‌های مبتنی بر جاوا اسکریپت رو پیدا کنید و هر چیزی که لازمه در مورد رندرینگ بدونید رو اینجا بهتون می‌گیم.

بیاید روراست باشیم، جاوا اسکریپت و سئو همیشه آبشون تو یه جوب نمیره. برای بعضی از سئوکارها، این موضوع اونقدر پیچیده به نظر میاد که ترجیح می‌دن دورش رو خط بکشن.

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

پس اگه شما این اصول اولیه رو خوب درک کنید، می‌تونید مشکلات رو ریشه‌یابی کنید، تأثیرشون رو بفهمید و با بچه‌های تیم فنی همکاری کنید تا مشکلات مهم رو حل کنید.

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

رندرینگ به زبان ساده

قبل از اینکه وارد جزئیات بشیم، بیاید یه نگاه کلی به قضیه بندازیم.

برای اینکه یه موتور جستجو بتونه محتوایی که با جاوا اسکریپت ساخته شده رو درک کنه، باید صفحه رو هم کرال (بخزه) و هم رندر کنه.

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

اگه موتور جستجو تصمیم بگیره که صفحه‌ای رو رندر نکنه، یا نتونه محتوا رو درست رندر کنه، این می‌تونه به یه مشکل بزرگ تبدیل بشه.

همه چیز به این برمی‌گرده که فرانت‌اند (Front-end) سایت شما، کدهای HTML رو در اولین پاسخ سرور چطور تحویل میده.

وقتی یه URL توی مرورگر ساخته میشه، یه فریم‌ورک فرانت‌اند مثل React، Vue یا Gatsby کدهای HTML اون صفحه رو تولید می‌کنه. خزنده قبل از اینکه URL رو برای رندرینگ به صف بفرسته تا محتوای نهایی رو ببینه، اول چک می‌کنه که آیا اون HTML از قبل روی سرور آماده هست یا نه (که بهش میگن HTML «از پیش رندر شده»).

اینکه HTML از پیش رندر شده‌ای در دسترس باشه یا نه، به نحوه پیکربندی فرانت‌اند بستگی داره. این HTML یا روی سرور تولید میشه یا توی مرورگر کاربر (کلاینت).

رندرینگ سمت سرور (Server-side rendering)

اسمش گویای همه چیزه. تو این حالت (که بهش SSR هم میگن)، یه صفحه HTML کامل و رندر شده به خزنده تحویل داده میشه، بدون اینکه نیازی به اجرای جاوا اسکریپت اضافه و رندرینگ مجدد باشه.

بنابراین، حتی اگه صفحه رندر نشه، موتور جستجو هنوزم می‌تونه تمام کدهای HTML رو کرال کنه، محتوای صفحه (مثل متادیتا، متن، تصاویر) رو درک کنه و رابطه اون رو با صفحات دیگه بفهمه (مثل بردکرامب، تگ کنونیکال و لینک‌های داخلی).

رندرینگ سمت کاربر (Client-side rendering)

در حالت CSR، کدهای HTML به همراه تمام کامپوننت‌های جاوا اسکریپت، توی مرورگر کاربر تولید میشن. اینجا جاوا اسکریپت باید حتما رندر بشه تا کدهای HTML برای کرال در دسترس قرار بگیرن.

اگه سرویس رندرینگ تصمیم بگیره صفحه‌ای که به صف فرستاده شده رو رندر نکنه، محتوا، لینک‌های داخلی، لینک تصاویر و حتی متادیتاها برای خزنده‌ها غیرقابل دسترس باقی می‌مونن.

در نتیجه، موتورهای جستجو تقریبا هیچ سرنخی برای درک ارتباط اون URL با کلمات کلیدی جستجو شده ندارن.

نکته: گاهی اوقات ترکیبی از این دو حالت وجود داره. یعنی بخشی از HTML در پاسخ اولیه سرور فرستاده میشه و بخش دیگه‌ای برای نمایش (رندر شدن) نیاز به اجرای JS داره. این موضوع به عوامل مختلفی بستگی داره که رایج‌ترین‌هاشون فریم‌ورک استفاده شده، نحوه ساخت کامپوننت‌های سایت و پیکربندی سرور هستن.

البته ابزارهایی هم وجود دارن که به شناسایی مشکلات سئوی مرتبط با جاوا اسکریپت کمک می‌کنن.

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

  • مشاهده سورس صفحه (View source): روی صفحه راست کلیک کنید و گزینه «view source» رو بزنید تا HTML از پیش رندر شده صفحه (یعنی اولین پاسخ سرور) رو ببینید.
  • ابزار Test live URL (در بخش URL inspection): با استفاده از این ابزار در سرچ کنسول، می‌تونید اسکرین‌شات، کدهای HTML و جزئیات مهم دیگه‌ای از صفحه رندر شده رو ببینید. (خیلی از مشکلات رندرینگ با مقایسه HTML اولیه از «view source» و HTML رندر شده از این ابزار پیدا میشن.)
  • ابزارهای توسعه‌دهنده کروم (Chrome Developer Tools): روی صفحه راست کلیک کنید و گزینه «Inspect» رو انتخاب کنید تا ابزارهایی برای دیدن خطاهای جاوا اسکریپت و موارد دیگه باز بشن.
  • افزونه Wappalyzer: با نصب این افزونه رایگان کروم، می‌تونید ببینید هر سایتی با چه تکنولوژی‌هایی ساخته شده و اطلاعات مخصوص به هر فریم‌ورک رو پیدا کنید.

مشکلات رایج سئو در جاوا اسکریپت

مشکل ۱: کدهای HTML از پیش رندر شده، در دسترس نیستن

علاوه بر تأثیرات منفی که قبلاً در مورد کرال و درک محتوا گفتیم، یه مشکل دیگه هم وجود داره: زمان و منابعی که موتور جستجو باید برای رندر کردن یه صفحه صرف کنه.

اگه خزنده تصمیم بگیره یه URL رو وارد فرآیند رندرینگ کنه، اون URL وارد صف رندرینگ میشه. این اتفاق معمولاً وقتی میفته که خزنده بین ساختار HTML اولیه و HTML رندر شده تفاوت احساس کنه. (که اگه هیچ HTML اولیه‌ای وجود نداشته باشه، این تفاوت خیلی واضحه!)

هیچ تضمینی وجود نداره که یه URL چقدر باید تو این صف منتظر بمونه. بهترین راه برای اینکه سرویس رندرینگ گوگل (WRS) رو راضی کنید که زودتر کارتون رو راه بندازه، اینه که با سیگنال‌های اعتبار (Authority Signals) قوی، اهمیت اون URL رو نشون بدید (مثلاً در منوی اصلی بهش لینک بدید، لینک‌های داخلی زیادی بهش بدید، یا به عنوان نسخه کنونیکال معرفی‌اش کنید). البته این کار هم یه کم پیچیده است، چون خود این سیگنال‌های اعتبار هم باید اول کرال بشن.

توی گوگل سرچ کنسول، می‌تونید تا حدودی بفهمید که آیا دارید سیگنال‌های درستی به صفحات کلیدی‌تون می‌فرستید یا اون‌ها رو تو برزخ منتظر گذاشتید.

به بخش Pages > Page indexing > Crawled – currently not indexed برید و ببینید آیا صفحات مهم شما تو این لیست هستن یا نه.

اگه تو این اتاق انتظار گیر کردن، به این دلیله که گوگل نتونسته تشخیص بده که آیا این صفحات اونقدر مهم هستن که براشون منابع صرف کنه یا نه.

دلایل رایج

تنظیمات پیش‌فرض

بیشتر فریم‌ورک‌های محبوب فرانت‌اند به صورت پیش‌فرض روی حالت رندرینگ سمت کاربر (CSR) تنظیم شدن. پس احتمال زیادی وجود داره که مقصر اصلی همین تنظیمات پیش‌فرض باشه.

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

اپلیکیشن تک‌صفحه‌ای (Single-page application)

اگه سایت شما یه اپلیکیشن تک‌صفحه‌ای (SPA) باشه، یعنی کل سایت در جاوا اسکریپت پیچیده شده و تمام اجزای یه صفحه در مرورگر تولید میشن (به عبارت دیگه، همه چیز سمت کاربر رندر میشه و صفحات جدید بدون بارگذاری مجدد لود میشن).

این موضوع چندتا پیامد منفی داره که شاید مهم‌ترینش اینه که صفحات شما پتانسیل این رو دارن که اصلا کشف نشن.

این به این معنی نیست که نمیشه یه SPA رو طوری تنظیم کرد که با سئو سازگارتر باشه. ولی به احتمال زیاد، برای رسیدن به این هدف به کار فنی و توسعه قابل توجهی نیاز خواهید داشت.

مشکل ۲: بخشی از محتوای صفحه برای خزنده‌ها در دسترس نیست

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

مثلاً فرض کنید یه سئوکار داره لینک‌های داخلی رو تحلیل می‌کنه و می‌بینه یه URL خاص که تو چندین صفحه بهش لینک داده شده، تقریباً هیچ لینک داخلی‌ای براش ثبت نشده.

اگه اون لینک در HTML رندر شده‌ای که ابزار Test Live URL نشون میده وجود نداشته باشه، پس به احتمال زیاد از طریق منابع جاوا اسکریپتی لود میشه که گوگل به اون‌ها دسترسی نداره.

HTML رندر شده در دسترس برای گوگل‌بات که توسط ابزار Test Live URL تولید شده

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

مثلاً اگه لینک صفحه پرسش‌های متداول (FAQ) در بخش مشابهی از تمام صفحات محصول نمایش داده میشه، این سرنخ بزرگیه که به برنامه‌نویس‌ها کمک می‌کنه تا مشکل رو سریع‌تر پیدا و حل کنن.

دلایل رایج

خطاهای جاوا اسکریپت

اول این نکته رو بگیم که اکثر خطاهای جاوا اسکریپتی که باهاشون مواجه میشید، برای سئو اهمیتی ندارن.

پس اگه دنبال خطاها بگردید و با یه لیست بلندبالا برید سراغ برنامه‌نویس‌تون و بگید «این همه ارور برای چیه؟»، ممکنه برخورد خوبی باهاتون نداشته باشن.

بهتره با توضیح «چرایی» و بیان خود مشکل، بهشون نزدیک بشید تا اون‌ها بتونن به عنوان متخصص جاوا اسکریپت (که واقعاً هم هستن!) مشکل رو حل کنن.

با این حال، خطاهای نحوی (syntax errors) وجود دارن که می‌تونن پردازش بقیه صفحه رو غیرممکن کنن (اصطلاحاً «render blocking»). وقتی این اتفاق میفته، رندرِر (renderer) نمی‌تونه عناصر HTML رو از هم جدا کنه، محتوا رو در DOM ساختاربندی کنه، یا روابط بین اون‌ها رو بفهمه.

معمولاً این نوع خطاها قابل تشخیص هستن، چون یه تأثیری هم توی ظاهر صفحه در مرورگر میذارن.

علاوه بر تایید بصری، می‌تونید با راست کلیک روی صفحه، انتخاب «inspect» و رفتن به تب «Console»، خطاهای جاوا اسکریپت رو ببینید.

محتوا برای نمایش به تعامل کاربر نیاز داره

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

چرا این مهمه؟ دوست قدیمی و قابل اعتمادمون، منوهای آکاردئونی رو در نظر بگیرید، و اینکه چقدر سایت‌ها از اون برای سازماندهی محتواهایی مثل جزئیات محصول و سوالات متداول استفاده می‌کنن.

بسته به اینکه این منوی آکاردئونی چطور کدنویسی شده باشه، ممکنه گوگل نتونه محتوای داخل اون رو رندر کنه، چون اون محتوا تا زمانی که JS اجرا نشه، لود نمیشه.

برای بررسی این موضوع، می‌تونید روی صفحه «Inspect» بزنید و ببینید آیا محتوای «پنهان» (یعنی چیزی که بعد از کلیک روی منو نشون داده میشه) در کدهای HTML وجود داره یا نه.

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

مشکل ۳: بخش‌هایی از سایت کرال نمیشن

اگه گوگل صفحه‌تون رو کرال کنه و به صف رندرینگ بفرسته، ممکنه اون رو رندر بکنه یا نکنه. ولی اگه اصلاً صفحه رو کرال نکنه، حتی این فرصت هم از بین میره.

برای اینکه بفهمید گوگل صفحات شما رو کرال می‌کنه یا نه، گزارش Crawl Stats می‌تونه خیلی مفید باشه. از مسیر Settings > Crawl stats بهش دسترسی دارید.

گزینه Crawl requests: OK (200) رو انتخاب کنید تا تمام دفعاتی که صفحات با کد وضعیت ۲۰۰ در سه ماه گذشته کرال شدن رو ببینید. بعد می‌تونید با فیلتر کردن، URLهای خاص یا کل دایرکتوری‌ها رو جستجو کنید.

گزارش Crawl Stats گوگل که زمان و پاسخ درخواست‌های کرال URLها را نشان می‌دهد

اگه URLها در گزارش‌های کرال ظاهر نمیشن، احتمال زیادی وجود داره که گوگل نتونسته اون صفحات رو کشف و کرال کنه (یا اینکه کد وضعیتشون ۲۰۰ نیست، که اون یه مشکل کاملاً متفاوته).

دلایل رایج

لینک‌های داخلی قابل کرال نیستن

لینک‌ها مثل تابلوهای راهنمایی برای خزنده‌ها هستن که اون‌ها رو به صفحات جدید می‌رسونن. این یکی از دلایلیه که صفحات یتیم (Orphan Pages) یه مشکل بزرگ محسوب میشن.

اگه سایت شما لینک‌سازی داخلی خوبی داره ولی تو گزارش‌هاتون صفحات یتیم زیادی می‌بینید، به احتمال زیاد دلیلش اینه که لینک‌ها در HTML اولیه (pre-rendered) در دسترس نیستن.

یه راه ساده برای بررسی اینه که به یه URL برید که به صفحه یتیم گزارش شده لینک داده. روی صفحه راست کلیک کنید و «view source» رو بزنید.

بعد، با CMD + f (یا Ctrl + f) آدرس صفحه یتیم رو جستجو کنید. اگه توی HTML اولیه وجود نداشت، ولی در صفحه رندر شده توی مرورگر دیده میشد، مستقیم برید سراغ مشکل شماره چهار.

نقشه سایت XML آپدیت نیست

نقشه سایت XML برای کمک به گوگل در کشف صفحات جدید و درک اینکه کدوم URLها رو برای کرال در اولویت قرار بده، حیاتیه.

بدون نقشه سایت، کشف صفحات فقط از طریق دنبال کردن لینک‌ها ممکنه.

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

بسته به فریم‌ورک فرانت‌اندی که استفاده می‌کنید، ممکنه به پلاگین‌هایی دسترسی داشته باشید که می‌تونن نقشه‌های سایت XML داینامیک ایجاد کنن.

این پلاگین‌ها اغلب به سفارشی‌سازی نیاز دارن، پس مهمه که سئوکارها هر URLی که نباید در نقشه سایت باشه و منطق پشت این تصمیم رو به دقت مستند کنن.

تایید این موضوع با اجرای نقشه سایت در ابزار سئوی مورد علاقه‌تون باید نسبتاً آسون باشه.

در دسترس نبودن لینک‌های داخلی برای خزنده‌ها فقط یه مشکل کشف صفحه نیست، بلکه یه مشکل «اعتبار» هم هست. از اونجایی که لینک‌ها اعتبار سئو (equity) رو از صفحه مبدا به صفحه مقصد منتقل می‌کنن، عامل مهمی در رشد اعتبار صفحه و دامنه هستن.

لینک‌های صفحه اصلی یه مثال عالی هستن. صفحه اصلی معمولاً معتبرترین صفحه یه وب‌سایته، پس لینکی از صفحه اصلی به یه صفحه دیگه وزن زیادی داره.

اگه این لینک‌ها قابل کرال نباشن، مثل اینه که شمشیر لیزری‌تون شکسته باشه. یکی از قوی‌ترین ابزارهاتون بی‌فایده میشه. (چه بازی جالبی با کلمات شد!)

دلایل رایج

برای رسیدن به لینک، به تعامل کاربر نیاز است

مثال منوی آکاردئونی که قبلاً زدیم، فقط یه نمونه از محتواییه که پشت یه تعامل کاربری پنهان شده. یه نمونه دیگه که می‌تونه پیامدهای گسترده‌ای داشته باشه، صفحه‌بندی با اسکرول بی‌نهایته – به خصوص برای سایت‌های فروشگاهی با کاتالوگ محصولات عظیم.

در حالت اسکرول بی‌نهایت، محصولات بی‌شماری در یه صفحه لیست محصولات (دسته بندی) لود نمیشن، مگر اینکه کاربر از یه نقطه خاصی بیشتر اسکرول کنه (lazy loading) یا روی دکمه «نمایش بیشتر» کلیک کنه.

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

به همین دلیله که سئوکارها عموماً صفحه‌بندی واقعی (true pagination) رو ترجیح میدن که در اون هر صفحه از نتایج، یه URL مشخص و قابل کرال داره.

با اینکه راه‌هایی برای بهینه‌سازی lazy loading و اضافه کردن همه محصولات به HTML اولیه وجود داره، اما این کار منجر به تفاوت بین HTML رندر شده و HTML اولیه میشه.

در عمل، این کار دلیلی ایجاد می‌کنه که صفحات بیشتری به صف رندر فرستاده بشن و خزنده‌ها سخت‌تر از چیزی که لازمه کار کنن – و ما می‌دونیم که این برای سئو خوب نیست.

حداقل، توصیه‌های گوگل برای بهینه‌سازی اسکرول بی‌نهایت رو دنبال کنید.

لینک‌ها به درستی کدنویسی نشدن

وقتی گوگل یه سایت رو کرال می‌کنه یا یه URL رو در صف رندر می‌کنه، در واقع یه نسخه بی‌حالت (stateless) از صفحه رو دانلود می‌کنه. این یکی از دلایل اصلیه که استفاده از تگ‌های href و انکر تکست‌های مناسب (همون ساختار لینک‌دهی که اغلب می‌بینید) اینقدر مهمه. خزنده نمی‌تونه فرمت‌های لینکی مثل router, span, یا onClick رو دنبال کنه.

می‌تونه دنبال کنه:

<a href=”https://example.com”>
<a href=”/relative/path/file”>

نمی‌تونه دنبال کنه:

<a routerLink=”some/path”>
<span href=”https://example.com”>
<a onclick=”goto(‘https://example.com’)”>

از نظر یه برنامه‌نویس، همه این‌ها راه‌های معتبری برای کدنویسی لینک هستن. پیامدهای سئوی این کار یه لایه اطلاعاتی اضافیه که وظیفه اون‌ها نیست که بدونن – وظیفه سئوکاره.

بخش بزرگی از کار یه سئوکار خوب اینه که این اطلاعات رو از طریق مستندسازی در اختیار برنامه‌نویس‌ها قرار بده.

مشکل ۵: متادیتاها وجود ندارن

در یه صفحه HTML، متادیتاهایی مثل عنوان، توضیحات، تگ کنونیکال و تگ متا روباتس، همگی در تگ head قرار دارن.

به دلایل واضح، نبود متادیتا برای سئو فاجعه‌باره، اما برای SPAها حتی بدتر هم هست. عناصری مثل تگ کنونیکالی که به خود صفحه اشاره می‌کنه، برای افزایش شانس موفقیت یه صفحه JS در عبور از صف رندرینگ، حیاتی هستن.

از بین تمام عناصری که باید در HTML اولیه وجود داشته باشن، تگ head برای ایندکس شدن از همه مهم‌تره.

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

دلایل رایج

نبود یا پیکربندی نادرست ابزار مدیریت متادیتا

در یه فریم‌ورک JS، یه پلاگین تگ head رو ایجاد می‌کنه و متادیتا رو داخل اون قرار میده. (محبوب‌ترین مثالش React Helmet هست.) حتی اگه یه پلاگین نصب شده باشه، معمولاً باید به درستی پیکربندی بشه.

باز هم، اینجاست که تنها کاری که سئوکارها می‌تونن انجام بدن اینه که مشکل رو به برنامه‌نویس اطلاع بدن، «چرایی» ماجرا رو توضیح بدن و برای رسیدن به معیارهای پذیرش (Acceptance Criteria) که به خوبی مستند شده، از نزدیک باهاشون همکاری کنن.

مشکل ۶: منابع (Resources) سایت کرال نمیشن

فایل‌های اسکریپت و تصاویر، بلوک‌های ساختمانی ضروری در فرآیند رندرینگ هستن.

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

برای اینکه ببینید آیا این URLها کرال میشن یا نه، می‌تونید درخواست‌های گذشته رو در گزارش Crawl Stats سرچ کنسول ببینید.

  • تصاویر: به Settings > Crawl Stats > Crawl Requests: Image برید.
  • جاوا اسکریپت: به Settings > Crawl Stats > Crawl Requests: JavaScript برید.

دلایل رایج

مسدود شدن دایرکتوری توسط فایل robots.txt

هم اسکریپت‌ها و هم تصاویر معمولاً در ساب‌دامین یا ساب‌فولدر مخصوص خودشون قرار می‌گیرن، بنابراین یه دستور disallow در فایل robots.txt از کرال شدن اون‌ها جلوگیری می‌کنه.

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

همچنین می‌تونید با استفاده از ابزار URL inspection در گوگل سرچ کنسول، هر اسکریپتی که هنگام رندر شدن صفحه مسدود شده رو ببینید. روی «Test live URL» کلیک کنید و بعد به مسیر View tested page > More info > Page resources برید.

اینجا می‌تونید هر اسکریپتی که در طول فرآیند رندرینگ لود نشده رو ببینید. اگه فایلی توسط robots.txt مسدود شده باشه، مشخص میشه.

منابع جاوا اسکریپت لود نشده که توسط ابزار Test Live URL در GSC گزارش شده

با جاوا اسکریپت رفیق شید!

بله، جاوا اسکریپت می‌تونه با خودش مشکلات سئویی به همراه داشته باشه. اما هرچقدر سئو تکامل پیدا می‌کنه، بهترین شیوه‌ها (best practices) با تجربه کاربری عالی مترادف میشن.

و یه تجربه کاربری عالی اغلب به جاوا اسکریپت وابسته است. پس با اینکه وظیفه یه سئوکار کدنویسی جاوا اسکریپت نیست، ما باید بدونیم که موتورهای جستجو چطور با اون تعامل می‌کنن، رندرش می‌کنن و ازش استفاده می‌کنن.

با درک قوی از فرآیند رندرینگ و برخی از مشکلات رایج سئو در فریم‌ورک‌های JS، شما در مسیر درستی برای شناسایی مشکلات و تبدیل شدن به یه متحد و همراه قدرتمند برای تیم فنی‌تون قرار گرفتید.

پاسخی بگذارید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *