בסביבות ספטמבר 2025, לא מעט כלי SEO וסקריפטים מותאמים אישית פשוט הפסיקו לעבוד — בשקט. האשם? Google הפסיקה לכבד באופן עקבי את הפרמטר num=100, שעליו משתמשים מתקדמים נשענו במשך שנים כדי להציג 100 תוצאות בעמוד. לא פורסמה הודעת סיום רשמית — רק דובר שאמר ל־Search Engine Land שהפרמטר "לא נתמך באופן רשמי". בערך באותו זמן, Google הוסיפה מצבי udm נוספים לצד הוורטיקלים הוותיקים של tbm, הודיעה שדומיינים עם סיומת מדינה יעברו בהדרגה להפניה ל־google.com, ודיווחה ש-AI Overviews הגיעו ליותר מ־2.5 מיליארד משתמשים חודשיים.
אם אתם בונים כתובות חיפוש, עוקבים אחרי דירוגים או מבצעים אוטומציה למחקר באמצעות פרמטרים של Google, סביר להניח שחלק מהתהליכים שלכם כבר נפגעו בלי ששמתם לב. ב-Thunderbit בדקנו את התיעוד הנוכחי של Google, הודעות שינוי עדכניות, מקורות שעברו reverse engineering ובדיקות חיות בפועל, כדי להבחין בין בקרים יציבים לבין בקרים תלויי-הקשר. התוצאה היא מדריך מעודכן, שמומלץ לבדוק לפני הטמעה, עבור פרמטרים של Google Search URL שחשובים ב-2026 — כולל מיפויי tbm/udm, נוסחת הקידוד של uule עבור מיקוד ברמת עיר, ועימותי פרמטרים שיכולים לחסוך שעות של דיבוג.
מה הם פרמטרים של Google Search URL?
פרמטרים של Google Search URL הם זוגות key=value שמופיעים אחרי ה-? בכתובת חיפוש של Google. הם שולטים כמעט בכל דבר — מה אתם מחפשים, באילו תוצאות מדינה תראו, ועד אם תקבלו תמונות, חדשות או קישורים כחולים קלאסיים.
כך כתובת חיפוש טיפוסית של Google מתפרקת:
https://www.google.com/search?q=best+crm+software&hl=en&gl=us&tbs=qdr:m
- כתובת בסיס:
https://www.google.com/search ?מתחיל את מחרוזת השאילתהq=best+crm+softwareהוא מונח החיפוש (רווחים מקודדים כ-+)&מפריד בין הפרמטריםhl=enמגדיר את שפת הממשק לאנגליתgl=usאומר ל-Google להציג תוצאות כאילו אתם בארה״בtbs=qdr:mמסנן לתוצאות מהחודש האחרון
חשוב להבחין: אופרטורי חיפוש כמו site:, filetype: ו-intitle: נכנסים לתוך הערך של q=. הם חלק מהשאילתה עצמה. לעומת זאת, פרמטרים של URL כמו gl, hl ו-tbs הם מפתחות נפרדים בכתובת, שמנחים את Google איך לעבד ולהציג את התוצאות. שניהם חשובים ועובדים יחד — אבל הם דברים שונים.
Google אף פעם לא פרסמה מפרט יחיד וממוספר לגרסה עבור הפרמטרים האלה. חלקם מגיעים מטופס ה-Advanced Search, חלקם מ-API של Custom Search, וחלקם עברו שחזור מתוך צפייה בכתובות של Google עצמה. לכן המאמר שאתם קוראים מבוסס על בדיקות חיות והתנהגות מתועדת — לא על חוזה API רשמי.
למה פרמטרים של Google Search URL חשובים ב-2026
פרמטרים ב-URL הם לא רק עניין של מפתחים. כל מי שעובד ב-SEO, שיווק, מכירות, תפעול או מוצר וצריך להבין מה Google מציגה עבור שאילתה מסוימת, בשוק מסוים, בזמן מסוים — הפרמטרים האלה הם ערכת הכלים שלכם.
חלוקה מהירה של מי מרוויח ואיך:
| שימוש | מי מרוויח | פרמטרים מרכזיים |
|---|---|---|
| מעקב דירוג SEO בין מדינות | צוותי SEO ושיווק | gl, hl, uule, pws |
| ניטור מתחרים לפי תאריך | צוותי אסטרטגיה ותפעול | tbs, q עם site: |
| ניטור מודעות בשווקים ספציפיים | צוותי מדיה ממומנת | gl, hl, udm |
| בדיקות SEO מקומי (ברמת עיר) | בעלי עסקים מקומיים | uule, gl |
| מחקר תוכן / מעקב אחר טרנדים | צוותי תוכן | tbs (סינון לפי תאריך), lr |
| הזנת נתוני חיפוש לאפליקציות AI/LLM | צוותי מוצר ונתונים | כמה פרמטרים + חילוץ מובנה |
שלושה שינויים גדולים הופכים את 2026 לשנה שונה מהותית:
num=100כבר לא אמין. הטריק הישן לקבל 100 תוצאות בעמוד הפסיק לעבוד בצורה עקבית בספטמבר 2025. Google לא הכריזה עליו כסריקה שהוצאה משימוש; דובר אמר שהוא מעולם לא היה נתמך רשמית.- הפניות של ccTLD הן תהליך מעבר, לא מעבר שהושלם. Google הודיעה באפריל 2025 שדומיינים עם סיומת מדינה (google.co.uk, google.de וכו׳) יעברו בהדרגה להפניה ל-google.com. Google לא פרסמה הודעת סיום למהלך, לכן אל תניחו שכל לוקליזציה מתנהגת עדיין באותו אופן.
- AI Overviews שינו את ה-SERP. Google מדווחת ש-AI Overviews הגיעו ליותר מ־2.5 מיליארד משתמשים חודשיים וליותר מ־200 מדינות וטריטוריות. מצבי
udmשעברו reverse engineering יכולים לשנות את תצוגת התוצאות בחלק מהמקרים, אבל הם לא מתג אוניברסלי ומובטח ל-AI Overview.
אם התהליכים שלכם לא עודכנו לשינויים האלה, יש סיכוי טוב שאתם מקבלים תוצאות חלשות או מטעות בלי לדעת.
גיליון עזר לפרמטרים של Google Search URL (2026)
לפני שנצלול לעומק, הטבלה הבאה היא רשימת ההפניה המעודכנת ביותר שהצלחתי להרכיב. כדאי לשמור אותה.
| פרמטר | מה הוא עושה | ערך לדוגמה | מצב |
|---|---|---|---|
q | שאילתת חיפוש (תומכת באופרטורים בתוכה) | q=best+crm+software | ✅ פעיל |
hl | שפת הממשק | hl=en, hl=ja | ✅ פעיל |
gl | הקשר מדינה/שוק | gl=us, gl=jp | ✅ פעיל |
lr | הגבלת תוצאות לשפת תוכן | lr=lang_en | ✅ פעיל |
cr | הגבלת תוצאות למדינת אירוח | cr=countryUS | ✅ פעיל |
start | היסט דפדוף | start=10 (עמוד 2) | ✅ פעיל |
num | כמות תוצאות לעמוד (בעבר) | num=100 | ⚠️ לא נתמך רשמית; לא אמין מאז ספט׳ 2025 |
udm | מצב תוכן קונטקסטואלי | udm=14 (web קלאסי) | ⚠️ עבר reverse engineering; משתנה לפי הקשר |
tbm | ורטיקל חיפוש | tbm=isch (תמונות) | ⚠️ עדיין נצפה; יש לבדוק לצד udm |
tbs | סינוני זמן, מיון, verbatim | tbs=qdr:w | ✅ פעיל |
safe | שליטת SafeSearch | safe=active | ✅ פעיל |
filter | סינון תוצאות כפולות | filter=0 | ✅ פעיל (נצפה) |
nfpr | ביטול תיקון אוטומטי | nfpr=1 | ✅ פעיל (נצפה) |
pws | ביטול התאמה אישית | pws=0 | ✅ פעיל |
uule | מיקוד גיאוגרפי ברמת עיר/DMA | uule=w+CAIQICI... | ✅ פעיל (עבר reverse engineering) |
as_q, as_epq, as_eq, וכו׳ | שדות של טופס Advanced Search | שונים | ✅ פעיל |
as_sitesearch | הגבלה לדומיין (Advanced Search) | as_sitesearch=example.com | ✅ פעיל |
as_filetype | הגבלה לסוג קובץ (Advanced Search) | as_filetype=pdf | ✅ פעיל |
ie, oe | קידוד קלט/פלט | ie=UTF-8 | ✅ פעיל (לעיתים נדירות נדרש) |
kgmid, si, ibp | ישות Knowledge Graph / תצוגת פיצ׳רים | שונים | ⚠️ תלויי-הקשר (לא לשימוש כללי) |
ei, ved, sxsrf, sclient | Session / tracking / telemetry | שונים | 🔒 פנימיים (להתעלם) |
gbv | תצוגת HTML בסיסית (בעבר) | gbv=1 | ❌ לא אמין ב-2026 |
כדאי להסיר ei, ved, sxsrf ו-sclient מכל URL שאתם שומרים או משתפים. אלו מצבי session וטלמטריה ש-Google מוסיפה אוטומטית — לא רלוונטיים לבניית כתובות חיפוש.
פרמטרי Google Search מרכזיים שעדיין עובדים
בדקתי כל אחד מאלה בפועל נכון לאמצע 2026. אלה הפרמטרים שתשתמשו בהם הכי הרבה.
q — שאילתת החיפוש שלכם
הפרמטר q נושא את מילות החיפוש. רווחים מקודדים כ-+ או %20. כאן נמצאים אופרטורי החיפוש המתועדים של Google — הם נכנסים לתוך הערך של q, לא כפרמטרי URL נפרדים.
כמה דוגמאות:
- ביטוי מדויק:
q=%22google+search+url+parameters%22 - הגבלה לאתר:
q=site%3Aexample.com+pricing - סוג קובץ:
q=filetype%3Apdf+annual+report+2026 - שילוב:
q=site%3Acompetitor.com+intitle%3Apricing+after%3A2026%2F01%2F01
תמיד יש לקודד ב-URL את הערך המלא של השאילתה. מרכאות, נקודתיים ונטיות חייבים קידוד נכון כדי לא להשחית את הכתובת.
hl — שפת הממשק
hl שולט בשפת הממשק של Google — כפתורים, תוויות, כותרות כמו "People also ask" — וגם משפיע על אילו תוצאות Google תעדיף. הוא משתמש בקודי ISO 639-1 כמו en, fr, de, ja, או בתגיות BCP 47 כמו en-gb או pt-br.
hl לא מכריח את כל המסמכים בתוצאות להיות באותה שפה. זהו אות חזק, אבל Google עדיין יכולה להציג תוצאות בשפות אחרות אם הן רלוונטיות מאוד. להגבלת שפת תוכן, השתמשו ב-lr.
gl — מדינה / מיקום גיאוגרפי
gl מדמה את המדינה שממנה אתם מחפשים, באמצעות קודי ISO 3166-1 alpha-2 (us, gb, jp, de). עם מעבר הדרגתי של ccTLD להפניה ל-google.com, gl הוא כעת הדרך העיקרית לקבל תוצאות ספציפיות למדינה.
אותה שאילתה עם ערכי gl שונים יכולה להחזיר תוצאות, Featured Snippets ו-Local Packs שונים לגמרי. למשל, q=best+bank&gl=us ו-q=best+bank&gl=jp יציגו בנקים שונים מאוד.
טיפ חשוב: תמיד מומלץ לשלב את gl עם hl כדי לקבל תוצאות לוקליות מדויקות. שימוש ב-gl=jp יחד עם hl=en נותן תוצאות משוק יפן בממשק באנגלית — שימושי מאוד לבדיקות SEO בינלאומיות.
lr ו-cr — הגבלת שפה והגבלת מדינה
אלה שני פרמטרים שמבלבלים ביןיהם לעיתים קרובות. ההבדל חשוב:
lr=lang_enמגביל לתוצאות של דפים הכתובים באנגלית (שפת התוכן)cr=countryUSמגביל לתוצאות של דפים המתארחים בארה״ב (מיקום השרת / שיוך למדינה)gl=usמדמה חיפוש מארה״ב (משפיע על דירוג, תוצאות מקומיות ומודעות)
גם lr וגם cr זמינים דרך טופס ה-Advanced Search של Google. חשוב להיזהר בשילובים — lr=lang_en + cr=countryJP פירושו "רק דפים באנגלית שמתארחים ביפן", וזה כבר סט תוצאות מצומצם מאוד. נרחיב על זה בסעיף העימותים.
start — דפדוף בין תוצאות
start=10 מבקש תוצאות שמתחילות במקום ה-11 (עמוד 2), start=20 לעמוד 3, וכן הלאה. מאחר ש-num=100 כבר לא אמין, הגדלת start בקפיצות של 10 היא ברירת המחדל הבטוחה יותר — אבל Google עדיין יכולה לשכתב או להגביל את הדפדוף.
הטריק הישן num=100&start=0 כדי לשלוף עמוד מלא של 100 תוצאות כבר לא עובד. אם הסקריפטים שלכם עדיין כוללים num, הסירו אותו — הוא פשוט מתעלם בשקט.
pws — ביטול התאמה אישית
pws=0 מבקש מ-Google לכבות התאמה אישית על בסיס חשבון. זה חיוני למעקב אחר דירוגים ב-SEO, כשאתם רוצים תוצאות שלא מוטות מהיסטוריית החיפושים שלכם, מהקליקים הקודמים או מהעדפות החשבון.
חשוב לדעת: pws=0 מפחית התאמה אישית, אבל לא מבטל את כל גורמי ההקשר. Google מציינת שהתוצאות עדיין יכולות להשתנות לפי זמן, מיקום, שפה ומכשיר. אין דבר כזה SERP "נייטרלי" באמת.
safe ו-filter — SafeSearch וסינון כפילויות
safe=activeמפעיל SafeSearch;safe=offמכבה אותו. שימו לב שהגדרות חשבון, מדיניות ארגונית, תצורת רשת או חוקים אזוריים עשויים לעקוף את הפרמטר הזה.filter=0מבטל את הסינון של תוצאות כפולות ב-Google. שימושי כשאתם רוצים לראות כל תוצאה ש-Google מצאה, כולל כפילויות קרובות שבדרך כלל היו מאוחדות.
nfpr — ביטול תיקון אוטומטי
nfpr=1 מונע מ-Google לשכתב את השאילתה בכפייה כשהמערכת חושבת שיש שגיאת כתיב. זה שימושי למעקב אחרי מונחי מותג עם איות לא רגיל, ז׳רגון טכני, או שאילתות עם שגיאה מכוונת שמתחרים מנסים לתפוס.
שימו לב ש-nfpr=1 רק מונע את השכתוב הכפוי. לשליטה רחבה יותר — ביטול הרחבת מילים נרדפות, שינויי איות ושאר השינויים האוטומטיים — השתמשו ב-tbs=li:1 (מצב verbatim), שמוסבר בהמשך בסעיף tbs.
המעבר מ-tbm ל-udm: מה השתנה ומה להשתמש עכשיו
זה אחד השינויים הגדולים ביותר בפרמטרים בשנים האחרונות — וגם אחד הקלים להגזים בחשיבותו.
tbm היה במשך יותר מעשור דרך נפוצה לעבור בין ורטיקלים של Google — תמונות, חדשות, וידאו, שופינג. Google גם הציגה מערכת מספרית של udm עם מצבים חופפים ונוספים. מאחר ש-Google לא פרסמה registry יציב לצרכנים, כדאי להתייחס לזה כמיפוי תלוי-הקשר ולא כתחליף נקי וסופי.
טבלת המיפוי המלאה מ-tbm ל-udm
המיפויים שלמטה משלבים התנהגות UI שנצפתה ובדיקות חיות מתאריך 12 באוגוסט 2026. כמה ערכים הוסרו או נכתבו מחדש בבקשות אנונימיות, לכן יש לבדוק כל שורה בסביבה, באזור ובקליינט שבהם תשתמשו בה:
| פרמטר ישן | ערך ישן | פרמטר חדש | ערך חדש | מצב |
|---|---|---|---|---|
tbm=lcl | מקומות/מקומי | udm=1 | מקומות/מקומי | ⚠️ תלוי-הקשר |
tbm=isch | תמונות | udm=2 | תמונות | ⚠️ תלוי-הקשר |
tbm=vid | סרטונים | udm=7 | סרטונים | ⚠️ תלוי-הקשר |
tbm=nws | חדשות | udm=12 | חדשות | ⚠️ תלוי-הקשר |
| — | — | udm=14 | Web קלאסי (ללא AI Overview) | 🆕 חדש, ללא מקבילה ב-tbm |
| — | — | udm=18 | פורומים | 🆕 חדש, ללא מקבילה ב-tbm |
tbm=shop | שופינג | udm=28 | שופינג | ⚠️ תלוי-הקשר |
tbm=bks | ספרים | udm=36 | ספרים | ⚠️ תלוי-הקשר |
| — | — | udm=39 | סרטונים קצרים | 🆕 חדש, ללא מקבילה ב-tbm |
| — | — | udm=50 | מצב AI Overview | 🆕 חדש, ללא מקבילה ב-tbm |
Google לא פרסמה registry יציב ל-udm — וזה סייג חשוב. הערכים האלה עברו reverse engineering מתוך צפייה בהתנהגות ה-UI של Google. הקבלה של ה-URL משתנה לפי חשבון, אזור, לקוח, עוגיות וקבוצת ניסוי. בבדיקות שלי, חלק מערכי udm הוסרו בבקשות HTTP אנונימיות, אבל עבדו בסשנים אינטראקטיביים בדפדפן. אל תניחו שכל ערך יעבוד בכל מקום.
מה עושה udm=14 ולמה SEOs אוהבים אותו
udm=14 הפך כמעט לקאלט בקהילת ה-SEO. Android Central תיארו אותו כדרך לבקש תצוגת תוצאות Web קלאסית בלי AI Overviews. בהרבה סשנים הוא אכן מחזיר SERP מסורתי של קישורים כחולים — אבל זו לא הבטחה רשמית או אוניברסלית.
למה זה חשוב? אם אתם עושים מעקב דירוג או בדיקות SEO, AI Overviews יכולים לדחוק תוצאות אורגניות מתחת לקו הקיפול ולהקשות על הערכת מיקומים. udm=14 יכול לתת לכם תצוגה נקייה יותר כש-Google מכבדת אותו.
עם זאת, udm=14 לא מובטח לעבוד בכל הקשר. בבדיקות חיות שנערכו ב-12 באוגוסט 2026, Google לעיתים הסירה או כתבה מחדש ערכי udm בהתאם להקשר הבקשה. התוצאה בפועל תלויה בסשן, בחשבון, באזור, בלקוח ובקבוצת הניסוי.
גם udm=50 נצפה בהקשרים של AI Mode / תוצאות AI, אבל לא נכון להציג אותו כדרך מובטחת לכפות AI Overview על כל שאילתה אקראית.
מה כדאי לעשות: לעדכן תהליכים מ-tbm ל-udm
ההמלצה שלי:
- הטמעות חדשות: להתייחס ל-
udmכקלט ניסיוני/תלוי-הקשר ולבנות fallback. - תהליכים קיימים: לתמוך ולבדוק גם
tbmוגםudmכשזה רלוונטי, במקום להניח שהמעבר הושלם. - לעולם לא לשלב את שניהם: כש-
tbmו-udmמופיעים יחד באותה כתובת, ההתנהגות לא צפויה. בבדיקות שלי, Google לפעמים הסירה את שניהם והחזירה שאילתה רגילה. עוד על זה בסעיף העימותים.
התחביר המלא של tbs: טווחי תאריכים מותאמים, מיון לפי תאריך, ו-verbatim
tbs הוא אחד הפרמטרים החזקים ביותר בארגז הכלים של Google Search URL, ורוב המדריכים רק מגרדים את פני השטח. הוא מטפל בסינון זמן, מיון לפי תאריך, מצב verbatim ועוד — הכול בתוך ערך אחד מופרד בפסיקים.
סינוני זמן סטנדרטיים
ערך tbs | משמעות | חלק URL לדוגמה |
|---|---|---|
qdr:h | השעה האחרונה | &tbs=qdr:h |
qdr:d | 24 השעות האחרונות | &tbs=qdr:d |
qdr:w | השבוע האחרון | &tbs=qdr:w |
qdr:m | החודש האחרון | &tbs=qdr:m |
qdr:y | השנה האחרונה | &tbs=qdr:y |
אלה הבסיסים שרוב המדריכים מכסים. אבל tbs יכול לעשות הרבה יותר.
טווחי תאריכים מותאמים
רוצים תוצאות מחלון זמן מסוים? השתמשו בתחביר cdr:1,cd_min:MM/DD/YYYY,cd_max:MM/DD/YYYY:
&tbs=cdr:1,cd_min:01/01/2026,cd_max:06/01/2026
כך מסננים לתוצאות ש-Google משייכת לתאריכים שבין 1 בינואר ל-1 ביוני 2026. זה שימושי מאוד למחקר מתחרים — למשל, "מה המתחרים פרסמו על תמחור ברבעון הראשון של 2026?" רק זכרו לקודד את כל הערך ב-URL, כי נקודתיים ונטיות דורשים קידוד.
הערת שימוש: שיוך התאריכים של Google לא תמיד מדויק. התאריך שמופיע בתוצאות החיפוש הוא ההערכה הטובה ביותר של Google, לא בהכרח תאריך הפרסום האמיתי. תמיד כדאי לאמת את התאריך בעמוד היעד.
מיון לפי תאריך ומצב Verbatim
כאן המדריך נכנס לשטח שכמעט אף מאמר מתחרה לא מכסה.
sbd:1 ממיין תוצאות לפי תאריך (מהחדש לישן). בפני עצמו זה שימושי, אבל לא יוצא דופן. הטריק הוא שאפשר לשלב אותו עם סינוני טווח זמן בתוך ערך tbs אחד:
&tbs=qdr:m,sbd:1
זה נותן תוצאות מהחודש האחרון, ממוינות לפי תאריך — מהחדש לישן. זו הדרך המהירה ביותר למצוא מה התפרסם ממש לאחרונה בנושא מסוים. אני משתמש בשילוב הזה כל הזמן כשאני עוקב אחרי תוכן של מתחרים.
li:1 מפעיל מצב verbatim — המקבילה ב-URL ללחיצה על כלי "Verbatim" בממשק החיפוש של Google. מצב Verbatim מבטל תיקון אוטומטי, הרחבת מילים נרדפות, שינויי איות ושאר השינויים האוטומטיים בשאילתה.
ההבדל בין li:1 לבין nfpr=1 הוא ברמת ההיקף:
nfpr=1: רק מונע שכתוב אכיפתי של איות/שאילתה (למשל, עוצר את Google מלהחליף "teh" ב-"the")tbs=li:1: מבטל את כל השינויים האוטומטיים — איות, מילים נרדפות, מונחים קשורים, התאמות פרסונליזציה
אפשר אפילו לשלב כמה ערכי tbs יחד. למשל, tbs=qdr:m,sbd:1,li:1 נותן תוצאות מהחודש האחרון, ממוינות לפי תאריך, עם התאמה מילולית. בבדיקות שלי השילוב הזה עובד, אבל אני ממליץ לאמת מול השאילתות הספציפיות שלכם, כי התחביר של tbs אינו מתועד באופן מלא.
איך בונים קוד uule למיקוד גיאוגרפי ברמת עיר
אם gl הוא עדשה ברמת מדינה, uule הוא מיקרוסקופ ברמת עיר. עבור SEO מקומי — בדיקה איך העסק שלכם מדורג בדנוור לעומת דאלאס, או מה רואה מחפש ברובע שיבויה בטוקיו — gl לבדו לא מספיק מדויק.
אף מאמר מוביל לא באמת מסביר איך לבנות קוד uule — הם מזכירים שהפרמטר קיים וממשיכים הלאה. הנה הפירוט המלא.
מתי להשתמש ב-gl לעומת uule לעומת cr
| פרמטר | רזולוציה | תרחיש שימוש טיפוסי | דורש קידוד? |
|---|---|---|---|
gl=us | ברמת מדינה | סימולציה מהירה של מדינה | לא |
cr=countryUS | ברמת מדינה (הגבלה) | סינון לפי מדינת אירוח | לא |
uule=w+CAIQICI... | ברמת עיר/DMA | בדיקת דירוג SEO מקומי | כן |
אלגוריתם הקידוד של uule (שלב אחר שלב)
הפרמטר uule משתמש באות מיקום בשם מקודד. הבנייה שלו עברה reverse engineering, לא תועדה רשמית על ידי Google, אבל קהילת ה-SEO אימתה אותה בהרחבה.
הגישה הבטוחה יותר היא לקודד payload קטן של Protocol Buffers במקום להישען על הקיצור שמועתק הרבה פעמים (ושעלול להיכשל עם תווים לא-ASCII). כך זה עובד:
- מאתרים את שם המיקום הקנוני של Google. Google מפרסמת יעדי גיאוגרפיה עם שמות קנוניים דרך נתוני המיקוד הגיאוגרפי של Google Ads API. לדוגמה:
New York,New York,United States - מקודדים את השם כבתים ב-UTF-8.
- בונים payload קטן של protobuf עם השם ואורך הבתים שלו.
- מקודדים את ה-payload ב-Base64url ומוסיפים לפניו
w+.
הנה קטע Python שמבצע את זה:
import base64
def encode_varint(value: int) -> bytes:
out = bytearray()
while True:
byte = value & 0x7F
value >>= 7
if value:
out.append(byte | 0x80)
else:
out.append(byte)
return bytes(out)
def build_uule(canonical_name: str) -> str:
name = canonical_name.encode("utf-8")
payload = b"\x08\x02\x10\x20\x12" + encode_varint(len(name)) + name
encoded = base64.urlsafe_b64encode(payload).decode().rstrip("=")
return "w+" + encoded
#דוגמה
print(build_uule("New York,New York,United States"))
#פלט: w+CAIQICIeTmV3IFlvcmssTmV3IFlvcmssVW5pdGVkIFN0YXRlcw
כשמכניסים את זה ל-URL, ודאו שה-+ הליטרלי ב-w+ מקודד כ-%2B על ידי ספריית ה-URL שלכם. רוב המימושים של URLSearchParams או urllib.parse.urlencode עושים את זה אוטומטית.
uule שנבנה נכון הוא עדיין רק אות מיקום אחד. הוא לא גובר על כתובת IP, הגדרות חשבון, מכשיר או קבוצת ניסוי. השתמשו בו לבדיקות כיוון ב-SEO מקומי — לא כהבטחה לדירוג מדויק ברמת עיר.
מתי פרמטרים של Google Search מתנגשים בשקט
שילובי פרמטרים יכולים להיכשל בלי שום הודעה: Google עשויה להתעלם מקלט אחד, לשכתב את ה-URL, או להחזיר תצוגה אחרת. בדיקות ההתנגשות הבאות שוות הוספה לכל תהליך עבודה עם קישור חיפוש.
אף מאמר מתחרה לא מכסה אינטראקציות בין פרמטרים. אבל אם אתם בונים כתובות חיפוש עם כמה פרמטרים — וסביר להניח שכן — אתם חייבים לדעת אילו שילובים מסתדרים ואילו מתנגשים.
gl + uule: מי מנצח?
כששניהם מופיעים, uule מספק אות מיקום ספציפי יותר מ-gl. אם תגדירו gl=uk ו-uule שמצביע לטוקיו, תקבלו תוצאות שמושפעות מטוקיו, לא תוצאות של בריטניה.
המלצה: אם אתם משתמשים ב-uule, עדיף להשמיט את gl לגמרי או להגדיר gl למדינה שמכילה את העיר שב-uule. אל תשלחו אותות סותרים.
tbm + udm: אל תשתמשו בשניהם
בבדיקות שלי, כש-tbm ו-udm הופיעו יחד באותה כתובת, Google לפעמים הסירה את שניהם והחזירה שאילתה רגילה של web. ההתנהגות לא עקבית בין סשנים וחשבונות.
המלצה: השתמשו רק ב-udm בהטמעות חדשות. אם חייבים לתמוך בתהליכים ותיקים, השתמשו באחד מהם — לעולם לא בשניהם.
lr + cr: סינון כפול עלול להחזיר אפס תוצאות
זה מלכוד עדין. lr=lang_en מגביל לתוכן באנגלית. cr=countryJP מגביל לדפים המתארחים ביפן. שלבו אותם ואתם מבקשים "דפים באנגלית שמתארחים ביפן" — שזה תת-קבוצה מאוד קטנה של האינטרנט.
המלצה: השתמשו באחד מהם או בשני הפרמטרים רק אם אתם באמת צריכים את החיתוך ביניהם. אם כן — צפו לפחות תוצאות באופן דרמטי.
num + start: דפדוף שבור
סקריפטים ישנים שמשתמשים ב-num=100&start=0 מחזירים עכשיו בשקט רק בערך 10 תוצאות. הפרמטר num כבר לא מכובד, אבל הוא גם לא זורק שגיאה — פשוט מתעלמים ממנו.
המלצה: הסירו את num מכל ה-URLs. בצעו דפדוף באמצעות start בקפיצות של 10 והסירו כפילויות בין עמודים.
הפניה מהירה לעימותים
| שילוב | מה קורה | המלצה |
|---|---|---|
gl + uule | uule מספק אות מדויק יותר | התאימו בין המדינה לעיר, או השמיטו את gl |
tbm + udm | לא צפוי — ייתכן ששניהם יוסרו | השתמשו רק ב-udm |
lr + cr | צמצום אגרסיבי, לעיתים כמעט אפס תוצאות | השתמשו באחד מהם |
num + start | num מתעלם, מוחזרות בערך 10 תוצאות | הסירו num, בצעו דפדוף עם start |
nfpr=1 + tbs=li:1 | בקרות קשורות אך לא זהות | בדקו על השאילתה הספציפית שלכם |
hl + lr | שפת ממשק ≠ הגבלת שפת תוכן | השתמשו במכוון; hl אינו מסנן תוכן |
מ- Google Search URL Parameters לחילוץ נתונים מובנה
בשלב הזה יש לכם כתובת חיפוש מדויקת של Google — השאילתה הנכונה, המדינה הנכונה, טווח התאריכים הנכון, ותוצאות web קלאסיות. השלב הבא הוא להוציא נתונים מובנים מתוך התוצאות.
בין אם אתם בונים rank tracker, מנטרים מתחרים או מזינים נתוני חיפוש לתהליך מחקר, לראות את התוצאות הנכונות הוא רק חצי מהעבודה. אתם צריכים כותרות, URLs, snippets, מיקומים ותאריכים בגיליון או במסד נתונים.
בניית כתובת חיפוש ממוקדת ב-Google (הכול יחד)
דוגמה מלאה שמשלבת כמה פרמטרים:
https://www.google.com/search?q=site%3Acompetitor.com+intitle%3Apricing&hl=en&gl=us&tbs=qdr:m,sbd:1&udm=14&pws=0
פירוק:
q=site%3Acompetitor.com+intitle%3Apricing— דפים ב-competitor.com עם "pricing" בכותרתhl=en— ממשק באנגליתgl=us— הקשר שוק ארה״בtbs=qdr:m,sbd:1— חודש אחרון, ממויין לפי תאריךudm=14— תוצאות web קלאסיות (ללא AI Overviews)pws=0— ללא התאמה אישית
אפשר לבנות את זה באופן תכנותי עם curl:
curl -L -G 'https://www.google.com/search' \
--data-urlencode 'q=site:competitor.com intitle:pricing' \
--data-urlencode 'hl=en' \
--data-urlencode 'gl=us' \
--data-urlencode 'tbs=qdr:m,sbd:1' \
--data-urlencode 'udm=14' \
--data-urlencode 'pws=0' \
-H 'User-Agent: Mozilla/5.0'
או עם Python:
import requests
params = {
"q": "site:competitor.com intitle:pricing",
"hl": "en",
"gl": "us",
"tbs": "qdr:m,sbd:1",
"udm": "14",
"pws": "0",
}
response = requests.get(
"https://www.google.com/search",
params=params,
headers={"User-Agent": "Mozilla/5.0"},
timeout=20,
)
print(response.url)
בקשות HTTP אנונימיות ל-Google מחזירות לעיתים קרובות מעטפת JavaScript בלי תוצאות שעברו רינדור בצד השרת, או אזהרות על תעבורה חריגה — וזה בדיוק המקום שבו לחילוץ מבוסס דפדפן יש יתרון.
חילוץ נתוני SERP בלי לכתוב parser
Parsing של HTML של Google הוא עבודה שבירה. מבנה ה-DOM משתנה לעיתים קרובות, שמות המחלקות מוסתרים, ומה שרואים בדפדפן לא תמיד זהה למה שמקבלים בתשובת HTTP גולמית.
גישה פשוטה יותר למי שאינם מפתחים: פותחים את כתובת החיפוש שבניתם בקפידה ב-Chrome, ואז משתמשים בכלי חילוץ מבוסס דפדפן כדי למשוך נתונים מובנים מהעמוד הנראה. ב-Thunderbit בנינו את תוסף Chrome שלנו בדיוק לסוג כזה של תהליך — אפשר להשתמש ב-AI Suggest Fields כדי לזהות עמודות כמו כותרת התוצאה, כתובת היעד, טקסט הסיכום והמיקום הנראה, ואז לחלץ הכול לגיליון בלי לכתוב parser.
זה לא המסלול היחיד. גם גישות מבוססות קוד עובדות, במיוחד אם צריך היקפים גדולים או חילוץ חוזר. אבל למחקר נקודתי, לביקורות ולניתוח תחרותי חד-פעמי, חילוץ מבוסס דפדפן חוסך לגמרי את השבריריות של parsing HTML.
מתי כדאי להשתמש ב-API רשמי במקום זאת
כאן נכנסת הערת שימוש אחראית — וזה חשוב.
תנאי השימוש של Google אוסרים גישה אוטומטית שמעקפת אמצעי הגנה, ו-Google Search Help מסווגת במפורש search scrapers ותוכנות ששולחות שאילתות אוטומטיות כדי לקבוע דירוג כתעבורה אוטומטית. הפעלת Google scraper ברמת production חושפת אתכם לחסימות IP, CAPTCHA ובעיות משפטיות אפשריות.
לצרכי נתוני חיפוש בהיקף גבוה וברמת production, המסלול הטוב יותר הוא API רשמי. Google’s Custom Search JSON API נסגר ללקוחות חדשים — משתמשים קיימים יכולים לעבור עד 1 בינואר 2027, עם 100 שאילתות חינמיות ליום ו-5 דולר לכל 1,000 שאילתות לאחר מכן. Google ממליצה בהמשך על Vertex AI Search לחיפוש מבוקר-אתרים.
עבור אתרים שבבעלותכם, Search Console Search Analytics API הוא מקור first-party לקליקים, חשיפות, CTR ומיקום ממוצע — בלי צורך ב-scraping.
תחשבו על הידע בפרמטרים של URL ככלי אבחון ומחקר: מצוין לבניית קישורי חיפוש מדויקים, להרצת בדיקות ידניות ולהבנת אופן העבודה של Google. לא תחליף ל-API רשמי בקנה מידה גדול.
אופרטורי חיפוש Google: הפרמטרים בתוך השאילתה שלכם
אופרטורי חיפוש נמצאים בתוך q=, אבל הם בני לוויה חיוניים לפרמטרים של URL. הטבלה הבאה מכסה את אלה ש-Google מתעדת כרגע, ועוד כמה שעדיין עובדים בפועל:
העוצמה האמיתית מגיעה משילוב האופרטורים בתוך q עם פרמטרים חיצוניים ב-URL:
q=site:competitor.com+intitle:pricing+after:2026/01/01&tbs=sbd:1&gl=us&udm=14
זה מוצא דפים ב-competitor.com עם "pricing" בכותרת, שפורסמו אחרי ינואר 2026, ממוינים לפי תאריך, בשוק ארה״ב, עם תוצאות web קלאסיות. זו שאילתת מודיעין תחרותי מדויקת מאוד, שנבנתה כולה מפרמטרים ואופרטורים של URL.
Google אומרת שתוצאות site: אינן מובטחות להיות מלאות — לכן לא כדאי להתייחס לשאילתת site: כמלאי ממצה של כל הדפים המאונדקסים.
שימוש אחראי: תנאי השימוש של Google והגבלות קצב
קצר אבל חשוב.
תנאי השימוש של Google אוסרים גישה פוגענית ועקיפת אמצעי הגנה. Google Search Help מציינת במפורש search scrapers ותוכנות אוטומטיות לקביעת דירוג כדוגמאות לתעבורה אוטומטית. הפרת התנאים עלולה להוביל לחסימות IP, CAPTCHA, הגבלות על חשבון ואפילו צעדים משפטיים.
הידע בפרמטרים של URL מתאים בעיקר ל: בניית ידנית של כתובות חיפוש מדויקות, יצירת קישורי חיפוש מסומנים לצוות, הרצת ביקורות קטנות בדפדפן, והבנת אופן הפעולה של ממשק החיפוש של Google. לעבודה אוטומטית בקנה מידה גדול, השתמשו ב-API הרשמיים של Google — או בספק נתוני חיפוש צד שלישי מורשה כמו Brave Search API.
ב-Thunderbit, תוסף הדפדפן שלנו בנוי לחילוץ בעמוד גלוי, ביוזמת המשתמש — לא לשאילתות Google אוטומטיות בהיקף גבוה. זה הבדל חשוב.
עיקרי הדברים: ערכת הכלים שלכם לפרמטרים של Google Search ב-2026
הגרסה המקוצרת:
- השתמשו ב-
gl+hlלאותות לוקליזציה ואל תסתמכו רק על ccTLD בזמן המהלך של הפניות מחדש ב-Google - בדקו גם
udmוגםtbmכשזה רלוונטי — אף אחד מהם אינו API צרכני יציב וממוסמך בגרסה רשמית udm=14עשוי לבקש תוצאות web קלאסיות בלי AI Overviews, אבל Google יכולה להסיר או לשכתב אותו- השתמשו ב-
uuleלמיקוד גיאוגרפי ברמת עיר עם נוסחת הקידוד מבוססת ה-protobuf שלמעלה - שליטה ב-
tbsהיא קריטית לסינון תאריכים מדויק (cdr:1,cd_min:...,cd_max:...), מיון לפי תאריך (sbd:1) וחיפוש verbatim (li:1) - שימו לב לעימותי פרמטרים:
glמולuule,tbmמולudm,lrמולcr num=100לא אמין ומעולם לא היה נתמך רשמית — השתמשו ב-startבקפיצות של 10 כברירת מחדל בטוחה יותר- לנתוני SERP מובנים, השתמשו בכלים מבוססי דפדפן כמו Thunderbit לעבודה נקודתית, או ב-API רשמי להיקפי production
- כבדו את תנאי השימוש של Google — פרמטרים ב-URL הם כלי מחקר, לא רישיון scraping
Google ממשיכה לשנות פרמטרים בלי הודעה מוקדמת. אמשיך לעדכן את ההפניה כשהדברים ישתנו — שמרו את המאמר ובואו לבדוק שוב.
למידע נוסף
- 9 Best SEO APIs for 2026 (With Real Cost-per-Request Data)
- How to Master Search Engine Scraping: A Complete Guide
- Top 27 Tools to Analyze and Monitor Website Rankings
- How to Use Web Scraper Pagination for Efficient Extraction
- What Is Search Automation? Benefits, Tools, and Strategies
שאלות נפוצות
מה עושה udm=14 בכתובת חיפוש של Google?
udm=14 יכול לבקש תצוגת תוצאות web קלאסית בלי AI Overviews, ולכן הוא פופולרי בקרב אנשי SEO. הוא עבר reverse engineering, לא מתועד רשמית כחוזה של Google, ו-Google עשויה להסיר או לשכתב אותו בהתאם לסשן, לחשבון, לאזור, ללקוח ולקבוצת הניסוי.
האם הפרמטר num עדיין עובד ב-2026?
אל תסמכו עליו. Google הפסיקה לכבד באופן עקבי את num=100 בספטמבר 2025, ודובר אמר שהפרמטר מעולם לא היה נתמך רשמית. השתמשו ב-start בקפיצות של 10 כברירת דפדוף בטוחה יותר, ובדקו את מספר התוצאות שמוחזר כי Google עדיין יכולה לשכתב או להגביל את התגובה.
איך מדמים חיפוש Google מעיר מסוימת?
השתמשו בפרמטר uule עם שם עיר מקודד. סעיף הקידוד למעלה מספק את האלגוריתם מבוסס ה-protobuf ודוגמת Python. תצטרכו את השם הקנוני של המיקום ב-Google (זמין מתוך נתוני geographic targeting של Google Ads), שאותו מקודדים לערך uule כמו uule=w+CAIQICIeNew+York,New+York,United+States.
מה ההבדל בין gl, lr ו-cr?
שלושת הפרמטרים האלה שולטים בהיבטים שונים של מיקוד גיאוגרפי ושפתי. gl מדמה את מיקום החיפוש שלכם ברמת מדינה (משפיע על דירוג ותוצאות מקומיות). lr מגביל לתוצאות של דפים הכתובים בשפת תוכן מסוימת. cr מגביל לדפים המתארחים במדינה מסוימת. אפשר לשלב ביניהם, אבל שילובים סותרים (כמו lr=lang_en + cr=countryJP) יצמצמו מאוד את התוצאות.
אפשר לשלב כמה ערכי tbs באותו URL?
כן — מפרידים ביניהם בפסיקים בתוך פרמטר tbs אחד. למשל, tbs=qdr:m,sbd:1 מסנן לחודש האחרון וממיין לפי תאריך (מהחדש לישן). אפשר גם להוסיף li:1 למצב verbatim: tbs=qdr:m,sbd:1,li:1. התחביר של tbs אינו מתועד רשמית, לכן כדאי לבדוק שילובים ספציפיים כדי לוודא שהם עובדים כמצופה.
