آیا باید یک اسلش (/) در انتهای URL ها داشته باشیم؟

اسلش انتهایی یک اسلش رو به جلو («/») است که در انتهای URL مانند domain.com/ یا domain.com/page/ قرار می گیرد. اسلش انتهایی معمولاً برای تشخیص دایرکتوری که دارای اسلش انتهایی است از فایلی که دارای اسلش انتهایی نیست استفاده می شود. با این حال، اینها دستورالعمل هستند و الزامی نیستند.

در گذشته، یک پوشه دارای یک اسلش انتهایی بود و یک فایل بدون اسلش انتهایی بود. یک پوشه نشان می‌دهد که فایل‌های بیشتری وجود دارد و شما معمولاً یک فایل فهرست (index.html، index.php، و غیره) دارید که محتوای صفحه از آنجا بارگیری می‌شود. بنابراین محتوا از آدرس domain.com/page/index.html می آید اما domain.com/page/ به کاربران نشان داده می شود. با فایل‌های مجزا، نام فایل را خواهید داشت و در انتها هیچ اسلید بعدی ندارید.

این روزها URL ها در اکثر سیستم ها به فایل ها اشاره نمی کنند. URL یک رکورد ذخیره شده در پایگاه داده است. سیستم های بدون سرور حتی فایل ها را روی سرور شما میزبانی نمی کنند.

ساختارهای URL مختلف ممکن است به طور متفاوتی رفتار شود. اینکه آیا شما انتخاب می کنید که از اسلش انتهایی استفاده کنید یا نه، بیشتر از هر چیزی یک اولویت شخصی است. بیایید به چند سناریو رایج نگاه کنیم.

 

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

domain.com=domain.com/

با این URL ها دقیقاً یکسان رفتار می شود و فرقی نمی کند از کدام نسخه استفاده کنید.

اسلش های انتهایی برای سایر URL ها اهمیت دارد

domain.com/page≠domain.com/page/

برای هر مورد غیر از اسلش انتهایی مستقیماً بعد از دامنه ریشه، یک اسلش انتهایی به عنوان یک URL جداگانه در نظر گرفته می شود.

اسلش های دنباله دار و سئو

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

همین محتوا در URL های اسلش و بدون اسلش دنباله نشان داده می شود

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

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

محتوای متفاوتی در URL های اسلش انتهایی و اسلش غیر انتهایی نشان داده می شود

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

Hreflang

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

افزودن یا حذف اسلش های دنباله دار

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

htaccess

حذف اسلش:

RewriteCond %{REQUEST_FILENAME} !-d 
RewriteRule ^(.*)/$ /$1 [L,R=301]

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

اضافه کردن اسلش:

RewriteCond %{REQUEST_FILENAME} !-f 
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]

نکته کد : به دنبال یک فایل می گردد و اگر فایل وجود داشته باشد، اسلش انتهایی را اضافه نمی کند. این از شکستن تصاویر، PDF، JS، CSS و غیره جلوگیری می کند.

وردپرس

اگر به تنظیمات > تنظیمات پیوند یکتا بروید، در صورت استفاده از ساختار سفارشی، می توانید تغییر دهید که آیا از اسلش انتهایی استفاده می کنید یا خیر.

/%postname%/اسلش انتهایی را به URL ها اضافه می کند

/%postname%اسلش انتهایی را از URL ها حذف می کند

فایل ها نباید به اسلش ختم شوند

در بیشتر موارد، اگر یک اسلش انتهایی به فایلی مانند html، .php، .js، .css، .pdf، .jpg و غیره اضافه کنید، فایل بارگیری نمی شود. این به این دلیل است که اکثر سیستم ها فرض می کنند که فایل یک پوشه است و از آنجایی که چیزی بعد از این مسیر وجود ندارد، معمولاً یک صفحه 404 برگردانده می شود.

حالا بیایید به تاثیر آن بر سئو نگاه کنیم.

چارچوب های جاوا اسکریپت

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

تاثیر بریده بریده بر گزارش

هنگام تعیین اینکه آیا از اسلش انتهایی استفاده شود یا خیر، باید گزارش دهی در نظر گرفته شود. به عنوان مثال، در کنسول جستجوی گوگل، می‌توانید یک ویژگی پیشوند دامنه یا URL را تنظیم کنید. اگر هنگام تنظیم یک ویژگی پیشوند URL (مثلاً دامنه/پوشه)، اسلش انتهایی را وارد نکنید، Google به هر حال یکی را اضافه می‌کند. در نتیجه، تمام بازدیدهای domain.com/folder (بدون سطل زباله انتهایی) گزارش نمی شود زیرا domain.com/folder/ (با اسلش انتهایی) یک سطح بالاتر است.

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

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

این regex است:^(/[a-z0–9/_-]*[^/])$

نتیجه گیری

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

منبع : https://ahrefs.com/