جان مولر (John Mueller) از گوگل، به تازگی درباره تاثیر سئوی آدرس های اینترنتی (URL) تصادفی که توسط سیستم های مدیریت محتوا (CMS) به صورت خودکار در کدهای خام HTML صفحات وب تزریق می شوند، توضیحات مهمی ارائه داده است.
سوال کاربران درباره URLهای داخلی و خودکار ساخته شده
اخیراً جان مولر در پلتفرم ردیت (Reddit) به سوال یکی از متخصصان سئو پاسخ داد. این فرد درباره یک لینک داخلی به صفحه ای از سایت که به طور خودکار توسط پلتفرم «اسکوئر اسپیس» (Squarespace – یک سایت ساز اشتراکی و متن بسته) ایجاد شده بود، ابراز نگرانی کرده بود.
این لینک داخلی، ظاهراً هیچ کاربرد خاصی برای کارفرمای این سئوکار نداشت و دسترسی خزنده ها به آن نیز از طریق فایل robots.txt مسدود شده بود. مشکل اینجا بود که این CMS اجازه ویرایش یا حذف این لینک را به کاربر نمی داد و همین موضوع، باعث ناامیدی و نگرانی سئوکار از بابت مشکلات احتمالی این «لینک داخلی مزاحم» برای سئوی سایت شده بود.
این متخصص سئو در حالی که در تلاش برای رفع مشکلات فنی (Technical SEO) سایت کارفرمای خود بود، متوجه شد که با وجود مسدود بودن این URL در فایل robots.txt، ابزار تخصصی «اسکریمینگ فراگ» (Screaming Frog) همچنان می تواند لینک های داخلی اشاره کننده به این صفحه را شناسایی کند. این موضوع این نگرانی را به وجود آورد که شاید ربات های گوگل هم بتوانند این لینک ها را پیدا کرده و ساختار سایت دچار افت رتبه شود.
سوال دقیق او در ردیت به این شرح بود:
«سلام به همگی!
من در حال برطرف کردن چند مشکل با اولویت بالا برای سایت مشتری ام هستم و فقط یک مورد نهایی باقی مانده است. یک URL داخلی وجود دارد که توسط فایل robots.txt مسدود شده است. سایت مشتری من روی پلتفرم Squarespace ساخته شده. صفحه مسدود شده توسط مشتری من ساخته نشده است، بلکه به نظر می رسد یک لینک فرعی تولید شده توسط خود سیستم اسکوئراسپیس باشد که به این شکل است:
https://domain/categories/=59487a4cd1758e7669102174نکته جالب این است که با استفاده از نرم افزار Screaming Frog، می توانم لینک های ورودی به این صفحه را پیدا کنم، اما این لینک در یک تگ
<a href>پنهان شده است. من آن را از طریق ابزارهای توسعه دهنده مرورگر (Developer Tools) پیدا کرده ام، اما هیچ ایده ای ندارم که چگونه آن را حذف کنم؛ چرا که اسکوئراسپیس هیچ دسترسی به بک اند (Backend) سایت به ما نمی دهد.دقیقا چه اتفاقی دارد می افتد و چطور باید این مشکل را حل کنم؟»
در پلتفرم های SaaS مانند اسکوئراسپیس یا شاپیفای بر خلاف سیستم های متن بازی مثل وردپرس، شما دسترسی مستقیمی به کدهای هسته یا دیتابیس ندارید و همین امر محدودیت هایی را برای سئوکاران ایجاد می کند.
بزرگنمایی روی کد HTML یک صفحه در اسکوئراسپیس که یک لینک داخلی با شناسه عددی/حروفی را نشان می دهد و توسط ابزارهای سئو شناسایی می شود.
لینک های تصادفیِ تولید شده توسط پلتفرم، تاثیری روی سئو ندارند
جان مولر از گوگل در پاسخ به این کاربر صراحتاً اعلام کرد که این URL و لینک هایی که به آن اشاره می کنند، هیچ مشکل و تهدیدی برای دیده شدن سایت در نتایج جستجو (Search Visibility) ایجاد نمی کنند. او پیشنهاد کرد که این لینک ها را کاملاً نادیده بگیرند.
مولر این گونه توضیح داد:
«این موضوع واقعاً اهمیتی ندارد. من اگر جای شما بودم آن را نادیده می گرفتم. این اتفاق هیچ تاثیر مثبت یا منفی روی جستجو / سئو ندارد.
برخی از پلتفرم ها به صورت پیش فرض چنین لینک هایی دارند؛ اگر محتوای ارزشمندی پشت این لینک وجود ندارد که بخواهید ایندکس شود، نیازی نیست هیچ کاری انجام دهید. (و احتمالاً با توجه به اینکه روی یک پلتفرم اشتراکی هاست شده اید، اصلاً کاری هم از دستتان برنمی آید!)»
ماهیت واقعی لینک های اسکوئراسپیس چیست؟
پلتفرم های مدیریت محتوای اشتراکی (Hosted CMS)، کنترل کاملی بر قالب های پایه، سیستم های مسیریابی (Routing) و فرآیند رندر جاوا اسکریپت سایت دارند. به همین دلیل است که آدرس هایی مانند آنچه کاربر به آن اشاره کرد، در پلتفرم هایی مثل Squarespace غیرقابل ویرایش هستند؛ زیرا آن ها بخش جدایی ناپذیری از معماری داخلی و ساختار مهندسی سایت محسوب می شوند.
آدرسی که کاربر نگران آن بود، به احتمال بسیار زیاد صرفاً یک «شناسه داخلی» (Internal Identifier) در دیتابیس اسکوئراسپیس است. در واقع این سیستم، به جای اینکه یک دسته بندی را با آدرسی مثل category=shoes فراخوانی کند، آن را از طریق شناسه عددی و حروفی دیتابیس خود به این شکل فراخوانی می کند:
59487a4cd1758e7669102174
ترفند ?format=json-pretty
برای مشاهده شناسه های پنهان دیتابیس در هر وب سایتی که بر بستر اسکوئراسپیس میزبانی می شود، یک ترفند ساده وجود دارد: کافی است عبارت ?format=json-pretty را به انتهای هر URL اضافه کنید. با این کار، سیستم رندرِ بصریِ صفحه وب را متوقف کرده و کدهای آن صفحه خاص را با فرمت ساختاریافته JSON به شما نمایش می دهد. این یک ترفند فنی است که معمولاً توسعه دهندگان اسکوئراسپیس از آن برای عیب یابی استفاده می کنند.
فرمت JSON یک استاندارد سبک برای تبادل داده است که خواندن آن برای ماشین ها ساده تر است. با این کد، شما عملاً پشت صحنه ساختار داده های آن صفحه را می بینید.
این شیوه از طراحی معماری کاملاً منطقی است؛ چرا که سیستم CMS می تواند از یک شناسه مرجع ثابت و داخلی برای یک URL دسته بندی استفاده کند و در عین حال، به کاربران اجازه دهد آدرس ظاهری (Slug) آن دسته بندی را به هر چیزی که دوست دارند تغییر دهند. در نتیجه، مهم نیست که کاربر چه نامی برای دسته خود انتخاب می کند یا چند بار نظرش عوض می شود؛ شناسه داخلی دیتابیس برای همیشه ثابت می ماند و پیوندهای سایت دچار شکستگی (Broken Links) نمی شوند.
بدون آگاهی از این اطلاعات فنی، ممکن است از دید یک ناظر بیرونی این طور به نظر برسد که یک CMS متن بسته در حال محدود کردن آزادی عمل کاربر است (چیزی که ظاهراً در وردپرس اتفاق نمی افتد). با این حال، واقعیت این است که اسکوئراسپیس دقیقاً برای اینکه به کاربران خود آزادی مطلق در نام گذاری دسته بندی ها بدهد از این روش استفاده می کند و این URLهای غیرقابل ویرایش، در واقع در حال خدمت رسانی برای تحقق همین هدف هستند.
مقایسه معماری داخلی سیستم های مدیریت محتوای اشتراکی (SaaS) مانند اسکوئراسپیس با سیستم های خودمیزبان مانند وردپرس در استفاده از شناسه های پایگاه داده.
شباهت پنهان وردپرس با این معماری
جالب است بدانید که وردپرس هم دقیقاً همین کار را با شناسه های داخلی خود انجام می دهد، با این تفاوت که کمی بیشتر از دید کاربران پنهان است. وردپرس از پارامتر term_id برای دسته بندی ها و برچسب ها، و از post_id برای نوشته ها، محصولات، برگه ها و فایل های پیوست استفاده می کند.
گاهی اوقات وقتی به سورس کد (Source Code) خام تولید شده توسط وردپرس نگاه می کنید، می توانید این پارامترهای term_id و post_id را ببینید. دقیقاً مانند URLهای اسکوئراسپیس که دیگر برای ما مرموز نیستند، این کدهای داخلی در وردپرس نیز نیازی به ویرایش یا حذف برای مقاصد سئو ندارند و کاملاً بی خطرند.
در تیم های تخصصی مانند دانش وب، ما روزانه با پروژه های متنوع طراحی سایت و سئو مواجهیم که هرکدام پیچیدگی های ساختاری خاص خود را دارند. تجربه ما نشان می دهد که دخالت بی مورد در ساختار هسته CMS (مانند تلاش برای حذف پارامترهای پیش فرض وردپرس در قالب ها)، نه تنها به سئو کمک نمی کند، بلکه می تواند باعث بروز خطاهای جبران ناپذیری در دیتابیس شود.
نتیجه گیری
انجام ممیزی های سئوی تکنیکال (Technical SEO Audits)، از جمله خزش (Crawl) سایت با ابزارهایی مثل Screaming Frog، می تواند باعث کشف قطعه کدها یا لینک های عجیب وغریبی شود که در واقع بودنشان در سایت کاملاً ضروری است.
آشنایی با نحوه کارکرد یک سیستم مدیریت محتوا (CMS)، به یک سئوکار و مالک سایت کمک می کند تا درک کند که آیا پیدا شدن یک کدِ عجیب، واقعاً نشانه یک مشکل است یا یک روال ۱۰۰٪ طبیعی در معماری آن سیستم محسوب می شود. به خصوص زمانی که با یک CMS کار می کنید که آشنایی کاملی با آن ندارید، بسیار مهم است که پیش از شناخت نحوه عملکرد لایه های زیرین آن، هیچ تغییر شتاب زده ای را به اسم «بهبود سئو» اعمال نکنید.
در بسیاری از مواقع، چیزی که در نگاه اول برای شما غیرقابل درک است، در واقع گزینه ای است که بهتر است به حال خود رها شود؛ دقیقاً همان طور که جان مولر از گوگل پیشنهاد کرد. اگر در تحلیل خطاهای ابزارهای سئو دچار سردرگمی شده اید، پیشنهاد می کنیم اجرای ممیزی های تکنیکال سایت خود را به متخصصان باتجربه ای مثل تیم دانش وب بسپارید تا با شناخت دقیق از ساختار پلتفرم های مختلف، سلامت فنی سایت شما را تضمین کنند.
در نهایت، در مورد تنظیم ابزار Screaming Frog برای خزش در سایتی مانند Squarespace، شاید بهتر باشد تنظیمات خزنده ی این ابزار را طوری پیکربندی کنید که دقیقاً از دستورات فایل Robots.txt پیروی کند یا حتی به صورت دستی آن را طوری تنظیم کنید که از خزش در صفحات خاص و بیهوده جلوگیری کند.