API למעקב דירוג: בנו לעצמכם גשש דירוגים של Google משני מקורות

‏"API לתיעוד דירוג" הוא לא דבר אחד. מפתחים שמחפשים "rank tracking API" רוצים בדרך כלל נקודת קצה אחת שמחזירה מיקומים, והשוק עונה להם במאמרי רשימה של ספקים. התשובה הכנה היא שצריך שני מקורות, ושהם עונים על שתי שאלות שונות.

‏Search Console API חינמי, רשמי, ומוגבל לתמיד לנכסים שאתם יכולים לאמת. ‏SERP API בתשלום, לא רשמי, ויכול לבדוק כל מילת מפתח בכל מקום, כולל מילים שמעולם לא דורגתם עליהן. אף אחד מהם לבדו אינו מתעד דירוג. יחד, מדובר בכ-120 שורות Python ורשומת cron אחת.

זהו הבנייה. היא מניחה שאתם יכולים להריץ סקריפט ולשמור קובץ. היא לא מניחה שאתם רוצים לבנות מוצר.

מה יהיה לכם בסוף

למי זה מיועד: למפתח או משווק טכני שכבר יש לו גישה ל-Search Console ורוצה מיקומים לפי לוח זמנים בלי לשלם לפי מושב.

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

זמן: כ-90 דקות לבנייה הראשונה, ואחר כך כ-10 דקות סקירה לכל הרצה.

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

לפני שמתחילים: מה כל מקור יכול ומה הוא לא יכול

תעשו את החלוקה הזאת נכון וכל שאר הבנייה מכנית. תעשו אותה לא נכון ותבזבזו חודש על בניית משהו שחסר תועלת או יקר.

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

שלושה מספרים ששווה להכיר לפני שכותבים קוד. ‏Search Console API מקבל מגבלת שורות שבין 1 ל-25,000 לבקשה, וברירת המחדל היא 1,000, כך שאתר בינוני יכול למשוך שלושה חודשים של נתוני שאילתות והתקנים בקריאה אחת. הוא מתיר 1,200 שאילתות בדקה לכל אתר ולכל משתמש. והוא כופה מכסות עומס הנמדדות במקטעים של 10 דקות, שבהן טווח תאריכים ארוך עולה יותר מקצר, וזו בדיוק הסיבה שההנחיות של Google עצמה אומרות להימנע משאילתה חוזרת על אותם נתונים.

שני מקורות, פלט אחד. ‏Search Console עונה "איפה אני מופיע", ‏SERP API עונה "איך נראה הדף".

שלב 1: קפיאו את סט מילות המפתח לפני שתכתבו קוד

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

שלוש קבוצות, והן מגיעות ממקורות שונים.

• מ-Search Console: כל שאילתה עם 20 חשיפות לפחות ב-90 הימים האחרונים. אתן לא בוחרים אותן; החשיפות שלכן בוחרות. זו הקבוצה שבה לתנועה יש משמעות, כי כבר יש ביקוש מחובר אליה.
• מהעסק: עשר עד עשרים השאילתות שממופות להכנסה, בין אם אתן מדורגים עליהן ובין אם לא.
• ממתחרים: השאילתות שמתחרה מדורג עליהן ואתם לא. אלה דורשות SERP API, כי Search Console לעולם לא יציג אותן.

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

שלב 2: משכו את המיקומים שלכם בחינם

החצי הזה רשמי, חינמי, ונותן לכם פילוח התקנים ונתוני קליקים שאין לאף SERP API.

from google.oauth2 import service_account
from googleapiclient.discovery import build

service = build(
    "searchconsole", "v1",
    credentials=service_account.Credentials.from_service_account_file(
        "gsc-key.json",
        scopes=["https://www.googleapis.com/auth/webmasters.readonly"],
    ),
)

body = {
    "startDate": "2026-06-14",
    "endDate": "2026-09-11",
    "dimensions": ["query", "device"],
    "type": "web",
    "dataState": "final",
    "rowLimit": 25000,
}

rows = service.searchanalytics().query(
    siteUrl="sc-domain:example.com", body=body
).execute().get("rows", [])

שני פרטים בבקשה הזאת עושים את רוב העבודה.

dataState: "final" מוציא נתונים טריים ש-Google עשויה עוד לשנות. בלעדיו, היומיים-שלושה האחרונים זזים בין הרצות וההפרש שלכם מציג תנועות שמעולם לא קרו.

dimensions: ["query", "device"] הוא מה שהופך את הפלט לשימושי בהמשך. הוספת התקן עכשיו לא עולה דבר. משיכה חוזרת של שלושה חודשי היסטוריה בהמשך עולה הרצה שלמה ולא נותנת לכם דבר עבור הימים שכבר דילגתם עליהם.

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

בדיקת איכות: מספר השורות צריך להיות מתחת ל-25,000. אם הוא בדיוק 25,000, אתם קטועים וצריך קריאה שנייה עם startRow: 25000.

אם זה נכשל: 403 בדרך כלל אומר שכתובת הדוא"ל של חשבון השירות מעולם לא נוספה כמשתמש בנכס. הוסיפו אותה ב-Search Console, המתינו כמה דקות, ונסו שוב.

שלב 3: משכו את תוצאות ה-SERP שאינכם רואים בנתונים שלכם

החצי השני מכסה את כל מה ש-Search Console לא יכול לעשות מבנית. זו קריאה עובדת מינימלית.

import base64, json, urllib.request

LOGIN, PASSWORD = "your-login", "your-password"

def serp(keyword, depth=100):
    token = base64.b64encode(f"{LOGIN}:{PASSWORD}".encode()).decode()
    payload = json.dumps([{
        "keyword": keyword,
        "location_name": "United States",
        "language_name": "English",
        "depth": depth,
    }]).encode()
    request = urllib.request.Request(
        "https://api.dataforseo.com/v3/serp/google/organic/live/advanced",
        data=payload,
        headers={"Authorization": f"Basic {token}",
                 "Content-Type": "application/json"},
        method="POST",
    )
    return json.loads(urllib.request.urlopen(request, timeout=120).read())

הגדירו `depth` ל-100, לא 200. בדקנו את זה בספטמבר 2026 בבקשה של 200 תוצאות על פני שש שאילתות. ‏Google החזירה 83 עד 128 תוצאות אורגניות ועצרה, והמיקום העמוק ביותר בכל הבדיקה היה 142. הבדיקה המלאה כאן. בקשה של 200 לא מניבה 200 תוצאות, ובהתאם לספק ייתכן שעדיין תחויבו על העומק שביקשתם. בקשו 100 ותקבלו כמעט תמיד את כל מה שקיים.

בקשה של 200 תוצאות וקבלה של 83 עד 128. עומק מעל כ-140 לא קונה דבר ברוב השאילתות המסחריות.

פלט צפוי: מטען JSON שמכיל פריטים אורגניים עם מיקום, כתובת, כותרת ודומיין.

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

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

שלב 4: אגרו את המטען הגולמי, לא את התקציר

זו ההחלטה שאנשים מתחרטים שדילגו עליה.

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

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

שלב 5: כתבו את כלל ההשוואה לפני שאתם קובעים לוח זמנים

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

אז הכלל צריך סף וכיוון.

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

קבצו את הפלט לפי סוג שאילתה: money, comparison, brand, informational.
אל תציעו תיקונים.

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

מה זה עולה

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

• מילת מפתח אחת שנבדקת פעם ביום במשך 30 יום = 30 בקשות בחודש.
• סט של 200 מילות מפתח שנבדק מדי יום = 6,000 בקשות בחודש.
• אותו סט שנבדק מדי שבוע = כ-860 בקשות בחודש.
• חצי Search Console חינמי, והוא בקשה אחת לכל תצוגה, בלי קשר לכמה מילות מפתח יש בתוכה.

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

מתי לקנות במקום לבנות

בנו את זה אם אתם רוצים מיקומים בתוך הצינור שלכם, אם כבר יש לכם הרשאות SERP API, או אם אתם צריכים את דף התוצאות הגולמי מסיבות שמעבר למיקום.

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

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

עמדת Auspia: שאלת ה-API לתיעוד דירוג היא בעצם שאלת בעלות על נתונים. ‏Search Console נותן לכם נתונים רשמיים על הנכס שלכם בחינם ותמיד יעשה זאת. כל השאר הוא צילום שאתם משלמים עליו. בנו קודם את החצי החינמי, והוסיפו את החצי בתשלום רק במקום שבו הוא עונה על שאלה שבאמת יש לכם.

שאלות נפוצות

האם Google מציעה API לתיעוד דירוג? לא באופן פומבי. ‏Search Console API מחזיר את המיקום הממוצע שלכם עבור שאילתות שאתם כבר מופיעים בהן, וזה קרוב אבל לא אותו דבר. הוא לא יכול לבדוק מילה שאינכם מדורגים עליה, והוא לא יכול לבדוק מתחרה.

עד כמה עמוק SERP API יכול להגיע? ספקים יקבלו ערכי עומק הרבה מעל 200, אבל Google מפסיקה להגיש תוצאות אי שם בין 100 ל-140 ברוב השאילתות המסחריות. בקשת יותר לא מניבה יותר תוצאות.

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

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

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

הכותב: Rowan Blake, אנליסט אוטומציית תוכן ב-Auspia, אחראי על יותר מ-100 צינורות פרסום. רואן כותב על צינורות נתונים אוטומטיים, דיווח מתוזמן, ועלות התחזוקה של מערכות שרצות בלעדיכם.