בקרב מקדמי אתרים, מנהלי אתרים ומתכנתים יש עדיין סטיגמה שגוגל לא יודע להסתדר כמו שצריך עם סקריפטים שבנויים על Javascript וספריות קוד שונות המבוססות עליה כמו למשל Angular או React.
ואכן, בעבר אתרים שטענו תוכן בזמן אמת לא תמיד התאנדקסו טוב בגוגל וגם הביצועים שלהם בדירוגים לא היו טובים במיוחד.
גם קישורים שנפתחו באמצעות JS ולא עשו שימוש בתג הרגיל (<a href=…>) נחשבו לקישורים בעייתיים ואתרים מסוימים כמו אתרים לפרסום של תוכן חופשי או אינדקסים של עסקים עשו בכך שימוש כדי לא להעביר קרדיט / "מיץ קישורים" לאתרים אליהם הם הפנו.
למרבה המזל, זה כבר מזמן לא המצב, שהוא עדיין לא מושלם, אבל הרבה יותר טוב מאשר בעבר.
אחרי הכול, אין כמעט אתר שלא עושה שימוש בסקריפטים או אלמנטים אינטראקטיביים בזמן אמת. (זאת בניגוד לאתרים שיכולים לטעון HTML באופן דינאמי, אך הקוד הסופי שהדפדפן קורא עדיין סטטי ברובו).
מה גוגל אומרת בנושא 🤔?
לאור הפסקה הקודמת, גוגל לא יכולה להתעלם מהמצב כיום ולכן היא מפרטת באופן נרחב ביותר כיצד לבנות אתרים שעושים שימוש ב-JS ועדיין יהיו ידידותיים עבור האלגוריתם שלה.
חשוב לציין שזה לא בהכרח יהיה נכון לכל מנוע חיפוש, כך שאם למשל אתם פונים לשווקים סגורים כמו סין (באידו) או רוסיה (יאנדקס), ייתכן שהפתרונות שגוגל מציעה לא יהיו מספיק טובים.
למעשה, יש סדרה שלמה של סרטונים בנושא, אבל כדי לא לשלוח אתכם לצפות בכמעט שעה של סרטונים (לפחות בזמן שאתם קוראים את המאמר), הנה השאלות והתרחישים הכי חשובים:
האם גוגל בכלל יכול לקרוא Javascript ומהו סדר העדיפויות שלו?
כמו שכבר ציינתי, התשובה היא חיובית. גוגל יכול לפענח את רוב הסקריפטים שמבוססים על השפה ולשלוף את התוכן שהם "פולטים" אל הדפדפן, בין אם הם מורצים בדפדפן עצמו בצד הלקוח (Client Side) ואם בשרת (Server Side).
לעומת זאת, מבחינת סדר עדיפויות, אם גוגל מגיע לעמוד חדש או עמוד שהשתנה, הוא קודם כל ייקרא את הקוד הרגיל ורק לאחר מכן יבצע רנדור (פיענוח) או הפעלה של הפלט מקוד ה-JS. בדרך כלל זה מתבצע בשני גלים שונים ולא באותו הביקור.
במילים אחרות, מדובר בתהליך איטי 🐢, וגוגל רומזת שאם מהירות האתר חשובה לכם, עדיף שלא תתבססו רק על סקריפטים כאלו.
כיצד גוגל מבחינה בין קבוצות של אתרים שעושים שימוש ב-JS ולמה זה בכלל חשוב?
גוגל מבצעת הבחנה בין שני סוגי אתרים מרכזיים:
✔️ האתרים מהסוג הראשון הם כאלו שבהם השימוש ב-JS הוא בעיקר על מנת להעשיר את התוכן כמו למשל באמצעות הוספת אנימציות או אפקטים שונים וכל התוכן המרכזי עדיין נמצא בתוך קוד ה-HTML. הסקריפטים כאן בדרך כלל רצים במחשב המקומי ולכן הם יחסית פחות מורכבים.
על מנת לראות את הפוטנציאל האורגני ותוך כמה זמן נכפיל לך את ההכנסות
ניתן לחייג למספר 052-9095200 או למלא את הטופס:
✔️ הסוג השני של האתרים הם אתרים שמבוססים על JavaScript באופן בלעדי ואפשר לתאר אותם כאפליקציות או "תוכנה כשירות" (Software as a Service). באתרים אלו יש מעין מעטפת (Shell) שלתוכה נטען כל שאר התוכן בזמן אמת מהשרת.
בביקור הראשון, כל מה שגוגל יראה רק את המעטפת בלי התוכן המרכזי, וכאן בדיוק מתחילה הבעיה….
אם אתם לא בטוחים באיזה סוג של אתר מדובר, גוגל ממליצה פשוט להסתכל על קוד המקור או לכבות את פיענוח ה-JS של הדפדפן (ליתר ביטחון, עדיף לעשות זאת עם תוסף).
אם כל התוכן עדיין קריא, סימן שלא מדובר באתר שהסקריפטים בו הם הכרחיים.
כמובן שגם לאחר שאתם מחזירים את פיענוח ה-JS, חשוב גם לבדוק כיצד גוגל רואה את התוכן, את זה הכי קל לעשות דרך ה-Mobile Friendly Test.
אפליקציות ווב כגון Angular או React והגשה בצד השרת
מבלי להיכנס יותר מדי ליסודות הפיתוח בסביבות תכנות שונות, חשוב לדעת כי Angular או סביבות דומות יכולות ליצור אפליקציות רשת אשר בהן כל העיבוד מתרחש בצד השרת ללא שליחת סקריפטים מקומיים פשוטים.
כך אומנם נוצרת אפליקציה שנוחה מאוד למשתמשים, אך מבחינת גוגל ומנועי חיפוש אחרים היא בעייתית מכיוון שכל התוכן נמצא כאמור בתוך מעטפת אחת והוא ייקרא אותו רק ב"גל השני".
ההמלצה הראשונה של גוגל למפתחים ב-Angular, React או vue.js היא להפריד בין התכנים השונים באמצעות ההגדרות הפנימיות של תגי המטא בקוד אותו אתם כותבים (כברירת מחדל כל תגי המטה שישלחו לדפדפן יהיו זהים). כך לפחות תהיה לכם הפרדה מינימלית בין התכנים, שהיא המפתח לכל SEO טוב.
אך עדיין נשארנו עם מגבלת "הגל השני". יש מספר פתרונות שניתן להשתמש בהם כגון "הגשה בצד שרת" (Server Side Rendering) או "רנדור מראש" (Pre Render). בשתי השיטות מדובר למעשה בהגשת התכנים באופן דומה להגשת HTML רגילה.
פרקים 6,5 ו-7 עוסקים בשלושת סביבות הפיתוח שהזכרתי למעלה:
למשל, ב-Angular יש להטמיע את ה- Angular Universal App, טכניקה שמאפשרת לאפליקציה לשלוח קוד סטטי שהוא למעשה קוד HTML אותו הרובוטים של מנועי החיפוש יכולים לקרוא גם ב"גל הראשון".
ל-React יש אפשרות דומה להצגה של דפים עם קוד HTML באמצעות React Snap. באופן הפשוט ביותר, שיטה זו מפעילה סוג של זחלן פנימי אשר יוצר את הקבצים על גבי השרת וכך גם כאן גוגל ומנועי חיפוש אחרים יוכלו לקרוא את התוכן המלא גם ב"גל הראשון".
למרות שזהו פתרון נוח שלא מפר את ההנחיות של גוגל, הוא עשוי להיות איטי יחסית לפתרון הדינאמי עליו אסביר מיד ולזלול משאבים מהשרת עצמו.
הגשה דינאמית
אפשרות אחרת היא הגשה כפולה באופן דינאמי (Dynamic Rendering): הגשה אחת מתבצעת באפליקציה והשנייה מתבצעת כקוד HTML רגיל. במקרה זה שני המקורות חייבים להיות זהים, אחרת אתם עשויים להסתכן במיסוך שהוא אסור על פי גוגל. (במיסוך מה שהגולש רואה הוא לא מה שגוגל רואה).
זוהי למעשה הדרך המומלצת על ידיד גוגל (ראו את טבלת ההשוואה בסוף) והיא מתאימה לאתרים גדולים המשתנים באופן תדיר ולא יכולים להרשות לעצמם האטה בקצב האינדוקס של גוגל.
גוגל ממחישים אותה בסרטון האחרון (מספר 8).
יצירת עמודים סטטיים לתוכן שנקרא בחלקים (Lazy Load)
Lazy Load היא מתודה יחסית פשוטה שבה השרת שולח כל פעם חלקים נוספים מהדף, למשל, כאשר אתם מסתכלים על רשימה ארוכה של מוצרים וכל פעם מתווספים עוד שלוש שורות עם שלושה מוצרים בכל טור, עד שמגיעים לסוף "המוחלט" (או הפוטר).
אם תרצו שגוגל יוכל לקרוא את כל המוצרים האלו גם בגל הראשון, פשוט צרו עמודים שלכל אחד מהם URL או קישור קבוע (permalink). אפשר למשל לעשות את זה דווקא בראש הדף.
על מנת להשלים את ההתאמה, ניתן גם לשנות את ה-URL בראש הדפדפן באופן דינאמי בכל טעינה נוספת של מוצרים לזה עם המספור הנכון (למעשה ה-permalink).
במצב זה, אם המשתמש ילחץ על כפתור Back 🔙 או יעתיק את הקישור וישתף אותו עם אחרים, הדפדפן יציג את הבלוק הקודם בצורה תקינה שלא תיצור בלבול.
דגשים נוספים:
- כדאי לדעת שאם אתם משתמשים בג'אווה סקריפט באופן בלעדי על מנת ליצור קישורים (אירוע On Click), אתם יוצרים בעיה גם עבור קוראי מסך ובעלי מוגבלויות, לא רק עבור מנועי חיפוש מסוימים.
- אל תשתמשו בקישורים עם # על מנת לעבור בין דפים (השימוש בסולמית הוא עבור חלקים שונים באותו העמוד), אלא רק על ידי קריאת ההיסטוריה של הדפדפן.
- במידה ואתם רוצים לבדוק כיצד גוגל רואה עמוד מסוים כבר במהלך הפיתוח על השרת המקומי, עשו שימוש בכלים כמו Ngrok על מנת להפוך את הכתובות לציבוריות.
- אם אתם לא בטוחים אם עמוד מסוים נוסף לאינדקס או לא ואיך הוא בדיוק נראה, תמיד תוכלו להשתמש בשורה העליונה ב- Search Console.
לסיכום
גם אם תכנות וקוד רחוקים מכם מרחק שנות אור, חשוב להיוועץ עם מקדם האתרים שלכם כבר בזמן שהוא מבצע הערכה ראשונית לאתר (Audit).
מקדם אתרים מיומן שמבין קצת כיצד אתרים עובדים מאחורי הקלעים, יוכל לאתר את השימוש בסקריפטים כאלו ולבצע את הבדיקות שתוארו כאן.
אתם יכולים גם להציג לו רשימת Audit מוכנה ולכלול שם באופן ברור את הנראות של העמודים הכוללים JS בגוגל (כפי שציינתי בהתחלה, אין כמעט אתרים שלא עושים שימוש כלשהו ב-JS).
