טיפול בפריצה יפנית / Cloaking באתרי וורדפרס

עודכן לאחרונה ב-6.3.2025

במדריך הבא אני אלמד איך מזהים פריצה יפנית (Cloaking) באתרי וורדפרס ואיך לפתור את הפריצה ולטפל בהשלכות שלה ברמת הקידום האורגני.

מהי "פריצה יפנית"?

הפריצה היפנית היא כאשר הפורץ עושה פרוצדורה שנקראת Cloaking לאתר – המשמעות שלה היא שגוגל רואה את האתר בתור אתר אחר + רואה, סורק ומאנדקס גם עמודים שלא קיימים.
כתוצאה מכך הביטויים הרצויים של האתר נעלמים והאתר מתחיל להיות מדורג על כל מיני ביטויים מוזרים (יפניים גם), מה שמקריס את הקידום לגמרי.

במה הפריצה הזו שונה מפריצה רגילה?

  • בפריצה רגילה – האתר משתנה לגמרי, התוכן הופך לתוכן אחר ונפתחים במערכת עמודים חדשים שניתן לראות ולמחוק. ניתן לזהות את הפריצה על ידי סריקת האתר עם תוסף אבטחה ולטפל בה באופן דאי פשוט.
  • בפריצה מסוג Cloaking – האתר עצמו תקין. אותה הנראות, אותו התוכן ואין עמודים חדשים במערכת.
    כל הדבר הזה נוצר מתוך השרת כתוצאה מקוד זדוני בקבצי הליבה של הוורדפרס כמו: wp-cron index.php ו-htaccess.

    הקוד שנוסף ל-htaccess הוא הקוד האחראי ל”הפניה” של גוגל לאתר המראה שהוא רואה, (באופן כללי זה הקובץ שנותן הוראות לדפדפנים ולמנועי החיפוש בכל מה שקשור לקריאת קבצי האתר, לדוגמה דרך הקובץ הזה ניתן להפנות את האתר לגרסת ה-HTTPS ללא תוסף, אפשר דרכו לחסום משתמשים לפי IP ושימושים נוספים). יחד עם זאת נוספים לתקייה הראשית של האתר ב-FTP קבצים לא מוכרים שלא קשורים לקבצי הליבה של הוורדפרס, קובץ ה-robots.txt משתנה וגם מפת האתר.

כיצד ניתן לדעת אם האתר שלי נפרץ?

התראות ב-Search console – קודם כל, הקונסול שולח מיילים בנוגע לשגיאות חדשות בכיסוי (לרוב בעמודים לא קיימים).

בנוסף ניתן לראות בדוח הביצועים עלייה חדה בכמות הכניסות לאתר ובכמות ההופעות, יחד עם ביטויים שהאתר לא אמור להופיע בהם.

בכיסוי גם רואים כמות עצומה של דפים חדשים מאונדקסים ולא מאונדקסים
(כשלמעשה האתר עצמו מכיל רק 30 עמודים)
מאוד חשוב לבצע בדיקות יומיות ב-SC, במידה ומגלים את הפריצה בזמן ניתן למזער את הנזקים ואפילו לא להיפגע כלל.

ניתן גם לעלות על הפריצה על ידי התראות מהשרת בנוגע לניצול משאבים גבוהה או שונה מהרגיל.
שרתים שמכבדים את עצמם מתריעים על כך, בגלל שהפריצה שולחת את גוגל לבקר באתר ולסרוק את כל אלפי העמודים “החדשים” בבת אחת יחד עם משתמשים חדשים שנכנסים לעמודים הלא קיימים באופן אורגני וקישורים מאתרים אחרים (שנפרצו גם כן).

כל אינטראקציה של הבוט של גוגל עם האתר יוצר פקודת PHP ותופס מקום ברוחב הפס, כל זה מעמיס על השרת (גם אם העמוד שנכנסים אליו הוא 404). שרתים חלשים יכולים לקרוס מהעומס הזה או להיפגע ולהוריד כתוצאה מכך את ביצועי המהירות של האתר.

ניתן לראות את כל הנתונים בדוחות של השרת – כמות הפעמים שהבוט של גוגל נכנס לאתר, שימוש הגולשים והבוטים ברוחב הפס שקופץ, ביקורים/תנועה בקבצי הליבה של האתר.

google bot
מתוך Awstats

הבוט של גוגל תופס 52GB מרוחב הפס לעומת בוטים אחרים של מנועי חיפוש/תוכנות (בינג, ahrefs וכו’) שתופסים פחות מ-100MB בגלל שהם לא נשלחים בכפייה לסרוק את האתר (הם גם רואים את האתר באופן תקין, לרוב עושים את ההפניה של אתר המראה רק לבוטים של גוגל).

graph
הדבר בא לידי ביטוי גם בקפיצות בדוח של רוחב הפס
page urls
עמודים של קבצי ליבה שהגיעה אליהם תנועה (מהדוח של השרת)

אם עושים בדיקה בכתובת דף פעולה בקונסול או בכלי אחר של גוגל כמו הכלי לבדיקת התאמה לניידים, יהיה ניתן לראות בתצוגה עמוד שונה מהעמוד האמיתי באתר.

איך מטפלים בפריצה?

לאחר שמזהים את הפריצה הזאת יש לפעול באופן הבא:

ניקוי קבצי השרת (FTP)

כמו שציינתי בהסבר על הפריצה לפני כן, תהליך ה-Cloaking מתבצע על ידי שינויים בקבצי השרת שב-FTP
יש לבדוק את הקבצים הבאים ולנקות אותם מהקוד הזדוני:

  • index.php
  • htaccess
  • wp-config
  • wp-cron
  • robots.txt
  • sitemap.xml

רצוי להחליף את הקבצים בקבצי ברירת המחדל של אתר וורדפרס חדש אם לא יודעים לזהות אל למחוק את הקוד הזדוני. אם זה לא פתר את הבעיה מומלץ גם לעבור על כל שאר הקבצים או לבנות את האתר מחדש במקרה הכי גרוע.

כל אלו נמצאים ב-public_html שהיא התיקייה הראשית של האתר בשרת.
בנוסף חשוב גם למחוק קבצים לא מוכרים שנמצאים בתיקיה כמו לדוגמה japan.php או שטות אחרת.
חובה לעשות גיבויים לפני כל מחיקה או שינוי בקוד.

הסרת משתמשים חשודים

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

  1. שרת
  2. search console
  3. אתר

תמחקו את כל המשתמשים הלא מוכרים ותשנו סיסמאות לכל המשתמשים שלכם בכל המקומות.

טיפול ב-backlinks

יחד עם הבקשות המרובות שהפורץ שלח לגוגל (דרך ה-SC או דרך PING שגוגל הודיעה שהיא תתעלם ממנו בעדכון של יוני 2023), גוגל מצא את עמודי המראה בעזרת קישורים חיצוניים מאתרים אחרים שנפרצו.

אז חשוב לעבור על הנתונים ב-Ahrefs, Majestic ובאזור הקישורים בקונסול, ולעשות התנערות מהדומיינים הלא רלוונטיים שמקשרים לאתר (גם אם מעשית העמוד המקשר הוא 404).
עושים את זה באמצעות קובץ disavow ששולחים לגוגל.

בקשת סריקה של העמודים החשובים

מגישים בסרצ’ קונסול מחדש את מפות האתר ושולחים בקשה לאנדקס את העמודים הרלוונטיים, רצוי לעשות זאת באמצעות indexing api לכמות גדולה של עמודים.

שליחת בקשה להסרת העמודים

שולחים בסרצ’ קונסול בקשה להסרת קישורים לא רלוונטיים
במידה ורואים שהעמודים הלא רלוונטיים מכילים slug קבוע (לדוגמה /japan/), ניתן לעשות את זה באופן גורף באופן הבא:

זה טוב כשמגלים את הפריצה בזמן וכמות העמודים עדיין לא כזאת גדולה
אך הפעולה הזאת תהיה פחות אפקטיבית במידה ויש עשרות אלפי עמודים…

הפיכת עמודי 404 לעמודי 410

עמודים בסטטוס 404 (לא נמצא) בעצם אומרים לגוגל שהעמוד קרגע לא באוויר, אך הוא יכול לחזור בעתיד (מה שגורם לו לא להוריד את העמוד ישר מתוצאות החיפוש).

עמוד בסטטוס 410 אומר לגוגל שהעמוד הוסר לצמיתות ולא יחזור שוב לשרת
ככה במקום להגיע לעמוד 404, יגיעו לעמוד שרשום בו רק:
Sorry, the page you requested has been permanently removed

אפשר לעשות זאת באמצעות התוסף הבא של עמודי 410

עקרון הפעולה של התוסף: ברגע שיש כניסה לעמוד 404 הוא נוסף לרשימה בתוסף (הוא אוסף רק עמודי 404, ככה שאין צורך לדאוג שעמוד קיים יופיע שם).

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

בנוסף ניתן לשלוח רשימה ידנית של קישורי 404 שאנחנו יכולים לייצא מהקונסול ולהגדיר גם להם סטטוס 410.

חשוב להדגיש שלמרות זאת, במידה וגוגל הספיק לסרוק כמות גדולה של עמודים, ייקח להם הרבה זמן לצאת מתוצאות החיפוש.

אך ביצוע הפעולות אכן עוזר לאתרים להתאושש ולקבל את המיקומים והתנועה שלהם בחזרה.

עדכון תחילת שנת 2024, כ-7 חודשים לאחר סיום טיפול בפריצה
ירידה בכמות העמודים ה”מוספאמים”, המיקומים של הביטויים יציבים לעומת שנה שעברה.

טיפול סרצ' קונסול

עדכון מתחילת 2025, קרוב לשנתיים אחרי טיפול בפריצה
כמעט ולא נשאר זכר לפריצה, ביצועי האתר עלו במהלך התקופה בכ-250%

טיפול בפריצה 2025