حل مشکل حذف اسلش انتهای آدرس در WP Rocket
- آموزش سئو وردپرسمقالات آموزشی
- بروزرسانی شده در

اگه بعد از فعال کردن وردپرس راکت متوجه شدید آدرسهای دارای اسلش و بدون اسلش هر دو باز میشن، عجله نکنید و مستقیم سراغ ویرایش تنظیمات سرور نرید. اول باید بفهمید هر آدرس چه کد پاسخی میده، نسخه اصلی سایتتون کدومه و رفتار دیدهشده واقعاً از وردپرس راکت میاد یا کش هاست و وبسرور باعثش شده.
در این راهنما، اول روش تشخیص مشکل رو میبینید. بعد تأثیر اسلش انتهای آدرس روی سئو رو بررسی میکنیم و سراغ راهحل رسمی وردپرس راکت، فایل .htaccess و تنظیمات NGINX میریم. در آخر هم یاد میگیرید ریدایرکت، canonical، لینکهای داخلی و نقشه سایت رو چطور با هم هماهنگ و آزمایش کنید.
آنچه در این مقاله میخوانید
اول مطمئن بشید مشکل اسلش واقعاً از وردپرس راکته
وردپرس راکت همیشه اسلش انتهای همه آدرسها رو حذف نمیکنه. طبق راهنمای رسمی وردپرس راکت، رفتار نهایی میتونه به قوانین بازنویسی وردپرس راکت، نوع وبسرور و کش سمت سرور بستگی داشته باشه. پس غیرفعال کردن موقت افزونه فقط یکی از آزمایشهاست و بهتنهایی علت قطعی رو ثابت نمیکنه.
تفاوت آدرس دارای اسلش و بدون اسلش چیه
این دو آدرس در ظاهر خیلی شبیه هم هستن:
https://example.com/sample-page
https://example.com/sample-page/ولی از نظر فنی دو URL جدا هستن. URL همون نشانی دقیق یک صفحه در وبه. سایت میتونه یکی رو مستقیماً با کد ۲۰۰ نمایش بده و اون یکی رو با ریدایرکت ۳۰۱ به نسخه اصلی بفرسته. کد ۲۰۰ یعنی صفحه مستقیم باز شده و کد ۳۰۱ یعنی آدرس برای همیشه به مقصد دیگهای منتقل شده.
وضعیت هر دو آدرس رو بررسی کنید
هر دو نسخه یک صفحه رو در پنجره ناشناس مرورگر باز کنید. بعد کلید F12 رو بزنید، وارد بخش Network بشید و صفحه رو دوباره بارگذاری کنید. روی درخواست اصلی صفحه کلیک کنید و مقدار Status Code و نشانی نهایی رو ببینید.
- اگه نسخه فرعی کد ۳۰۱ میده و به نسخه انتخابی شما میره، رفتار اصلی درست انجام شده.
- اگه هر دو نسخه کد ۲۰۰ میدن، هر دو آدرس مستقیم در دسترس هستن و باید بقیه سیگنالهای نسخه اصلی رو بررسی کنید.
- اگه چند ریدایرکت پشتسرهم میبینید، احتمالاً با زنجیره ریدایرکت روبهرو هستید.
- اگه مرورگر مرتب بین دو آدرس جابهجا میشه، احتمالاً دو قانون متناقض حلقه ریدایرکت ساختهان.
عاملهای مختلف رو جداگانه آزمایش کنید
اول از سایت و تنظیماتش نسخه پشتیبان بگیرید. بعد کش وردپرس راکت رو پاک کنید و دوباره هر دو آدرس رو آزمایش کنید. اگه تغییری ندیدید، کش هاست، CDN و مرورگر رو هم پاک کنید. CDN یعنی شبکهای از سرورها که نسخهای از فایلها یا صفحههای سایتتون رو نزدیکتر به بازدیدکننده تحویل میده.
برای یک آزمایش کوتاه، وردپرس راکت رو موقتاً غیرفعال کنید و نتیجه رو دوباره ببینید. اگه رفتار همچنان باقی موند، قانون احتمالاً در Apache، NGINX، کش سرور، CDN یا افزونه دیگهای اجرا میشه. بعد از آزمایش، افزونه رو دوباره فعال کنید.
حذف اسلش انتهای آدرس چه تأثیری روی سئو داره
داشتن یا نداشتن اسلش بهخودیخود باعث بهتر شدن رتبه نمیشه. مسئله اصلی هماهنگیه. بهتره کاربر و موتور جستجو همیشه به یک نسخه مشخص برسن و همه نشانههای سایت همون نسخه رو معرفی کنن.
گوگل دو نسخه آدرس رو چطور بررسی میکنه
راهنمای گوگل درباره انتخاب URL اصلی توضیح میده که موتور جستجو میتونه آدرسهای مشابه رو جداگانه پیدا کنه و بعد یکی رو بهعنوان canonical انتخاب کنه. canonical یعنی نسخهای که شما ترجیح میدید بهعنوان آدرس اصلی صفحه شناخته بشه.
گوگل ممکنه نسخه دیگه رو از یک لینک خارجی، لینک داخلی اشتباه، نقشه سایت قدیمی یا مسیرهای دیگه پیدا کنه. به همین دلیل، صرفاً اینکه شما جایی به نسخه بدون اسلش لینک نداده باشید تضمین نمیکنه اون آدرس هیچوقت کشف نشه.
چرا canonical بهتنهایی همیشه کافی نیست
تگ canonical داخل کد صفحه به گوگل پیشنهاد میده کدوم URL اصلیه، ولی یک دستور اجباری برای مرورگر یا همه موتورهای جستجو نیست. کاربر همچنان میتونه نسخه فرعی رو باز کنه و رباتها هم ممکنه اون رو درخواست کنن. ریدایرکت دائمی ۳۰۱ سیگنال روشنتریه و بازدیدکننده رو هم به مقصد اصلی میفرسته.
بهترین حالت اینه که ریدایرکت ۳۰۱، canonical خودارجاع، لینکهای داخلی و نقشه سایت روی یک نسخه هماهنگ باشن. canonical خودارجاع یعنی صفحه در تگ canonical به آدرس اصلی خودش اشاره کنه.
نسخه انتخابشده گوگل رو ببینید
در گوگل سرچ کنسول وارد ابزار URL Inspection بشید و URL صفحه رو بررسی کنید. در اطلاعات ایندکس، مقدارهای User-declared canonical و Google-selected canonical رو مقایسه کنید. اولی نسخه پیشنهادی سایتتونه و دومی نسخهایه که گوگل انتخاب کرده. اگه این دو فرق دارن، ریدایرکت، canonical، لینکهای داخلی و نقشه سایت رو دوباره بررسی کنید.
قبل از حل مشکل، نسخه اصلی آدرسها رو انتخاب کنید
قبل از افزودن هر قانونی باید تصمیم بگیرید نسخه دارای اسلش اصلیه یا نسخه بدون اسلش. اگه این تصمیم روشن نباشه، ممکنه یک بخش سایت اسلش اضافه کنه و بخش دیگه همون اسلش رو برداره.
آدرس دارای اسلش بهتره یا بدون اسلش
برای بیشتر سایتها هیچکدوم برتری عمومی و مستقیمی برای سئو نداره. انتخاب مناسب همون ساختاریه که وردپرس و سایتتون الان بهطور ثابت تولید میکنن. اگه سایت قدیمیه و صفحههاش ایندکس شدهان، معمولاپیوند یکتاً حفظ ساختار فعلی کمریسکتره.
تغییر بیدلیل ساختار URL میتونه ریدایرکتهای زیادی بسازه، گزارشهای آماری رو پراکنده کنه و بررسی خطاها رو سختتر کنه. اگه فقط میخواید دو نسخه به یک آدرس برسن، لازم نیست همزمان ساختار پیوند یکتا رو هم عوض کنید.
ساختار پیوندهای یکتای وردپرس رو بررسی کنید

در پیشخوان وردپرس به مسیر «تنظیمات ← پیوندهای یکتا» برید. ساختار انتخابشده رو یادداشت یا از صفحه عکس محلی برای خودتون تهیه کنید، ولی فعلاً چیزی رو تغییر ندید. بعد یکی از نوشتهها رو باز کنید و ببینید وردپرس لینک اون رو با اسلش میسازه یا بدون اسلش.
لینکهای منو، نوشتهها و نقشه سایت رو هم نمونهگیری کنید. اگه بیشتر بخشها نسخه دارای اسلش رو تولید میکنن، همون نسخه معمولاً انتخاب طبیعیتریه. برای شناخت ارتباط URLها و ساختار کلی سایت هم میتونید راهنمای معماری سایت رو بخونید.
روش پیشنهادی وردپرس راکت برای برگردوندن اسلش انتهای آدرس
اگه نسخه اصلی سایتتون اسلش داره و آزمایشها نشون میدن رفتار به وردپرس راکت مربوطه، سادهترین نقطه شروع افزونه کمکی رسمی همین محصوله. این افزونه برای اجرای ریدایرکت نسخه بدون اسلش به نسخه دارای اسلش ساخته شده.
نصب افزونه کمکی رسمی وردپرس راکت
- نسخه پشتیبان بگیرید. از فایلهای سایت، پایگاه داده و تنظیمات فعلی سرور بکاپ داشته باشید تا اگه ریدایرکت اشتباهی ساخته شد، بتونید به وضعیت قبل برگردید.
- افزونه کمکی رو از مرجع رسمی بگیرید. وارد صفحه رسمی راهحل اسلش وردپرس راکت بشید و فایل معرفیشده در همون صفحه رو دریافت کنید. این کار مطمئنتر از استفاده از لینک دانلود قدیمی یا سایتهای متفرقه هست.
- افزونه رو نصب کنید. در پیشخوان به «افزونهها ← افزودن افزونه تازه ← بارگذاری افزونه» برید. فایل ZIP رو انتخاب کنید، روی «هماکنون نصب نمایید» بزنید و بعد افزونه رو فعال کنید.
- همه کشها رو پاک کنید. کش وردپرس راکت، کش هاست، CDN و مرورگر رو پاک کنید. اگه از پراکسی معکوس استفاده میکنید، کش اون رو هم خالی کنید. پراکسی معکوس سرویسیه که قبل از سرور اصلی درخواست کاربر رو دریافت میکنه.
- ریدایرکت رو دوباره آزمایش کنید. نسخه بدون اسلش یک نوشته یا برگه رو باز کنید. باید با یک ریدایرکت ۳۰۱ به همون آدرس دارای اسلش برسید.

اگه افزونه کمکی نتیجه نداد، چند قانون متناقض اضافه نکنید. اول بررسی کنید ریدایرکت در کدوم لایه اجرا میشه و بعد فقط همون لایه رو اصلاح کنید.
حل مشکل با فایل .htaccess در سرور Apache
Apache یک نرمافزار وبسروره که خیلی از هاستهای وردپرسی ازش استفاده میکنن. فایل .htaccess هم یک فایل تنظیمات محلیه که میتونه قانونهای بازنویسی و ریدایرکت رو برای سایت اجرا کنه.
معمولاً این فایل در پوشه اصلی نصب وردپرس و کنار فایلهایی مثل wp-config.php قرار داره. چون اسمش با نقطه شروع میشه، شاید لازم باشه نمایش فایلهای مخفی رو در فایل منیجر هاست فعال کنید.
قبل از ویرایش چه کاری انجام بدید
یک نسخه از فایل فعلی .htaccess دانلود کنید و بکاپ کامل سایت رو هم نگه دارید. اگه بعد از ویرایش با خطای ۵۰۰ یا از دسترس خارج شدن سایت روبهرو شدید، باید بتونید فایل سالم قبلی رو سریع برگردونید.
قانون مربوط به اسلش باید قبل از قوانین اصلی وردپرس قرار بگیره و بیرون از محدودهای باشه که بین عبارتهای # BEGIN WordPress و # END WordPress قرار داره. وردپرس ممکنه محتوای داخل اون محدوده رو دوباره تولید کنه.
نمونه زیر درخواستهای GET رو فقط وقتی به نسخه دارای اسلش میفرسته که مقصد یک فایل یا پوشه واقعی نباشه. مسیرهای REST API و بخش مدیریت وردپرس هم مستثنا شدهان. REST API راهیه که وردپرس و برنامههای دیگه با درخواستهای مشخص داده ردوبدل میکنن.
# Add a trailing slash to public, non-file URLsRewriteEngine OnRewriteCond %{REQUEST_METHOD} =GETRewriteCond %{REQUEST_FILENAME} !-fRewriteCond %{REQUEST_FILENAME} !-dRewriteCond %{REQUEST_URI} !/$RewriteCond %{REQUEST_URI} !^/wp-json(?:/|$) [NC]RewriteCond %{REQUEST_URI} !^/wp-admin(?:/|$) [NC]RewriteRule ^ %{REQUEST_SCHEME}://%{HTTP_HOST}%{REQUEST_URI}/ [R=301,L]نکته: پشتیبانی از متغیر REQUEST_SCHEME و محل درست این قانون میتونه به تنظیمات سرورتون بستگی داشته باشه. قبل از استفاده در سایت اصلی، کد رو با پشتیبانی هاست بررسی کنید. اگه سایت پشت پراکسی یا CDN قرار گرفته، تشخیص HTTPS هم باید در تنظیمات سرور درست انجام بشه.
بعد از ذخیره، صفحه اصلی، یک نوشته، یک برگه، فایل تصویر، مسیر /wp-json/ و صفحه ورود رو آزمایش کنید. اگه حلقه ریدایرکت یا خطای سرور دیدید، فایل بکاپ رو برگردونید و از پشتیبانی هاست کمک بگیرید.
حل مشکل در وبسرور NGINX
NGINX وبسرور دیگهایه که تنظیماتش رو از فایلهای مرکزی سرور میخونه. NGINX فایل .htaccess رو پردازش نمیکنه، پس افزودن قانون به اون فایل روی سرور NGINX خالص اثری نداره.
قانون افزودن اسلش چطور کار میکنه
نمونهای که راهنمای رسمی وردپرس راکت برای افزودن اسلش معرفی میکنه، مسیرهای فایلمانند و REST API رو کنار میذاره و بقیه URLهای واجد شرایط رو با ریدایرکت دائمی به نسخه دارای اسلش میفرسته:
# Force Trailing Slash (less REST API calls and files)if ($request_uri !~ "^/wp-json") { rewrite ^([^.]^[^/])$ $1/ permanent;}نیازمند بررسی: جای درست این قطعه و سازگاری عبارت منظم اون با ساختار همه مسیرهای سایتتون باید توسط مدیر سرور بررسی بشه. قانونهای NGINX به چیدمان بلوکهای server و location وابستهان و قرار دادن کد در بخش اشتباه میتونه نتیجه متفاوتی بسازه.
قانون حذف اسلش برای نسخه بدون اسلش
اگه ساختار اصلی سایتتون بدون اسلشه، راهنمای وردپرس راکت نمونه زیر رو برای فرستادن نسخه دارای اسلش به نسخه بدون اسلش نشون میده:
# Remove Trailing Slash (less REST API calls and files)if ($request_uri !~ "^/wp-json") { rewrite ^/(.*)/$ /$1 permanent;}این تنظیم رو به پشتیبانی هاست یا مدیر سرور بسپارید. اونها میتونن قبل از بارگذاری دوباره NGINX، درستی فایل تنظیمات رو آزمایش کنن و استثناهای مخصوص سایتتون رو هم در نظر بگیرن.
بعد از اعمال تغییرات، نتیجه رو کامل آزمایش کنید
- هر دو نسخه URL رو باز کنید. یک نوشته، یک برگه و در صورت نیاز یک دستهبندی رو با اسلش و بدون اسلش آزمایش کنید. مقصد نهایی باید همون نسخه اصلی انتخابشده باشه.
- کد پاسخ رو ببینید. نسخه فرعی باید مستقیم با کد ۳۰۱ به نسخه اصلی برسه. وجود چند ریدایرکت پشتسرهم یا رفتوبرگشت بین دو نسخه نشونه تنظیم نادرسته.
- canonical رو مقایسه کنید. کد منبع صفحه اصلی رو باز کنید و عبارت
rel="canonical"رو پیدا کنید. URL داخل اون باید با مقصد نهایی ریدایرکت یکی باشه. - لینکهای داخلی و نقشه سایت رو ببینید. منو، لینکهای داخل نوشتهها و URLهای نقشه سایت باید نسخه اصلی رو استفاده کنن. لینک دادن مستقیم به مقصد، از ریدایرکت اضافه جلوگیری میکنه.
- همه کشها رو پاک کنید. کش افزونه، هاست، CDN و مرورگر رو خالی کنید و آزمایش رو در حالت ناشناس تکرار کنید.
- نتیجه گوگل رو بررسی کنید. بعد از اینکه گوگل دوباره صفحه رو بررسی کرد، در URL Inspection ببینید canonical انتخابشده گوگل با نسخه اصلی سایتتون هماهنگه یا نه.
تغییرات مربوط به URL رو فقط روی یک صفحه آزمایش نکنید. صفحه اصلی، نوشتهها، برگهها، دستهبندیها، فایلهای واقعی، صفحه ورود و مسیرهای API رفتار یکسانی ندارن و باید نمونهای از هرکدوم رو ببینید.
اگه مشکل حل نشد، این موارد رو بررسی کنید
- افزونههای ریدایرکت، سئو و امنیت: ممکنه افزونه دیگهای قبل یا بعد از وردپرس راکت قانون جداگانهای اجرا کنه. تنظیمات مربوط به تغییر URL، اجبار HTTPS و canonical رو بررسی کنید.
- کش هاست، CDN یا پراکسی معکوس: ممکنه پاسخ قدیمی هنوز در لایهای خارج از وردپرس نگهداری بشه. اگه از CDN استفاده میکنید، راهنمای انتخاب CDN هم به شناخت این لایه کمک میکنه.
- قوانین قدیمی یا تکراری:فایل
.htaccess، تنظیمات Apache و فایلهای NGINX رو برای قانونهای مشابه بررسی کنید. یک قانون ممکنه اسلش رو اضافه کنه و قانون دیگه همون رو برداره. - HTTPS، www و دامنه اصلی: اگه درخواست همزمان بین HTTP و HTTPS، یا بین دامنه دارای www و بدون www جابهجا میشه، احتمال زنجیره ریدایرکت بالا میره. اول نسخه اصلی دامنه رو مشخص کنید.
- فایلها و مسیرهای خاص: تصویرها، فایلهای CSS و JavaScript، مسیر
/wp-json/، صفحه ورود و مدیریت وردپرس نباید کورکورانه زیر قانون عمومی قرار بگیرن.
اشتباههایی که موقع تغییر اسلش آدرسها نباید انجام بدید
- ساختار پیوندهای یکتا و قانون ریدایرکت رو همزمان تغییر ندید. وقتی دو تغییر با هم انجام بشن، پیدا کردن علت خطا سخت میشه.
- همه درخواستها رو بدون استثنا ریدایرکت نکنید. فایلها، پوشههای واقعی، API و مسیرهای مدیریتی ممکنه به قانون جداگانه نیاز داشته باشن.
- افزونه کمکی، قانون
.htaccessو تنظیم NGINX متناقض رو همزمان فعال نکنید. یک راه روشن و قابلکنترل انتخاب کنید. - بدون بکاپ سراغ فایلهای سرور نرید. حتی یک نشانه اشتباه در تنظیمات ممکنه سایت رو از دسترس خارج کنه.
- بعد از تغییر فقط باز شدن صفحه رو نبینید. کد پاسخ، مقصد نهایی، canonical، لینکهای داخلی و نقشه سایت هم باید هماهنگ باشن.
جمعبندی انتخاب بهترین روش
برای حل مشکل حذف اسلش انتهای آدرس در WP Rocket، اول باید ثابت کنید مشکل واقعاً از همین افزونه میاد. اگه نسخه اصلی سایتتون اسلش داره و رفتار بعد از فعال شدن قوانین وردپرس راکت تغییر کرده، افزونه کمکی معرفیشده در راهنمای رسمی معمولاً سادهترین گزینه برای یک کاربر تازهکاره.
اگه ریدایرکت باید در سطح سرور اجرا بشه، روی Apache میتونید با بکاپ و کمک پشتیبانی هاست فایل .htaccess رو تنظیم کنید. روی NGINX بهتره حتماً مدیر سرور قانون رو در جای درست قرار بده، تنظیمات رو آزمایش کنه و بعد سرویس رو دوباره بارگذاری کنه.
اگه یکی از دو نسخه همین حالا با ۳۰۱ به نسخه اصلی میره و canonical، لینکهای داخلی و نقشه سایت هم هماهنگ هستن، تغییر اضافه لازم نیست. داشتن یا نداشتن اسلش مهمترین بخش ماجرا نیست؛ ثابت موندن نسخه اصلی و جلوگیری از چند مسیر متناقض مهمتره.
سؤالهای رایج درباره اسلش انتهای آدرس و وردپرس راکت
آیا وردپرس راکت همیشه اسلش انتهای آدرسها رو حذف میکنه؟
نه. رفتار نهایی به تنظیمات وردپرس، قوانین وردپرس راکت، نوع وبسرور و کش سمت سرور بستگی داره. هر دو نسخه URL رو آزمایش کنید و فقط بعد از جدا کردن این عاملها نتیجه بگیرید.
نمایش هر دو نسخه URL با کد ۲۰۰ برای سئو مشکلسازه؟
این وضعیت میتونه دو URL جدا با محتوای یکسان در اختیار موتور جستجو بذاره. بهتره یک نسخه اصلی انتخاب کنید و ریدایرکت ۳۰۱، canonical، لینکهای داخلی و نقشه سایت رو با همون نسخه هماهنگ نگه دارید.
canonical میتونه جای ریدایرکت ۳۰۱ رو بگیره؟
نه، این دو دقیقاً یک کار انجام نمیدن. canonical نسخه اصلی پیشنهادی رو به موتور جستجو نشون میده، ولی ریدایرکت ۳۰۱ کاربر و ربات رو به مقصد اصلی میفرسته. وقتی هر دو نسخه نباید جداگانه در دسترس باشن، هماهنگی این دو بهتره.
بعد از تغییر اسلش آدرسها باید نقشه سایت رو دوباره ثبت کنید؟
اگه نشانی نقشه سایت عوض نشده، معمولاً لازم نیست هر بار اون رو دوباره ثبت کنید. ولی باید مطمئن بشید URLهای داخل نقشه به نسخه اصلی جدید اشاره میکنن و سرچ کنسول میتونه نقشه رو بدون خطا بخونه.
چرا تغییرات بعد از پاک کردن کش هم دیده نمیشن؟
ممکنه پاسخ قدیمی در کش هاست، CDN، پراکسی معکوس یا مرورگر مونده باشه. احتمال دیگه اینه که قانون در لایه متفاوتی مثل NGINX اجرا بشه. همه کشها رو پاک کنید و نتیجه رو در حالت ناشناس همراه با کد پاسخ بررسی کنید.
برای تنظیم NGINX باید از پشتیبانی هاست کمک بگیرید؟
بله، برای بیشتر کاربران این کار امنتره. NGINX فایل .htaccess نداره و جای قانون در فایل تنظیمات سرور مهمه. پشتیبانی هاست میتونه درستی تنظیمات رو قبل از بارگذاری دوباره سرویس آزمایش کنه.

سلام و خسته نباشید
و با تشکر از آموزش هاتون
من یک مشکلی دارم در همین مورد ممنون میشم اگر بتونید کمک کنید
من در انتهای نامک سایتم در صفحات اسلش وجود داره ولی وقتی بدون اسلش میزنی ریدایرکت نمیشه به نامک اسلش دار و بدون اسلش نمایش داده میشه
فکر میکنم این موضع باعث میشه برای هر صفحه 2 عدد url وجود داشته باشه
این موضوع چطور قابل حله؟
تشکر
درود سپاس از شما. همین آموزش مشکل رو حل میشه.
سلام
ممنون که راه حل این مشکل رو پیدا کردین. اما من تنظیمات لینک ها رو بدون اسلش انتها گذاشتم و این کدی که دادین اجبار به گذاشتن اسلش میکنه. نمیشه کد رو طوری تغییر بدین که ریدایرکت به حالت بدون اسلش داشته باشه؟ ( منظورم اینه که کلا اسلش رو از ته لینکها برداره و اگه کسی اسلش اضافه کرد ریدایرکت بشه به حالت بدون اسلش )
با سلام
نه متاسفانه ساختار کد به شکلی هست که بدون اسلش ارور ۵۰۰ دریافت میکنید. خط آخر رو مطالعه بفرمایید
سلام . از صبح درگیر این موضوع بودم که بالاخره یه راه پیدا کردم. اونم استفاده از کد زیر هستش:
RewriteCond %{REQUEST_FILENAME} !-d
RewriteRule ^(.*)/$ /$1 [R=301,L]
این کد رو به اول فایل htaccess اضافه کردم و کار میکنه. بیزحمت شما هم چک کنید و اگه دارم درست میگم و برای سایت مشکلی پیش نمیاره تاییدش کنید و به مقالتون اضافه کنید. منتظر پاسختون هستم. با تشکر
سلام اگر خطای ۵۰۰ ایجاد نمیکنه و کار میکنه پس مشکلی نداره. ساختار کد مشکلی ندارد.