دسته بندی:

هاست وردپرس چیست و چه تفاوتی با هاست جنرال دارد؟

هاست وردپرس چیست و چه تفاوتی با هاست جنرال دارد؟

حدود ۱۳ دقیقه مطالعه

سایت وردپرسی که روی هاست نامناسب نشسته باشد، با هیچ افزونه‌ای درست نمی‌شود. صفحه‌ها دیر باز می‌شوند، پیشخوان کند است و همین که یک مطلب پربازدید می‌شود، خطای «Error establishing a database connection» یا محدودیت منابع بالا می‌آید. هاست وردپرس پاسخ همین مشکل است: سروری که به‌جای پشتیبانی از هر اسکریپت ممکن، فقط برای اجرای وردپرس تنظیم شده است.

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

مزایای خرید هاست وردپرس

با خرید هاست وردپرس، سایت شما سریع‌تر لود می‌شود و پایداری بیشتری دارد. دلیلش ساده است: در هاست‌های عمومی و جنرال، سرور باید انواع اسکریپت‌ها و سیستم‌های مدیریت محتوا را پشتیبانی کند و پر از پکیج‌ها و ماژول‌هایی است که سایت شما هرگز از آن‌ها استفاده نمی‌کند؛ همین هم منابع را مصرف می‌کند و هم سطح حمله (attack surface) را بزرگ‌تر می‌کند. روی سروری که فقط وردپرس روی آن اجرا می‌شود، تنها بسته‌ها و سرویس‌های موردنیاز وردپرس نصب‌اند و کل استک — از وب‌سرور تا کش و دیتابیس — حول همین یک نرم‌افزار تنظیم شده است. پاسخ سریع‌تر سرور هم برای کاربر و هم برای خزنده‌های گوگل اهمیت دارد؛ صفحه کند در Core Web Vitals امتیاز پایینی می‌گیرد و سروری که مرتب از دسترس خارج می‌شود بودجه خزش سایت را هدر می‌دهد. با این حال هاست فقط سقف سرعت را بالا می‌برد؛ قالب سنگین و تصاویر بهینه‌نشده را هیچ سروری جبران نمی‌کند.

نکته دیگر اینکه «تخصصی» لزوماً به معنای گران نیست؛ با توجه به امکاناتی که روی این پلن‌ها ارائه می‌شود، قیمت هاست‌های کانفیگ‌شده مخصوص وردپرس در عمل نزدیک به هاست اشتراکی هم‌رده است. مقایسه را روی مشخصات فنی هر پلن انجام دهید، نه روی برچسب آن.

تفاوت فنی هاست وردپرس با هاست جنرال

عبارت «کانفیگ‌شده برای وردپرس» اگر به مشخصات فنی ترجمه نشود، صرفاً یک شعار تبلیغاتی است. تفاوت واقعی در چهار جای مشخص است.

۱. وب‌سرور و لایه‌های کش

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

  • کش صفحه (Full-page cache): خروجی HTML آماده را ذخیره می‌کند تا PHP اصلاً اجرا نشود. در LiteSpeed و OpenLiteSpeed این کار داخل خود وب‌سرور و با افزونه LiteSpeed Cache انجام می‌شود، در Nginx با FastCGI Cache و در معماری‌های دیگر با Varnish جلوی وب‌سرور.
  • کش آبجکت (Object cache): Redis یا Memcached نتیجه کوئری‌های تکراری دیتابیس را نگه می‌دارد. این لایه دقیقاً همان‌جایی مفید است که کش صفحه کار نمی‌کند: پیشخوان، کاربران لاگین‌کرده و صفحه‌های سبد خرید ووکامرس.
  • OPcache: بایت‌کد کامپایل‌شده PHP را در حافظه نگه می‌دارد. این مورد سطح سرور است و اگر فعال نباشد، همه چیز کندتر است.

یک نکته که اغلب دردسر می‌سازد: کش صفحه باید برای کاربران لاگین‌کرده و صفحه‌های سبد خرید و تسویه‌حساب دور زده شود. اگر کوکی‌هایی مانند wordpress_logged_in_* و کوکی‌های سبد خرید در قوانین bypass لحاظ نشوند، ممکن است صفحه کاربر A به کاربر B نمایش داده شود. روی هاست تخصصی این قوانین از پیش تنظیم شده‌اند؛ روی هاست جنرالی که خودتان Varnish را جلوی آن گذاشته‌اید، این کار با شماست.

۲. نسخه PHP

این مهم‌ترین و در عین حال ارزان‌ترین بهبود ممکن است. نسخه‌های PHP 5.x، تمام شاخه‌های ۷٫x و همچنین PHP 8.0 و ۸٫۱ به پایان چرخه پشتیبانی امنیتی رسیده‌اند و دیگر وصله دریافت نمی‌کنند. PHP 8.2 هم فقط تا پایان ۲۰۲۶ وصله امنیتی می‌گیرد و پشتیبانی فعالش تمام شده است؛ بنابراین اگر امروز نسخه را عوض می‌کنید، هدف را روی PHP 8.3 یا بالاتر بگذارید. اما پیش از تغییر نسخه بدانید PHP 8 چند چیز را حذف کرده و قالب‌ها و افزونه‌های قدیمی با آن Fatal Error می‌دهند:

  • create_function() در PHP 8.0 حذف شده است؛ جای آن closure می‌نشیند.
  • each() در PHP 8.0 حذف شده و باید با foreach بازنویسی شود.
  • توابع mysql_* از PHP 7.0 حذف شده‌اند؛ جایگزین آن‌ها mysqli یا PDO است.
  • دسترسی به کاراکتر رشته با آکولاد (مثل $str{0}) در PHP 8.0 حذف شده و باید $str[0] نوشته شود.
  • بسیاری از مواردی که در PHP 7 فقط Warning بودند در PHP 8 به خطای کشنده تبدیل شده‌اند؛ مثل مقداردهی به یک ویژگی روی متغیری که شیء نیست، یا استفاده از یک مقدار اسکالر به‌عنوان آرایه.

روش درست این است که اول روی یک نسخه آزمایشی سایت نسخه PHP را بالا ببرید و لاگ خطا را بررسی کنید، بعد روی سایت اصلی اعمال کنید. نسخه فعلی PHP را از مسیر «ابزارها ← سلامت سایت ← اطلاعات ← سرور» در پیشخوان ببینید؛ ساختن فایل phpinfo.php در پوشه عمومی سایت کار درستی نیست و اگر ساختید بلافاصله حذفش کنید.

۳. لیمیت‌هایی که وردپرس واقعاً به آن‌ها حساس است

  • memory_limit — وردپرس به‌طور پیش‌فرض خودش را به ۴۰ مگابایت (و در حالت مالتی‌سایت ۶۴ مگابایت) محدود می‌کند، مگر اینکه در wp-config.php تغییرش دهید.
  • max_input_vars — مقدار پیش‌فرض ۱۰۰۰ است و علت کلاسیک «ذخیره نشدن منوی بزرگ» یا «برگشتن تنظیمات قالب» همین است، آن هم بدون هیچ پیام خطایی.
  • upload_max_filesize و post_max_size — سقف حجم فایل قابل آپلود در کتابخانه رسانه؛ دومی باید بزرگ‌تر یا مساوی اولی باشد.
  • max_execution_time — برای ایمپورت محتوا، بکاپ‌گیری و به‌روزرسانی افزونه‌های سنگین لازم است.

افزایش حافظه وردپرس در wp-config.php و بالاتر از خط /* That's all, stop editing! */ نوشته می‌شود:

define( 'WP_MEMORY_LIMIT', '256M' );
define( 'WP_MAX_MEMORY_LIMIT', '512M' );

این دو ثابت فقط وقتی اثر دارند که هاست اجازه بالا بردن memory_limit را در زمان اجرا بدهد. روی بسیاری از سرورهای اشتراکی این کار با تنظیمات سطح سرور قفل شده است؛ در آن حالت هرچه اینجا بنویسید نادیده گرفته می‌شود و باید از پشتیبانی هاست بخواهید سقف PHP اکانت را بالا ببرد.

۴. کرون‌جاب واقعی به‌جای WP-Cron

وردپرس زمان‌بند داخلی خودش را با هر بازدید صفحه اجرا می‌کند. روی سایت پربازدید یعنی هدررفت منابع و روی سایت کم‌بازدید یعنی زمان‌بندی‌ها اصلاً اجرا نمی‌شوند. راه‌حل استاندارد، خاموش کردن آن و سپردن کار به کرون سیستم است. این خط هم بالاتر از /* That's all, stop editing! */ می‌رود:

define( 'DISABLE_WP_CRON', true );

و سپس در بخش Cron Jobs کنترل‌پنل:

*/5 * * * * /usr/local/bin/php /home/USER/public_html/wp-cron.php >/dev/null 2>&1

ترتیب کار مهم است: اول کرون سیستمی را بسازید و از اجرا شدنش مطمئن شوید، بعد WP-Cron را خاموش کنید. اگر برعکس عمل کنید و کرون سیستمی به هر دلیلی کار نکند، همه زمان‌بندی‌های سایت — از انتشار زمان‌بندی‌شده مطالب تا به‌روزرسانی‌های خودکار و ارسال ایمیل‌های افزونه‌ها — بی‌سروصدا متوقف می‌شود.

مسیر باینری PHP هم روی هر سرور فرق می‌کند: روی cPanel معمولاً /usr/local/bin/php است، روی بعضی سرورها /usr/bin/php و در برخی پلن‌ها باید نسخه مشخصی مثل ea-php83 را صدا بزنید. اگر دسترسی SSH دارید با which php مسیر درست را پیدا کنید، وگرنه از پشتیبانی بپرسید. پس از ساختن کرون، چند دقیقه بعد بررسی کنید که واقعاً اجرا شده باشد.

بکاپ خودکار و چیزی که معمولاً فراموش می‌شود

یک بکاپ کامل وردپرس دو بخش دارد و هر دو لازم است: دیتابیس (محتوا، تنظیمات، کاربران) و فایل‌ها، به‌ویژه پوشه wp-content که قالب، افزونه‌ها و کتابخانه رسانه در آن است. اگر SSH دارید، نسخه دستی به این شکل گرفته می‌شود:

mkdir -p ~/backup
mysqldump -u DB_USER -p DB_NAME > ~/backup/db-$(date +%F).sql
tar -czf ~/backup/files-$(date +%F).tar.gz -C ~/public_html wp-content

دو هشدار درباره همین دو خط. اول اینکه رمز دیتابیس را با -p تنهای بدون مقدار بدهید تا در تاریخچه شل و در لیست پروسه‌ها ذخیره نشود. دوم و مهم‌تر اینکه فایل بکاپ را هرگز داخل public_html نگذارید؛ یک فایل .sql در مسیر عمومی یعنی کل دیتابیس شما — با ایمیل و هش رمز کاربران — برای هرکسی که آدرسش را حدس بزند قابل دانلود است. مسیر ~/backup در نمونه بالا بیرون از پوشه عمومی است و باید همان‌طور بماند.

سه نکته تفاوت بکاپ واقعی و بکاپ کاغذی را می‌سازد. اول اینکه نسخه پشتیبان نباید فقط روی همان سرور بماند؛ اگر دیسک یا خود اکانت از دست برود، بکاپ هم با آن می‌رود. دوم اینکه بکاپ بازیابی‌نشده بکاپ نیست؛ حداقل یک بار روی یک زیردامنه یا سایت محلی بازگردانی‌اش کنید. سوم اینکه سیاست نگه‌داری مشخص داشته باشید: اگر سایت هک شود و فقط بکاپ دیروز را داشته باشید، احتمالاً نسخه آلوده را بازیابی می‌کنید، پس چند نسخه با فاصله زمانی نگه دارید.

امنیت لایه سرور در برابر امنیت خود وردپرس

هاست وردپرس مجهز به فایروال و آنتی‌ویروس به‌روز است و فایل‌های کانفیگ هر هاست از هاست دیگر جداست؛ این جداسازی احتمال سرایت یک نفوذ از یک اکانت به اکانت‌های دیگر روی سرور اشتراکی را به‌شدت کم می‌کند، هرچند هیچ جداسازی‌ای صددرصد نیست. اما این نیمی از ماجراست؛ بیشتر هک شدن سایت‌های وردپرسی از افزونه یا قالب آسیب‌پذیر و رمز عبور ضعیف مدیر شروع می‌شود، نه از رخنه در وب‌سرور. بنابراین ایمن‌سازی خود وردپرس بر عهده شماست: به‌روزرسانی مرتب هسته و افزونه‌ها، حذف (نه فقط غیرفعال کردن) افزونه‌ها و قالب‌های بلااستفاده، ورود دومرحله‌ای و پرهیز از نسخه‌های نال‌شده.

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

define( 'DISALLOW_FILE_EDIT', true );

دوم، جلوگیری از اجرای PHP در پوشه آپلودها؛ مسیر رایج نفوذ این است که یک شل با پسوند PHP در wp-content/uploads آپلود شود. در Apache 2.4 — نسخه‌ای که امروز روی سرورها اجرا می‌شود — یک فایل .htaccess داخل همان پوشه با این محتوا بسازید:

<FilesMatch ".(?:php[0-9]*|phtml|phar)$">
    Require all denied
</FilesMatch>

بعد از ساختن این فایل، یک بار سایت و پیشخوان را باز کنید و مطمئن شوید چیزی نشکسته است. اگر خطای ۵۰۰ گرفتید، فایل .htaccess را حذف کنید تا سایت برگردد و بعد علت را بررسی کنید.

اگر در راهنماهای قدیمی به نحو زیر برخوردید، آن مربوط به Apache 2.2 است؛ شاخه‌ای که آخرین نسخه‌اش در سال ۲۰۱۷ منتشر شد و دیگر پشتیبانی نمی‌شود. این نحو روی Apache 2.4 بدون ماژول mod_access_compat کار نمی‌کند و می‌تواند خطای ۵۰۰ بدهد:

<Files *.php>
    Order Deny,Allow
    Deny from all
</Files>

روی Nginx فایل .htaccess اصلاً خوانده نمی‌شود و معادل آن در کانفیگ سایت نوشته می‌شود:

location ~* /wp-content/uploads/.*.php$ {
    deny all;
}

سه شرط برای اینکه این بلوک واقعاً کار کند: باید داخل بلوک server همان سایت باشد، باید پیش از بلوک عمومی location ~ .php$ نوشته شود (Nginx اولین بلوک regex منطبق را انتخاب می‌کند و اگر بعد از آن بیاید هرگز اجرا نمی‌شود)، و پیش از ری‌لود حتماً کانفیگ را با nginx -t تست کنید؛ ری‌لود با کانفیگ خراب می‌تواند وب‌سرور را پایین بیاورد. این تغییر دسترسی root می‌خواهد و روی هاست اشتراکی باید از پشتیبانی درخواستش کنید.

کنترل‌پنل و دستورهایی که عوض شده‌اند

درباره کنترل‌پنل یک اصلاح لازم است: در فهرست‌های قدیمی این سرویس نام Kloxo (کلوکسو) آمده بود. توسعه Kloxo و ادامه‌دهنده‌اش Kloxo-MR سال‌هاست متوقف شده و روی سرور جدید نباید از آن استفاده کرد. Webmin هم در عمل ابزار مدیریت سیستم است نه کنترل‌پنل هاستینگ؛ لایه هاستینگ آن Virtualmin است. کنترل‌پنل‌هایی که امروز فعالانه نگه‌داری و وصله می‌شوند cPanel و DirectAdmin هستند. برای اینکه بدانید هر پلن با کدام کنترل‌پنل ارائه می‌شود، مشخصات همان پلن را در صفحه محصول ببینید یا پیش از خرید از پشتیبانی بپرسید.

اگر روی سرور مجازی یا اختصاصی خودتان کار می‌کنید، دستورهای آموزش‌های قدیمی هم عوض شده‌اند. روی همه توزیع‌های امروزی (AlmaLinux، Rocky Linux، Ubuntu، Debian) مدیریت سرویس‌ها با systemctl انجام می‌شود و service httpd restart یا /etc/init.d/httpd restart منسوخ‌اند:

# AlmaLinux / Rocky Linux — کانفیگ در /etc/httpd/
systemctl restart httpd

# Ubuntu / Debian — کانفیگ در /etc/apache2/
systemctl restart apache2

ضمناً CentOS 7 در ژوئن ۲۰۲۴ و CentOS 8 پیش از آن به پایان عمر رسیده‌اند؛ اگر هنوز روی آن‌ها هستید، مهاجرت به AlmaLinux یا Rocky Linux یک ضرورت امنیتی است، نه یک بهبود اختیاری. این مهاجرت را روی سرور زنده و بدون آمادگی شروع نکنید: اول اسنپ‌شات یا بکاپ کامل بگیرید و اگر ابزار تبدیل درجا را اجرا می‌کنید، مطمئن شوید راه بازگشت دارید.

انتخاب پلن بر اساس ترافیک

«چند بازدید در ماه» به‌تنهایی معیار بدی است، چون ۱۰۰ هزار بازدید یک وبلاگ با ۱۰ هزار بازدید یک فروشگاه ووکامرس اصلاً یک مقدار منابع مصرف نمی‌کند. معیارهای واقعی اینها هستند:

  • نسبت درخواست‌های قابل کش: در وبلاگ و سایت شرکتی بیشتر بازدیدکننده‌ها مهمان‌اند و کش صفحه تقریباً همه ترافیک را جواب می‌دهد. در فروشگاه و سایت عضویت‌محور کاربر لاگین می‌کند و کش صفحه دور زده می‌شود؛ آنجا تعداد PHP worker و توان دیتابیس تعیین‌کننده است.
  • همزمانی، نه مجموع ماهانه: آنچه سرور را زمین می‌زند بیشترین تعداد کاربر همزمان در ساعت اوج است. اگر کمپین تبلیغاتی یا خبرنامه دارید، همان چند دقیقه را مبنا بگیرید.
  • حجم دیتابیس و تعداد فایل: جدول wp_options پر از داده autoload و کتابخانه رسانه چند ده هزار فایلی، هر دو روی مصرف منابع و سرعت بکاپ اثر مستقیم دارند.

عدد خودتان را اندازه بگیرید: کاربران همزمان ساعت اوج را از Google Analytics یا Matomo بردارید، حجم فایل‌ها را با du -sh ~/public_html و حجم دیتابیس را از phpMyAdmin ببینید و مصرف منابع اکانت را در کنترل‌پنل رصد کنید. اگر مرتب به سقف CPU یا Entry Process می‌خورید، ارتقای پلن اشتراکی معمولاً مشکل را حل می‌کند؛ اگر به ماژول اختصاصی، نسخه خاص نرم‌افزار یا دسترسی root نیاز دارید، وقت رفتن به سرور مجازی یا اختصاصی است.

چه زمانی هاست وردپرس انتخاب درستی نیست؟

  • وقتی سایت شما وردپرسی نیست یا قرار است چند اسکریپت مختلف (جوملا، اپلیکیشن Node.js، سیستم اختصاصی) را در یک اکانت اجرا کنید. سروری که فقط برای وردپرس تنظیم شده برای بقیه محدودکننده است و هاست جنرال گزینه بهتری است.
  • وقتی به دسترسی root، نصب ماژول دلخواه یا کانفیگ سفارشی وب‌سرور نیاز دارید؛ این کار روی هاست اشتراکی — هرچقدر هم تخصصی — شدنی نیست.
  • وقتی مشکل واقعی سایت هاست نیست. اگر ۴۵ افزونه فعال دارید، قالب چندمنظوره سنگین استفاده می‌کنید و تصاویر ۳ مگابایتی آپلود می‌کنید، جابه‌جایی هاست فقط مشکل را با هزینه بیشتر جابه‌جا می‌کند. اول افزونه‌های بلااستفاده را حذف و تصاویر را بهینه کنید.

چطور مطمئن شویم واقعاً بهتر شده است؟

قبل و بعد از انتقال همین چند عدد را بگیرید تا قضاوت‌تان بر اساس حس نباشد. زمان رسیدن اولین بایت (TTFB) بهترین شاخص برای سنجش خود سرور است و هدرهای پاسخ نشان می‌دهند کش صفحه واقعاً کار می‌کند یا نه (در درخواست دوم باید نشانه HIT دیده شود):

curl -s -o /dev/null -w "TTFB: %{time_starttransfer}s | total: %{time_total}sn" https://example.com/
curl -s -o /dev/null -D - https://example.com/ | grep -i -E "x-litespeed-cache|x-cache|cf-cache-status|^age:"

در دستور دوم عمداً از -I استفاده نشده است؛ درخواست HEAD در بعضی لایه‌های کش مثل یک درخواست عادی رفتار نمی‌کند و نتیجه گمراه‌کننده می‌دهد. هر دو دستور فقط می‌خوانند و چیزی روی سرور تغییر نمی‌دهند.

در کنار این، سلامت خود وردپرس را هم بررسی کنید: در «ابزارها ← سلامت سایت» نسخه PHP، وضعیت HTTPS و ماژول‌های نصب‌نشده را می‌بینید. اگر WP-CLI در دسترس است، wp core verify-checksums دست‌کاری فایل‌های هسته را نشان می‌دهد و wp plugin list --update=available افزونه‌های به‌روزنشده را فهرست می‌کند.

جمع‌بندی

هاست وردپرس یعنی سروری که لایه کش، نسخه PHP، لیمیت‌ها، کرون و قوانین امنیتی‌اش از قبل برای وردپرس تنظیم شده باشد، نه صرفاً یک برچسب روی همان پلن قبلی. پیش از خرید این چند مورد را بپرسید: وب‌سرور و نوع کش صفحه چیست، Redis یا Memcached در دسترس هست، چه نسخه‌هایی از PHP قابل انتخاب‌اند، بکاپ خودکار با چه دوره‌ای و روی چه محلی گرفته می‌شود و کنترل‌پنل کدام است. برای مشخصات و قیمت به‌روز هر پلن صفحه خرید هاست را ببینید و اگر شک داشتید، سناریوی سایت خودتان (نوع سایت، ترافیک ساعت اوج، لاگین‌محور بودن یا نبودن) را برای پشتیبانی توضیح دهید تا پلن درست پیشنهاد شود.

آموزش‌های مرتبط

خدمات مرتبط آنلاین سرور