एसईओ बनाम विकास, ग्राहक को कैसे चोट नहीं पहुंचाई जाए

लेख में सभी आंकड़े केवल हमारे अनुभव से प्रस्तुत किए गए हैं और आपके डेटा से भिन्न हो सकते हैं (68 एसईओ परियोजनाओं का विश्लेषण किया गया था, उनमें से 26 हमारे विकास और संवर्धन हैं, और 23 परियोजनाएं जहां हमारा विकास है और अनुकूलन पक्ष में है)।

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

आइए इस बारे में बात करें कि यह संघर्ष क्या हो सकता है और इससे कैसे बचा जा सकता है।



तो इस संघर्ष में आपके प्रोजेक्ट का क्या हो सकता है:

• पूर्ण और अंतिम विफलता: पैसा खर्च (और काफी), और परिणाम के बजाय, केवल अप्रिय परिणाम;
• साइट के माध्यम से बिक्री में गिरावट (भले ही परियोजना औपचारिक रूप से सफल हो);
• परियोजना सफल है, यहां तक ​​कि बिक्री भी बढ़ी है, लेकिन लागत कई बार अनुमान में फिट नहीं हुई;
• हां, प्रोजेक्ट सफलतापूर्वक पूरा हो सकता है, लेकिन इसके लिए आपको प्रबंधक और वार्ताकार के जादुई कौशल की आवश्यकता होगी।

संघर्ष का एनाटॉमी

डेवलपर्स आपको बताएंगे कि "सबसे अधिक भाग के लिए एसईओ भ्रमपूर्ण संपादन प्रदान करता है जो _possibly_ साइट की स्थिति में सुधार करता है, और आपको डेवलपर से लिंक को हटाने की आवश्यकता होती है (माना जाता है कि यह स्थिति को खराब कर देता है), जबकि आपका खुद का फांसी शर्म नहीं है।"

एसईओ कहेगा कि: "डेवलपर्स केवल साइट में बदलाव नहीं करना चाहते हैं और यह नहीं समझते हैं कि उनकी आवश्यकता क्यों है, क्योंकि वे विषय को नहीं समझते हैं। वास्तव में, सब कुछ प्राथमिक रूप से किया जाता है, और संपादन की सुरक्षा विशेषज्ञों के अनुभव पर निर्भर करती है। ”

ऐसा लगता है कि स्थिति समझ में आ रही है, और संघर्ष अपरिहार्य है। यह सच है, अगर यह एक विभाग और विकास विभाग एक कंपनी के विभाजन हैं, तो इसे कम किया जा सकता है।

ऑप्टिमाइज़र्स के साथ डेवलपर की बातचीत आमतौर पर तब शुरू होती है जब खोज इंजन अनुकूलन के लिए एक तकनीकी कार्य (टीओआर) तैयार होता है। यह एक ऐसा दस्तावेज है जिसमें एसईओ विशेषज्ञ डेवलपर को अपनी आवश्यकताओं के लिए साइट को फिर से तैयार करने के लिए कहते हैं। और फिर ग्राहक के लिए, आश्चर्य शुरू होता है।

वेबसाइट अनुकूलन के लिए तकनीकी विशिष्टताओं में, आमतौर पर काफी विशिष्ट और तार्किक आवश्यकताएं होती हैं। डेवलपर्स उनके बारे में जानते हैं और कोड में इसे foresee करते हैं। लेकिन यहाँ बारीकियाँ हैं:

1. उद्देश्य: "अच्छा" पृष्ठ पते (सीएनसी - एसईओ-शब्दजाल में) बनाने के लिए।
अयोग्य रूप से योग्य ऑप्टिमाइज़र खुद को इस वाक्यांश तक सीमित रखते हैं, और फिर पूरे पाठ में टीके यूआर यूआरएल का उपयोग करते हैं जो उन्होंने खुद को निर्दिष्ट किए बिना बताया कि कौन सा पेज इस तरह के पते के साथ दिखाई देना चाहिए। दूसरी ओर, विशेषज्ञ, पहले, एक साइट के सभी पृष्ठों के लिए सीएनसी के निर्माण के लिए एक सार्वभौमिक एल्गोरिथ्म, और दूसरी बात, उन पृष्ठों की एक सूची को लिखेंगे, जिन्हें "था-यह बन गया" प्रारूप में विशेष पते की आवश्यकता है।

लेकिन समस्या हमेशा अच्छे तरीके से हल नहीं होती है। इसके अलावा, यहां तक ​​कि 1 सी-बिट्रिक्स के रूप में ऐसी प्रतीत होती समस्या-मुक्त सीएमएस के लिए (उदाहरण के लिए, यदि साइट की मुख्य सामग्री एक निर्देशिका है जिसमें श्रेणियों को फ़िल्टर के माध्यम से चयन द्वारा निर्धारित किया जाता है)।

2. उद्देश्य: दिए गए पृष्ठों के लिए निर्दिष्ट मेटा टैग्स को लिखें (यह सरल प्रतीत होता है, लेकिन फिर से फ़िल्टर के साथ निर्देशिका को याद रखें)।

3. कार्य: विशिष्ट पृष्ठों पर पाठ ब्लॉक जोड़ें। समस्याएं समान हो सकती हैं। यहां भी, ग्राहक को एसईओ का खतरा है। यदि काम के बयान में यह लिखा गया है "ग्रंथों को बाद में प्रदान किया जाएगा" - किसी भी मामले में इसे काम न करने दें!

हम अनुशंसा करते हैं कि आप पहले अच्छे पाठ लिखें, और उसके बाद ही साइट पर उनकी स्थापना के साथ समस्या का समाधान करें। दो कारण हैं: सबसे पहले, यदि आप सामग्री के लिए ब्लॉक के डिजाइन को अनुकूलित करते हैं, तो यह अंत में बेहतर लगेगा यदि आप सामग्री को एक ब्लॉक में भरते हैं जो संरचना में इसके लिए बिल्कुल उपयुक्त नहीं है।



दूसरे, क्योंकि आशावादी सैकड़ों पृष्ठों के लिए ग्रंथों का अनुरोध कर सकते हैं। यदि आप ग्रंथों को नहीं देते हैं, तो वे एसईओ कॉपीराइटर से ऑर्डर किए जाते हैं। यदि आप उन्हें पोस्ट करने से पहले पढ़ते हैं, तो आप प्रति माह दस टुकड़ों पर सहमत होने का प्रबंधन कर सकते हैं (या उन्हें स्वयं फिर से लिख सकते हैं)। यदि आप साइट को बढ़ावा नहीं देते हैं, तो सामग्री की गुणवत्ता कम होने के कारण उपयोगकर्ता आदेश नहीं देंगे।

पृष्ठ लेआउट, छवि नाम, लिंक, robots.txt, आदि के लिए आमतौर पर निम्नलिखित आवश्यकताएं हैं। - सामान्य तौर पर - कुछ भी आपराधिक नहीं। काफी पागल होता है (भगवान का शुक्र है, यह हमारे टीके में नहीं पाया गया है):

• इनपुट पेज का पता बदलें ("mScript" - एसईओ-शब्दजाल में) "sitename.ru" से "sitename.ru/product_name.html";
• कैलकुलेटर से कैटलॉग से स्वचालित डेटा प्रतिस्थापन को तोड़ने के लिए, ताकि कैलकुलेटर पर इनपुट हमेशा शून्य डेटा के साथ हो, और ताकि उपयोगकर्ता अपने हाथों से खरोंच से सभी मूल्यों को चलाएं;
• मुख्य पृष्ठ पर तीन के बजाय दो कॉलम बनाएं (स्पष्टीकरण के बिना, निश्चित रूप से, इसमें पवित्र अर्थ क्या है);
• कुछ विदेशी योजना के अनुसार पेज हेडर जनरेट करें (मैं आपको विश्वास दिलाता हूं, हाथ से लिखी हेडिंग - वे शासन करते हैं), आदि।

व्यक्तिगत अनुभव से, जब खोज इंजन अनुकूलन परियोजनाएं सफल होती हैं, और जब वे संभवतः विफल हो जाते हैं:

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

जब डेवलपर्स एसईओ-टीके प्राप्त करते हैं, तो वे आमतौर पर आवश्यकताओं के भाग के कार्यान्वयन के साथ समस्याएं पाते हैं, और वे एकमुश्त बकवास के बारे में सवाल पूछने लगते हैं। ग्राहक जोर देकर कहते हैं (ऑप्टिमाइज़र उसे धकेल रहे हैं) - डेवलपर्स एक ठोस मूल्य टैग जारी कर रहे हैं।

ग्राहक इसे आशावादियों के लिए कहता है। वे आपत्ति करने लगते हैं - कि सब कुछ तत्व रूप से किया जा सकता है। स्वाभाविक रूप से, ग्राहक चरम है।

घटनाओं के विकास के लिए विकल्प:

• ग्राहक तकनीकी कार्य के कार्यान्वयन के लिए डेवलपर को भुगतान करता है। परिणाम: टीके किया जाता है, लेकिन आशावादियों को हमेशा शिकायत करने के लिए कुछ मिलता है। सबसे अधिक संभावना है, सब कुछ एक संघर्ष में परिणाम होगा। और ग्राहक इस बात का अहसास बना रहेगा कि वह ओवरपेड है। और इस वजह से, वे ऑप्टिमाइज़र के साथ गलती पाएंगे। परियोजना अंत में विफल हो जाएगी।
• ऑप्टिमाइज़र खुद को टीके को लागू करने के लिए कहते हैं और ग्राहक को बचाने के लिए ऐसा करता है। परिणाम: एक उच्च संभावना के साथ साइट टूट जाती है (भले ही अनुकूलक के पास अच्छे प्रोग्रामर हों, साइट एक जटिल प्रणाली है!)। इस मामले में, हर कोई एक पड़ोसी के कुटिल हाथों को इंगित करेगा। ग्राहक को इसकी मरम्मत करनी होगी। ठीक है, अगर उसने इस बिंदु पर डेवलपर के साथ संबंध खराब नहीं किया। तीसरी टीम इसे और भी अधिक महंगा और अप्रिय करेगी। आशावादियों की टीम के साथ संबंध भी अनिवार्य रूप से बिगड़ेंगे। प्रोजेक्ट फेल हो जाएगा।

पुराना चुटकुला

बाज़ारिया प्रोग्रामर से पूछता है: किसी बड़ी परियोजना के समर्थन में क्या कठिनाई है?

प्रोग्रामर: ठीक है, कल्पना कीजिए कि आप एक लेखक हैं और परियोजना "युद्ध और शांति" का समर्थन करते हैं। आपके पास TK है - एक अध्याय लिखिए कि कैसे नताशा रोस्तोवा बारिश में पार्क में चली। आप लिखते हैं "बारिश हो रही थी", बचाओ, त्रुटि संदेश "नताशा रोस्तोवा की मृत्यु हो गई, निरंतरता असंभव है" मक्खियों। वह मर क्यों रही है? आप समझने लगते हैं। यह पता चलता है कि पियरे बेजुखोव के फिसलन वाले जूते, वह गिर गया, उसकी बंदूक जमीन पर गिर गई और एक पोल पर गोली चल गई, और एक स्तंभ से एक गोली नताशा के पास गिरी। क्या करें? बंदूक निष्क्रिय चार्ज? जूते बदलें? हमने पिलर को हटाने का फैसला किया। हम संदेश "लेफ्टिनेंट Rzhevsky मृत्यु हो गई।" यह पता चला है कि अगले अध्याय में वह एक स्तंभ पर झुक जाता है जो अब नहीं है ...

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

यह पता चला है कि "डेवलपर-आशावादी" संघर्ष को या तो हल किया जा सकता है यदि वे एक दूसरे के साथ सीधे सहमत होते हैं, और ग्राहक के माध्यम से नहीं, या ग्राहक की ओर से शांत प्रबंधन द्वारा। हम केवल विशेष रूप से हमारे द्वारा विकसित की गई परियोजनाओं को बढ़ावा देने के लिए शुरू करने में सक्षम थे, जो कि अनुकूलन के लिए हमारे पास समय से पहले कोई नहीं था।

ऐसा लगता है कि यह विकल्प आदर्श है, लेकिन यहां तक ​​कि ऐसी परियोजनाएं अंततः विफल हो सकती हैं। कारण आमतौर पर औपचारिक मानदंडों के साथ ग्राहक की अपेक्षाओं का बेमेल हैं, प्रक्रिया में भाग लेने या बल में ग्राहक की मनाही (जो बाकी की तुलना में इस उद्योग में अधिक सामान्य है)। इन समस्याओं से कैसे निपटें - नीचे विचार करें। वैसे भी, सफल परियोजनाओं का हिस्सा कई गुना अधिक है।

व्यक्तिगत अनुभव से। कम से कम नुकसान के साथ एक एसईओ परियोजना को लक्ष्य तक कैसे लाया जाए

हमने ग्राहकों के लिए निम्नलिखित सिफारिशें विकसित की हैं (यहां मैं एसईओ-ट्रिक्स के बारे में बात नहीं करूंगा, सभी एक जैसे, ऑप्टिमाइज़र उनके बारे में बेहतर तरीके से बात कर पाएंगे, लेकिन मैं केवल संगठनात्मक मुद्दों पर ही बात करूंगा):

• खोज प्रोत्साहन के लिए कंपनी चुनते समय, डेवलपर से एक वाणिज्यिक प्रस्ताव का अनुरोध करें। इसके साथ काम करने से आपको संपादन पर एक निश्चित राशि की बचत होगी। ऑफ़र में कीमतों की तुलना करते समय इसे ध्यान में रखें। और यह सभी को बहुत सारी नसों को बचाएगा।

• यदि उसी स्थान पर एसईओ का आदेश देना जहां विकास असंभव है, और ग्राहक के पास एड़ी के ऊपर संघर्ष सिर में उतरने और दोनों टीमों का प्रबंधन करने की ताकत नहीं है - तो उन्हें सीधे कनेक्ट करना बेहतर है, उन्हें सहमत होने दें।
• शुरू करने से पहले, पता करें कि क्या प्रमोशन के लिए प्रोजेक्ट मैनेजर को विकासशील साइटों (या कम से कम सिर्फ वेब प्रोग्रामिंग में अनुभव) के लिए परियोजनाओं के प्रबंधन का अनुभव है। आदर्श रूप से, यदि उसके पास प्रयोज्य क्षमता भी है। यह आपको टीके की वस्तुओं से बचाएगा जो असंभव या बहुत महंगा है, या जो साइट की उपयोगिता को कम कर देगा।
• खोज इंजन अनुकूलन के लिए तकनीकी विशिष्टताओं को बनाते समय प्राथमिकता हमेशा प्रयोज्य पर होनी चाहिए। यदि संपादन साइट को कम सुविधाजनक बनाता है - तो इसकी आवश्यकता नहीं है। इसके अलावा, अब खोज इंजन व्यवहार कारकों के लिए बहुत अधिक वजन देते हैं (यदि उपयोगकर्ता आपकी साइट को बहुत जल्दी छोड़ देते हैं तो स्थिति गिर जाएगी)।
• एसईओ से संदर्भ की एक बहुत विस्तृत, समझने योग्य और विशिष्ट शर्तों की मांग करें। यह न केवल डेवलपर को, बल्कि ग्राहक को भी स्पष्ट होना चाहिए। सर्वनाम सामान्यीकरण नहीं होना चाहिए: सब कुछ, हर कोई, कोई भी, आदि। केवल इस मामले में ऑप्टिमाइज़र तकनीकी विशिष्टताओं की आवश्यकताओं की गलत या अपूर्ण पूर्ति के परिणामस्वरूप परिणाम की अनुपस्थिति का श्रेय नहीं दे पाएंगे।
• डेवलपर से संदर्भ की शर्तों के प्रत्येक आइटम के लिए एक आकलन की मांग करें, और ToR पर एक सामान्य मूल्यांकन नहीं। सबसे पहले, आप तुरंत अप्रत्याशित रूप से महंगे संपादन प्रकट कर सकते हैं, और दूसरी बात, आवश्यकताओं को बदलते समय, आपके लिए नई राशि पर चर्चा करना आसान होगा।
• उन मदों पर चर्चा करें जहां संपादन बजट आपको परेशान करता है, न केवल डेवलपर्स के साथ, बल्कि एसईओ के साथ भी। शायद आप इस संपादन के बिना कर सकते हैं या इसे अलग तरीके से कर सकते हैं। यदि साइट में परिवर्तन करने की लागत (श्रमसाध्यता) इस संपादन से अपेक्षित वापसी से अधिक है, तो निश्चित रूप से ऐसा करना आवश्यक नहीं है।
• ग्राहक परियोजना की सफलता का आकलन करता है, सबसे पहले, औपचारिक संकेतों से नहीं, बल्कि अनुप्रयोगों की मात्रा और गुणवत्ता से। इसलिए, आशावादी को पहले रूपांतरण के बारे में सोचने की जरूरत है, फिर पदों के बारे में। यदि साइट पुरानी है, तो पर्याप्त जानकारी नहीं है, और ग्रंथों को किसी ने मातम के तहत बहुत रचनात्मक लिखा था - आपको इसे ठीक करने की आवश्यकता है! ग्राहकों को सलाह: अपने संभावित ग्राहकों से पूछें कि क्या उन्हें आपकी साइट पसंद है और क्या इसका उपयोग करना सुविधाजनक है। यदि नकारात्मक समीक्षा दोहराई जाती है - एक अवसर को प्रतिबिंबित करने और तत्काल इसे फिर से करने के लिए।
• खैर, एक और पल। जब एक ग्राहक रूपांतरण में गिरावट के बारे में शिकायत करता है, तो ऑप्टिमाइज़र को इसे पास नहीं होने देना चाहिए। ग्राहकों को सलाह: यदि आपको लगता है कि कम आवेदन आए हैं (और यह वास्तव में गणना के बाद ऐसा है), तो समस्या का विश्लेषण करने के लिए ऑप्टिमाइज़र की आवश्यकता करने में संकोच न करें। परियोजना का पूरी तरह से परीक्षण किया जाना चाहिए, सभी मैट्रिक्स का विश्लेषण किया जाना चाहिए। आमतौर पर, ऐसे मामलों में, आप अप्रत्याशित चीजें पकड़ सकते हैं जो एसईओ से संबंधित नहीं हैं, लेकिन परियोजना को विफल कर सकती हैं। उदाहरण के लिए, अनुप्रयोग थे, लेकिन वे मेल तक नहीं पहुंचे, या अचानक सभी आदेश स्पैम में आने लगे। या समस्या साइट पर नए उत्पादों के परिवर्तन है, क्योंकि उनके पास खराब तस्वीरें हैं। संक्षेप में, विकल्प अंतहीन हैं।
• यातायात को आकर्षित करने के लिए वैकल्पिक चैनलों का उपयोग करें। ग्राहकों के लिए एसईओ के प्रभाव की प्रतीक्षा करना मनोवैज्ञानिक रूप से कठिन है, जो कि जैसा कि आप जानते हैं, छह महीनों में थोड़ा ध्यान देने योग्य हो जाता है। ताकि यह न लगे कि पैसा हवा के लिए लिया जा रहा है - समानांतर में, यह प्रासंगिक विज्ञापन के माध्यम से यातायात को आकर्षित करने के लायक है।
• SEO कॉपीराइटर से ग्रंथों को कभी नहीं, बिल्कुल, कभी नहीं, कभी भी ऑर्डर न करें। न तो आपकी साइट पर, न ही बाहरी साइटों के लेखों के रूप में जहां लिंक खरीदे जाते हैं। यदि उत्पाद सस्ता नहीं है, तो खरीदार कंपनी के नाम से, खोज इंजन के माध्यम से विक्रेता के बारे में जानकारी की तलाश करेगा। और ये कॉपी राइटिंग "ग्रंथ" प्रत्यर्पण में दिखाई देंगे। खरीदार उन्हें पढ़ेगा, अपर्याप्तता देखेगा, और उच्च स्तर की संभावना के साथ लेनदेन को मना कर देगा।
• याद रखें कि पीआर विभाग भुगतान करता है। लेकिन केवल इस शर्त पर कि कॉपीराइटर फ्रीलांस नहीं हैं, लेकिन एक पूरे दिन के लिए कार्यालय में हैं और पहले से ही विषय को समझते हैं। उदाहरण के लिए, हमारे राज्य में दो कॉपीराइटर-पीआर-मैनेजर हैं जो अपने समय का 90% हमें लिखते हैं। सीईओ और कभी-कभी परियोजना प्रबंधक भी लेख लिखते हैं।

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