ישי שמש, K logic

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

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

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

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

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

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

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

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

1. חינוך קשוח – חשוב שכל מי שקשור לאתר באופן ישיר או עקיף, החל מהצוות הטכני וכלה בסמנכ"ל פיתוח עסקי, יהיה מודע לסכנות שיכולות לנבוע משכפול תכנים וידאג לשלב את גוף ה-SEO בכל שיתוף פעולה בין אתרים שכולל סינדיקציה של תכנים.

2. תחימת החשיפה לסיכון – ההמלצה הברורה שלנו עבור אתרים שמבצעים סינדיקציית תוכן, היא לתחום את סך התכנים לגביהם מבוצע שיתוף פעולה בכ-30% מסך התכנים המקוריים שפורסמו באתר (המספר עשוי להשתנות קצת בהתאם ל-trust של האתר).

3. לחשוף טפח, להסתיר טפחיים – במידת האפשר רצוי לשתף רק גרסא מקוצרת של המאמר.

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

5. וכמובן הקפדה ברמת הטכנית על כל הדברים המוכרים בדגש על:
a. חסימה (תג META + robots.txt) עבור אזורים גדולים של תוכן שמשולבים באתרים אחרים.
b. קישור עם URL אבסולוטי שמוביל לאתר המקורי בגוף המאמר.
c. שימוש בתג canonical עבור כל אחד מהעמודים באתר.
d. שימוש ב-Google XML sitemap בכדי להאיץ אינדוקס של תכנים חדשים.

  עומר שובל, iSEO – נטוורקינג

לפני כשנה העלינו עיצוב חדש באתר יד2 שגרר שינויים מרובים – הוספת אלמנטים בדפים, שינויי גרפיקה, סרגלי ניווט חדשים, footer חדש ועוד. בזמנו, מטעמי נוחות, העדיפו ביד2:

א. לבצע את כל השינויים בבת אחת.
ב. לעשות את בדיקות ה- QA של ה- SEO על הגרסה החדשה באתר (ב- live).

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

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

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

הפעלתי את האפליקציה וקיבלתי רשימה מאוד ארוכה של דפי טעות שאותה יכולתי לנתח. לאחר בדיקת מספר כתובות מהרשימה הפתרון היה כבר מול עיני: יד2 השתמשו בקוד החדש ב- URL-ים רלטיביים ובטעות הפנו לכתובות שאינן קיימות באתר – ליתר דיוק, עשרות אלפי כתובות לא קיימות, שגדלו באופן אקספוננציאלי, שכולן מחזירות דפי 404.

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

כיצד ניתן להימנע ממקרים דומים ? מספר המלצות:

1. אל תאשרו ללקוח להתחמק מפתיחת אזור QA שבו תוכלו לבצע את כל הבדיקות לפני שמעבירים את הגרסה ל- live.

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

3. עשו בדיקות באופן שוטף על הלוגים של האתר – אם מדובר בקבצים גדולים, היעזרו בפקודת grep. כך תמצאו תקלות הרבה יותר מהר מאשר לחכות ל- webmaster tools של גוגל שיציג אותן (מה גם שלא תמיד תקבלו אינדיקציה ב- webmaster tools, גם אם יש תקלות). במיוחד מומלץ לבדוק מספר ימים לפני שינוי ומספר ימים אחרי השינוי באתר על מנת לוודא שאתר הלקוח ממשיך להתנהל באופן תקין.

4. חפשו סימנים מזהים גם במנועי החיפוש – אם פקודת site: מציגה מספרים קטנים מאוד או גדולים מאוד יחסית לכמות הדפים שהתקבלה לפני שינוי שבצעתם – הנושא שווה בדיקה.

5. עברו על האתר "מנקודת המבט" של גוגל – אם יש לכם אפשרות, הפעילו רובוט שלכם שיבצע ניטור לכמות הדפים וכתובותיהם באתר הלקוח (מומלץ בשוטף ולא רק בתקופת שינויים). אתם תתפלאו אילו דברים ניתן למצוא.

אני נעזר בתוכנת iSEO שבאופן אוטומטי "דואגת" לעשות עבורי כל יום את המלצות 3, 4 ו- 5 מלמעלה אבל לא מוותר גם על שימוש באפליקציית ה- LogParser, שהצילה את יד2 בזמנו מעונש וודאי בגוגל.

  גלעד ששון, Nekuda

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

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

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

טעות/מלכודת נפוצה נוספת שגרמה לי לכאבי ראש בעבר הרחוק היא הגדרות גורפות באמצעות regular expressions בקבצי .htaccess (.rewrite/redirects etc)– אם אתם לא בטוחים לגמרי מה הולך לקרות, מוטב לבדוק בסביבה מבודדת ולא באתר החי.

  פבל ישראלסקי, AskPavel

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

אחד הלקוחות שלי משתמש בבר ניווט פנימי עם טאבים בעמודים מסוימים. זה נפוץ בכל מני אתרי אפילייט שיש להם בעמוד המכירה מעבר בין טאבים שונים כגון: review, download, testimonials וכו' – עבור אותו עמוד שבו נמצאים. מה שקורה זה שאותו לקוח התחיל לרדת בדירוגים מאז עדכון הפנדה מסיבה לא ברורה – התוכן איכותי, ייחודי, מתחדש, פרופיל קישורים טבעי וכו'. העניין הוא שברוב המקרים הטאבים הללו משאירים את הגולש באותו URL ורק התוכן מתחלף (יש כאלו שמוסיפים # ל-URL המקורי). אבל אצל הלקוח המבנה היה שונה. בגלל שזמן הטעינה של האתר היה כל כך מהיר, קשה היה לשים לב שהטאבים הובילו ל-URL שונה בהיררכיה אחת גבוה יותר מעמוד האב. כששמתי לב לזה הלכתי לדוח שאני מאד אוהב ב-webmaster tools שנקרא html suggestions ושמתי לב שיש באתר אחוז מאד גבוהה של טייטלים ודסקריפשנים משוכפלים. מסתבר שלכל טאב היה את אותו הטייטל והדסקריפשן כמו של עמוד האב. אז אם בכל דף כזה היו כ- 10 טאבים, זה אומר שלדומיין היו 10 טייטלים ודסקריפשנים זהים. עכשיו דמיינו שלדומיין הזה היו מאות דפים מהסוג הזה, מה שמוסיף לדומיין אחוז גבוה מאד של דופליקציה 🙂

זה כמובן נעשה בתום לב, כנראה שמי שתכנן את האתר התייחס לטאבים כאילו הם חלק אינטגרלי מעמוד האב – אך מבחינת גוגל כל עוד יש להם URL ייחודי הם דפים נפרדים לכל דבר. מה שעשינו זה לשכתב את הטייטלים והדסקריפשנים שלהם כך שירחיבו את מה שנכתב בתגים של עמוד האב. כעבור 22 יום האתר חזר למיקומים ואף התברג על ביטויים חדשים. הטראפיק האורגני גדל בכמה מאות אחוזים בגלל שכעת הוא גם טירגט הרבה ביטויי זנב ארוך שלא היו קיימים קודם.

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

  שוקי גלילי

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

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

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

כש-SEO הופך לחזות הכל, נוצרת מהר מאד סטגנציה בתנועה הישירה, בתנועת ה-Referrals ב-Brand Search וכו'. בסופו של דבר, זה גורם לפעילות סביב האתר להיראות לגוגל פחות טבעית ומזיק ל-Trust שלו.

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

  אביב מנוח, Usearch McCann

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

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

  איתן יריב, WAO

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

התברר לנו שמדובר היה בגרסת האתר הקודם לאתר הקיים, אתר שמדפיו התקיימו הפניות 301 לדפים באתר החדש בהתאמה ואלו (ההפניות) התבטלו עם מעבר האחסון- קובץ השגיאה המותאם אישית אשר טיפל בהם לא הועבר במסגרת הקבצים מחברת אחסון אחת לאחרת ולא הוגדר על ידי חברת האחסון בהנחיותינו עם המעבר.

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

מהמקרה האמור למדנו והוספנו לצ'ק ליסט של פעולות חיוניות את נושא בחינת קיום ההפניות לאתר מדפי האתר על גרסאותיו הקודמות ולאורך חייו

  שני סלמה, iLevel

מניסיוני בין הלקחים החכמים יותר שהפקתי: לקוח שעושה בעיות בשלב של חתימת החוזה, יעשו בעיות במהלך כל הקמפיין, וקמפיין זה מטרתו להיכשל.

  מיכל כהן, WebGuru

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

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