אתר ללא HTTPS – למה זה כשל גם אם "אין מה להגן"

אתר שנטען ב-HTTP במקום HTTPS לא רק מקבל סימון "Not Secure" בכרום ובספארי – הוא חשוף לציתות, ל-MITM, להזרקת קוד על ידי ספקי אינטרנט (כן, זה קורה), ומקבל דירוג נמוך יותר במנועי חיפוש. גוגל הצהירה זה מכבר ש-HTTPS הוא סיגנל דירוג, ובמקרים מסוימים אתרי HTTP פשוט לא נכללים ב-Search Console כמתבקש.

למה זה משנה

גם אם האתר שלך הוא בלוג סטטי בלי טפסים, גם אז HTTP חושף: כל מבקר על Wi-Fi משותף או רשת ארגונית רואה אילו דפים נקראו, מה שמפר פרטיות; ספקי אינטרנט מסוימים (במיוחד בנייד) מזריקים פרסומות לתוך עמודי HTTP – המבקרים שלך רואים תוכן שלא יצרת; וכל קריאה אל wp-login.php שלא הופנתה ל-HTTPS חושפת את סיסמת המנהל בטקסט גלוי. מבחינה מסחרית, סנדבוקסים של PayPal, Stripe ו-Google Workspace חוסמים אינטגרציה עם דומיינים שלא משדרים HTTPS, ולכן אי אפשר להפעיל checkout או SSO תקין.

איך לזהות

גש לאתר בכרום. אם בסרגל הכתובת רשום "Not secure" או אייקון של מנעול שבור, האתר על HTTP. בדיקה משלימה: curl -I http://example.com – אם מחזיר 200 ולא redirect ל-HTTPS, אין כפיית SSL. כלי חיצוני: https://www.ssllabs.com/ssltest/ – יציג את הציון של תצורת ה-SSL (מומלץ A או A+).

איך לתקן

שלב 1 – התקנת תעודה. רוב ספקי האחסון תומכים ב-Let's Encrypt בחינם. ב-cPanel: SSL/TLS Status > Run AutoSSL. ב-Plesk: Domains > example.com > SSL/TLS Certificates. אם אין: certbot --apache בשרת ייעודי.

שלב 2 – שינוי כתובות. Settings > General, החלף את שני השדות מ-http:// ל-https://.

שלב 3 – עדכון DB:

wp search-replace 'http://example.com' 'https://example.com' --all-tables-with-prefix --skip-columns=guid

שלב 4 – Redirect 301:

RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://$server_name$request_uri;
}

שלב 5 – טיפול ב-Mixed Content. פתח את האתר ב-DevTools > Console; כל אזהרת "Mixed Content" מצביעה על תמונה/CSS/JS שעדיין נטען מ-HTTP. תקן ידנית או הוסף לכותרת Content-Security-Policy: upgrade-insecure-requests.

טעויות נפוצות

טעות ראשונה: להתקין SSL ולא לעשות search-replace. תמונות, קישורי תפריט וקישורים פנימיים בתוכן יישארו עם http:// – תוצאה: Mixed Content בכל עמוד. טעות שנייה: לדלג על דגל --skip-columns=guid. שדה guid ב-wp_posts לא נועד להיות URL נטען – הוא מזהה ייחודי. החלפתו עלולה לשבור RSS readers שמחזיקים מטמון. טעות שלישית: לסמוך על Really Simple SSL בלבד. הוא תיקון מהיר אבל מוסיף עומס PHP בכל בקשה. אחרי search-replace תקין, אפשר להסיר אותו.

בדיקה לאחר תיקון

גלוש לאתר ב-Chrome – המנעול חייב להיות שלם, בלי "Not secure" או "Mixed Content". הרץ curl -I http://example.com – אמור להחזיר HTTP/1.1 301 Moved Permanently ו-Location: https://.... בצע סריקת SSL Labs ושאף ל-A או A+. ב-Search Console, הוסף את הגרסה ה-HTTPS כ-property חדשה ועקוב אחר אינדקס תקין.

אחרון חביב, אחרי שהמעבר ל-HTTPS הסתיים, עדכן את כל הכלים החיצוניים: Google Search Console (הוסף את גרסת ה-HTTPS כ-property), Google Analytics (עדכן את ה-default URL בהגדרות הנכס), Bing Webmaster Tools, וכל webhook חיצוני שמתקשר עם האתר. גם פלטפורמות שיווק (MailChimp, ActiveCampaign) דורשות עדכון של URLs פנימיים בקמפיינים. דילוג על שלב זה גורם לתנועה אורגנית להמשיך להגיע לכתובות HTTP ישנות שמוצגות במנועי חיפוש – ה-redirect 301 יטפל בה, אבל אם יש שכחה, תאבד מידע אנליטי.