pushState और SEO

Question

बहुत से लोग कह रहे हैं, हैशबैंग के बजाय पुशस्टेट का उपयोग करें।

जो मुझे समझ नहीं आ रहा है, आप हैशबैंग का उपयोग किए बिना सर्च-इंजन फ्रेंडली कैसे होंगे?

मुमकिन है कि आपका पुशस्टैट कंटेंट क्लाइंट-साइड जावास्क्रिप्ट कोड द्वारा जनरेट किया गया हो।

परिदृश्य इस प्रकार है:

मैं चालू हूं example.com। मेरा उपयोगकर्ता एक लिंक पर क्लिक करता है:href="example.com/blog"

pushState क्लिक को कैप्चर करता है, URL को अपडेट करता है, कहीं से JSON फाइल पकड़ता है, और सामग्री क्षेत्र में ब्लॉग पोस्ट की सूची बनाता है।

हैशबैंग्स के साथ, Google अपनी स्थैतिक सामग्री प्राप्त करने के लिए escaped_fragment URL पर जाना जानता है।

पुशस्टेट के साथ, Google केवल कुछ नहीं देखता है क्योंकि यह JSON को लोड करने के लिए जावास्क्रिप्ट कोड का उपयोग नहीं कर सकता है और बाद में टेम्पलेट बना सकता है।

इसे करने का एकमात्र तरीका मैं देख सकता हूं कि सर्वर साइड पर टेम्पलेट को प्रस्तुत करना है, लेकिन यह क्लाइंट के लिए एप्लिकेशन परत को आगे बढ़ाने के लाभों को पूरी तरह से नकार देता है।

तो क्या मुझे यह अधिकार मिल रहा है, ग्राहक-साइड अनुप्रयोगों के लिए पुशस्टैट एसईओ के अनुकूल नहीं है?

Comments

भविष्य के पाठकों के लिए ध्यान दें: यह प्रश्न अप्रचलित है । आधिकारिक Google कथन पढ़ें - संक्षेप में, Googlebot अब JS का समर्थन करता है।

— mik01aj

Answer 1

मेटा टैग का उपयोग करने के बारे में जो Google उन लोगों के लिए सुझाता है जो अपने URL में हैश-बैंग्स नहीं चाहते हैं: <meta name="fragment" content="!">

अधिक जानकारी के लिए यहां देखें: https://developers.google.com/webmasters/ajax-crawling/docs/getting-sted

दुर्भाग्य से मुझे नहीं लगता कि निकोल ने इस मुद्दे को स्पष्ट किया कि मुझे लगा कि ओपी हो रहा है। समस्या बस इतनी है कि हम यह नहीं जानते कि हम हैश-बैंग का उपयोग नहीं करते हैं तो हम किसे सामग्री परोस रहे हैं। Pushstate हमारे लिए इसका समाधान नहीं करता है। हम नहीं चाहते कि खोज इंजन एंड-यूजर्स को किसी ऐसे URL पर नेविगेट करने के लिए कहे जो अनजाने JSON से बाहर निकलता हो। इसके बजाय, हम URL बनाते हैं (जो अन्य कॉल को अधिक URL पर ट्रिगर करते हैं) जो AJAX के माध्यम से डेटा पुनर्प्राप्त करते हैं और उपयोगकर्ता को हमारे द्वारा पसंद किए जाने के तरीके से प्रस्तुत करते हैं। यदि उपयोगकर्ता एक मानव नहीं है, तो एक विकल्प के रूप में हम एक html-स्नैपशॉट की सेवा कर सकते हैं, ताकि खोज इंजन मानव उपयोगकर्ताओं को URL पर ठीक से निर्देशित कर सकें कि वे अनुरोधित डेटा (और एक प्रचलित तरीके से) खोजने की उम्मीद करेंगे। लेकिन अंतिम चुनौती यह है कि हम उपयोगकर्ता के प्रकार का निर्धारण कैसे करते हैं? हाँ हम संभवतः उपयोग कर सकते हैं। htaccess या सर्च इंजन बॉट्स के URL को फिर से लिखने के लिए हम पता लगाते हैं, लेकिन मुझे यकीन नहीं है कि यह कितना फुलप्रूफ और फ्यूचरप्रूफ है। यह भी संभव हो सकता है कि Google इस तरह के काम करने के लिए लोगों को दंडित कर सकता है, लेकिन मैंने इस पर पूरी तरह से शोध नहीं किया है। तो (pushstate + google का मेटा टैग) कॉम्बो एक संभावित समाधान प्रतीत होता है।

Comments

@NickC, ठीक है, मैं देख रहा हूं, इसलिए अब मुझे लगता है कि एक बेहतर समाधान सामग्री को शुरू में बिना किसी जेएस के प्रदर्शित करना है। लेकिन आपके जेएस के शीर्ष पर (पृष्ठ लोड होने और डोम तैयार होने के बाद) HTML कोड को छुपाने के लिए तुरंत कुछ कोड होता है जिसे शुरू में जेएस एन्हांसमेंट के साथ प्रदर्शित किया गया था या इसे बदल दिया गया था। उदाहरण के लिए, मैं jquery डेटाट्रेड्स का उपयोग करता हूं, इसलिए मैं पहले एक HTML तालिका प्रदर्शित करता हूं, फिर JS ग्रिड संस्करण में प्रदर्शित सामान्य सारणीबद्ध डेटा को बदलने / छिपाने / बदलने के लिए JS को तुरंत लोड करता हूं। फिर उस बिंदु से, किसी भी अन्य ajax अनुरोधों को JSON के रूप में परोसा जा सकता है, जो URL को पुशस्टेट के माध्यम से अपडेट कर रहा है।

— प्राग्रामर

आपके द्वारा सुझाए गए समाधान के साथ आपका अनुभव कैसा है? क्या Google ने यह 'अस्थायी' HTML इंडेक्स किया था? क्या यह प्रासंगिक Google खोज में ठीक से दिखाई देता है? इसका यह भी मतलब नहीं है कि अनुभव थोड़ा 'घिनौना' है क्योंकि जेएस द्वारा उत्पन्न HTML के साथ प्रारंभिक HTML पृष्ठ 'ताज़ा' है?

— नीलेश काले

@ निलेशकेले यहाँ समाधान मैंने काम किया है और यह बहुत अच्छी तरह से काम पूरा करता है: stackoverflow.com/questions/22824991/… । मैं अभी एक HTML तालिका पास करता हूं और JSON समकक्ष (HTML में क्या है) के साथ भी jqgrid करता हूं। एसईओ HTML को पढ़ता है, और उपयोगकर्ता को एक उन्नत अनुभव और सभी बाद के अनुरोधों को अजाक्स के माध्यम से प्राप्त होता है। पुशस्टेट का उपयोग करके, मैं URL को अपडेट कर सकता हूं कि उपयोगकर्ता कैसे ग्रिड / हैशबैंग की आवश्यकता के बिना पेज को आधार बनाता है)। इससे उपयोगकर्ता URL को सहेज सकता है और उसी परिणाम पर वापस जा सकता है।

— प्राग्रामर

मैं कुछ दिनों में कोशिश करूँगा कि बेहतर तरीके से समझाने के लिए अपने उत्तर पर EDIT कर सकूँ।

— प्राग्रामेर

AJAX- क्रॉलिंग योजना अब समाप्त हो गई है: Developers.google.com/webmasters/ajax-crawling/docs/… । इसे उपयोग करने वाली साइटों को बदलने की सलाह दी जाती है: plus.google.com/+JohnMueller/posts/LT4fU7kFB8W

— रक्षक एक

Answer 2

क्या pushStateबुरा है यदि आपको अपनी सामग्री पढ़ने के लिए खोज इंजन की आवश्यकता है?

नहीं, के बारे में बात pushStateहैशबंग्स के लिए एक ही सामान्य प्रक्रिया को पूरा करने के आसपास है, लेकिन बेहतर दिखने वाले URL के साथ। इस बारे में सोचें कि जब आप हैशबैंग का उपयोग करते हैं तो वास्तव में क्या होता है ...

तुम कहो:

हैशबैंग्स के साथ, Google अपनी स्थैतिक सामग्री प्राप्त करने के लिए escaped_fragment URL पर जाना जानता है।

तो दूसरे शब्दों में,

1. Google एक लिंक देखता है example.com/#!/blog
2. Google अनुरोध करता है example.com/?_escaped_fragment_=/blog
3. आप उस सामग्री का स्नैपशॉट लौटाते हैं जिसे उपयोगकर्ता को देखना चाहिए

जैसा कि आप देख सकते हैं, यह पहले से ही सर्वर पर निर्भर करता है। यदि आप सर्वर से सामग्री का स्नैपशॉट नहीं दे रहे हैं, तो आपकी साइट ठीक से अनुक्रमित नहीं हो रही है।

तो Google पुशस्टेट के साथ कुछ भी कैसे देखेगा?

PushState के साथ, google सिर्फ कुछ भी नहीं देखता है क्योंकि यह जावास्क्रिप्ट लोड करने के लिए json लोड नहीं कर सकता है और बाद में टेम्पलेट बना सकता है।

वास्तव में, गूगल जो भी हो पर अनुरोध कर सकते हैं देखेंगे site.com/blog। एक URL अभी भी सर्वर पर एक संसाधन को इंगित करता है, और क्लाइंट अभी भी इस अनुबंध का पालन करते हैं। बेशक, आधुनिक ग्राहकों के लिए, जावास्क्रिप्ट ने पृष्ठ ताज़ा किए बिना सामग्री के साथ पुनर्प्राप्ति और बातचीत के लिए नई संभावनाएं खोली हैं , लेकिन अनुबंध समान हैं।

तो इसका उद्देश्य pushStateयह है कि यह सभी उपयोगकर्ताओं को पुराने और नए, JS- सक्षम और समान नहीं है, लेकिन नए उपयोगकर्ताओं को एक बढ़ाया अनुभव प्राप्त होता है ।

आपको अपनी सामग्री देखने के लिए Google कैसे मिलेगा?

1. फ़ेसबुक अप्रोच - URL पर उसी सामग्री को परोसें site.com/blogजो आपके क्लाइंट ऐप को /blogस्टेट पर पुश करने पर बदल जाएगी । (फेसबुक pushStateअभी तक उपयोग नहीं करता है कि मुझे पता है, लेकिन वे हैशबैंग के साथ ऐसा करते हैं)

2. ट्विटर का दृष्टिकोण - सभी आने वाले URL को हैशबैंग समकक्ष के लिए पुनर्निर्देशित करता है। दूसरे शब्दों में, "/ ब्लॉग" का एक लिंक /blogराज्य पर जोर देता है । लेकिन अगर यह सीधे अनुरोध किया जाता है, तो ब्राउज़र समाप्त हो जाता है #!/blog। (Googlebot के लिए, यह तब _escaped_fragment_आपके इच्छानुसार रूट होगा । अन्य क्लाइंट के लिए, आप pushStateसुंदर URL पर वापस आ सकते हैं )।

तो क्या आप _escaped_fragment_क्षमता खो देते हैं pushState?

दो अलग-अलग टिप्पणियों में, आपने कहा

बच गया टुकड़ा पूरी तरह से अलग है। आप शुद्ध अनुपचारित सामग्री, कैश्ड सामग्री की सेवा कर सकते हैं, और उस लोड के तहत नहीं डाल सकते हैं जो सामान्य पृष्ठ हैं।

Google के लिए आदर्श समाधान यह है कि या तो जावास्क्रिप्ट साइटों को करें या यह जानने का कोई तरीका लागू करें कि पुशस्टेट साइटों (robots.txt?) के लिए भी कोई बचा हुआ टुकड़ा URL है।

आपके द्वारा बताए गए लाभों को अलग नहीं किया गया है _escaped_fragment_। यह आपके लिए पुनर्लेखन करता है और विशेष रूप से नामित GETपरम का उपयोग करता है वास्तव में कार्यान्वयन विवरण है। इसके बारे में वास्तव में कुछ विशेष नहीं है जो आप मानक URL के साथ नहीं कर सकते थे - दूसरे शब्दों में, mod_rewrite या आपके सर्वर के समकक्ष का उपयोग करके अपने आप /blogको फिर से लिखना ।/?content=/blog

क्या होगा यदि आप सर्वर-साइड कंटेंट को सर्व नहीं करते हैं?

आप URL पुनः लिखने नहीं कर सकते और सेवा सामग्री के कुछ प्रकार पर /blog(या जो भी राज्य आप ब्राउज़र में धकेल दिया), तो अपने सर्वर वास्तव में नहीं रह गया है HTTP अनुबंध से बंधे है।

यह महत्वपूर्ण है क्योंकि एक पृष्ठ पुनः लोड (जो भी कारण के लिए) इस URL पर सामग्री खींचेगा। (देखें https://wiki.mozilla.org/Firefox_3.6/PushState_Security_Review - "व्यू-सोर्स और रीलोड दोनों नए URI में कंटेंट को लाएंगे यदि एक को पुश किया गया था।"

ऐसा नहीं है कि जेएस एपीआई के माध्यम से क्लाइंट-साइड और लोडिंग कंटेंट पर एक बार यूजर इंटरफेस खींचना एक बुरा लक्ष्य है, बस यह कि इसका वास्तव में HTTP और URL के साथ कोई हिसाब नहीं है और यह मूल रूप से पिछड़ा-संगत नहीं है।

फिलहाल, यह सटीक बात है कि हैशबैंग के लिए इरादा है - अलग-अलग पृष्ठ राज्यों का प्रतिनिधित्व करने के लिए जो क्लाइंट पर नेविगेट किए जाते हैं और सर्वर पर नहीं। उदाहरण के लिए, एक पुनः लोड, उसी संसाधन को लोड करेगा जो हैशेड मान को पढ़, पार्स और संसाधित कर सकता है।

यह सिर्फ ऐसा होता है कि उनका उपयोग (विशेष रूप से फेसबुक और ट्विटर द्वारा) किया जाता है, ताकि पृष्ठ ताज़ा किए बिना इतिहास को सर्वर-साइड स्थान पर बदल दिया जा सके। यह उन उपयोग मामलों में है कि लोग पुशस्टैट के लिए हैशबैंग को छोड़ने की सिफारिश कर रहे हैं।

यदि आप सभी सामग्री क्लाइंट-साइड को प्रस्तुत करते हैं, तो आपको pushStateएक अधिक सुविधाजनक इतिहास एपीआई के भाग के रूप में सोचना चाहिए , और हैशबैंग का उपयोग करने के तरीके से नहीं।

Comments

@ हेरी - क्या आपने मेरे जवाब के बाकी हिस्सों को पढ़ा है? एक URL एक URL है - जिसका अर्थ है एक संसाधन लोकेटर। क्या सर्वर का मानना ​​है कि सामग्री मौजूद है site.com/blog? यदि नहीं, तो यह खोज इंजन में मौजूद नहीं है। का उद्देश्य pushStateउस के आसपास काम करना नहीं है। यह सुविधा के लिए है। हैशबैंग या तो इसे ठीक नहीं करते हैं, और _escaped_fragment_यह एक जटिल समस्या है जो अभी भी जेएस उत्पन्न सामग्री के स्नैपशॉट वाले सर्वर पर निर्भर है (सामान्य उपयोगकर्ताओं द्वारा देखा जाता है, जैसा कि आप इसे डालते हैं)। pushStateवास्तव में यह सब सरल करता है।

— निकोल

@Harry - जब तक URL क्लाइंट साइड सामग्री की सेवा के लिए डिज़ाइन नहीं किए जाते, तब तक वे सर्वर पर एक संसाधन का उल्लेख करते हैं, और क्लाइंट उन्हें उस तरह से व्यवहार करेंगे, जिसमें बॉट्स शामिल हैं। इसका मतलब यह नहीं है कि ग्राहक पर जितना संभव हो सके आपका लक्ष्य एक अमान्य है, लेकिन समय के लिए इसे (बदसूरत) हैशबैंग का उपयोग करके पूरा करना पड़ सकता है। मैंने आपके उपयोग के मामले में अपना उत्तर अपडेट कर दिया है।

— निकोल

@ हेरी सबसे पहले मैं केवल यही कहता हूं कि Google जो कह रहा है, उसके लिए मैं जा रहा हूं _escaped_fragment_और मुझे नहीं पता कि तुम विशेष रूप से क्या करते हो। लेकिन गूगल का कहना है कि क्या से, मैं तुम्हें ग्रहण करना चाहिए सामग्री के कुछ प्रकार की सेवा सर्वर द्वारा जब आप उस क्वेरी परम देखें। आपके मामले में इसके लिए कुछ प्रवंचना की आवश्यकता होगी, लेकिन आप कुछ <noscript>सामग्री या कुछ और परोस सकते हैं /blogऔर फिर JS को वह पृष्ठ बनाना होगा जो आप चाहते हैं। या, आप बॉट का पता लगाने का प्रयास कर सकते हैं और जानबूझकर पूरी तरह से अलग सामग्री परोस सकते हैं।

— निकोल

एक बार फिर सही और सबसे अच्छा उत्तर सही नहीं उठाया गया है ... बुरा, बुरा।

अगर मैं की तरह एक कड़ी: <a href="product/productName" onclick="showProduct(product)">A product</a>, और साथ "onclick शुरू होता है preventDefault()", तो AJAXly भार पेज में उत्पाद के बारे में नई सामग्री, और मुझे यकीन है कि लिंक बनाने "... / उत्पाद / productName" का एक संस्करण लोड होगा वह पृष्ठ जहां सर्वर से प्रतिक्रिया पर विशिष्ट उत्पाद सामग्री शामिल की जाएगी --- तो, ​​साइट अभी भी गतिशील रूप से काम करेगी, लेकिन सीधे उत्पाद लिंक पर जाकर स्थैतिक सामग्री भी उपलब्ध होगी? इस तरह से pushState या हैशबैंग की कोई ज़रूरत नहीं, नहीं?

— युवल ए।

Answer 3

सभी दिलचस्प बात के बारे में pushState और #!, और मैं अभी भी नहीं देख सकता कि कैसे pushState की जगह #! 'का मूल पोस्टर पूछता है।

हमारे 99% जावास्क्रिप्ट-आधारित Ajax साइट / एप्लिकेशन को SEOable बनाने के लिए हमारा समाधान #!निश्चित रूप से उपयोग कर रहा है। चूंकि क्लाइंट रेंडरिंग HTML, जावास्क्रिप्ट और PHP के माध्यम से की जाती है, इसलिए हम अपने पेज लैंडिंग द्वारा नियंत्रित लोडर में निम्न तर्क का उपयोग करते हैं। HTML फ़ाइलें जावास्क्रिप्ट और PHP से पूरी तरह से अलग हैं क्योंकि हम दोनों में (अधिकांश भाग के लिए) एक ही HTML चाहते हैं। जावास्क्रिप्ट और PHP ज्यादातर एक ही काम करते हैं, लेकिन PHP कोड कम जटिल है क्योंकि जावास्क्रिप्ट एक अधिक समृद्ध उपयोगकर्ता अनुभव है।

जावास्क्रिप्ट HTML में इंजेक्शन के लिए jQuery का उपयोग करता है जो वह चाहता है। PHP, HTML में जो सामग्री चाहता है, उसे इंजेक्ट करने के लिए PHPQuery का उपयोग करता है - 'लगभग' एक ही तर्क का उपयोग करते हुए, लेकिन PHP संस्करण के रूप में बहुत सरल केवल SEOable लिंक के साथ एक SEOable संस्करण प्रदर्शित करने के लिए उपयोग किया जाएगा और जावास्क्रिप्ट संस्करण की तरह बातचीत नहीं की जाएगी।

सभी तीन घटक हैं जो एक पृष्ठ, page.htm, page.js और page.php को बनाते हैं, जो किसी भी चीज के लिए मौजूद हैं, जो एस्केप संस्करण का उपयोग करके यह जानने के लिए है कि क्या जावास्क्रिप्ट संस्करण को जावास्क्रिप्ट संस्करण के स्थान पर लोड करना है। PHP संस्करण को गैर-एसईओ करने योग्य सामग्री (जैसे पृष्ठ जो केवल उपयोगकर्ता लॉगिन के बाद ही देखे जा सकते हैं) के लिए मौजूद होने की आवश्यकता नहीं है। सब सीधा है।

मैं अभी भी हैरान हूं कि कुछ फ्रंट एंड डेवलपर्स कैसे महान साइटों (Google डॉक्स की समृद्धि के साथ) को विकसित कर रहे हैं, जो कि ब्राउजर वालों के साथ सर्वर साइड प्रौद्योगिकियों का उपयोग किए बिना ... यदि जावास्क्रिप्ट भी सक्षम नहीं है, तो हमारा 99% जावास्क्रिप्ट समाधान है निश्चित रूप से PHP के बिना कुछ भी नहीं करेगा।

PHP सर्व किए गए पेज पर उतरने और जावास्क्रिप्ट सक्षम होने पर जावास्क्रिप्ट संस्करण पर पुनर्निर्देशित करने के लिए एक अच्छा URL होना संभव है, लेकिन उपयोगकर्ता के दृष्टिकोण से यह अच्छा नहीं है क्योंकि उपयोगकर्ता अधिक महत्वपूर्ण दर्शक हैं।

एक और बात। यदि आप केवल एक सरल वेबसाइट बना रहे हैं, जो बिना किसी जावास्क्रिप्ट के काम कर सकती है, तो मैं पुशस्टैट को उपयोगी हो सकता हूं अगर आपका उत्तरोत्तर अपने उपयोगकर्ता के अनुभव को एक साधारण सांख्यिकीय रूप से प्रदान की गई सामग्री से बेहतर तरीके से बढ़ाना चाहता है, लेकिन यदि आप अपने उपयोगकर्ता को देना चाहते हैं। जाने के लिए सबसे अच्छा अनुभव ... मान लीजिए कि आपका नवीनतम गेम जावास्क्रिप्ट में लिखा गया है या Google डॉक्स जैसी कोई चीज़ है, तो इस समाधान के लिए इसका उपयोग कुछ हद तक सीमित है क्योंकि पीछे की ओर गिरने पर उपयोगकर्ता अनुभव के दृष्टि की तुलना में दर्दनाक होने से पहले केवल इतनी दूर जा सकता है साइट का।