מהי הפנייה מחדש?
הפניה מחדש היא דרך לשלוח הן משתמשים ומנועי חיפוש לכתובת אתר שונה מזו שביקשו במקור.
סוגי ההפניות כיום
- 301, "הועבר לצמיתות" (מומלץ לקידום אתרים)
- 302, "נמצא" או "הועבר זמנית"
- Meta Refresh
301, "הועבר לצמיתות"
הפניית 301 היא הפניה קבועה המנתבת בין 90-99% מהון הקישורים (כוח הדירוג) לדף המנותב מחדש.
301 מתייחס לסטטוס קוד HTTP עבור הפניה מסוג זה.
ברוב המקרים, הפניה מחדש 301 היא השיטה הטובה ביותר ליישום הפניות מחדש באתר.
302, " נמצאו" (HTTP 1.1) / "הועברו באופן זמני" (HTTP 1.0)
חלק מעובדי גוגל ציינו כי ישנם מקרים בהם ניתן לטפל באופן דומה ב- 301 וב- 302, אך הראיות שלנו מצביעות על כך שהדרך הבטוחה ביותר להבטיח שמנועי חיפוש ודפדפנים מכל הסוגים ייתנו קרדיט מלא היא להשתמש ב- 301 בעת הפניה קבועה של כתובות אתרים.
האינטרנט פועל על פרוטוקול הנקרא פרוטוקול העברת HyperText (HTTP) המכתיב כיצד כתובות URL עובדות.
יש לו שתי גרסאות עיקריות, 1.0 ו- 1.1.
בגרסה 1.0, 302 מתייחס לקוד הסטטוס "הועבר זמנית", אולם בגרסה 1.1 זה השתנה, ומשמעותו היא "נמצא".
307, "הועבר באופן זמני בלבד" (HTTP 1.1)
הפניית 307 היא יורשת ההפניה של 302 HTTP 1.1
.בעוד שהסורקים הגדולים יתייחסו אליו כמו ל- 302 במקרים מסוימים, עדיף להשתמש ב- 301 כמעט לכל המקרים.
היוצא מן הכלל לכך הוא כאשר תוכן באמת מועבר באופן זמני בלבד (כגון במהלך תחזוקה) והשרת כבר זוהה על ידי מנועי החיפוש כתואם 1.1.
זאת מכיוון שבעצם בלתי אפשרי לקבוע אם מנועי החיפוש זיהו דף תואם או לא, ולכן בדרך כלל עדיף להשתמש בהפניית 302 לתוכן שהועבר זמנית.
ריענון מטה – Meta Refresh
ריענון מטא הוא סוג של הפניה מחדש ברמת הדף ולא ברמת השרת.
בדרך כלל הניתוב איטי יותר, ולרוב הוא משויך לספירה לאחור של חמש שניות עם הטקסט "אם אינך מנותב מחדש תוך חמש שניות, לחץ כאן".
ריענון מטא אכן מעביר חלק מההון הקישורי, אך אינו מומלץ כטקטיקה של SEO בגלל שמישות לקויה ואובדן הון עצמי של קישורים.
שיטות עבודה מומלצות לקידום אתרים
מקובל להפנות מחדש כתובת אתר אחת לאחרת.
כאשר עושים זאת, חשוב להקפיד על שיטות עבודה מומלצות על מנת לשמור על ערך ה- SEO.
הדוגמה הנפוצה הראשונה לכך מתרחשת בתרחיש פשוט: כתובת URL שצריכה להפנות לכתובת אחרת לצמיתות.
ישנן אפשרויות רבות לעשות זאת, אך באופן כללי, הפניית 301 עדיפה הן למשתמשים והן למנועי חיפוש.
הגשת 301 מציינת הן לדפדפנים והן לבוטים של מנועי החיפוש שהדף עבר לצמיתות.
מנועי החיפוש מפרשים זאת בכך שלא רק שהדף שינה מיקום, אלא שאפשר למצוא את התוכן, או גרסה מעודכנת שלו, בכתובת האתר החדשה.
המנועים יישאו כל שקלול קישור מהדף המקורי לכתובת האתר החדשה.
שימו לב, כאשר מעבירים דף מכתובת אתר אחת לאחרת, למנועי החיפוש ייקח קצת זמן לגלות את ה- 301, לזהות אותו ולזכות את הדף החדש בדירוג ובאמון של קודמו.
תהליך זה יכול להיות ארוך יותר אם עכבישים למנועי חיפוש לעיתים נדירות מבקרים בדף האינטרנט הנתון, או אם כתובת האתר החדשה אינה נפתרת כראוי.
הפנייה מחדש – אופציות נוספות
אפשרויות אחרות להפניה מחדש, כמו 302 וריענון מטא, הן תחליפים גרועים, מכיוון שהם בדרך כלל לא יעברו את הדירוג ואת ערך מנועי החיפוש כמו הפניה 301.
הפעם היחידה שההפניות האלה מהוות חלופות טובות היא אם מנהל אתרים בכוונה לא רוצה להעביר את הון הקישורים מהדף הישן לחדש.
העברת תוכן הופכת מורכבת יותר כאשר אתר שלם משנה את הדומיין שלו או כאשר תוכן עובר מדומיין אחד לאחר.
עקב שימוש לרעה מצד שולחי דואר זבל וחשד מצד מנועי החיפוש, הפניות 301 בין דומיינים דורשות לעיתים זמן רב יותר כדי לעקוב אחר ספירה ולספור אותם כראוי.
301 , הפניות מחדש באפאצ'י
· הבעיה:
כשחברת MOZ השיקה את האתר הראשון שלה seomoz.org, הוא התארח בכתובת www.socengine.com/seo/ , ולא בדומיין שלו.
כשהמפתחים המקוריים העבירו את seomoz.org לשרת ייעודי משלהם, הם רצו שניתן יהיה לגשת אליו כאל דומיין משלה ולא כאל תת-תיקייה של socengine.com., ולשם כך הם היו זקוקים למבקרים שניגשים לכל דבר בכתובת www.socengine.com/seo/ כך שיופנו אל www.seomoz.org .
ההפניה מחדש הייתה צריכה להכיל מספר שינויים בשמות הקבצים והתיקיות, והיה צריך לבצע ב- 301 הפניות מחדש כדי להיות ידידותיים למנועי החיפוש.
לשם כך הם היו צריכים להעביר גם את http://seomoz.org למטרות אסתטיות ולהימנע משגיאות קנוניזציה.
· הפתרון:
הגישה הפשוטה ביותר לעשות זאת הייתה להוסיף 301 הפניות מחדש לקוד ה- PHPשהפעיל את seomoz.org באמצעות פונקציית הכותרת שלPHP , תוך ניצול העוצמה של מודול האפאצ'י,mod_rewrite .
לעומת זאת, המפתחים הבינו שהם יכולים להתאים תבניות ספציפיות לתיקיות שלמות ולנתב אותם לכתובות האתר החדשות שלהם מבלי לעבור על כל סקריפט PHP.
· התקנה:
על מנת שזה יעבוד, על שרת אינטרנט להתקין את מודול אפאצ'י mod_rewrite .
ברוב ההתקנות של אפאצ'י מותקן כברירת מחדל mod_rewrite.
השרת המקורי של SEOmoz ניהל את הפצת הלינוקס FreeBSD, ו- mod_rewrite נכלל כברירת מחדל.
כדי לבדוק אם המודול מותקן, המפתח יכול לאמת שהוא פועל על ידי הוספת השורה הבאה לקובץ התצורה של אפאצ'י או לקובץ htaccess רלוונטי: RewriteEngine On
· הקשר:
מודול mod_rewrite פועל בהקשר לכל שרת או בהקשר לכל ספרייה.
ההקשר לכל שרת מחייב את המפתח לערוך את קובץ התצורה של אפאצ'י httpd.conf.
,ואילו ההקשר לכל ספרייה משתמש בקבצי htaccess, הקיימים בכל תיקיה שמשתמש רוצה להגדיר.
אם מנהל אתרים אינו יכול לגשת ל- httpd.conf, הוא יצטרך להשתמש בקבצי .htaccess.
ביטויים רגולריים (aka Regexes)
(מתוך wikipedia.org 🙂
ביטוי רגולרי הוא מחרוזת המתארת או תואמת קבוצה של מחרוזות על פי כללי תחביר מסוימים.
ביטויים רגולריים משמשים עורכי טקסט וכלי עזר רבים כדי לחפש ולבצע מניפולציות בגופי טקסט על בסיס דפוסים מסוימים.
ביטויים רגולריים הם מיומנות חיונית וחשובה הן עבור מתכנתים והן עבור מנהלי מערכות.
להפניית כתובות אתרים לפי הדוגמאות במסמך זה, חשוב להבין את יסודות השימוש ב- regexes.
להלן רשימה של הדמויות והמפעילים המשמשים את ה- regexes, המתוארים במסמך זה:
– . תקופה- תואמת כל דבר
– * כוכבית- תואמת לאפס או יותר מהתווים הקודמים
– + סימן פלוס – תואם אחד או יותר מהדמות הקודמת
– () סוגר- סגירת ערך בסוגריים תאחסן את מה שמתאים במשתנה לשימוש אחר כך. השימוש בזה מכונה גם התייחסות אחורית
– (value1 | value2)- סגירת שני ערכים או יותר בסוגריים והפרדתם עם תו צינור היא המקבילה לאמירה: "התאמת ערך 1 או ערך 2"
הפניית קבצים ותיקיות ספציפיים מתחום אחד למשנהו
המפתחים המקוריים של Moz היו זקוקים להפניה מהשרת הישן לזה החדש עם שמירת הקבצים.
· דוגמא:
הפניה מחדש: http: // www.socengine.com/seo/ s …
אל: /somefile.php
· פתרון:
הוסף את ההנחיה הבאה לקובץ הרלוונטי בשרת socengine.com:
RedirectMatch 301 /seo/(.*) / $ 1
· הסבר:
הביטוי הרגולרי /seo/(.*) אומר לאפאצ'י להתאים את תיקיית ה- SEO, ואחריה אפס או יותר מכל התווים סביב ה- .*
הסוגריים אומר לאפאצ'י לשמור את המחרוזת המותאמת כהפניה אחורית, הממוקמת בסוף כתובת האתר שהופנתה, במקרה זה$1 .
הפניית שמות מארח קנוניים
היזמים המקוריים של Moz היו צריכים להפנות כל בקשה, שלא מתחילה ב- www.seomoz.org כדי לוודא שהם כוללים את ה-www.
הם עשו זאת לא רק משום שזה נראה טוב יותר, אלא כדי להימנע משגיאות קנוניזציה נפוצות.
הפניה מחדש: http://seomoz.org/
אל: http://www.seomoz.org/
הפנייה מחדש: http://mail.seomoz.org/
אל: http://www.seomoz.org
הפנייה מחדש: http://seomoz.org/somefile.php
אל: www.seomoz.org/somefile…
http://#####replaceparse27####… >Solution
הוסיפו את ההנחיה הבאה:
RewriteCond% {HTTP_HOST} *! ^ www * .seomoz .org [NC] RewriteRule (.*)http://www.seomoz.org/http://www.seomoz.org/$1 [L, R = 301] </ Pre>
· הסבר
הנחיה זו אומרת לאפאצ'י לבדוק את המארח שאותו האורח מבקר, ואם הוא אינו שווה ערך ל- www.seomoz.org , להפנות מחדש אל www.seomoz.org .
סימן הקריאה (!) מול www.seomoz.org שולל את ההשוואה באומרו, "אם המארח אינו www.seomoz.org , בצע RewriteRule".
במקרה שלנו RewriteRule מפנה אותו אל www.seomoz.org תוך שמירה על הקובץ המדויק אליו הם ניגשו בהפניה אחורית.
הפנייה מחדש מבלי לשמור על שם הקובץ
כמה מהקבצים שהיו קיימים בשרת הישן לא היו קיימים בשרת החדש. במקום לשמור על שמות הקבצים בניתוב מחדש (מה שיגרום לשגיאה 404 שלא נמצאת בשרת החדש), היה צורך להפנות את הקבצים הישנים לכתובת ה- URL הבסיסית של הדומיין החדש.
הפניה מחדש: http: // www.socengine.com/seo/ s …
אל: http: // www.seomoz.org /
· פתרון:
הוסיפו את ההנחיה הבאה:
RedirectMatch301/seo/someoldfile.php http://www.seomoz.org </ pre & ... class = "bottom0">
· הסבר:
בהשמטת סוגריים כלשהם, כל הבקשות עבור /seo/someoldfile. צריכות לנתב לכתובת האתר הבסיסית של http: // www.seomoz.org
הפנייה מחדש מחרוזת ה- GET
לחלק מתסריטי ה- PHP היו שמות שונים' אך מחרוזת ה- GET נשארה זהה.
מפתחי Moz היו צריכים להפנות את המבקרים לסקריפטים החדשים של PHPתוך שמירה על מחרוזות ה- GET הללו.
מחרוזת ה- GET היא קבוצת התווים שמגיעה אחרי שם קובץ בכתובת ה- URL ומשמשת להעברת נתונים לדף אינטרנט.
דוגמה למחרוזת GET בכתובת האתר /myfile.php?this=that&foo=bar תהיה ?this=that&foo=bar
הפניה מחדש: http: // www.socengine.com/seo/ c …
אל: www.seomoz.org /artcat.p …
http: // ##### replaceparse37 #### … class = "bottom0">
· פתרון:
הוסיפו את ההנחיה הבאה:
RedirectMatch 301 /seo/categorydetail.php(.*) http: //www.seomoz.org/artcat.p ... class = "bottom0">
· הסבר:
שוב הביטוי הרגולרי (.*) אומר לאפאצ'י להתאים לאפס או יותר מכל תו ולשמור אותו כהפניה האחורית $1. מכיוון שיש $1 אחרי /seo/categorydetail.php, כעת הוא ינתב את מחרוזת ה- get לקובץ ה- PHP החדש הזה.
הפנייה מחדש בעת שינוי סיומות קבצים
בתרחיש המקורי הייתה תיקיית קבצים בשרת הישן שהיו מעורבים HTML ו- PHP.
בשרת החדש הקבצים האלה היו כולם PHP והצריכו לוגיקה להפניה מחדש כדי לשנות את כתובות ה- URL הישנות לתוסף החדש הזה.
הפניה מחדש: http: // www.socengine.com/seo/ g …
אל: http://www.seomoz.org/articles…
הפניה מחדש: http: // www.socengine.com/seo/ g …
אל: www.seomoz.org/articles…
http: // ##### replaceparse41 #### … class = "bottom0"> פתרון:
הוסיפו את ההנחיה הבאה:
RedirectMatch 301 /seo/guide/(.*).(php|html) http: //www.seomoz.org/articles ... class = "bottom0">
* הסבר:
(*.) תואם לאפס או יותר מכל תו ושומר אותו כהפניה אחורית $1. .(php|html) אומר לאפאצ'י להתאים תקופה, ולאחריה "php" או "html", ושומר אותה כנקודת ההפניה האחורית $ 2 (אם כי זה לא משמש בדוגמה זו).
שימו לב לתקופה שנמלטה עם נטייה אחורית, זאת על מנת להבטיח שאפאצ'י לא יפרש את התקופה כמשמעות "כל דמות" אלא כתקופה ממשית.
סוגרים "php" ו-"html" בסוגריים ומפרידים אותם בתו צינור "|" , שפירושו להתאים לאחד מהערכים.
כך אם זה היה אומר (php|html|css|js|jpg|gif), ה- regex יתאים לכל אחד מהקבצים עם התוספים php, html, css, js, jpg או gif.
לסיכום,
על ידי שימוש בכוחם של mod_rewrite וקסם ביטוי קבוע מעט, פיתחו המפתחים המקוריים במוז קבוצה של כללים פשוטים להפניה מחדש של דפי אינטרנט.
באמצעות 301 הפניות מחדש, הם עשו זאת באופן ידידותי למנועי חיפוש.
