כיצד להסיר את גרסת הוורדפרס מהדר האתר לצורכי אבטחה ושיפור טעינה

בשיעור הזה אני מלמד אותך איך להסיר או לצמצם חשיפה של גרסת WordPress מתוך ה-head של האתר, מתוך גישה מקצועית ומסודרת: להבין קודם מה באמת מודפס, מה הסיכון בפועל, איך לבצע את השינוי בצורה בטוחה, ואיך לוודא שלא שברת תוסף, feed, REST API או אזור ניהול. המטרה שלי היא לא רק לתת לך שורת קוד, אלא לגרום לך להבין איפה WordPress מזריקה generator tags, למה לא כדאי לערוך קבצי ליבה, ואיך ליישם את הפתרון הנכון בתוסף קטן או בקובץ functions.php של child theme.

להבין מה באמת מוסר מה-head ולמה זה לא קסם אבטחה

WordPress משתמשת בפונקציה wp_generator() כדי להדפיס תג generator, ובמקרים מסוימים גם feedים וערוצים אחרים עשויים להציג מידע דומה. הסרה של תג הגרסה אינה מחליפה עדכוני אבטחה, חומת אש, הרשאות תקינות או תחזוקה שוטפת. היא כן עוזרת לצמצם חשיפה מיותרת, לנקות מעט מה-head, ולהקטין מצב שבו בוטים או סורקים מקבלים רמז מיידי על גרסת הליבה. לכן אנחנו מתייחסים לזה כהקשחה קלה, לא כשכבת הגנה מלאה.

מבחינה מעשית, אני ממליץ לחשוב על זה כך: קודם מעדכנים WordPress, תוספים וערכות נושא; אחר כך מסירים חשיפות לא הכרחיות. אם האתר עדיין רץ עם גרסה ישנה, הסרת התג לא באמת תפתור את הבעיה המרכזית. היא רק תגרום לך להרגיש מוגן יותר ממה שאתה באמת.

• מה כן מרוויחים: head נקי יותר, פחות fingerprinting בסיסי, קוד יותר מסודר.
• מה לא מרוויחים: חסינות מפני חולשות בליבה, בתוספים או בשרת.
• מה הכי חשוב: לא לגעת בקבצי core, לא לחסום רכיבים ש-WordPress צריכה בפועל, ולבדוק staging לפני production.

לאתר מאיפה התג מגיע לפני שמוחקים משהו

לפני כתיבת קוד, אני רוצה שתבדוק מה האתר שלך באמת מדפיס. פתח את עמוד הבית, בצע View Source, וחפש generator, wp_head, או את מספר הגרסה. כדאי גם לבדוק feed בסיסי כמו /feed/, כי לפעמים מפתחים מסירים את התג מה-head אבל משאירים אותו בערוצים אחרים.

הבדיקה הזו חשובה כי לפעמים מקור התג הוא לא WordPress עצמה אלא תוסף ביצועים, SEO, Site Health או כלי צד שלישי. ברגע שאתה יודע איפה החשיפה מופיעה, אתה בוחר פתרון מדויק במקום לזרוק עשרה remove_action() לא קשורים.

1. בדוק View Source של עמוד ציבורי.
2. בדוק feed ציבורי.
3. בדוק אם תוסף אבטחה או ביצועים כבר מסיר את התג.
4. בדוק Query Monitor או רשימת hooks אם יש כפילות.

ליישם נכון: תוסף קטן עדיף על עריכת core

הדרך הבטוחה ביותר היא לשים את ההסרה בתוסף קטן משלך או ב-must-use plugin. כך השינוי לא ילך לאיבוד בעדכון theme, הוא נשאר נייד בין פרויקטים, ואפשר לכבות אותו בבדיקה מהירה אם יש תקלה. Child theme מתאים כשכבר יש לך מקום מסודר לקוד תפעולי, אבל תוסף קטן לרוב נקי יותר.

<?php
/**
 * Plugin Name: Pablo Remove WP Version
 * Description: הסרה מבוקרת של תגי גרסת וורדפרס מה-frontend.
 * Version: 1.0.0
 * Author: pablo rotem
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

/**
 * מחזיר מחרוזת ריקה במקום תג generator.
 *
 * @author pablo rotem
 */
function pablo_rotem_hide_wp_generator(): string {
    return '';
}
add_filter( 'the_generator', 'pablo_rotem_hide_wp_generator' );

/**
 * מסיר פעולות ברירת מחדל שמדפיסות generator ב-head.
 *
 * @author pablo rotem
 */
function pablo_rotem_remove_wp_version_head(): void {
    remove_action( 'wp_head', 'wp_generator' );
}
add_action( 'init', 'pablo_rotem_remove_wp_version_head' );

בקוד הזה אני משתמש גם ב-remove_action() וגם ב-the_generator. זה נותן לך כיסוי טוב יותר: גם מונע הדפסה ב-head, וגם מחזיר ערך ריק במסלולים שמשתמשים בפילטר.

הגישה כאן מקצועית כי היא לא משנה ליבה, לא מסתמכת על output buffering, ולא מנסה לעשות replace גס ל-HTML אחרי הרינדור. אנחנו עובדים עם hookים רשמיים, שזה בדיוק מה שאתה רוצה בקוד WordPress ארוך טווח.

מתי לבחור MU Plugin במקום functions.php

אם אתה מנהל כמה אתרים או רוצה הקשחה שאף אחד לא יבטל בטעות מה-backend, אני ממליץ לשים את ההסרה כ-MU Plugin. תוסף MU נטען אוטומטית, לא תלוי בהפעלה ידנית, והוא מושלם לחוקי בסיס של הפרויקט: hardening, headers, cleanup וקונפיגורציה.

<?php
/**
 * תוסף MU להסרת תגי version מיותרים.
 * שמור כקובץ: wp-content/mu-plugins/pablo-hardening.php
 *
 * Author: pablo rotem
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

add_filter( 'the_generator', '__return_empty_string' );

add_action( 'init', function (): void {
    remove_action( 'wp_head', 'wp_generator' );
}, 20 );

היתרון הגדול בגישה הזאת הוא משמעת תפעולית: אתה יודע שכל אתר חדש שאתה מקים יטען את אותו hardening file. זה שימושי במיוחד אם אתה מפתח תשתיות WordPress ללקוחות ואתה רוצה סטנדרט קבוע.

האם להסיר גם את ?ver= מנכסים ציבוריים

פה אני רוצה שתהיה זהיר. הרבה מדריכים ברשת זורקים מיד פונקציה שמסירה ?ver= מכל CSS ו-JS, כאילו זו תמיד אופטימיזציה. בפועל, הפרמטר הזה משמש גם ל-cache busting, ולכן אם תסיר אותו בלי להבין איך אתה עובד עם CDN, אגרסיביות cache ולייט-סטייגים, אתה עלול לקבל מצב שבו לקוח רואה קובץ ישן. לכן אני מתייחס להסרת version מנכסים כאל צעד אופציונלי, לא חובה.

<?php
/**
 * הסרת פרמטר ver מנכסים ציבוריים.
 * שים לב: לא להשתמש בזה בלי הבנה של caching ו-debugging.
 *
 * Author: pablo rotem
 */

if ( ! defined( 'ABSPATH' ) ) {
    exit;
}

function pablo_rotem_strip_asset_version( string $src ): string {
    if ( is_admin() ) {
        return $src;
    }

    $parts = wp_parse_url( $src );

    if ( empty( $parts['query'] ) ) {
        return $src;
    }

    parse_str( $parts['query'], $query_args );

    if ( isset( $query_args['ver'] ) ) {
        unset( $query_args['ver'] );
        $base = strtok( $src, '?' );
        $src  = empty( $query_args ) ? $base : add_query_arg( $query_args, $base );
    }

    return $src;
}

add_filter( 'style_loader_src', 'pablo_rotem_strip_asset_version', 20 );
add_filter( 'script_loader_src', 'pablo_rotem_strip_asset_version', 20 );

אם אתה בוחר להשתמש בזה, בדוק היטב אחרי כל deploy: האם CSS חדש באמת נטען, האם JS מתרענן, והאם הלקוחות לא מקבלים קבצים ישנים מה-cache. אם אתה עובד עם Cloudflare, LiteSpeed Cache או CDN אחר, שלב את הבדיקה הזו כחלק מה-release checklist שלך.

בדיקות לאחר ההטמעה: לא מסיימים בלי QA

אחרי ההטמעה אני רוצה שתעבוד כמו מפתח אחראי: תנקה cache, תבדוק עמודי frontend, עמודי בלוג, עמודי מוצר אם יש WooCommerce, feed, REST API, אזור ניהול, והתחברות. המטרה היא לוודא שלא הסרת משהו חיוני ושלא השפעת על טעינת משאבים.

• בדוק View Source וחפש generator.
• בדוק שה-feed עדיין נפתח תקין אם האתר משתמש בו.
• בדוק טעינת CSS ו-JS אחרי ניקוי cache.
• בדוק שאין שגיאות PHP, warnings או notices בלוג.
• בדוק שכלי SEO לא הוסיפו תג מקביל משלהם.

אני גם ממליץ לשמור צילום מסך או snapshot של לפני ואחרי. זו דרך פשוטה להוכיח לעצמך מה באמת השתנה ולא לעבוד על זיכרון בלבד.

טעויות נפוצות שאני רואה שוב ושוב

הטעות הראשונה היא לערוך את general-template.php או קובץ ליבה אחר. זה נשבר בעדכון הבא ומייצר חוב טכני מיידי. הטעות השנייה היא להדביק חמישה snippets בלי להבין אם הם כפולים. הטעות השלישית היא לקרוא לזה "אבטחה" ולשכוח לעדכן את האתר עצמו.

עוד טעות נפוצה היא להסיר ?ver= ולשכוח שה-cache ממשיך להגיש קבצים ישנים. במקרה כזה, הלקוח מדווח שהעיצוב שבור, אבל אצלך בדפדפן הכול נראה תקין כי יש לך קבצים חדשים. לכן בכל שינוי של assets צריך בדיקת cache אמיתית.

ולבסוף, אל תשים את הקוד ישירות בתוסף צד שלישי דרך editor. שמור אותו ב-Git, תעד מה שינית, וכתוב README קצר. זה מה שמבדיל בין סניפט שעובד עכשיו לבין תחזוקה מקצועית.

סיכום

במדריך הזה ראית שהסרת גרסת WordPress מה-head היא משימה פשוטה יחסית, אבל צריך לבצע אותה נכון: לעבוד עם hooks רשמיים, להעדיף תוסף קטן או MU plugin, לבדוק feed ו-assets, ולהבין שהמטרה היא הקשחה עדינה וניקוי head – לא תחליף לעדכונים ולאבטחה אמיתית.

קישורים רשמיים להמשך עבודה

• wp_generator() – WordPress Developer Resources
• Plugin API / Hooks – WordPress Developer Resources
• Security Nonces – WordPress Developer Resources
• Sanitizing Data – WordPress Developer Resources
• PHP Manual