איך מתקנים את האזהרה „לא מאובטח”
בקצרה: האזהרה אומרת שהדף נטען ב־HTTP רגיל, או שדף HTTPS עדיין טוען משהו ב־HTTP. התקינו תעודת TLS חינמית, הפנו כל כתובת http:// לכתובת https:// בהפניה קבועה (301), העבירו את מערכת ניהול התוכן לכתובות https:// ותקנו תוכן מעורב. מאז Chrome 154 (אוקטובר 2026) כרום גם מבקש מהמבקרים אישור לפני שהוא פותח דף HTTP ציבורי, כך שאתר שעובד רק ב־HTTP מאבד מבקרים עוד לפני שהם רואים אותו.
שלבים בקצרה
- התקינו תעודה. הפעילו את התעודה החינמית בפאנל האחסון, או השתמשו ב־Let’s Encrypt עם Certbot.
- הפנו מ־HTTP ל־HTTPS. שלחו כל בקשת http:// לכתובת https:// בהפניית 301.
- החליפו את כתובות האתר. שנו את כתובת האתר בוורדפרס או במערכת ניהול התוכן ל־https://.
- תקנו תוכן מעורב. טענו כל תמונה, סקריפט, גופן וטופס דרך https://.
- בדקו כל שלב בהפניות. ודאו שאף שלב בין הקישור הראשון לדף הסופי לא עובר ב־HTTP רגיל.
- הוסיפו HSTS. כשהכול עובד ב־HTTPS, הורו לדפדפנים להשתמש תמיד ב־HTTPS.
הקוד וההגדרות נשארים באנגלית.
מה האזהרה אומרת בפועל
דפדפנים מציגים „לא מאובטח” בשורת הכתובת כשהדף עצמו הגיע ב־HTTP, בלי הצפנה. כל מי שנמצא באותה רשת Wi-Fi, נתב פרוץ או מפעיל הרשת יכולים לקרוא ולשנות את מה שהמבקר שולח ומקבל, כולל סיסמאות וטפסי יצירת קשר. מנעול עם אזהרה, או דף https:// בלי מנעול, מעידים בדרך כלל על תוכן מעורב: הדף ב־HTTPS, אבל תמונה, סקריפט או טופס בתוכו עדיין משתמשים ב־http://.
מעכשיו קשה יותר להתעלם מהאזהרה. ב־Chrome 154, שיצא באוקטובר 2026, ההגדרה „תמיד להשתמש בחיבורים מאובטחים” פעילה כברירת מחדל: כרום מנסה קודם HTTPS, ואם זה נכשל הוא מציג אזהרה על כל המסך ומבקש מהמבקר אישור לפני שהוא פותח אתר HTTP ציבורי. כרום מציג את האזהרה הזו גם כשאחת ההפניות בדרך לדף שלכם עוברת ב־HTTP, אפילו אם הדף הסופי ב־HTTPS.
שלב 1: התקינו תעודה חינמית
רוב חברות האחסון כוללות תעודה חינמית. חפשו בפאנל הניהול „SSL/TLS”, „Let’s Encrypt” או „AutoSSL” והפעילו אותה גם ל־yourdomain.com וגם ל־www.yourdomain.com. אם אתם מנהלים שרת בעצמכם, Certbot מנפיק תעודת Let’s Encrypt חינמית ומחדש אותה אוטומטית:
sudo apt install certbot python3-certbot-nginx
sudo certbot --nginx -d yourdomain.com -d www.yourdomain.com
# Apache: install python3-certbot-apache and use --apache instead of --nginxתעודה בתשלום לא הופכת את החיבור לבטוח יותר. תעודה חינמית מאומתת־דומיין נותנת את אותה הצפנה ואת אותו מנעול.
שלב 2: הפנו מ־HTTP ל־HTTPS
תעודה לבדה לא מספיקה: אנשים עדיין מקלידים את הכתובת בלי https://, וקישורים ישנים מפנים ל־http://. ענו לכל בקשת HTTP בהפניה קבועה (301) לאותו נתיב ב־HTTPS. ב־nginx:
server {
listen 80;
listen [::]:80;
server_name yourdomain.com www.yourdomain.com;
return 301 https://yourdomain.com$request_uri;
}ב־Apache או באחסון משותף, הוסיפו את השורות האלה בראש קובץ .htaccess בתיקיית השורש של האתר:
RewriteEngine On
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]מאחורי Cloudflare, הפעילו את SSL/TLS ← Edge Certificates ← Always Use HTTPS, וקבעו את מצב ה־SSL ל־Full (strict) ברגע שלשרת שלכם יש תעודה תקפה משלו. מצב „Flexible” יחד עם הפניה בשרת הוא סיבה נפוצה ללולאת הפניות אינסופית.
שלב 3: העבירו את וורדפרס (או מערכת ניהול התוכן) ל־https://
בוורדפרס, פתחו את הגדרות ← כללי ושנו גם את כתובת וורדפרס וגם את כתובת האתר ל־https://. קישורים שכבר שמורים בתוך פוסטים ווידג'טים עדיין מכילים http://. עם WP-CLI אפשר להחליף את כולם בבת אחת; הריצו קודם הרצת ניסיון וגבו את מסד הנתונים לפני ההרצה האמיתית:
wp option get siteurl
wp search-replace 'http://yourdomain.com' 'https://yourdomain.com' --all-tables --dry-run
# looks right? back up the database, then run it again without --dry-runשלב 4: תקנו תוכן מעורב
פתחו את הדף, לחצו F12 והסתכלו בלשונית Console: הדפדפן מפרט כל משאב שהוא חסם או שדרג כי התבקש דרך http://. שנו את הכתובות האלה ל־https:// (או לנתיבים יחסיים), והחליפו כל וידג'ט של צד שלישי שלא תומך ב־HTTPS. במדריך ההפניות והתוכן המעורב יש פקודות חיפוש ושורת Content-Security-Policy שמשדרגת אוטומטית בקשות שנשארו.
שלב 5: בדקו כל שלב בשרשרת ההפניות
האזהרה החדשה של כרום מופיעה גם כששלב בהפניה עובר ב־HTTP, למשל https://yourdomain.com ← http://www.yourdomain.com ← https://www.yourdomain.com. עקבו אחרי השרשרת מכל כתובת התחלה וודאו שרק הבקשה הראשונה היא http://:
for u in http://yourdomain.com http://www.yourdomain.com https://yourdomain.com https://www.yourdomain.com; do
echo "== $u"; curl -sIL "$u" | grep -iE '^(HTTP/|location:)'
doneבאופן אידיאלי, כל כתובת מגיעה לדף הסופי בהפניה אחת. עדכנו גם קישורים שבשליטתכם: פרופיל העסק בגוגל, הרשתות החברתיות, חתימת הדוא״ל והמודעות.
שלב 6: נעלו את זה עם HSTS
כשכל דף וכל תת־דומיין עובדים ב־HTTPS, הוסיפו את הכותרת Strict-Transport-Security כדי שהדפדפנים ידלגו לגמרי על HTTP בביקורים הבאים. התחילו עם max-age קצר והגדילו אותו כשאתם בטוחים. ראו HSTS בשפה פשוטה.
עדיין רואים אזהרה?
- שגיאת תעודה על כל המסך (למשל NET::ERR_CERT_DATE_INVALID) היא בעיה אחרת: ראו שגיאות תעודת SSL בהסבר פשוט.
- רק בחלק מהדפים: הדפים האלה עדיין טוענים משהו דרך http://, או שטופס שולח לכתובת http://.
- רק אצל חלק מהמבקרים: סימנייה או קישור ישן ל־http://, הפניה שנשמרה במטמון, או תת־דומיין בלי תעודה.
- אחרי החלפת אחסון או CDN: ייתכן שלשרת החדש עוד אין תעודה, או שהוא מציג תעודה של שם אחר.
מה HackGrade בודקת
הסריקה החינמית של HackGrade בודקת את ההפניה מ־HTTP ל־HTTPS, אם התעודה מהימנה ומתי היא פוקעת, את גרסת ה־TLS, את HSTS ואת התוכן המעורב בדף הבית, ומסבירה את התיקונים הראשונים בשפה פשוטה. היא קוראת רק את מה שהדפדפן של כל מבקר רואה.
שאלות נפוצות
האם האזהרה „לא מאובטח” פוגעת בדירוג שלי בגוגל?
HTTPS הוא אות דירוג קל, אבל המחיר הגדול הוא באנשים: מבקרים רבים עוזבים כשהם רואים אזהרה, ומאז Chrome 154 הם צריכים לאשר אזהרה על כל המסך לפני שאתר שעובד רק ב־HTTP בכלל נפתח.
האם צריך תעודת SSL בתשלום כדי להעלים את האזהרה?
לא. תעודות חינמיות מאומתות־דומיין, כמו Let’s Encrypt, נותנות את אותה הצפנה ומעלימות את האזהרה בדיוק כמו תעודות בתשלום.
התקנתי תעודה ועדיין רואים „לא מאובטח”. למה?
בדרך כלל האתר עדיין נפתח ב־http:// כי אין הפניה, או שדף ה־HTTPS טוען תוכן מעורב. הוסיפו את הפניית ה־301, ואז חפשו משאבי http:// בקונסולה של הדפדפן.
האם האזהרה מסוכנת למבקרים שלי?
ב־HTTP, כל מה שהם מקלידים, כמו סיסמאות ופרטי קשר, יכול להיקרא או להשתנות על ידי מי שנמצא באותה רשת. לכן הדפדפנים מזהירים, ולכן חשוב לתקן גם באתר תדמית פשוט.