IMPORTHTML מחזיר כלום ו-IMPORTXML מחזיר #N/A כי הנתונים לא נמצאים ב-HTML - הם מגיעים אחר כך דרך JavaScript. ארבע דרכים להכניס אותם לגיליון בכל זאת, מדורגות לפי כמה זמן כל אחת ממשיכה לעבוד.
עיקרי הדברים
- פונקציות הייבוא של Google Sheets מושכות HTML גולמי ולעולם לא מריצות JavaScript. אם הנתונים לא נמצאים ב"הצג מקור", שום נוסחה לא תמצא אותם.
- לפני שמושיטים יד לדפדפן, פתחו את לשונית הרשת. רוב העמודים הדינמיים מושכים את הנתונים מנקודת קצה JSON שאפשר לקרוא לה ישירות - וזה מהיר, זול ויציב בהרבה מרינדור.
- Apps Script יכול למשוך, אבל גם הוא לא מרנדר JavaScript. הוא פותר אימות ותזמון, לא את בעיית הרינדור.
- רינדור בדפדפן headless הוא מוצא אחרון והיקר ביותר לתחזוקה. השתמשו בו רק כשבאמת אין נקודת קצה של נתונים מאחורי העמוד.
אתם מדביקים כתובת ב-IMPORTHTML, ומקבלים תא ריק. מנסים IMPORTXML עם XPath שהעתקתם מהדפדפן, ומקבלים #N/A. לעמוד ברור שיש טבלה - אתם מסתכלים עליה.
הסיבה פשוטה. Sheets מושך את מסמך ה-HTML הגולמי שהשרת מחזיר. עמודים מודרניים מחזירים לעיתים קרובות מעטפת כמעט ריקה וממלאים אותה ב-JavaScript אחרי שהדפדפן רץ. Sheets לעולם לא מריץ את ה-JavaScript הזה, ולכן הוא רואה את המעטפת.
קודם כל לאשר את האבחנה
פתחו את העמוד, הציגו מקור (לא את הכלי בדיקה - ממש view-source), וחפשו ערך שאתם רואים על המסך. אם הוא לא שם, העמוד מרונדר בצד הלקוח ושום נוסחת Sheets לא תעבוד עליו לעולם. אם הוא כן שם, ה-XPath שלכם שגוי והבעיה פשוטה בהרבה ממה שחשבתם.
זה לוקח שלושים שניות וקובע את כל מה שאחריו.
אפשרות 1: למצוא את נקודת הקצה של הנתונים (לנסות ראשון)
אם JavaScript שם נתונים על העמוד, הוא קיבל אותם ממקום כלשהו - כמעט תמיד בקשה לנקודת קצה JSON. הרבה יותר קל לעבוד מול נקודת הקצה הזו מאשר מול העמוד.
פתחו את כלי הפיתוח בדפדפן, עברו ללשונית Network, סננו ל-Fetch/XHR, ורעננו את העמוד. עברו על התשובות וחפשו את זו שמכילה את הנתונים שלכם. כשתמצאו, יש לכם כתובת שמחזירה JSON מובנה ונקי, בלי ניתוח HTML ובלי רינדור.
זה עדיף על רינדור בכל ממד. זה מהיר יותר, כמעט לא עולה להריץ, והרבה יותר יציב - עיצוב מחדש שמשנה כל class בעמוד לרוב משאיר את נקודת הקצה של הנתונים ללא שינוי.
ברגע שיש לכם את נקודת הקצה, פונקציית Apps Script קטנה יכולה למשוך אותה, לחלץ את השדות הדרושים, ולכתוב אותם לגיליון לפי לוח זמנים. זה בדרך כלל שלושים שורות קוד והוא ישרוד כמה עיצובים מחדש.
אפשרות 2: משיכה ב-Apps Script
משיכת URL ב-Apps Script יכולתית יותר מנוסחאות הייבוא - אפשר לקבוע כותרות, לטפל באימות, לעקוב אחרי התחברות, לנתח JSON, ולתזמן הרצות עם טריגר מבוסס זמן.
מה שהוא לא יכול לעשות זה להריץ JavaScript. הוא מושך, בדיוק כמו הנוסחאות. לכן Apps Script הוא הכלי הנכון כשמצאתם נקודת קצה של נתונים, או כשהעמוד מרונדר בשרת אבל דורש כותרות או אישורי גישה. הוא לא פתרון לבעיית הרינדור עצמה.
אפשרות 3: שירות רינדור
כשבאמת אין נקודת קצה נגישה - הנתונים מגיעים דרך מנגנון שאי אפשר לשחזר, או שהם מורכבים מכמה מקורות בצד הלקוח - צריך משהו שבאמת מריץ דפדפן.
הדפוס המעשי הוא לשים את הדפדפן מחוץ לגיליון. שירות קטן, שרץ איפה שכבר יש לכם איפה להריץ דברים, טוען את העמוד בדפדפן headless, מחלץ את מה שצריך, ואז כותב לגיליון דרך Sheets API או חושף נקודת קצה פשוטה ש-Apps Script קורא לה.
היו מפוכחים לגבי העלות. דפדפנים headless איטיים ביחס למשיכה, צורכים זיכרון אמיתי, והם החלק השביר ביותר בכל מערכת איסוף - הם נשברים כשהעמוד משתנה, כשמופיע דיאלוג הסכמה, וכשהאתר מוסיף הגנת בוטים. זה פרויקט אמיתי עם תחזוקה אמיתית, לא נוסחה.
אפשרות 4: לחשוב מחדש על הדרישה
שווה לשאול לפני שבונים משהו: האם לאתר יש API רשמי, ייצוא, או פיד RSS? האם יש מערך נתונים ציבורי עם אותו מידע? האם הנתונים באמת צריכים להיות בגיליון, או שהגיליון הוא פשוט המקום שבו הדיווח קורה כרגע?
מספר מפתיע של בקשות לסקרייפינג מעמודים דינמיים מתפוגגות כשמישהו בודק אם המקור מפרסם את הנתונים בדרך אחרת.
השוואה
| גישה | מטפלת ב-JS | מאמץ | יציבות |
|---|---|---|---|
| IMPORTHTML / IMPORTXML | לא | דקות | נמוכה |
| Apps Script על נקודת קצה של נתונים | לא נדרש | שעות | גבוהה |
| Apps Script על HTML מרונדר בשרת | לא | שעות | בינונית |
| שירות דפדפן headless חיצוני | כן | ימים עד שבועות | נמוכה עד בינונית |
| API רשמי או ייצוא | לא נדרש | שעות | הגבוהה ביותר |
הערות מעשיות
- שמרו במטמון באגרסיביות. אם הנתונים משתנים יומית, אל תמשכו אותם בכל פעם שהגיליון מחשב מחדש. כתבו לגיליון מוסתר לפי לוח זמנים ושהנוסחאות הגלויות יקראו משם.
- כתבו חותמת זמן. כל כתיבה אוטומטית צריכה לחתום מתי היא רצה. גיליון שמציג נתונים ישנים בלי חיווי שהם ישנים הוא הדרך שבה מתקבלות החלטות שגויות בביטחון מלא.
- טפלו במקרה הריק במפורש. אם המשיכה מחזירה כלום, אל תדרסו את הערכים הקודמים בריקים. שמרו את הנתונים הטובים האחרונים וסמנו את הכשל.
- הגבילו קצב. טריגר שרץ כל חמש דקות מול אתר של מישהו הוא גם לא מנומס וגם דרך טובה להיחסם.
- בדקו את התנאים. העמדה המשפטית משתנה לפי אתר, לפי מדינה ולפי מה שנאסף. שווה מבט לפני שמאטמטים משהו בנפח.
התשובה הקצרה
חפשו את נקודת הקצה של ה-JSON. ברוב המקרים היא קיימת, פשוט לקרוא לה מ-Apps Script, והיא תמשיך לעבוד הרבה אחרי שכל גישה מבוססת HTML הייתה נשברת. הושיטו יד לדפדפן headless רק אחרי שאישרתם שאין מאחורי העמוד למה לקרוא.
אם יש לכם מקור שמתנגד לכל אלה, קבעו שיחה ללא עלות. קשור: איסוף נתונים מאתר אל Google Sheets, איך לאסוף נתונים בלי להיחסם, ולמה סקרייפרים נשברים.
שאלות נפוצות
למה IMPORTHTML מחזיר כלום לעמוד שלי?
כי Google Sheets מושך את ה-HTML הגולמי שהשרת מחזיר ולעולם לא מריץ JavaScript. הרבה עמודים מודרניים מחזירים מעטפת כמעט ריקה וממלאים אותה בדפדפן, ולכן Sheets רואה את המעטפת ולא את התוכן שאתם רואים על המסך. אשרו את זה בשלושים שניות: פתחו view-source בעמוד וחפשו ערך שאתם רואים. אם הוא נעדר מהמקור, שום נוסחת Sheets לא תשלוף אותו לעולם.
האם Google Apps Script יכול לרנדר JavaScript?
לא. משיכת URL ב-Apps Script יכולתית יותר מנוסחאות הייבוא - היא יכולה לקבוע כותרות, לטפל באימות, לנתח JSON ולרוץ לפי לוח זמנים - אבל היא מבצעת משיכה, לא רינדור דפדפן. היא פותרת בעיות אימות ותזמון, לא את בעיית הרינדור. המקום שבו Apps Script הופך חזק באמת הוא כשאיתרתם את נקודת הקצה של ה-JSON מאחורי העמוד, כי אז לא נדרש רינדור בכלל.
איך מוצאים את נקודת הקצה של ה-JSON מאחורי עמוד?
פתחו את כלי הפיתוח בדפדפן, עברו ללשונית Network, סננו ל-Fetch/XHR, ורעננו את העמוד. סרקו את התשובות וחפשו את זו שמכילה את הערכים שאתם רוצים. כשתמצאו, יש לכם כתובת שמחזירה נתונים מובנים ונקיים, וזה מהיר, זול ויציב בהרבה מניתוח HTML מרונדר - עיצוב מחדש שמשנה כל class לרוב משאיר את נקודת הקצה של הנתונים ללא שינוי כלל.
מתי דפדפן headless באמת נחוץ?
רק כשבאמת אין נקודת קצה נגישה מאחורי העמוד - למשל כשהנתונים מגיעים דרך מנגנון שאי אפשר לשחזר, או כשהם מורכבים בצד הלקוח מכמה מקורות. זה מוצא אחרון כי הוא איטי ביחס למשיכה, צורך זיכרון אמיתי, והוא הרכיב השביר ביותר בכל מערכת איסוף: הוא נשבר על שינויי פריסה, על דיאלוגי הסכמה חדשים, וכשהאתר מוסיף הגנת בוטים. התייחסו אליו כאל פרויקט עם תחזוקה שוטפת, לא כאל תחליף לנוסחה.
כל כמה זמן ריענון מתוזמן של גיליון צריך לרוץ?
התאימו את זה לתדירות שבה נתוני המקור באמת משתנים, לא לתדירות שבה אתם מסתכלים על הגיליון. אם הנתונים מתעדכנים יומית, טריגר יומי שכותב לגיליון מוסתר הוא הנכון, כשהנוסחאות הגלויות קוראות משם ולא מושכות מחדש. הרצת טריגר כל כמה דקות מול אתר של מישהו אחר היא גם לא מנומסת וגם דרך יעילה להיחסם. כתבו תמיד חותמת זמן לצד הנתונים כדי שאף אחד לא יטעה בין ערכים ישנים לעדכניים.
להמשך קריאה
שירות רלוונטי
Web Scraping וחילוץ נתונים
סקרייפינג וצינורות נתונים אמינים שמספקים נתונים נקיים.
על הכותב
יהונתן סעדיה
מהנדס פרילנסר לאוטומציה, אתרים ו-MVP
אני יהונתן סעדיה, מהנדס בכיר שבונה אוטומציה עסקית, אתרים מותאמים ומוצרי MVP לעסקים קטנים ובינוניים בארה"ב, אירופה וישראל. המדריכים האלה נכתבים מתוך עבודה אמיתית עם לקוחות, לא מתיאוריה.
בוא נעבוד יחדיש לך פרויקט דומה?
ספר לי מה אתה מנסה להפוך לאוטומטי או לבנות, ואומר לך מהי הדרך המהירה והאמינה ביותר ליישם את זה.