היי — שאלת שני דברים באותה הודעה: למה הסנכרון לשלושת הדומיינים שלך נורה שעה מאוחר יותר ממה שקבעת, והאם כדאי פשוט להעביר את צוות האופטימיזציה שלך למצב אוטונומי כשאתה כבר שם. מסתבר ששני הדברים הם אותה שיחה בדיוק, אז בוא אטפל בהם יחד במקום לירות שתי תשובות נפרדות.
נתחיל מצורת המערכת, כי היא מסבירה את שתי הבעיות. כל צוות כאן פועל באחד משלושה מצבים — פעם אחת, ידני, אוטונומי — ו"אוטונומי" הוא לא איזו שכבה נפרדת וחכמה יותר. זו ריצה ידנית עם לוח זמנים מצורף והלולאה נשארת סגורה. אותו סוכן, אותם מעקות בטיחות, אותו הכל, פשוט מתזמן שמחליט מתי ללחוץ על הכפתור במקומך. ברגע שזה ברור, השאר נופל למקומו.
למה הסנכרון שלך ולוח הזמנים שלך יושבים במקומות שונים
| תזמון | מה זה מניע |
|---|---|
| סנכרון נתונים | המשיכה היומית של נתוני Search Console / Analytics / חנות ללוחות המחוונים שלך — הדלק לכל השאר |
| ריצות סוכנים | ריצות אופטימיזציה אוטומטיות אחרי כל סנכרון, סריקות מחקר שממלאות מחדש את תור התדריכים שלך, וכל צוות שאתה משאיר פועל |
תמצא הגדרות סנכרון יושבות עם כל דומיין והגדרות ריצה יושבות עם כל צוות — לא בעמוד אוטומציה משולב אחד, מה שאני יודע מרגיש לא נכון בפעם הראשונה שאתה מחפש. עם זאת, זה מכוון. קצב הסנכרון שלך נוגע בנתונים: באיזו מהירות Search Console באמת מתרענן. קצב הריצה שלך נוגע בצוות: באיזו מהירות אתה רוצה שהצוות הזה יפעל על מה שהוא רואה. אלו שאלות שונות עם תשובות שונות, וגרסה מוקדמת יותר של הפלטפורמה חיברה אותן יחד בעמוד אחד, מה שאומר שנגיעה באחת מהן גררה אותך לחשוב על שתיהן. הפרדתן הייתה התיקון.
דבר אחד ששווה לדעת לפני שתתזמן משהו לצוות האופטימיזציה שלך: ריצה שנורה לפי לוח זמנים וריצה שאתה מתחיל ידנית מייצרות אובייקט זהה לחלוטין ברגע שהן פועלות. אותו דוח, אותה רשומת היסטוריה, אותה עלות קרדיטים, אותה יכולת לפתוח אותה באמצע ריצה ולצפות במה שהיא עושה. נתקלתי באנשים שהניחו שריצות מתוזמנות הן גרסה קלה יותר וחתוכה כדי לחסוך בעלות — הן לא. אם לא היית סומך על ריצה שהפעלת בעצמך, אל תשים אותה על טיימר.
מה בעצם השתבש עם לוח הזמנים שהיגרת
ציינת שהדבקת את השעה ישירות מהכלי הישן שלך — 14:00 UTC, שאמורה הייתה לנחות ב-2 בצהריים בשעה שלך. זו בדיוק המלכודת. שדה הזמן שלנו רוצה את השעון המקומי שלך, לא UTC; הוא מציג את אזור הזמן שזוהה ממש מתחתיו כדי שלא תצטרך אף פעם לנחש. הדבק ערך UTC שם והוא יטופל כאילו הוא כבר מקומי, יומר ל-UTC פעם שנייה, ותקבל ריצה ב-4 אחר הצהריים במקום 2. התיקון עבור שני הדומיינים האחרים שלך: הזן מחדש את השעות במקומי, התעלם מכל ערך UTC שהכלי הישן נתן.
השעה ששאלת עליה בעצם — הסנכרון שנוחת ב-7 בבוקר במקום 6 — היא תופעה של שעון קיץ, וכדאי להבין אותה פעם אחת במקום לרדוף אחריה בכל מרץ ואוקטובר. קבע סנכרון של 6:00 בברלין בינואר והפלטפורמה שומרת 5:00 UTC, כי ברלין נמצאת ב-UTC+1 בחורף. מתזמן נאיבי פשוט ימשיך לירות ב-5:00 UTC לנצח. עם קפיצת שעון הקיץ, ברלין עוברת ל-UTC+2, ואותה תזוזת 5:00 UTC נוחתת עכשיו ב-7:00 מקומי — בשקט, ללא שגיאה, פשוט מספרים כמה שעות מאוחר יותר ממה שציפית. אנחנו ממירים בזמן ההזנה כנגד ההיסט הנוכחי במקום זאת, כך שלוח זמנים של 6:00 אומר 6:00 שעון קיר ביום שבו הוא רץ, שעון קיץ או לא. אם אתה עדיין רואה סטייה של שעה אחרי הזנת השעה מחדש במקומי, שווה כרטיס תמיכה — זה לא אמור לקרות עם לוח זמנים שהוזן מחדש.
קביעת הקצב בפועל
- סנכרון: יומי, לא מהיר יותר. נתוני Search Console מגיעים בפיגור של יומיים עד שלושה ימים ביום טוב. סנכרון כל שעה בין שלושת הדומיינים שלך לא ייתן לך מספרים טריים יותר, הוא רק ימלא את היסטוריית הסנכרון בעבודות ששולפות שוב ושוב את אותם נתונים מפגרים.
- אופטימיזציה: משורשרת לסנכרון, לא בשעון נפרד. זה החלק החשוב ביותר לגבי מה שאתם עומדים לתזמן. אם הסנכרון מסתיים ב-6:02 במקום ב-6:00 כי ה-API של גוגל היה איטי באותו בוקר, ריצת האופטימיזציה מופעלת מיד לאחר מכן, על הנתונים הטריים - היא לא ממתינה למשבצת הזמן שלה עצמה ב-6:15 ומסתכנת בריצה על נתוני אתמול אם הסנכרון במקרה התארך. שני שעונים בלתי תלויים נשמעים בסדר עד היום שבו הם נסחפים זה מזה.
- מחקר: שבועי, בגודל שצוות התוכן שלכם באמת יכול לטפל בו. בריפים לא מתיישנים בין לילה, ובריפים שלא נבדקים ויושבים בתור עדיין עולים קרדיטים כדי להיווצר גם אם אף אחד לא פועל לפיהם. אם הצוות שלכם יכול לאשר בפועל ארבעה או חמישה בריפים בשבוע, קבעו את הסריקה כך שתפיק בערך את זה - סריקה יומית שמזינה הרגל בדיקה שבועי פשוט בונה תור שאף אחד אף פעם לא עובד דרכו.
- מודעות, כשתגיעו לאותו צוות בחודש הבא: אין תזמון, בכוונה. טיוטות נוצרות לפי דרישה; שום דבר לא מתפרסם או מוציא כסף בלעדיכם. ההיגיון מוסבר בהטיעון נגד הוצאה אוטומטית, אבל בקצרה - טעות בתזמון של סנכרון תוכן היא מטרד קטן, וטעות בתזמון של הוצאה על מודעות היא חשבון לתשלום. אל תצפו שההגדרות של הצוות ההוא ייראו כמו אלה שאתם מגדירים היום.
אז - האם כדאי להפוך את האופטימיזציה לאוטונומית?
הנה התשובה הכנה, שפחות דרמטית ממה שהשאלה מרמזת: הפעלתה משנה פחות ממה שהייתם חושבים. הסוכן לא מקבל שום יכולת חדשה שלא הייתה לו כשלחצתם על הפעלה בעצמכם - אותם חסמי אישור לכל דבר הרסני, אותם שיקולי דעת, אותו הכול. מה שמשתנה זה רק מי מחליט מתי הוא פועל. כרגע, אתם. בתזמון, השעון מחליט.
השאלה שבאמת הייתי שואל, במקום "האם אוטונומי בטוח", היא זו: האם אתם מרוצים מהתוצאה של שלוש ריצות האופטימיזציה הידניות האחרונות שלכם שיקרו שוב, ללא השגחה, בכל קצב שתגדירו? אם כן, אתם מוכנים - הפעילו את זה. אם אתם מרוצים רק כי אישית בדקתם כל אחת משלוש הריצות הללו לפני שמשהו במורד הזרם קרה, זה סימן אמיתי, והוא אומר שלהישאר ידני עוד קצת זו ההחלטה הנכונה, לא כישלון של אומץ.
בהתחשב במצב שלכם - שלושה דומיינים שעברו הגירה זה עתה, זמנים שעדיין לא התייצבו לגמרי - הייתי ממתין עם האוטונומיה עוד כמה ימים. תקנו את שני התזמונים הנותרים, צפו בסנכרון של מחר נוחת בשעה הנכונה, הריצו את האופטימיזציה ידנית עוד פעמיים-שלוש כדי שבאמת תראו מה היא עושה מקצה לקצה. אחר כך תזמנו אותה. שאלות הקצב שלמעלה הופכות הרבה יותר קלות למענה כשיש לכם ריצה אמיתית מול העיניים, מאשר בהפשטה, ואין שום עלות בהמתנת שבוע כדי להגיע לזה.



