התשובה הקצרה
הסרת אפליקציית Shopify אינה הוכחה שכל מה שהיא הוסיפה ל־Theme נעלם. אפליקציות שמותקנות באמצעות Theme App Extension אמורות להסיר את הבלוקים שלהן בעת הסרה, אבל אפליקציה שערכה בעבר קבצי Liquid, הוסיפה Script Tag או ביקשה להדביק קוד ידנית יכולה להשאיר snippets, קבצי JavaScript, CSS, פיקסלים או קריאות חיצוניות. לכן לא מוחקים שורות לפי שם שנראה חשוד: קודם מזהים את מקור הקוד, בודקים אם הוא עדיין בשימוש, מגבים Theme ומסירים רק אחרי בדיקת תלות.
הבדיקה הנכונה היא לא “האם החנות מהירה יותר אחרי ניקוי”, אלא האם הקוד שייך לאפליקציה שכבר אינה בשימוש, היכן הוא נטען, מה הוא משנה למשתמש ולמדידה, והאם הסרתו משאירה HTML, מעקב, checkout ותבניות תקינים.
בחנויות Shopify הבעיה מופיעה בדרך כלל אחרי כמה סבבים של התקנות, החלפות אפליקציות, מעבר בין Themes או הוראות התקנה ישנות. שורת קוד יכולה להישאר ב־theme.liquid, ב־snippet, בקובץ asset, בתבנית JSON או בהגדרה שמפעילה App Embed. לפעמים היא אינה עושה דבר. לפעמים היא מוסיפה סקריפט לכל עמוד, משבשת אירועי אנליטיקס, מכפילה רכיב גלוי או משנה את הדרך שבה מנוע חיפוש רואה את ה־HTML.
מה באמת יכול להישאר אחרי הסרת אפליקציה?
צריך להפריד בין ארבעה מנגנוני התקנה. ההבדל ביניהם קובע אם פעולת הניקוי היא כיבוי, הסרה דרך Theme Editor, מחיקת קוד או בכלל בדיקה במערכת חיצונית.
| סוג ההטמעה | איפה מחפשים | מה ידוע | פעולה ראשונה |
|---|---|---|---|
| App block | Template או Section ב־Theme Editor | רכיב שנוסף למיקום מסוים בעמוד | בודקים אם הבלוק עדיין מופעל ומסירים אותו דרך העורך |
| App embed | Theme settings וה־head או body המרונדר | רכיב צף, overlay, סקריפט, מטא־תג או פיקסל | מכבים את ה־embed ובודקים את ה־HTML וה־Network |
| קוד Theme ישיר | theme.liquid, snippets, sections ו־assets | קוד שנכתב או הודבק בתוך קבצי התבנית | מזהים תלות, מגבים ומסירים רק את היחידה המתועדת |
| Script או שירות חיצוני | ScriptTag, פיקסל, GTM, DNS או מערכת צד שלישי | הקוד יכול להיטען מחוץ לקבצי ה־Theme | מאתרים את מקור הקריאה לפני עריכה מקומית |
Shopify מתארת Theme App Extensions כדרך שמוסיפה בלוקים, embeds, assets ו־snippets בלי לערוך ישירות את קוד ה־Theme. בתיעוד שלה מצוין שכאשר מסירים אפליקציה, הבלוקים הקשורים אליה מוסרים אוטומטית. זה לא אומר שכל קוד היסטורי שנוסף לפני המעבר למנגנון הזה נוקה; זו בדיוק הסיבה שבודקים גם את הקבצים ואת הבקשות שהדפדפן שולח.
לא כל קוד שנשאר הוא בעיית SEO
המונח “קוד מת” נשמע חד־משמעי, אבל הוא מתאר מצב שדורש ראיות. סקריפט שלא מציג רכיב עשוי עדיין לשלוח אירוע רכישה. קובץ CSS קטן יכול להיות בשימוש ב־Theme אחר. קריאה לשרת חיצוני יכולה להיות חלק מהסכמה או מפיקסל שהעסק עדיין צריך. מצד שני, קוד שנשאר מאפליקציה שהוסרה עלול להכביד על כל דף, להכניס שגיאות JavaScript או להשאיר markup ותוכן שהקונה אינו צריך לראות.
| ממצא | סיכון אפשרי | איך מאמתים | החלטה זמנית |
|---|---|---|---|
| קריאה לשם או דומיין של אפליקציה שהוסרה | בקשה מיותרת, שגיאה או תלות שנשברה | חיפוש בקבצי Theme וב־Network בכמה תבניות | לסמן לבדיקה; לא למחוק לפני שמבינים את ההקשר |
| סקריפט שמוסיף פיקסל או אירוע | כפילויות או אובדן מדידה | השוואת אירועים ב־GA4, פיקסלים ומערכת ההזמנות | להפריד בין ניקוי קוד לבין החלפת מקור המדידה |
| CSS או JS שאינם משנים את העמוד | עלות ביצועים ותחזוקה, לרוב בלי שינוי נראות | Coverage, Network ובדיקה ב־Theme Preview | לתעד ולתעדף לפי עלות, לא לפי פחד |
| Markup או קישור שנשארו בעמוד | תוכן כפול, קישורים מטעים או פגיעה ב־UX | HTML שנשלח, DOM מרונדר ובדיקה ידנית | לטפל לפני שינויי SEO אחרים |
ה־workflow שלי: ממלאי אפליקציות לראיה שאפשר לפעול לפיה
אני לא מתחיל מהקובץ הגדול ביותר ולא מסיר שורות עם מילים כמו app או script. זה מתכון להחזרת קוד שנמחק בטעות בערב שבת. מתחילים ממלאי ומתקדמים לפי ראיות.
1. בונים פנקס אפליקציות
מייצאים את האפליקציות הפעילות ואת אלה שהוסרו בתקופה הרלוונטית, רושמים למה כל אחת שימשה, באילו תבניות היא הופעלה, מי אחראי עליה ומה אמור להישאר אחרי ההסרה. אם אין היסטוריה, מתחילים מרשימת האפליקציות הנוכחית, היסטוריית גרסאות ה־Theme, שמות הדומיינים שנקראים והערות ההתקנה.
המטרה אינה למצוא “אשמים”. היא ליצור קשר בין סימן טכני לבין בעלים. בלי הקשר כזה, אי אפשר לדעת אם reviews הוא שארית של אפליקציית ביקורות ישנה או רכיב שעדיין מציג ביקורות פעילות.
2. קובעים Theme בדיקה ושומרים נקודת חזרה
לפני עריכה יוצרים Duplicate של ה־Theme הפעיל או עובדים על עותק שאינו מפורסם. שומרים את תאריך הבדיקה, את שמות הקבצים שישתנו ואת רשימת התרחישים שצריך לבדוק. לא מנקים ישירות את התבנית הפעילה כשאין דרך לשחזר שינוי בתוך דקות.
נקודת החזרה אינה תחליף להבנת הקוד. היא רק מאפשרת לחזור למצב קודם אם בדיקה מגלה שהוסרו אירוע, מחיר, כפתור או רכיב קופה.
3. ממפים חתימות, לא מוחקים מחרוזות
מחפשים שם אפליקציה, דומיין CDN, מזהה סקריפט, namespace של CSS, שם snippet, הערה שהשאיר המפתח וקישור ל־App Embed. את כל הממצאים רושמים בטבלה עם קובץ, שורה, תבנית, תנאי טעינה ותלות אפשרית.
| שדה | דוגמה | למה זה חשוב |
|---|---|---|
| מקור | layout/theme.liquid | מראה אם הקוד נטען בכל האתר או רק בתבנית מסוימת |
| חתימה | דומיין, handle או namespace | מאפשרת לקשור את הקוד לאפליקציה ולא רק למילה כללית |
| תנאי טעינה | כל עמוד, מוצר בלבד או checkout | קובע את היקף הסיכון ואת סדר הבדיקה |
| תלות | snippet, event, metafield או endpoint | מונע מחיקה של קוד שמופעל ממקום אחר |
| בדיקה | HTML, Network, אירוע, UX | מחבר בין שינוי בקוד לתוצאה שאפשר לאמת |
4. בודקים שלוש שכבות: קובץ, דפדפן ומדידה
שכבת הקובץ: האם החתימה עדיין נמצאת ב־Theme, והאם הקובץ נקרא מ־layout, section, snippet או asset אחר?
שכבת הדפדפן: האם הקריאה מופיעה ב־HTML, ב־DOM אחרי הרצה או בכרטיסיית Network? האם היא מתרחשת בכל עמוד או רק במקום שבו האפליקציה אמורה לעבוד?
שכבת התוצאה: האם אירוע purchase עדיין נשלח פעם אחת, האם מוצר ניתן להוספה לסל, האם תפריט, חיפוש, canonical ותוכן חשובים עובדים, והאם מובייל רואה את אותו מסלול?
השלוש חייבות להיפגש. קובץ שנראה מיותר אך נטען רק ב־Theme לא פעיל אינו כמו סקריפט שמתווסף לכל עמוד. בקשה חיצונית שאינה מופיעה בקובץ הפעיל עשויה להגיע מ־App Embed או מפיקסל; חיפוש טקסטואלי בלבד לא ימצא אותה.
מטריצת החלטה: להשאיר, לכבות, להסיר או להחליף
| מה יודעים | מה עושים | מה בודקים לאחר מכן |
|---|---|---|
| האפליקציה פעילה והרכיב בשימוש | לא מסירים; בודקים טעינה, היקף ותלות | האם אפשר להגביל עמודים או לעבור ל־App Embed נקודתי |
| ה־App Embed מיותר אך מזוהה בבירור | מכבים או מסירים דרך Theme Editor | HTML, Network, UX ואירועי מדידה |
| קוד ישן שייך לאפליקציה שהוסרה, בלי תלות פעילה | מוחקים מהעותק ומעלים לבדיקה | רגרסיה בתבניות, שגיאות Console ומהירות |
| מקור הקוד לא ידוע | משאירים ומתעדים עד שיש בעלים וראיות | חיפוש היסטורי, בדיקת Theme קודם והשוואת התנהגות |
| הקוד משכפל מעקב או markup | מגדירים מקור אמת אחד ומסירים את הכפילות | אירוע אחד, ערכים נכונים ודוח הזמנות תואם |
הכלל המעשי שלי הוא: ככל שהוודאות נמוכה יותר והתלות העסקית גבוהה יותר, כך השינוי צריך להיות קטן והבדיקה רחבה יותר. לא מחליפים מערכת ביקורות רק מפני שמצאנו קובץ CSS ישן; ולא משאירים סקריפט של פיקסל כפול רק מפני שהוא “לא נראה בעין”.
דוגמה היפותטית: שלושה ממצאים, שלוש פעולות
נניח שחנות החליפה אפליקציית ביקורות, התקינה כלי Upsell והסירה אפליקציית SEO ישנה. בבדיקה נמצאים שלושה סימנים:
- App Embed של כלי ה־Upsell כבוי אבל קובץ JavaScript שלו עדיין נטען מ־
theme.liquid. כאן בודקים אם הקובץ שייך להתקנה ישנה, מסירים אותו מעותק Theme ומוודאים שאין כפתור או אירוע שמסתמך עליו. - Snippet של הביקורות עדיין נקרא מעמוד מוצר, אבל הוא מפנה ל־namespace של האפליקציה החדשה. לא מוחקים אותו לפי שם; בודקים אם הוא משמש את הרכיב הפעיל ומחליפים רק את הקריאה הישנה.
- סקריפט של אפליקציית SEO לשעבר מופיע רק ב־Theme הישן. אין סיבה לגעת ב־Theme הפעיל לפני שמוודאים שההיסטוריה אינה משמשת כעותק חזרה. מתעדים, ואז משאירים או מנקים בנפרד.
הדוגמה אינה טוענת שחנות מסוימת נבדקה. היא ממחישה את ההבדל בין חתימה, שימוש ותלות. אותו ממצא טקסטואלי יכול להוביל להסרה, להחלפה או לאי־פעולה, בהתאם לראיות.
איך זה קשור ל־SEO, UX ומדידה?
שאריות Theme אינן “בעיית SEO” מסוג אחד. הן יכולות לפגוע בשלוש שכבות שונות:
- SEO טכני: קוד יכול לשנות canonical, מטא־תגים, קישורים, markup או תוכן שנוסף באופן לא צפוי. בודקים את ה־HTML וה־DOM בעמודי מוצר, קטגוריה ומאמר.
- חוויית משתמש וביצועים: סקריפטים גלובליים, בקשות חיצוניות ו־CSS מיותר יכולים להוסיף עבודה גם בעמודים שאינם זקוקים לאפליקציה. מודדים את ההיקף ואת השפעת השינוי, לא רק ציון יחיד בכלי ביצועים. אם זו בדיקת מהירות רחבה, אפשר להיעזר ב־מדריך Core Web Vitals ל־Shopify.
- מדידה: שני מקורות שמאזינים לאותו אירוע יכולים ליצור רכישות או הוספות לסל כפולות. לפני שמסיקים מסקנה מ־GA4, משווים את האירוע למערכת ההזמנות ולמקור ההטמעה. ניתוח מבנה הקוד וה־DOM שייך ל־מדריך JavaScript SEO באיקומרס, אבל כאן השאלה היא מי צריך להישאר ומי כבר לא.
אם האפליקציה משפיעה על תגי SEO, קישורים או תוכן, מסלול העבודה צריך להתחבר ל־בדיקת SEO לחנות Shopify. לא נכון להסתפק בהסרת קובץ ולסמן את המשימה כגמורה.
QA אחרי ניקוי: מה חייב לעבור לפני פרסום?
- פותחים את Theme Preview ובודקים בית, קטגוריה, מוצר, חיפוש, סל ותבנית תוכן.
- בודקים מובייל ודסקטופ; במיוחד תפריט, בחירת וריאנט, הוספה לסל, פופ־אפ ורכיב צף.
- משווים HTML, canonical, כותרות, קישורים ותוכן חשוב לפני ואחרי.
- בודקים ב־Network שהקריאה הישנה אינה נטענת ושאין קריאה חדשה שנכנסה בטעות לכל עמוד.
- מאמתים אירועי view_item, add_to_cart ו־purchase פעם אחת ובערכים הנכונים, אם הם חלק מהחנות.
- בודקים Console, שגיאות טעינה, תמונות, CSS, שפות, Markets ו־checkout.
- בודקים תבנית מוצר עם וריאנטים, מוצר ללא מלאי ועמוד שאין בו את האפליקציה.
- מתעדים מה הוסר, מאיזה קובץ, באיזה Theme, מי אישר ומה תוכנית החזרה.
מתי לא לנקות עדיין?
לא מנקים כאשר אין דרך לזהות בעלות על הקוד, כאשר האפליקציה עדיין פעילה בחלק מה־Markets או ה־Themes, כאשר אין עותק חזרה, או כאשר אי אפשר לבדוק הזמנה ומדידה אחרי השינוי. גם קוד שנראה “ישן” יכול להיות תלוי ב־snippet אחר או בתהליך תפעולי שאינו גלוי ללקוח.
במקרה כזה הפעולה הנכונה יכולה להיות תיעוד, כיבוי מבוקר, פתיחת משימת בעלות או איסוף ראיות נוסף. ניקוי מאוחר ומאומת עדיף על מחיקה מהירה שמייצרת בעיה חדשה ומחייבת חיפוש אשמים.
סדר יישום מומלץ לחנות קיימת
התחילו מאפליקציות שהוסרו ושנטענו גלובלית, עברו לקוד שמשנה markup או מדידה, ורק אחר כך טיפלו בקבצים קטנים שהשפעתם אינה ידועה. בכל שלב שמרו baseline, בדקו עותק Theme והשוו את אותה קבוצת תרחישים.
המטרה אינה להגיע ל־Theme בלי שורת JavaScript אחת. חנות מסחרית צריכה קוד כדי למכור, למדוד ולהציג מידע. המטרה היא שכל קוד יהיה בעלים, תפקיד, תנאי טעינה ותוכנית יציאה.
הערת גבול Shopify משנה את מנגנוני האפליקציות והתבניות, ומפתחים שונים מתקינים קוד בדרכים שונות. לכן יש לאמת את הממצא מול התבנית, האפליקציה והגרסה הפעילה בחנות בזמן הבדיקה; אין למחוק קוד רק מפני שהוא תואם לדוגמה כאן.
מקורות ובדיקה
המקורות נבדקו בעת העדכון האחרון. קישורים חיצוניים נפתחים באתר המקור.
כפיר אהרון, לולו דיגיטל
עוסק במשך שנים ב־SEO, CRO ו־PPC, ועבד עם עשרות אתרי איקומרס ובעלי עסקים בישראל. המאמר נבדק מול המקורות המופיעים בעמוד, ומפריד בין הנחיה רשמית, שיקול מקצועי ודוגמה היפותטית.