JavaScript meets SEO: It works

   מיכאל גולדברג |  יוני 2018
בכתבה הבאה נסקור את נושא ה-JS מזווית ה- SEO ונרכז בו את כל המידע וההנחיות שלנו בנושא. נתחיל בהסבר רקע קצר על האופן בו Google עובד ונבין את האתגר ש- JavaScript מציב עבורו, על בסיס הבנה זו נציג את הפתרונות וההתאמות על מנת ש-Google יוכל לאנדקס אותו בצורה טובה.

תוכן עניינים:

  1. הקדמה
  2. איך גוגל עובד?
  3. אתגר ושמו JS
  4. הנחיות להתאמת אתר JS
  5. קייס סטאדי
  6. מקורות

הקדמה

א. את גיבוש נקודת ההסתכלות שלנו על אתרי JavaScript מזווית ה-SEO נפתח בציטוט של ,John Muller ה-Googler המפורסם:

 

 

המסר ברור- Google מבינים כי שימוש ב- JavaScript רק ילך ויגבר, ולכן, כבר תקופה ארוכה שהם עושים מאמצים על מנת להתאים את עצמם לכך.
כיום, בשנת 2018, לגיטימי לבנות אתר העושה שימוש נרחב ב-JS. היתרונות ברורים, ועם הזמן היכולות של Google ילכו וישתפרו ויותאמו לסטנדרטים של האינטרנט.

ב. יחד עם זאת – Having Said That, בטווח הקצר והבינוני אתרי JS מציבים ל-Google אתגרי זחילה ואינדוקס משמעותיים. ובזה, בעצם, נעסוק במאמר זה – מיפוי הבעיות של גוגל בהקשר של אתרי JS, ונרחיב אודות ה-Practice המומלץ כדי להתגבר עליהן.

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

 

איך Google עובד?

 

א. יעילות (Efficiency)
קודם כל, חשוב להבין שאלמנט מרכזי בכל מה שקשור ל-Technical SEO הוא יעילות (Efficiency). זהו נושא חשוב ביותר עבור מנגנוני הזחילה והאינדוקס של Google שמוכרחים להתנהל ביעילות המקסימלית. האינטרנט הוא אוקיינוס עצום שצריך לזחול ולאנדקס אך המשאבים של Google, אדירים ככל שיהיו, הם בסופו של דבר מוגבלים.
זו הסיבה שחלק ניכר מפעילות ה-SEO שנעשה בהיבט הטכני תהיה לסייע למנגנוני הזחילה והאינדוקס לייעל את עבודתם באתר, בין אם זה להגדיר תגית <h1> אחת ברורה בדף ובין אם זה לחסום אזור שלם באתר בעזרת קובץ ה-robots.txt, ומגוון פעולות נוספות שמטרתן לסייע למנגנוני הזחילה והסריקה לזחול דפים רלוונטיים בלבד ו"להבין" בצורה ברורה את תוכן הדף.

ב. Crawl & Index
נפתח בהסבר קצר על התהליך, עם שני המנגנונים המרכזיים של Google:
מנגנון זחילה – הידוע בשמו Googlebot, המנגנון אחראי על גילוי כתובות URL חדשות ושליחתם לאינדוקס. ה-crawler מבקש את הכתובת מהשרת, מקבל ממנו את קובץ ה-HTML ושולח אותו לאינדוקס, תוך שהוא כבר אוסף מתוכו את הקישורים שהוא מכיל לכתובות נוספות, וממשיך הלאה לזחול את הכתובות החדשות שאסף.
מנגנון אינדוקס – הפחות ידוע בשמו Caffeine, הוא המנגנון אחראי על הסריקה והאינדוקס של התוכן בכתובת ה-URL שקיבל מ-Googlebot. בין היתר המנגנון אחראי על – אינדוקס התוכן בדף, הערכת חשיבותו, וכדומה, כשהוא גם אחראי על תיעדוף הזחילה שלו ל-Googlebot – כלומר, באיזו תדירות יש לבקר בדף, על פי רמת חשיבותו.
כפי שניתן להבין המנגנונים עובדים יחד ובמקביל, האחד זוחל ומגלה כתובות ובמקביל השני סורק ומאנדקס את תוכנן, ומבצע הערכת איכות ותיעדוף. יעילות.
עם זאת חשוב להבין שהמנגנונים נפרדים.

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

ד. WRS מסתמך על Chrome 41
עוד בהקשר של Caffeine, הוצהר רשמית כי מנגנון הרינדור של Google (ה-Web Rendering Service) מסתמך כיום על דפדפן Chrome בגרסה 41, ולמעשה המנגנון זהה לגרסה זו של הדפדפן. כלומר, Google מסתמכים על דפדפן בן 3 שנים (!) כדי לרנדר דפים.
הבנה של היכולות והמגבלות של דפדפן Chrome בגרסה 41 תקל מאוד על בניית אתר בצורה ש-Google יוכל לסרוק היטב, כמו כן הדפדפן יכול לשמש כלי debugging חשוב.

 

 

ניתן להתקין chrome 41 כאן

 

אתגר ושמו JavaScript

 

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

בואו נצלול פנימה ונפרוש את נקודות החיכוך בין JS למנועי החיפוש:

א. הוא עובד ב- Client side rendering – כלומר, ה-HTML נטען בצד לקוח. יש לכך השלכות משמעותיות על מנועי החיפוש:

> ההשלכה המרכזית היא ש-Google צריך להקצות משאבים לרינדור הדף. באתרים שנטענים ב-server side, מה שקורה זה ש-Googlebot מבקש את הדף מהשרת ומקבל את כל ה-HTML מרונדר ומוכן לאינדוקס, Googlebot מעביר אותו כפי שהוא ל-Caffeine שיכול כבר לאנדקס אותו. התהליך מכיל 2 שלבים: זחילה ואינדוקס.
באתרי JS הנטענים ב-Server side מנוע החיפוש מקבל מהשרת קובץ בסיסי בלבד ודרוש שלב נוסף בתהליך – רינדור ה-HTML המלא של הדף על מנת להכינו לאינדוקס. כעת התהליך מכיל שלב נוסף: זחילה > רינדור > אינדוקס. השלב הנוסף, הרינדור, מצריך מ-Google משאבים נוספים בתהליך וכאמור Google מנהל את משאביו ביעילות מקסימלית.

> השלכה נוספת, אשר נגזרת מן הקודמת, היא אי יכולתו של Googlebot לזחול קישורים וכתובות נוספות במקביל לפעולת הסריקה שמבצע Caffeine. כאמור, באתרי JS המתרנדרים בצד לקוח, Googlebot אינו מקבל HTML מרונדר ומוכן מהשרת ולכן על מנת שהוא יוכל להמשיך לזחול כתובות URL חדשות מתוך הדף, עליו להמתין עד ש-Caffiene יסיים לרנדר את הדף, יזהה בו את הקישורים וישלח לו אותם על מנת שיזחל אותם. לא יעיל.

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

הבהרה: המונח – rendering מתייחס להרכבת ה-HTML (ה-DOM), ולא לויזואליזציה של ה-DOM בפיקסלים:

 

 

כדאי להתעכב רגע ולהתעמק עוד בתהליך האינדוקס של דפי JS הנטענים ב-Server side:
בסרטון למפתחים (בנקודה זו) Google חושפים (וכפי שהוסבר לעיל) כי מבחינת מנוע החיפוש פעולת הרינדור היא פעולה נפרדת לחלוטין מהזחילה או האינדוקס, כך שבדפים הצורכים משאבי רינדור האינדוקס מושהה עד שיתפנו משאבי הרינדור הנחוצים:

 

 

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

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

להלן התרשים הרשמי של Google, הממחיש את התהליך המלא:

 

 

אגב, בשל שני גלי האינדוקס הנ"ל, לעתים ניתן לראות כתובות של דפי Client side המאונדקסות אך תוכנם אינו מאונדקס.

ב. חוסר התאמה ל-Chrome 41 – ספריות JS היום עושות שימוש בדברים שלא היו לפני 3 שנים ולכן chrome 41 לא יודע לרנדר (למשל ES6), המשמעות היא, שגם Google לא יודע לרנדר, ותוכן ש-google לא יודע לרנדר לא יכול להתאנדקס.
נציין כי לא פחות חשובה מכך היא העובדה שגולשים המשתמשים בדפדפנים ישנים יותר (כשתחת ההגדרה "ישנים" נכנסות גם גרסאות חדשות יותר של explorer ואפילו Safari) יסבלו מאותן הבעיות בעת גלישה באתר, ועלולים לראות את התוכן בצורה חלקית או לא בכלל.

ג. מהירות – מהירות אתר היא אתגר בפני עצמו בלי קשר ל-JS, אך אתרי JS עלולים להיות איטיים בטעינה הראשונית שלהם (בפעם הראשונה שיש בקשה מהשרת), ולא בהכרח באשמת ה-JS עצמו. בדפי Server Side כל התוכן החשוב של הדף (כולל תגיות meta קריטיות) מגיע מהשרת ב-JS ולא ב-HTML, כך שאם תהליך הרינדור והרכבת ה-HTML מתוך ה-Scripts איטי ואורך יותר מממספר שניות Google עלול לנטוש ללא רינדור מלא של תוכן הדף.

ד. תוכן חבוי – בנוסף, JS עושה שימוש בכל מיני events שהם user generated, ומצריכים אינטראקציה של הגולש (כמו onclick) על מנת שהתוכן יטען, כלומר – התוכן לא נטען בטעינה הראשונית של הדף, אלא רק כאשר הגולש יוצר אינטראקציה מסוימת הדפדפן שולח בקשה נוספת לשרת וטוען את התוכן המבוקש.
חשוב להבין, google אינו גולש ואינו יוצר אינטראקציה עם הדף. ולכן, תוכן שאינו קיים בדף בסיום הטעינה הראשונית אלא חבוי מאחורי event הקשור להתנהגות גולש/אינטראקציה, לא יהיה זמין ל-google ולא יאונדקס.

ה. כתובת URL – חלק מספריות ה-JS (כמו Angular 1) עושות שימוש ב-# בכתובות ה-URL, אך Google מתעלם מכל מה שמופיע אחרי ה-# ב-URL, מכיוון שמבחינתו לא מדובר בכתובת ייחודית, אלא בקישור פנימי למיקום ספציפי בתוך אותו הדף, מעין סימנייה. כלומר, מבחינת Google אין כאן כתובת ייחודית שיש צורך לאנדקס בנפרד.

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

 

הנחיות להתאמת אתר JS למנועי חיפוש

 

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

א. הגשת דפים

על מנת לוודא שדפים הבנויים ב-JS מוגשים באופן ש-Google יכול לאנדקס בקלות וביעילות (כלומר, חוסכים ממנו את שלב הרינדור עד כמה שניתן) מבלי לפגוע ביתרונות של JS עבור המשתמשים, Google מציעים 2 פתרונות אפשריים, אשר המכנה המשותף ביניהם הוא שעבור Google מוגשים דפים שעיקר תוכנם כבר מרונדר:

פתרון א': Hybrid Rendering – הפתרון האידיאלי אשר לדעת Google יהווה הסטנדרט בנושא בטווח הארוך, אך מורכב יותר להטמעה.

פתרון ב': Dynamic rendering – פתרון פונקציונאלי הנותן מענה מספק לבעיה כרגע.

נרחיב מעט על הפתרונות הללו:
Hybrid Rendering או Isomorphic JavaScript – הצורה המומלצת על ידי Google לבנות את האתר (ההמלצה בנקודה זו בסרטון רשמי של Google למפתחים, והמלצה דומה בנקודה זו בסרטון נוסף של ג'ון מולר) היא בשיטת Hybrid Rendering אותה ניתן לבצע בעזרת Isomorphic JavaScript. העיקרון המנחה הוא שימוש משולב של server rendering ו-client rendering. התוכן המרכזי אשר חשוב למשתמש ולמנועי חיפוש מרונדר ב-server side, ומגיע ל-browser כבר כ-HTML. אלמנטים בדף שנועדו בעיקר לאינטרקציה עם המשתמש (שלרוב לא רלוונטיים עבור google), מרונדרים ב-client side. באופן זה Google אינו צריך לרנדר את תוכן הדף אשר חשוב לו לאנדקס, אך האתר עדיין יכול להציע לגולשים חווית משתמש עשירה. האיזון הנכון ביניהם מוסבר היטב כאן:

 

 

 

בפועל זה עלול להיות מורכב להטמעה במרבית ה-frameworks, אך ניתן להשתמש ב-Angular Universal – Framework המאפשר את ההתאמות הנכונות לאיזון בין server side ל-client side. (האתר הרשמי של Angular Universal). בנוסף, פתרון זה מצריך שרת מבוסס JS.

Dynamic Rendering

העיקרון בפתרון זה הוא שהשרת מזהה בקשות מ-googlebot (על פי User agent) ועבור google בלבד הוא מרנדר את הדף ב-server side, אך עבור משתמשים הדף מתרנדר ב-server side כרגיל. במסגרת פתרון זה, google ממליץ שלא לבצע את הרינדור עבור googlebot בשרת כפי שהוא, בשל כמות המשאבים שזה עלול לצרוך, אלא מומלץ לשלב תשתית בשרת המאפשרת לו לרנדר עבור גוגל בצורה חיצונית .כך נראה תרשים הזרימה של אתר JS המגיש ב-dynamic rendering ומכיל תשתית רינדור ייעודית בשרת:

 

 

 

יש להבין כי במידה רבה מדובר ב – "תרגיל" דומה מאוד לפתרון ה-escaped fragment, בו הגשנו תוכן ייעודי לזחלנים של מנועי החיפוש (פתרון ש-Google הוציא משימוש כבר בשנה שעברה), אלא שבפתרון זה מגישים את התוכן הייעודי על פי user-agent ולא על פי Query. פתרון זה עשוי להיות פשוט יותר להטמעה, אך כאמור, המלצת google לטווח הארוך היא להשתמש ב-Hybrid Rendering.

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

 

ב. שימוש ב- chrome 41.

כאמור, ה-WRS של Google מבוסס על דפדפן chrome 41, חובה להכיר את המגבלות של chrome 41 ולהתאים את מבנה האתר ליכולות הסריקה של Google. מומלץ להשתמש ב-chrome 41 על מנת לאתר בעיות, וככלי debugging. כניסה ל-Console (תחת Inspect) ב-Chrome 41 תציג לנו את רשימת הבעיות שהדפדפן נתקל בהן בעת טעינת הדף, אלה אותן התקלות ש-Google יתקל בהן. מודיעין יקר. בתמונה, אתר JS של לקוח שמתקשה בדירוגים, ה-GSC מראה שהדברים משתבשים בעת הרינדור, אך רק ב-Console (תחת Inspect) ב-chrome 41 יכולנו לראות מה הגורמים לבעיות:

 

 

בנוסף, ל-WRS של Google (המבוסס על Chrome 41) יש כמה מגבלות שחשוב להכיר:

 

 

 

ג. Graceful Degradation

בהמשך לסעיף הקודם, יש ליצור באתר יכולת התאמה עבור דפדפנים ישנים יותר/מתקדמים פחות, מלבד Google מצויה כאן תועלת גם עבור משתמשים העושים שימוש בדפדפן כזה. כאן נוכל רק להמליץ על שימוש ב- Transpiling/polyfilling, אך כמובן שהפיתוח שלכם יכול למצוא את הפתרונות המתאימים לו ובלבד שיבוצעו בדיקות התאמה על Chrome 41 כפי שצוין.

 

ד. אופטימיזציית רינדור

כפי שציינו לעיל, מהירות הטעינה היא פקטור משמעותית ובפרט באתרי JS העלולים להיות איטיים בטעינה הראשונית, כאשר תוכן שלוקח לו יותר מממספר שניות להתרנדר ככל הנראה יינטש, והאתר כולו יזחל ויסרק פחות. בנוסף, החל מיולי 18 מהירות טעינה הופכת להיות גורם דירוג במובייל, במידה והאתר איטי מהרגיל, לכן יש לשים דגש על מהירות הטעינה של דפי האתר בזמן הבנייה – מומלץ להיעזר במדריך אופטימיזציית הרינדור של הצוות הטכני ב-Google.

 

ה. כתובות URL – בעזרת History API

מומלץ לבנות את כתובות ה-URL בצורה ידידותית (Friendly), ובכל מקרה יש להימנע משימוש ב-Fragmented URLs (מכילים #) כי כאמור Google מתעלם מכל מה שמגיע אחרי ה-# ולא מאנדקס את ה-URL הייחודי. כמו כן, כדאי להימנע מכתובות Hashbang (#!). אמנם Google יודעים לזחול אותן, ולאחרונה אף הצהירו כי הם מתעלמים מכתובות escaped fragment מכיוון שהם לא זקוקים להם יותר, היות ויש להם את היכולת לרנדר JS ישירות בכתובת ה-#! במידת הצורך, אך ניסיוננו מראה כי צצות בעיות רבות סביב כתובות #!. המלצת Google היא להשתמש ב-History Api (כ-100 שניות צפייה מנקודה זו בסרטון) – זהו פתרון המאפשר יצירת כתובות URL ידידותיות באתרי Single page applications, ובאתרים העושים שימוש נרחב ב-JS.

ו. קישורים

כל קישור ל-URL שנרצה כי Google יזחל ויאנדקס חייב להיות ב- href. גוגל מתייחס אך ורק לקישורים המסומנים ב-href (נקודה זו בסרטון). בניית הקישורים ב-html תבטיח כי google זוחל ומגיע לכלל התכנים באתר.

ז.  אלמנטים מרכזיים ב-Inline

כפי שמשתמע מסעיף א', האלמנטים המרכזיים בדף מבחינת מנועי חיפוש (כלומר, התוכן המרכזי ותגיות ה-Meta – טייטל, קנוניקל וכדומה) צריכים להיות Inline על מנת לוודא כי הם נגישים למנועי החיפוש. כאמור, שימוש נכון ב-Hybrid Rendering\Dynamic Rendering יוצר מצב בו האלמנטים המרכזיים מרונדרים ב-server side  ומגיעים לדפדפן כשהם Inline ב-html.

ח. תמונות ב-Lazy loading

במידה ואתר עושה שימוש ב-Lazy loading עבור תמונות על מנת לשפר את מהירות הטעינה (כלומר, בטעינה ראשונית הדף נטען עם place holder היכן שהתמונה ממוקמת ורק כאשר התמונה נכנסת ל-view-port של הגולש, למסך שלו, נטענת התמונה עצמה), יש לוודא כי התמונות נגישות למנועי החיפוש. כאמור, מנוע החיפוש לא יוצר אינטראקציה משמעותית עם הדף. הוא לא גולל ולא מכניס את התמונה למסך שלו, כך שלמעשה מנוע החיפוש מרנדר את הדף אך לא רואה את התמונות (כפי שהזכרנו קודם, התמונות לא נטענות בטעינה הראשונית) ולא יכול לגשת אליהם. ישנם 2 פתרונות אפשריים:

1). הוספת התמונה בתגית </noscript> סביב אלמנט ה-<img>. התגית הזו מגדירה אלטרנטיבה לדפדפנים אשר אינם תומכים ב-,scripts וטוענת להם את התמונה בטעינה הראשונית. בצורה זו גוגל יוכל לגשת לקובץ התמונה דרך התגית הזו בקוד.

 

2). הוספת structured data סביב התמונה, כך שגוגל יוכל לגשת לתמונה ולאנדקס אותה דרך ה-structured data:

 

 

 

ט. מידע נוסף אודות Google

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

Google הוא Stateless 

הזחלן של google מוגדר כ-stateless, ולכן כל תוכן באתר אשר מוצג רק עבור גולשים ב-state מסוים – לדוגמה, רק עבור גולשים עם Cookies ספציפיים (למשל תוכן ייעודי למשתמשים רשומים), לא יהיה זמין ל-google. להלן מה ש-google מנקה בטעינת הדף, וכל תוכן שמסתמך על שמירת מידע באחד מהם לא יוצג עבור Google:

 

 

 

> Google משתמש ב-Caching

מנוע החיפוש משתמש בכבדות ב-Caching, וגם קבצי AJAX יכולים להיות ב-cache אצל Google. לכן יש לוודא שאם מתבצעים שינויים בתוך קבצי ה-JS יש להשתמש במנגנון גרסאות ב-URL שלהם על מנת ש-Google ידע לבצע קריאה מחודשת של הקובץ.

 

 

י. מה לא לעשות

– לא לחסום JS ב-robots.txt – מסיבות מובנות, אך משום מה זה עדיין practice נפוץ.

– לא להשתמש בקישורי Onclick עבור תוכן חשוב בדף – כפי שצוין, Google אינו מתנהג כגולש. תוכן אשר יצריך אינטראקציית משתמש על מנת להיטען, לא ירונדר על ידי google ולא יתאנדקס.

דוגמא לתוכן חשוב: סרגל ניווט נפתח. זוהי טעות נפוצה לשים את סרגל הניווט הנפתח מאחורי onclick – במצב כזה, google לא מרנדר את סרגל הניווט, על כל המשתמע מכך (לא זוחל את הקישורים המופיעים בו ולא יודע להעריך את חשיבות הדפים המקושרים רוחבית). טיפ לבדיקת תקינות: בדיקה ב-chrome 41.  אם סרגל הניווט הנפתח (או כל דבר אחר שתרצו לבדוק) נמצא ב-DOM בסיום טעינת הדף, אז הוא יהיה שם גם עבור Google, אשר יוכל לסרוק אותו בסיום הטעינה הראשונית. אם לא, אז התוכן חבוי ומצריך אינטראקציית גולש על מנת להיטען, ו-Google לא ירנדר ולא יאנדקס אותו.

– לא להשתמש בהפניות JS – הפניות צריכות להיות ברמת השרת (301). הניסיון הנרחב שלנו מלמד כי הפניות JS יוצרות בעיות גם בזיהוי ההפניה וגם בהעברת "link Juice". (למרות רמיזות של Google שהם מסתדרים איתן), זו פינה שעדיף לא להיכנס אליה שלא לצורך.

* בשולי הדברים חשוב לציין שכל האמור לעיל נוגע רק ל-Google – מנועי חיפוש אחרים נמצאים הרחק מאחורי Google בכל הקשור ליכולות זחילה וסריקה של JS, ויש לקחת זאת בחשבון. תוכלו לבדוק בחשבון ה-Google Analytics שלכם מהו אחוז התנועה האורגנית המגיעה ממנועי חיפוש אחרים. ניתן לבדוק תחת – Acquisition > Campaigns > Organic Keywords > Source.

*******************************************

Case Study

נצרף כאן תיאור מקרה קצר בו פתרנו בעיית JS של לקוח שלנו. מדובר בלקוח שהוא אוטוריטה בתחומו, וככזה הוא גם בעל אתר גדול, המביא תנועה רבה. הלקוח מחזיק אתר מובייל נפרד, המשלב הרבה JavaScript באזורים שונים באתר – ובאזורים אלו Google התקשה לרנדר את תוכן הדף. כל זאת כאשר ברקע ישנה היערכות למעבר ל-Mobile first Index, ולכן ישנה חשיבות גבוהה להתאמת דפי המובייל של האתר למנועי החיפוש.

 

לדוגמא, כך נראתה בדיקה ב-Fetch as Google בחשבון ה-GSC של הלקוח:

 

 

Google לא הצליח לרנדר את תוכן הדפים. כמובן שבדיקה הראתה כי אין קבצים חסומים, כך שידענו כי קיימת בעיה, אך לא ידענו מהם הגורמים לה. על מנת לאתר את הגורמים ישבנו יחד עם צוות הפיתוח של הלקוח, התקנו אצלם דפדפן ,Chrome 41 ובעזרת בדיקה פשוטה ב-Console ב-Developer tools של הדפדפן הצליח צוות הפיתוח לפתור את הבעיות במהירות וביעילות. לאחר התיקון Google כעת מצליח לרנדר את תוכן דפים אלו.

 

כך נראה דף לדוגמא לאחר התיקון:

 

 

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

 

ב-GSC ניתן לראות עליה יפה ב-Impressions במובייל בדפים אלו מיד לאחר התיקון:

 

 

כמו כן ניתן לראות מגמה דומה ב-Clicks ממובייל לדפים אלו:

 

 

כמובן אותה המגמה משתקפת גם בנתוני ה-Users ב-Google Analytics:

 

 

מקרה זה ממחיש את חשיבות העבודה עם Chrome 41.

 

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

 info@operad.com

 

 

 

 

 

 

*******************************************

המקורות החשובים ביותר להבנת הנושא הם כדלהלן:

– ראשית יש לצפות בסרטון זה:

https://www.youtube.com/watch?v=PFwUbgvpdaQ&feature=youtu.be – סרטון רשמי של גוגל על התאמת JS למנועי חיפוש.

– לאחר מכן בסרטון זה:

https://www.youtube.com/watch?v=83As5qYrMno – סרטון של Google שמדריך מפתחים איך לבנות אתר JS מותאם ל-Google

למי שרוצה לקרוא ולהעשיר/לתקן/להוסיף:

 

https://www.elephate.com/blog/ultimate-guide-javascript-seo/ -מדריך כללי
https://www.elephate.com/blog/chrome-41-key-to-website-rendering/ – שימוש ב-chrome 41

http://www.stateofdigital.com/javascript-seo-crawling-indexing/ – הסבר מעולה על מנגנוני זחילה וסריקה והבעיה ב-JS

https://hackernoon.com/polyfills-everything-you-ever-wanted-to-know-or-maybe-a-bit-less-7c8de164e423 – הסבר על pollyfills (לרפרף)

https://www.searchenginejournal.com/javascript-seo-like-peanut-butter-and-jelly-thanks-to-isomorphic-js/183337/ – מה זה Isomorphic

https://webmasters.googleblog.com/2017/12/rendering-ajax-crawling-pages.html – הודעה של גוגל על התעלמות מ-escaped freagement

http://www.stateofdigital.com/javascript-seo-the-definitive-resource-list/ – מאגר מידע גדול על נושא ה-JS

https://moz.com/blog/javascript-seo – מדריך כללי ל-SEO&JS

https://www.briggsby.com/dealing-with-javascript-for-seo/ – מדריך כללי נוסף מצוין

https://www.elephate.com/blog/javascript-vs-crawl-budget-ready-player-one/ – הסבר על השלכות ה-JS על תקציב הזחילה

https://www.elephate.com/blog/everything-you-know-about-javascript-indexing-is-wrong/ – מסקנות מהניסוי הכי גדול שנעשה בנושא

http://diveinto.html5doctor.com/history.html – הסבר על History Api, להתמקד בחלק "The Why".

https://universal.angular.io/ – אתר Angular Universal הרשמי.

 

 

 

 

<   |   >