قطعه کد حذف نسخه وردپرس از سایت

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

داستان نسخه‌ای که همه می‌توانند ببینند

وردپرس، به‌طور پیش‌فرض، نسخهٔ خودش را در چند نقطهٔ مختلف سایت اعلام می‌کند: در متاتگ‌های هدر HTML، در فایل‌های CSS و JS به‌عنوان query string، در فیدهای RSS، و در چند مسیر دیگر. دلیل این کار، در نگاه اول منطقی است: ابزارهای پایش و توسعه‌دهنده‌ها بتوانند نسخهٔ سایت را به‌سادگی شناسایی کنند. اما همین سادگی، باعث می‌شود هر ربات یا مهاجم ساده‌ای هم بتواند نسخهٔ شما را در چند ثانیه ببیند و براساس آن تصمیم بگیرد.

منطق رایج توصیهٔ «حذف نسخه» این است: اگر نسخهٔ شما لو نرود، مهاجم نمی‌داند روی چه نسخه‌ای از وردپرس هستید و نمی‌تواند آسیب‌پذیری‌های شناخته‌شدهٔ آن نسخه را هدف بگیرد. این منطق، در نگاه اول قانع‌کننده است، ولی در سطح فنی، چند نکتهٔ پنهان دارد که در ادامه به آن‌ها می‌پردازیم. تجربهٔ من در پروژه‌های واقعی این است که حذف نسخه، ابزار مفیدی است ولی اگر به‌جای استراتژی امنیتی کامل، خودش هدف شود، می‌تواند باعث غفلت از خطرات بزرگ‌تر شود. مبانی کلی این تفکر را در راهنمای امنیت وردپرس برای مبتدیان با جزئیات آورده‌ام.

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

نسخهٔ وردپرس دقیقاً کجا لو می‌رود؟

پیش از هر تغییری، باید بدانید نسخهٔ شما در چه نقاطی از سایت قابل‌مشاهده است. در تجربهٔ چند‌سالهٔ خودم، پنج مسیر اصلی را شناسایی کرده‌ام:

پنج مسیر بالا، در نگاه اول ساده به‌نظر می‌رسند ولی هرکدام یک نکتهٔ ظریف دارند. مثلاً query string روی فایل‌های CSS/JS، که خودش هم به دلایل کش مدیریت می‌شود و حذفش می‌تواند روی بهینگی سایت اثر بگذارد. نکتهٔ دیگری که زیاد دیده‌ام: هدر X-Powered-By از سمت PHP می‌آید، نه از وردپرس؛ حذفش نیاز به تنظیم در سطح سرور یا فایل php.ini دارد، نه یک اسنیپت PHP ساده. اگر با تنظیمات سرور آشنایی کمتری دارید، امن‌سازی فایل wp-config در وردپرس و هاست چیست و چگونه انتخاب درستی داشته باشیم را پیشنهاد می‌کنم.

نکتهٔ چهارم، فایل readme.html، در تجربهٔ من پرمخاطب‌ترین نکته و در عین حال ساده‌ترین موردی است که اکثر مدیران نادیده می‌گیرند. این فایل به‌طور پیش‌فرض در ریشهٔ سایت قرار می‌گیرد و نسخهٔ وردپرس را اعلام می‌کند. راه‌حل: حذف این فایل یا محدودسازی دسترسی به آن از طریق .htaccess. این کار در یکی از مقالات آینده که به‌عنوان مقالهٔ تکمیلی پیشنهاد می‌کنم، با جزئیات باز می‌شود.

حذف نسخه دقیقاً چه چیزی را پنهان می‌کند؟

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

اول، نسخه از راه‌های غیرمستقیم هم قابل‌حدس است. هر نسخهٔ وردپرس، فایل‌های CSS و JS پیش‌فرض مشخصی دارد که محتوایشان در هر نسخه کمی تغییر می‌کند. مهاجم حرفه‌ای می‌تواند از محتوای این فایل‌ها، نسخه را تخمین بزند. همچنین برخی افزونه‌ها و قالب‌های خاص، در نسخه‌های مشخصی از وردپرس استفاده می‌شوند. پس حذف نسخه، جلوی مهاجم حرفه‌ای را نمی‌گیرد.

دوم، حملات رباتیک عموماً نسخه‌محور نیستند. بیشتر حملات خودکار به وردپرس، بر اساس آسیب‌پذیری‌های شناخته‌شده کار می‌کنند و تمام سایت‌های وردپرسی را یک‌جا اسکن می‌کنند، بدون توجه به نسخه. یعنی حتی اگر نسخهٔ شما پنهان باشد، ربات همچنان سایت شما را امتحان می‌کند و اگر آسیب‌پذیری‌ای در افزونه یا قالب شما باشد، آن را هدف می‌گیرد. توضیح جامع‌تر این دستهٔ حملات در جلوگیری از حملات Brute Force در وردپرس و بدافزار چیست و چگونه وارد سایت می‌شود آمده است.

سوم، ارزش اصلی در کاهش «سطح حمله» است، نه در تأمین امنیت. اصطلاح «attack surface» یا سطح حمله، در امنیت نرم‌افزار یعنی مجموعهٔ نقاطی که مهاجم می‌تواند از آن‌ها شروع کند. حذف نسخه، سطح حمله را به‌اندازهٔ کوچکی کاهش می‌دهد، ولی این کاهش، فقط در برابر حملات هدفمند و کم‌تعداد اثر دارد، نه در برابر حملات انبوه.

بنابراین، حذف نسخه را باید یک «تمرین بهداشتی» در نظر بگیریم، نه یک «اقدام امنیتی اصلی». این تمرین ارزشمند است ولی جای خودش را دارد و نباید با لایه‌های اصلی امنیت اشتباه گرفته شود.

ساده‌ترین اسنیپت: حذف generator از هدر

ساده‌ترین و پرکاربردترین اسنیپت حذف نسخه، با استفاده از هوک init و تابع remove_action نوشته می‌شود:

add_action( 'init', 'wphk_remove_wp_version_generator' );

function wphk_remove_wp_version_generator() {
    remove_action( 'wp_head', 'wp_generator' );
}

سه نکتهٔ کلیدی در همین کد سه‌خطی. اول، استفاده از هوک init؛ چرا که در این لحظه، هستهٔ وردپرس تابع wp_generator را به wp_head متصل کرده و ما می‌توانیم آن را حذف کنیم. اگر این کد را در هوک دیرتری اجرا کنید، ممکن است remove_action موفق نشود. دوم، نام‌گذاری با پیشوند اختصاصی wphk_ برای جلوگیری از تعارض با افزونه‌های دیگر. سوم، این تابع هیچ مقدار بازگشتی ندارد چون Action است، نه Filter؛ تفاوت این دو در تفاوت Action و Filter در وردپرس چیست با مثال توضیح داده شده است.

اگر می‌خواهید حذف نسخه را در همان هوکی انجام دهید که خود وردپرس برای این کار استفاده می‌کند، می‌توانید از یک رویکرد جایگزین استفاده کنید و اولویت را کمی تغییر دهید:

add_action( 'init', 'wphk_remove_wp_version_generator', 20 );

اولویت ۲۰ به این معناست که کد شما بعد از افزونه‌های دیگر اجرا می‌شود و بنابراین اگر افزونه‌ای به‌طور تصادفی تابع wp_generator را دوباره اضافه کرده، حذف شما بعد از آن اعمال می‌شود. این نکته، در پروژه‌هایی که چند افزونهٔ امنیتی نصب دارند، ارزش مهمی دارد. برای مطالعهٔ بیشتر در مورد مدیریت اولویت، Priority در هوک‌های وردپرس چیست مرجع کاملی است.

اسنیپت کامل‌تر: پوشش فید، اسکریپت و استایل

حذف نسخه از هدر HTML، فقط یک بخش از کار است. نسخهٔ وردپرس در فید RSS و در query string فایل‌های CSS/JS هم لو می‌رود. برای پوشش کامل، از اسنیپت زیر استفاده می‌کنم:

/**
 * Snippet: Hide WordPress version everywhere.
 *
 * @since 2026-09-16
 * @author WordPressKar
 *
 * Purpose: Remove WP version from head, RSS feed, and asset query strings.
 * Location: mu-plugins directory or child theme functions.php.
 * Notes: Does not affect WordPress core updates or security patches.
 */

// 1. حذف نسخه از هدر HTML
add_action( 'init', 'wphk_hide_wp_version_head' );

function wphk_hide_wp_version_head() {
    remove_action( 'wp_head', 'wp_generator' );
}

// 2. حذف نسخه از فید RSS
add_filter( 'the_generator', 'wphk_hide_wp_version_feed' );

function wphk_hide_wp_version_feed( $generator ) {
    return '';
}

// 3. حذف query string نسخه از فایل‌های CSS و JS
add_filter( 'script_loader_src', 'wphk_remove_version_query', 15 );
add_filter( 'style_loader_src', 'wphk_remove_version_query', 15 );

function wphk_remove_version_query( $src ) {
    if ( strpos( $src, 'ver=' ) !== false ) {
        $src = remove_query_arg( 'ver', $src );
    }
    return $src;
}

سه نکتهٔ مهم در این اسنیپت کامل. اول، بخش دوم با هوک the_generator انجام می‌شود که یک Filter است و تگ <generator> در فید را به رشتهٔ خالی تبدیل می‌کند. بازگشت رشتهٔ خالی در اینجا درست است چون هدف حذف کامل آن تگ است. دوم، بخش سوم برای فایل‌های CSS و JS با دو فیلتر script_loader_src و style_loader_src انجام می‌شود. سوم، استفاده از remove_query_arg که تابع استاندارد وردپرس برای حذف یک پارامتر از URL است. برای مطالعهٔ بیشتر در مورد این نوع فیلترها، مهم‌ترین Filter Hook های وردپرس و نحوه استفاده از add_filter در وردپرس مراجع کاملی هستند.

یک تذکر مهم در مورد بخش سوم: حذف query string از فایل‌های CSS و JS می‌تواند روی کش مرورگر اثر بگذارد. اگر سایت شما از کش مرورگر با زمان طولانی استفاده می‌کند، کاربران ممکن است نسخهٔ قدیمی فایل‌ها را ببینند. راه‌حل: به‌جای حذف کامل، از یک روش جایگزین مثل تغییر نام فایل با هش استفاده کنید، یا از فایل‌های با نام‌گذاری نسخه‌ای (مثل style.v3.css) بهره ببرید. توضیح دقیق‌تر این تصمیم در بهترین افزونه‌های کش وردپرس آمده است.

فایل readme.html و متاتگ‌های پنهان

یکی از مسیرهایی که در پوشش کامل اسنیپت بالا جا نمی‌ماند، فایل readme.html در ریشهٔ سایت است. این فایل به‌طور پیش‌فرض نسخهٔ وردپرس را اعلام می‌کند و اگر مستقیماً به آن دسترسی پیدا شود، نسخهٔ سایت قابل‌مشاهده است. سه راه برای حل این مشکل وجود دارد:

روش اول: حذف فایل. ساده‌ترین کار، حذف فایل readme.html از ریشهٔ سایت است. توجه: این فایل با هر آپدیت وردپرس دوباره بازمی‌گردد، بنابراین پس از هر آپدیت باید دوباره حذفش کنید. اگر با ابزار FTP آشنایی ندارید، cPanel چیست و چه کاربردی دارد و چگونه فضای cPanel را آزاد کنیم مراجع خوبی هستند.

روش دوم: محدودسازی دسترسی با .htaccess. اگر فایل را نگه می‌دارید، می‌توانید دسترسی مستقیم به آن را مسدود کنید:

# در فایل .htaccess
<Files "readme.html">
    Require all denied
</Files>

این روش، فایل را نگه می‌دارد ولی دسترسی به آن را مسدود می‌کند. کاربر عادی نمی‌تواند آن را ببیند و در عین حال، وردپرس از این فایل هیچ‌وقت استفاده نمی‌کند. اگر با .htaccess آشنایی کمتری دارید، فایل htaccess چیست و چه کاربردی دارد مرجع کاملی است.

روش سوم: نادیده‌گرفتن. صادقانه بگویم: از نظر ارزش امنیتی، این فایل کم‌ترین اهمیت را دارد. حذف یا نگه‌داشتن آن تفاوت محسوسی در تجربهٔ امنیتی سایت شما نمی‌سازد. توصیهٔ من: اگر می‌خواهید کامل باشید، حذفش کنید؛ ولی این کار نباید اولویت اصلی امنیتی شما باشد.

ارزش واقعی: این کار چه چیزی را حل می‌کند و چه چیزی را نه

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

واقعیت اول: حذف نسخه، جلوی مهاجم حرفه‌ای را نمی‌گیرد

مهاجم حرفه‌ای، از ابزارهای تشخیص خودکار استفاده می‌کند که نسخهٔ وردپرس شما را حتی با حذف متاتگ، از الگوهای رفتاری و محتوای فایل‌ها تخمین می‌زند. حذف نسخه، ابزار شما در برابر کنجکاوهای سطح پایین است، نه در برابر یک مهاجم جدی. اگر می‌خواهید در برابر مهاجم جدی محافظت کنید، باید به لایه‌های اصلی امنیت فکر کنید که در ادامه می‌آید.

واقعیت دوم: ارزش اصلی، در ترکیب با سایر لایه‌هاست

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

واقعیت سوم: برای سایت‌های کوچک، ارزش کمی دارد

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

اما برای سایت‌های متوسط و بزرگ — سایت‌های فروشگاهی، سایت‌های شرکتی با دادهٔ مشتری، سایت‌های آموزشی با اطلاعات کاربران — پنهان‌کردن نسخه می‌تواند به‌عنوان بخشی از استراتژی «کاهش سطح حمله» ارزش داشته باشد. در این حالت، حذف نسخه یک اقدام کوچک است که همراه با لایه‌های اصلی، تصویر کلی امنیت را کامل‌تر می‌کند.

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

اگر هدف امنیت است، این‌ها مهم‌تر از پنهان‌کردن نسخه‌اند

اگر هدف واقعی شما امنیت است — نه فقط ظاهر امنیتی — این فهرست را در اولویت بالاتری از حذف نسخه قرار دهید:

1. به‌روزرسانی منظم وردپرس، قالب و افزونه‌ها: بیشترین آسیب‌پذیری‌های واقعی، از نسخه‌های قدیمی افزونه‌ها و قالب‌ها می‌آید، نه از نسخهٔ قدیمی وردپرس. اگر این بخش را جدی نگیرید، حذف نسخه فقط تئاتر است. مقالهٔ بهترین افزونه‌های امنیتی نکات خوبی در این باره دارد.
2. احراز هویت دو مرحله‌ای برای مدیران: اگر رمز مدیر شما افشا شود، هیچ حذف نسخه‌ای نمی‌تواند جلوی مهاجم را بگیرد. 2FA این لایه را می‌بندد. راهنمای عملی در فعال‌سازی 2FA برای کاربران وردپرس و تأثیر احراز هویت دو مرحله‌ای بر امنیت.
3. محدودسازی تلاش‌های ورود: بدون این لایه، حملهٔ Brute Force می‌تواند در چند ساعت رمز را بشکند. توضیحات در جلوگیری از حملات Brute Force در وردپرس.
4. بکاپ منظم و تست‌شده: حتی اگر همهٔ لایه‌ها شکست بخورد، بکاپ سالم می‌تواند سایت شما را نجات دهد. راهنمای کامل در چگونه از سایت وردپرسی بکاپ بگیریم و بهترین افزونه‌های پشتیبان‌گیری وردپرس.
5. اسکن دوره‌ای بدافزار: حتی با همهٔ محافظت‌ها، اسکن منظم می‌تواند بدافزارهای پنهان را کشف کند. ابزارها در بهترین ابزارهای اسکن بدافزار.
6. مدیریت رمز عبور امن: استفاده از رمز یکتا برای هر حساب و مدیریت متمرکز رمزها، پایه‌ای‌ترین لایه است. اصول آن در اصول مدیریت رمز عبور امن.

اگر این شش لایه را درست پیاده کنید، حذف نسخه به یک لایهٔ تکمیلی تبدیل می‌شود که ارزش خودش را دارد. اگر این لایه‌ها را نداشته باشید، حذف نسخه فقط یک حس کاذب امنیت می‌سازد که می‌تواند خطرناک‌تر از نداشتنش باشد.

محل درست قرارگیری این اسنیپت

مانند همهٔ اسنیپت‌ها، محل قرارگیری این کد هم تصمیم مهمی است. سه گزینه پیش روی شماست، ولی برای این اسنیپت خاص، توصیهٔ من واضح‌تر از موارد دیگر است.

گزینهٔ اول: افزونهٔ اختصاصی یا mu-plugins. این گزینه را برای این اسنیپت توصیه می‌کنم. دلیل: اسنیپت حذف نسخه، بخشی از استراتژی امنیتی سایت است و باید در همهٔ قالب‌ها پایدار بماند. اگر در چایلد تم باشد، با تعویض قالب از بین می‌رود و ممکن است کسی متوجه نشود. اگر با ساختار افزونهٔ اختصاصی آشنا نیستید، کدنویسی اختصاصی برای افزونه وردپرس و ساختار فایل‌های یک افزونه استاندارد وردپرس مراجع کاملی هستند.

گزینهٔ دوم: چایلد تم. اگر پروژهٔ شما ساده است و نمی‌خواهید افزونهٔ اختصاصی بسازید، چایلد تم گزینهٔ قابل‌قبولی است. ولی در نظر بگیرید که این اسنیپت بخشی از امنیت سایت است، نه ظاهر آن؛ بنابراین جای طبیعی‌اش افزونه است، نه قالب. تفاوت‌ها و کاربردهای چایلد تم در قالب وردپرس چایلد چیست و چه زمانی به آن نیاز داریم.

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

در پروژه‌های خودم، این اسنیپت را در یک افزونهٔ اختصاصی به نام «امنیت پایه» نگه می‌دارم که شامل چند اسنیپت کوچک دیگر هم هست: غیرفعال‌سازی ویرایش فایل، حذف نسخه، محدودسازی برخی نقاب‌های حساس. این ساختار، به من اجازه می‌دهد در هر پروژه، افزونهٔ کوچک را کپی کنم و امنیت پایه را فعال کنم. برای نمونه‌های مشابه، قطعه کد غیرفعال کردن ویرایش فایل وردپرس را ببینید.

اشتباهات رایج در حذف نسخهٔ وردپرس

در بازبینی سایت‌های مختلف، شش اشتباه تکراری در این حوزه را دیده‌ام که هرکدام درس‌آموز است:

هرکدام از این موارد را در پروژه‌ای دیده‌ام و هزینه‌اش را یا مشتری پرداخت کرده یا توسعه‌دهندهٔ بعدی. برای مرور عمومی این نوع اشتباهات، اشتباهات رایج هنگام استفاده از قطعه کد وردپرس و اشتباهات رایج امنیتی وردپرس مراجع جامعی هستند.

دو پروندهٔ واقعی از پروژه‌ها

برای این‌که این اصول انتزاعی نمانند، دو پروندهٔ واقعی از تجربهٔ خودم را مرور می‌کنم — بدون جزئیات هویتی، ولی با ساختار دقیق مشکل و راه‌حل.

پروندهٔ اول: سایتی که نسخه‌اش را حذف کرده بود ولی هک شد

در پروژه‌ای برای یک شرکت کوچک، تیم فنی قبلی تمام لایه‌های حذف نسخه را پیاده کرده بود — حتی هدر X-Powered-By را هم حذف کرده بود. با این حال، سایت هک شد و مجبور شدیم پاک‌سازی کامل انجام دهیم. بررسی نشان داد که علت، یک افزونهٔ قدیمی بود که به‌دلیل ناسازگاری با نسخهٔ جدید وردپرس، آپدیت نشده بود و مهاجم از یک آسیب‌پذیری شناخته‌شده در آن بهره برد. درس بزرگ این پرونده: حذف نسخه، سطح حمله را در لایهٔ بسیار کوچکی کاهش می‌دهد، ولی اگر لایه‌های اصلی (به‌روزرسانی، اسکن، بکاپ) نباشند، این کار ارزش واقعی‌اش را از دست می‌دهد. مسیر پاک‌سازی این نوع مشکل در راهنمای پاک‌سازی سایت وردپرسی هک شده آمده است.

پروندهٔ دوم: سایتی که با حذف نسخه، سرعتش افت کرد

در پروژه‌ای دیگر، تیم فنی قبلی اسنیپت حذف نسخه را بدون توجه به کش پیاده کرده بود. نتیجه: در صفحهٔ سرعت، LCP به‌طور محسوس افزایش پیدا کرده بود، چون کاربران با هر بازدید، نسخهٔ جدید فایل‌های CSS و JS را دانلود می‌کردند که کش مرورگر نمی‌توانست نگه دارد. راه‌حل: بازگرداندن query string ولی با مقدار هش که با هر آپدیت تغییر می‌کند، و نه با نسخهٔ وردپرس. این تغییر کوچک، هم امنیت را حفظ کرد و هم سرعت را به حالت اول بازگرداند. تحلیل عمیق این تصمیم در چگونه سرعت سایت وردپرسی را افزایش دهیم آمده است.

این دو پرونده، دو روی سکهٔ حذف نسخه را نشان می‌دهند: از یک طرف، این کار به‌تنهایی امنیت نمی‌سازد؛ از طرف دیگر، اگر بدون توجه به اثرات جانبی اعمال شود، می‌تواند به مشکلات جدید منجر شود. آگاهی از هر دو طرف، تفاوت بین استفادهٔ حرفه‌ای و آماتور است.

جمع‌بندی تجربه و مسیر پیشنهادی

حذف نسخهٔ وردپرس، یکی از توصیه‌های همیشگی در فضای امنیت وردپرس است که ارزش واقعی‌اش درست درک نمی‌شود. این کار، سطح حمله را کمی کاهش می‌دهد ولی جایگزین لایه‌های اصلی امنیت نیست. پیاده‌سازی درست آن، با یک اسنیپت کوتاه و هوک init انجام می‌شود و می‌تواند بخش‌های دیگر مثل فید و query string فایل‌ها را هم پوشش دهد. پیچیدگی اصلی در فایل readme.html و هدر X-Powered-By است که خارج از حیطهٔ اسنیپت PHP قرار می‌گیرند. محل درست این اسنیپت، افزونهٔ اختصاصی است نه چایلد تم، چون بخشی از امنیت سایت است و باید پایدار بماند.

گام بعدی عملی: اگر این اسنیپت را هنوز پیاده نکرده‌اید، آن را در محیط لوکال یا استجینگ اضافه کنید. سپس سه چیز را بررسی کنید: هدر HTML از متاتگ generator خالی است؛ فید RSS تگ نسخه ندارد؛ و query string فایل‌های CSS/JS با احتیاط مدیریت می‌شود. اگر همه این‌ها درست بود، یادداشتی کنار اسنیپت بگذارید که چرا این کد اضافه شده — چون بعد از چند ماه، این یادداشت به یادآور مفیدی تبدیل می‌شود. اگر تجربه‌ای با حذف نسخهٔ وردپرس داشته‌اید — به‌ویژه اگر در پروژه‌ای با کش یا افزونهٔ امنیتی به نکته‌ای برخورده‌اید که در این مقاله پوشش داده نشده — برای من جالب است بدانید چطور حلش کردید. تجربهٔ خودتان را در دیدگاه‌ها بنویسید؛ به‌ویژه اگر روش تمیزی برای ترکیب امنیت و سرعت در این حوزه پیدا کرده‌اید. 🛡️