
تغییر مسیر وب سایت به مرورگرها و موتورهای جستجو اطلاعات مربوط به یک URL و محل پیدا کردن صفحه وب را می دهد. استفاده صحیح از تغییر مسیرها ضروری است زیرا بر نحوه خزیدن و نمایه سازی وب سایت ها توسط گوگل تاثیر می گذارند. در حالی که اکثر مردم به تغییر مسیر به عنوان یک نشانه انحرافی اینترنتی فکر می کنند، اتفاقات بسیار بیشتری در حال رخ دادن است و کشف آن به طرز شگفت انگیزی لذت بخش است.
مرورگرها و خزنده های موتور جستجو مانند GoogleBot عامل کاربر (user agent) نامیده می شوند. هنگامی که یک عامل کاربر سعی می کند به یک صفحه وب دسترسی پیدا کند، آنچه اتفاق می افتد این است که عامل کاربر درخواستی را ارائه می دهد و سرور وب سایت پاسخی را صادر می کند.
این پاسخ ، کد وضعیت پاسخ HTTP نامیده می شود و یک وضعیت برای درخواست URL فراهم می کند. در شرایطی که یک عامل کاربر مانند GoogleBot یک URL درخواست می کند، سرور پاسخ می دهد. به عنوان مثال، اگر درخواست برای URL موفقیت آمیز باشد، سرور کد پاسخ ۲۰۰، که به این معنی است که درخواست برای URL موفقیت آمیز بوده است، ارائه خواهد داد. بنابراین فکر می کنید زمانی که GoogleBot به یک وب سایت می رسد، تلاش می کند آن را ببلعد، در حالیکه آنچه اتفاق می افتد یک سری درخواست و پاسخ است.
وقتی ما در مورد یک تغییر مسیر صحبت می کنیم، چیزی که ما در مورد آن صحبت می کنیم پاسخ سرور است. این پاسخی به درخواست یک URL است. اگر URL در URL دیگری وجود داشته باشد (به دلیل اینکه منتقل شده است)، سرور به عامل کاربر می گوید که درخواست URL به یک URL دیگر هدایت می شود. کد پاسخ برای URL تغییر یافته معمولا به شکل کد وضعیت پاسخ ۳۰۱ یا ۳۰۲ است.
کل مجموعه کدهای پاسخ ۳xx اطلاعات زیادی را منتقل می کند که می تواند به صورت اختیاری توسط عامل کاربر عمل کند. یک مثال از عملی که عامل کاربر می تواند انجام دهد ذخیره یک مخزن از URL جدید است به طوری که دفعه بعدی که URL قدیمی درخواست شود، به جای آن URL جدید را درخواست خواهد کرد. بنابراین، تغییر مسیر ۳۰۱ و ۳۰۲ بیشتر از یک تابلوی جاده اینترنتی است که می گوید: «به اینجا بروید، نه آنجا».

تغییر مسیرها چیزی بیش از دو کد وضعیتی هستند که همه با آنها آشنا هستند، کدهای پاسخ ۳۰۱ و ۳۰۲. در مجموع هفت کد وضعیت پاسخ دهی رسمی ۳xx وجود دارد. اینها، انواع مختلف تغییر مسیرهای موجود برای استفاده هستند:
برخی از کدهای وضعیت فوق به مدت طولانی وجود نداشته و ممکن است مورد استفاده قرار نگیرند. بنابراین قبل از استفاده از هر کد دستوری به غیر از ۳۰۱ یا ۳۰۲، مطمئن شوید که عامل کاربر مورد نظر می تواند آن را تفسیر کند.
از آنجا که GoogleBot از آخرین نسخه کروم (که یک مرورگر بدون سر است) استفاده می کند، به راحتی می توان با بررسی اینکه آیا کروم کد وضعیت را با لیست سازگاری مرورگر تشخیص می دهد یا خیر، بررسی کرد که آیا یک کد وضعیت سازگار است یا خیر. برای سئو، باید از کدهای پاسخ ۳۰۱ و ۳۰۲ استفاده کرد، مگر اینکه دلیل خاصی برای استفاده از یکی از کدهای دیگر وجود داشته باشد.
کد وضعیت ۳۰۱ به طور معمول به عنوان تغییر مسیر ۳۰۱ در نظر گرفته می شود. اما نام رسمی آن ۳۰۱ Moved Permanently است. تغییر مسیر ۳۰۱ به یک عامل کاربر نشان می دهد که URL (زمان هایی که به عنوان منبع هدف یا صرفا منبع شناخته می شود)به مکان دیگری تغییر یافته است و باید از URL جدید برای درخواست های بعدی استفاده کند.
همان طور که پیش تر گفته شد، اطلاعات بیشتری نیز وجود دارد. کد وضعیت ۳۰۱ همچنین به عامل کاربر پیشنهاد می کند:
این نکته آخر یک مسئله فنی است. براساس استانداردهای رسمی برای کد وضعیت ۳۰۱:
« توجه: به دلایل تاریخی، یک عامل کاربر ممکن است روش درخواست را از POST به GET برای درخواست بعدی تغییر دهد. اگر این رفتار نامطلوب باشد، می توان به جای آن از کد وضعیت ۳۰۸ (جابه جایی دائمی) استفاده کرد.»
برای سئو، وقتی موتورهای جستجو تغییر مسیر ۳۰۱ را مشاهده می کنند، رتبه صفحه قدیمی را به صفحه جدید منتقل می کنند. قبل از ایجاد تغییر، هنگام استفاده از تغییر مسیر ۳۰۱ باید مراقب باشید. تغییر مسیر ۳۰۱ تنها زمانی باید استفاده شود که تغییر به یک URL جدید دائمی باشد. زمانی که تغییر موقتی است، نباید از کد وضعیت ۳۰۱ استفاده شود.
علاوه بر این، اگر بعدا نظر خود را تغییر دهید و به URL قدیمی بازگردید، ممکن است URL قدیمی دیگر رتبه بندی نشود و ممکن است زمان ببرد تا دوباره رتبه بندی شود. بنابراین نکته مهمی که باید به خاطر داشته باشید این است که در صورت دائمی بودن تغییر، از کد وضعیت ۳۰۱ استفاده خواهد شد.

نکته مهمی که در مورد کد وضعیت ۳۰۲ باید بدانید این است که برای موقعیت هایی که یک URL به طور موقت تغییر می کند، مفید است. معنای این کد پاسخ این است که URL موقتا در یک URL متفاوت قرار دارد و پیشنهاد می شود که از URL قدیمی برای درخواست های آینده استفاده شود.
کد وضعیت تغییر مسیر ۳۰۲ همچنین با یک هشدار فنی مرتبط با GET و Post همراه است:
« توجه: به دلایل تاریخی، یک عامل کاربر ممکن است روش درخواست را از POST به GET برای درخواست بعدی تغییر دهد. اگر این رفتار نامطلوب باشد، می توان به جای آن از کد وضعیت ۳۰۷ استفاده کرد.»
اشاره به دلایل تاریخی ممکن است به عوامل کاربر قدیمی یا باگی اشاره کند که ممکن است روش درخواست را تغییر دهند.
تغییر مسیر ۳۰۷ به این معنی است که URL درخواستی به طور موقت منتقل می شود و عامل کاربر باید از URL اصلی برای درخواست های بعدی استفاده کند. تنها تفاوت بین یک کد وضعیت ۳۰۲ و ۳۰۷ این است که یک عامل کاربر باید URL جدید را با همان درخواست HTTP درخواست کند که برای درخواست URL اصلی استفاده می شود.
این بدان معناست که اگر عامل کاربر صفحه را با درخواست GET درخواست کند، عامل کاربر باید از درخواست GET برای URL موقت جدید استفاده کند و نمی تواند از درخواست POST استفاده کند. به غیر از کد وضعیت ۳۰۷ که درخواست های بعدی را ملزم می کند از یک نوع باشند (POST یا GET)و اینکه ۳۰۲ می تواند هر دو مسیر را طی کند، همه چیز بین ۳۰۲ و ۳۰۷ کد وضعیت یکسان است.
شما می توانید یک تغییر مسیر را از طریق فایل های پیکربندی سرور انجام دهید. htaccess on Apache.conf file on Nginx یا از طریق پلاگین ها اگر از وردپرس استفاده می کنید. در همه موارد، آنها دستور یکسانی برای نوشتن قوانین تغییر مسیر دارند. آنها فقط با دستورات مورد استفاده در فایل های پیکربندی متفاوت هستند. برای مثال، تغییر مسیر در Apache به شکل زیر خواهد بود:
Options +FollowSymlinks RewriteEngine on RedirectMatch 301 ^/oldfolder/ /newfolder/
در سرورهای Nginx به این شکل خواهد بود:
rewrite ^/oldfolder/ /newfolder/ permanent;
دستورات مورد استفاده برای اعلام کد وضعیت تغییر مسیر سرور و دستور عمل متفاوت است. برای مثال:
اما نحو تغییر مسیر (^/oldfolder/ /newfolder/) برای هر دو یکسان است. در Apache، مطمئن شوید که ماژولهای mod_rewrite و mod_alias (مسئول مدیریت تغییر مسیرها) در سرور شما فعال هستند. از آنجایی که پرکاربردترین نوع سرور Apache است، در اینجا نمونه هایی برای آن آورده شده است. مطمئن شوید که فایل hhtaccess این دو خط را در بالای قوانین تغییر مسیر داشته باشد و قوانین را در زیر آن ها قرار دهید:
Options +FollowSymlinks RewriteEngine on
رایج ترین و پرکاربردترین نوع تغییر مسیر، هنگام حذف صفحات یا تغییر URL ها است. به عنوان مثال، بگویید URL را از /old-page/ به /new-page/ تغییر داده اید.
RewriteRule ^old-page(/?|/.*)$ /new-page/ [R=301,L]
یا
RedirectMatch 301 ^/old-page(/?|/.*)$ /new-page/
تنها تفاوت بین این دو روش این است که روش اول از ماژول Apache mod_rewrite و روش دوم از Mod_alias استفاده می کند. عبارت منظم “^” به این معنی است که URL باید با “/old-page” شروع شود، در حالی که (/?|/.*)$ نشان می دهد که هر چیزی که پس از “/old-page/” با اسلش “/” یا بدون علامت دقیق باشد، نشان می دهد، باید به /new-page/ هدایت شود.
ما همچنین میتوانیم از (.*)، یعنی ^/old-page(.*) استفاده کنیم، اما مشکل اینجاست که اگر صفحه دیگری با URL مشابه مانند /old-page-other/ دارید، زمانی که شما تغییر مسیر داده میشود. ما فقط می خواهیم /old-page/ را تغییر مسیر دهیم.
هر تغییری از URL صفحه را به یک آدرس جدید هدایت می کند. اگر از تغییر مسیر به شکل زیر استفاده کنیم:
Redirect 301 /old-page/ /new-page/
…بدون عبارات منظم، همه URL های دارای رشته پرس و جو UTM، به عنوان مثال، /old-page?utm_source=facebook.com (که رایج است زیرا URL ها برای اشتراک گذاری در شبکه های اجتماعی استفاده می شوند) به ۴۰۴ ختم می شوند. حتی /old-page بدون اسلش انتهایی “/” به ۴۰۴ ختم می شود.

فرض کنید ما مجموعه ای از URL ها مانند /category/old-subcategory-1/، /category/old-subcategory-2/، /category/final-subcategory/ داریم و می خواهیم همه زیر شاخه ها را در /category/final-subcategory/ ادغام کنیم. ما در اینجا به قانون “همه به جز” نیاز داریم.
RewriteCond %{REQUEST_URI} !/category/final-subcategory/
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(category/). /category/final-subcategory/ [R=301,L]
در اینجا، میخواهیم همه را در زیر /category/ در خط سوم تغییر مسیر دهیم، به جز اگر /category/final-subcategory/ در خط چهارم باشد. ما همچنین قانون “!-f” را در خط دوم داریم که هر فایلی مانند تصاویر، CSS یا فایل های جاوا اسکریپت را نادیده می گیرد. در غیر این صورت، اگر دارایی هایی مانند “/category/image.jpg” داشته باشیم، آن نیز به “/final-subcategory/” هدایت می شود و باعث شکستن تصویر می شود.
اگر تغییر ساختار دسته را انجام داده اید و می خواهید همه چیز را از دایرکتوری قدیمی به فهرست جدید منتقل کنید، می توانید از قانون زیر استفاده کنید.
RewriteRule ^old-directory$ /new-directory/ [R=301,NC,L] RewriteRule ^old-directory/(.*)$ /new-directory/$1 [R=301,NC,L]
من از ۱$ در هدف استفاده کردم تا به سرور بگویم که باید همه موارد موجود در URL را که به دنبال /old-directory/ (یعنی /old-directory/subdirectory/) قرار دارد را به خاطر بسپارد و آن را (به عنوان مثال، “/subdirectory/”) به آدرس ارسال کند. مقصد در نتیجه به /new-directory/subdirectory/ هدایت می شود. من از دو قانون استفاده کردم: یک مورد بدون اسلش انتهایی و دیگری با اسلش انتهایی.
من می توانم آنها را در یک قانون با استفاده از (/?|.*)$ RegExp در انتها ترکیب کنم، اما وقتی URL درخواستی بدون اسلش دنباله دار باشد، مشکل ایجاد می کند و یک اسلش “//” به انتهای URL اضافه می کند.
فرض کنید ۱۰۰ URL در وب سایت خود با نام شهر “شیکاگو” دارید و می خواهید آنها را حذف کنید. برای URL http://yourwebiste.com/example-chicago-event/، قانون تغییر مسیر به این صورت خواهد بود:
RewriteRule ^(.*)-chicago-(.*) http://%{SERVER_NAME}/$1-$2 [NC,R=301,L]
اگر URL مثال به شکل http:// yourwebiste.com/example/chicago/event/ باشد، تغییر مسیر به این صورت خواهد بود:
RewriteRule ^(.*)/chicago/(.*) http://%{SERVER_NAME}/$1/$2 [NC,R=301,L]
داشتن URL های متعارف مهمترین بخش سئو است. در صورت عدم وجود، ممکن است وب سایت خود را با مشکلات محتوای تکراری به خطر بیندازید زیرا موتورهای جستجو URL های دارای نسخه های «www» و «غیر www» را به عنوان صفحات مختلف با محتوای یکسان در نظر می گیرند. بنابراین، باید مطمئن شوید که وب سایت را فقط با یک نسخه که انتخاب می کنید، اجرا می کنید. اگر می خواهید وب سایت خود را با نسخه www اجرا کنید، از این قانون استفاده کنید:
RewriteCond %{HTTP_HOST} ^yourwebsite.com [NC]
RewriteRule ^(.*)$ http://www.yourwebsite.com/$1 [L,R=301]
برای نسخه “غیر www”:
RewriteCond %{HTTP_HOST} ^www.yourwebsite.com [NC]
RewriteRule ^(.*)$ http://yourwebsite.com/$1 [L,R=301]
اسلش انتهایی نیز بخشی از متعارف سازی است، زیرا URL هایی که دارای اسلش در انتها یا بدون آن هستند نیز به طور متفاوتی رفتار می شوند.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteRule ^(.*[^/])$ /$1/ [L,R=301]
با این کار مطمئن خواهید شد که /example-page به /example-page/ هدایت می شود. می توانید به جای اضافه کردن، اسلش را حذف کنید . در این صورت به قانون زیر نیاز خواهید داشت:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [L,R=301]

پس از اقدام گوگل برای تشویق صاحبان وب سایت ها به استفاده از SSL، مهاجرت به HTTPS یکی از روش های رایجی است که تقریبا هر وب سایتی از آن برخوردار است. قانون بازنویسی زیر را می توان برای اجباری کردن HTTPS در هر وب سایتی به کار برد.
RewriteCond %{HTTP_HOST} ^yourwebsite.com [NC,OR]
RewriteCond %{HTTP_HOST} ^www.yourwebsite.com [NC]
RewriteRule ^(.*)$ https://www.yourwebsite.com/$1 [L,R=301,NC]
با استفاده از این افزونه می توانید تغییر مسیر نسخه وب یا غیر وب سایت را با یک قانون تغییر مسیر HTTPS ترکیب کنید.
این نیز یکی از پرکاربردترین تغییر مسیر هاست که تصمیم میگیرید مسیر دامنه خود را تغییر دهید و باید دامنه خود را تغییر دهید. قانون زیر old-domain.com را به new-domain.com هدایت می کند.
RewriteCond %{HTTP_HOST} ^old-domain.com$ [OR]
RewriteCond %{HTTP_HOST} ^www.old-domain.com$
RewriteRule (.*)$ http://www.new-domain.com/$1 [R=301,L]
از دو حالت استفاده میکند: یکی با نسخه «www» URLها و دیگری «غیر www» زیرا هر صفحهای به دلایل تاریخی ممکن است لینک های ورودی به هر دو نسخه داشته باشد. اکثر صاحبان سایت از وردپرس استفاده می کنند و ممکن است برای تغییر مسیر نیازی به فایل htaccess نداشته باشند اما در عوض از یک افزونه استفاده کنند.
مدیریت تغییر مسیرها با استفاده از افزونه ها ممکن است کمی با آنچه در بالا بحث کردیم متفاوت باشد. برای مدیریت صحیح RegExp برای پلاگین خاص، ممکن است لازم باشد اسناد آنها را بخوانید. از میان پلاگین های موجود، من یک افزونه رایگان به نام Redirection را توصیه می کنم که دارای پارامترهای زیادی برای کنترل قوانین تغییر مسیر و بسیاری از اسناد مفید است.
این مورد اغلب زمانی اتفاق میافتد که برای بررسی همه URLهای ۴۰۴ خود تنبل هستید و آنها را به صفحه فرود مناسب نگاشت میکنید. به گفته گوگل، هنوز هم همه آن ها به صورت ۴۰۴ در نظر گرفته می شوند. اگر صفحاتی از این قبیل دارید، باید به فکر ایجاد صفحات زیبای ۴۰۴ باشید و کاربران را برای مرور بیشتر یا یافتن چیزی غیر از آنچه که به دنبال آن بودند با نمایش گزینه جستجو جذب کنید.
گوگل به شدت توصیه می کند که محتوای صفحه تغییر مسیر داده شده باید معادل صفحه قدیمی باشد. در غیر این صورت، این تغییر مسیر ممکن است به عنوان یک تغییر مسیر نرم در نظر گرفته شود و رتبه آن صفحه را از دست خواهید داد.
اگر نشانیهای اینترنتی متفاوتی برای وبسایتهای دسکتاپ و تلفن همراه دارید (یعنی «example.com» برای دسکتاپ و «m.example.com» برای تلفن همراه)، باید مطمئن شوید که کاربران را به صفحه مناسب نسخه موبایل هدایت میکنید.
Correct: “example.com/sport/” to “m.example.com/sport/”
Wrong: “example.com/sport/” to “m.example.com”
همچنین، باید اطمینان حاصل کنید که اگر یک صفحه در دسکتاپ ۴۰۴ است، باید در موبایل نیز ۴۰۴ باشد. اگر نسخه موبایلی برای صفحه ای ندارید، می توانید از تغییر مسیر به نسخه موبایل خودداری کنید و آنها را در صفحه دسکتاپ نگه دارید.
این امکان وجود دارد که با استفاده از یک برچسب متادیتا مانند مثال زیر، یک تغییر مسیر انجام دهید:
<meta http-equiv=”refresh” content=”۰;url=http://example.com/new-page/” />
اگر این تگ را در /old-page/ وارد کنید، کاربر را بلافاصله به /new-page/ هدایت می کند. گوگل این تغییر مسیر را ممنوع نمی کند، اما استفاده از آن را توصیه نمی کند. موتورهای جستجو ممکن است نتوانند آن نوع تغییر مسیر را به درستی تشخیص دهند. همین امر در مورد تغییر مسیرهای جاوا اسکریپت نیز صادق است.

این پیام زمانی نمایش داده می شود که شما یک تنظیمات منظم اشتباه داشته باشید و در یک حلقه بی نهایت به پایان برسد. معمولا این اتفاق زمانی رخ می دهد که شما یک زنجیره معکوس داشته باشید. فرض کنید مدت ها پیش صفحه ۱ را به صفحه ۲ هدایت کرده اید. شاید فراموش کرده باشید که صفحه ۱ دوباره هدایت می شود و تصمیم گرفته اید صفحه ۲ را دوباره به صفحه ۱ هدایت کنید. در نتیجه با چنین قانونی مواجه خواهید شد:
RewriteRule ^page1 /page2 [R=301,NC,L] RewriteRule ^page2 /page1 [R=301,NC,L]
این کار یک حلقه بی نهایت ایجاد می کند و خطای نشان داده شده در بالا را ایجاد می کند.
دانستن اینکه تغییر مسیرها چیست و کدام موقعیت به کد وضعیت خاصی نیاز دارد، برای بهینه سازی صحیح صفحات وب ضروری است. این یک بخش اصلی از درک سئو است. بسیاری از موقعیت ها به دانش دقیق تغییر مسیرها نیاز دارند، مانند انتقال یک وب سایت به یک دامنه جدید یا ایجاد یک URL صفحه نگهدارنده موقت برای یک صفحه وب که تحت URL عادی خود باز می گردد.
در حالی که بسیاری از موارد با یک متصل شونده امکان پذیر است، متصل شونده ها می توانند بدون درک درست زمان و چرایی استفاده از نوع خاصی از اتصال مجدد مورد سو استفاده قرار گیرند.
منبع: لینک