עימוד (Pagination) ב-SEO — כיצד לנהל עמודי רשימה ללא פגיעה בדירוג

עימוד (Pagination) הוא הפיצול של תוכן ארוך לעמודים מרובים: עמוד קטגוריה עם 200 מוצרים שמוצגים 20 בכל עמוד, בלוג עם 100 מאמרים שמוצגים 10 בכל עמוד, או רשימת חדשות שמפוצלת לעמוד 1, עמוד 2, עמוד 3 וכן הלאה.

מבחינת SEO, Pagination יוצרת מספר אתגרים: בזבוז תקציב סריקה — Googlebot מבזבז זמן על עמוד 8 של קטגוריה שמעטים הגיעו אליה. פיצול PageRank — קישורים חיצוניים לאתר מגיעים בדרך כלל לעמוד הראשון, בעוד שהמוצרים בעמוד 5 מקבלים מעט מאוד PageRank. כפילות תוכן חלקית — header, footer, ניווט וחלק מהתוכן חוזרים בכל עמוד.

עד 2019, גוגל המליצה על תגיות rel=prev ו-rel=next כדי לאותת על רצף עמודי pagination. ב-2019 גוגל הודיעה שהיא מפסיקה לתמוך בהם — ולמעשה הייתה מתעלמת מהם זמן רב לפני ההכרזה.

ה-decision הזה הפתיע רבים בתעשייה, אך ההגיון של גוגל היה ברור: גוגל מסוגלת להבין מבנה pagination מקישורים ומ-URL patterns ללא תגיות ייעודיות.

אם יש לך אתר שעדיין משתמש ב-rel=prev/next — זה לא מזיק, אך גם לא עוזר. אין צורך להסירם, אך אין טעם להוסיפם לאתרים חדשים.

ניהול נכון של pagination תלוי בסוג האתר והתוכן.

אפשרות 1 — noindex לעמודים עמוקים: חסום עמודים עמוקים (עמוד 3 ומעלה) עם noindex. תוכן שנמצא בעמוד 5 של קטגוריה לרוב לא יאונדקס בכל מקרה ולא תורם לדירוג. הסתר את הבלגן מגוגל ושמור את תקציב הסריקה לדפי מוצר.

אפשרות 2 — Canonical לעמוד ראשון: canonical של עמוד 2, 3, 4 מצביע על עמוד 1. זה אומר לגוגל שעמוד 1 הוא הגרסה הרשמית. בעיה: מוצרים שנמצאים רק בעמוד 3 לא יאונדקסו.

אפשרות 3 — 'Load More' ב-JavaScript: לא מפצלים לדפים אלא מטעינים תוכן נוסף ב-JavaScript. נוח למשתמש, אך גוגל לא תמיד מרנדרת תוכן שנטען דינמית. מחייב בדיקה שגוגל רואה את כל המוצרים.

Infinite Scroll הוא גישה שבה תוכן נוסף נטען אוטומטית בגלילה — בלי לחיצה על 'עמוד הבא'. נפוץ ב-Instagram, Twitter, ואתרי מדיה.

מבחינת SEO, Infinite Scroll בעייתי: Googlebot לא גולל מסך. הוא סורק HTML מוגש ומרנדר JavaScript, אך לא מבצע גלילה. תוכן שמגיע רק לאחר גלילה לרוב לא נסרק.

פתרון: השתמש ב-Infinite Scroll למשתמשים, אך שמור על URLs לעמודי pagination בניווט. לכל 'גוש' תוכן שנוסף — יש URL ייחודי. כך גוגל יכולה לגשת לתוכן ישירות דרך ה-URL, ואילו המשתמש חווה גלילה רציפה.

עמודי Pagination הם אחד המבזבזים הגדולים של תקציב הסריקה. חנות עם 100 קטגוריות, כל אחת עם 10 עמודי pagination — 1,000 URL שמבזבזים מכסה.

גישה מומלצת לניהול תקציב: חסום עמודי pagination עמוקים ב-robots.txt. לדוגמה, שורה כמו:

Disallow: /category/*?page=

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

וודא שכל מוצר, מאמר, או פריט תוכן נגיש גם ישירות מה-Sitemap — לא רק דרך Pagination. כך גוגל יכולה לגלות ולאנדקס מוצרים מבלי לסרוק עמודי Pagination עמוקים.

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

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

הכל בסיטמאפ: כל URL של מוצר מאונדקס ישירות מה-Sitemap, ללא תלות ב-Pagination.

עמוד קטגוריה ראשון מאונדקס: עמוד 1 של כל קטגוריה מאונדקס — הוא מייצג את הקטגוריה.

עמודים 2+ עם noindex: עמודים נוספים נגישים למשתמש (UX) אך נחסמים לגוגל. מוצרים שמופיעים רק בעמוד 5 מגיעים לאינדוקס דרך ה-Sitemap.

קישורים פנימיים ישירים: מכל עמוד מאונדקס, ישנם קישורים ישירים למוצרים הפופולריים — לא רק ב-pagination.

Google Search Console — בדוק Pages report לאיתור עמודי Pagination שאונדקסו שלא היית רוצה. אם רואה עמוד קטגוריה 15 באינדקס — יש בעיה.

Screaming Frog — סרוק את האתר ובדוק כמה URL של Pagination קיימים, ואילו מהם נגישים לגוגל (אין robots.txt block ואין noindex).

בדיקת GSC Crawl Stats — האם אחוז גדול מהסריקות הולך ל-URL עם ?page= או /page/N/? זה מצביע על בזבוז תקציב.

PageSpeed Insights — בדוק גם את ביצועי עמוד 1 של קטגוריה. עמוד קטגוריה שמציג 50 מוצרים עם תמונות — עלול להיות איטי ולפגוע ב-Core Web Vitals.