কাঙ্ক্ষিত পেজগুলো এবং পুনঃব্যবহারযোগ্য প্রমাণ দিয়ে শুরু করুন
আপনি কোন পাবলিক পেজগুলোকে সার্চারদের দ্বারা খুঁজে পাওয়া উচিত মনে করেন তা তালিকাভুক্ত করুন: প্রধান পণ্য, আরটিকেল, ক্যাটাগরি এবং স্থানান্তরিত URL। প্রত্যেকটির জন্য পছন্দের URL, প্রত্যাশিত রেসপন্স, ইনডেক্সযোগ্যতা, টেমপ্লেট, মালিক, এবং অগ্রাধিকার নথিভুক্ত করুন। বৈধ বর্জ্য (legitimate exclusions) আলাদা রাখুন।
প্রতিনিধিত্বমূলক URL-এর জন্য একটি অযোগ্যতা ছাড়া (unauthenticated) রেসপন্স, হেডার, রিডাইরেক্ট পথ, পেজ সোর্স, রেন্ডার করা ভিউ, অভ্যন্তরীণ-লিংক অবস্থা, এবং সাইটম্যাপ অবস্থা ক্যাপচার করুন। প্রতিটি টেমপ্লেট এবং URL প্যাটার্ন থেকে নমুনা নিন। প্রমাণ সময়-নির্ধারিত: একটি CDN সেটিং, ডেপ্লয়মেন্ট, কনসেন্ট লেয়ার, বা পার্সোনালাইজেশন পরে পরিবর্তন করতে পারে।
হোমপেজ পাস করা মানেই লিস্টিং, পণ্য ভ্যারিয়েন্ট বা লোক্যালাইজড রুটগুলো কাজ করে এমন প্রমাণ দেয় না।
ফিক্স এবং পরবর্তী রিগ্রেশন তুলনা করার জন্য তারিখযুক্ত হেডার এবং রেন্ডার করা প্রমাণ রাখুন।
ইনডেক্সযোগ্যতাকে সচেতন সিদ্ধান্ত করুন
ইনডেক্সযোগ্যতা অর্থ একটি পেজ সার্চ ইন্ডেক্সে অন্তর্ভুক্ত হতে পারে; এটি ক্রলিং বা র্যাঙ্কিংয়ের সমান নয়। HTML-এ meta robots নির্দেশনা এবং X-Robots-Tag রেসপন্স হেডারগুলো পরীক্ষা করুন। noindex নির্দেশনা সার্চ ইঞ্জিনকে একটি পেজ দেখাচ্ছে না বলে বলে; X-Robots-Tag নন-HTML ফাইল যেমন PDF-এও প্রযোজ্য।
robots.txt আলাদাভাবে পর্যালোচনা করুন। একটি ক্রলারকে একটি পেজের noindex নির্দেশনা দেখতে হলে সেই পেজে অ্যাক্সেস থাকতে হবে, তাই উক্ত URL ব্লক করলে নির্দেশনা দেখা আটকাতে পারে। ডিপ্লয়কৃত, পাবলিক রেসপন্স পরীক্ষা করুন কারণ CMS সেটিংস এবং এনভায়রনমেন্ট ফ্ল্যাগ অতিরিক্ত নিয়ম যোগ করতে পারে। noindex হল অ্যাক্সেস কন্ট্রোল নয়: সংবেদনশীল বিষয়বস্তুকে প্রটেক্ট করতে অথেনটিকেশন ও উপযুক্ত সিকিউরিটি রিভিউ ব্যবহার করুন।
কাঙ্ক্ষিত-ইনডেক্স পেজগুলিতে noindex, লগইন রেসপন্স, স্টেজিং রেফারেন্স, এবং ব্লক করা অপরিহার্য অ্যাসেটগুলো ফ্ল্যাগ করুন।
যেখানে HTML head নেই সেখানে এমনকি HTTP রেসপন্স হেডারেও নির্দেশনা থাকতে পারে।
একটি পছন্দের URL নির্দিষ্ট ও সুসংগত করুন
ক্যানোনিকালাইজেশন একই ধরনের ডুপ্লিকেট বা খুব সমজাতীয় সংস্করণগুলির মধ্যে পছন্দের URL চিহ্নিত করে, যেমন HTTP বনাম HTTPS, ভিন্ন হোস্ট, ট্র্যাকিং প্যারামিটার, ফিল্টার, বা প্রিন্ট পেজ। canonical উপাদান, অভ্যন্তরীণ লিংক, সাইটম্যাপে থাকা URL, এবং রিডাইরেক্ট ডেস্টিনেশন তুলনা করুন। একটি ইনডেক্সযোগ্য পেজের জন্য, সাধারণত এগুলো একই সম্পূর্ণ পছন্দের URL নির্দেশ করা উচিত।
ডুপ্লিকেট অবসানের সময় সার্ভার-সাইড স্থায়ী রিডাইরেক্ট ব্যবহার করুন। Google স্থায়ী রিডাইরেক্ট এবং rel=canonical-কে শক্তিশালী সিগন্যাল বলে বিবেচনা করে, যখন সাইটম্যাপের অন্তর্ভুক্তি দুর্বল সঙ্কেত; সিগন্যালগুলো একরূপ হলে পছন্দ দৃঢ় হয়। robots.txt ব্যবহার করে canonical নির্দেশ করা বা এক পেজকে প্রতিযোগিতামূলক canonical দেওয়া থেকে বিরত থাকুন। স্ব-রেফারেন্সযুক্ত canonical পছন্দের সংস্করণ নির্দেশ করতে সাহায্য করে, তবে সার্চ-ইঞ্জিনের চয়েস আপনার নিয়ন্ত্রণের বাইরে থেকে যায়।
ভ্যারিয়েন্টগুলো, পছন্দের টার্গেট, প্রয়োজনীয় কন্ট্রোল, এবং একজন মালিক ডকুমেন্ট করুন।
মাইগ্রেশনের আগে পুরনো-থেকে-নতুন ম্যাপিং পরীক্ষা করুন এবং একটি রিভার্সিবল রিডাইরেক্ট পরিবর্তন প্রস্তুত রাখুন।
স্ট্যাটাস কোড এবং রিডাইরেক্ট আচরণ পরীক্ষা করুন
স্ট্যাটাস কোড ব্রাউজার এবং ক্রলারকে কী হয়েছে তা বলে। গুরুত্বপূর্ণ লাইভ পেজগুলি প্রত্যাশিত কনটেন্টসহ অর্থপূর্ণ 2xx রেসপন্স ফিরিয়ে দেয়া উচিত। যদি কোনো পেজের উপযুক্ত প্রতিস্থাপন না থাকে তবে সেটিকে প্রকৃত 404 বা 410 ফেরত দিতে হবে; স্থানান্তরিত কনটেন্ট নিকটতম উপযুক্ত প্রতিস্থাপনে পৌঁছানো উচিত। শুধুমাত্র একটি এরর দেখানো 200 পেজটি সফট 404 হিসেবে বিবেচিত হতে পারে।
প্রতিটি রিডাইরেক্ট হপ রেকর্ড করুন। সাধারণত Google সাধারণ ওয়েব ক্রলিংয়ের জন্য 10 পর্যন্ত হপ অনুসরণ করে, কিন্তু চেইনগুলো ল্যাটেন্সি ও ভঙ্গুরতা বাড়ায়। Google জানায় যে 5xx ও 429 রেসপন্স ক্রলিং সাময়িকভাবে ধীর করতে পারে এবং স্থায়ী সার্ভার ত্রুটি শেষমেশ ইনডেক্স করা URL মুছে ফেলতে পারে। recurring failures থাকলে অ্যাপ্লিকেশন, CDN, অরিজিন, ক্যাশ, ডিপেন্ডেন্সি এবং ডেপ্লয়মেন্ট স্তরের ইঞ্জিনিয়ারিং মালিকের সাথে তদন্ত করুন।
অরিজিনাল URL, হপ, কোড, চূড়ান্ত URL এবং প্রত্যাশিত অবস্থা সংরক্ষণ করুন।
আরেকটি হপ যোগ করার পরিবর্তে CMS, CDN, হোস্ট, লোকেল বা স্ল্যাশ নিয়মগুলোর ওভারল্যাপ রিমুভ করুন।
JavaScript রেন্ডারিং ও রাউটগুলো যাচাই করুন
কী টেমপ্লেটগুলোর জন্য আরম্ভিক HTML এবং রেন্ডার করা ভিউ—উভয়ই—ইনস্পেক্ট করুন। রেন্ডারিংয়ের পর প্রধান কনটেন্ট, শিরোনাম, লিংক, canonical, robots নির্দেশনা, এবং স্টেট বিদ্যমান আছে কি না তা নিশ্চিত করুন। Google আলাদা ক্রল, রেন্ডার, এবং ইনডেক্স ধাপ বর্ণনা করে এবং বলে এমন কনটেন্ট যা রেন্ডার করা HTML-এ দৃশ্যমান নয় তা ইনডেক্স করা যায় না।
নেভিগেশনের জন্য href মান যুক্ত anchor উপাদান ব্যবহার করুন। কেবল ফ্রাগমেন্ট-ভিত্তিক রাউট যেগুলো আলাদা কনটেন্ট লোড করে তা ডিসকভারির জন্য নির্ভরযোগ্য নয়। না-অস্তিত্বমান পণ্য, আরটিকেল, এবং filtered URL সরাসরি রিকোয়েস্ট করুন। ক্লায়েন্ট-সাইড অ্যাপ্লিকেশনের জন্য একটি বাস্তব এরর স্টেট প্রয়োজন; Google একটি সার্ভার 404-এ রাউট করা বা সফট 404 এড়াতে noindex যোগ করার নথিভুক্তি করে। সার্ভার রেন্ডারিং বা প্রেরেন্ডারিং সাহায্য করতে পারে, তবে ডিপ্লয়কৃত রেসপন্স যাচাই করুন।
রেসপন্স HTML, রেন্ডার করা HTML, এবং মানব ব্রাউজার ভিউ-তে উপাদানগত পার্থক্য চেক করুন।
সোর্স HTML-কে অগ্রাধিকার দিন; যদি JavaScript এটি সেট করে, নিশ্চিত করুন একটি সংঘাতহীন একক canonical আছে।
সাইটম্যাপ ও অভ্যন্তরীণ লিংকগুলো পরিষ্কার রাখুন
সাইটম্যাপ একটি ডিসকভারি মানচিত্র; এটি ইনডেক্সিং কমান্ড নয়। সফল, কাঙ্ক্ষিত, পছন্দের canonical URL-গুলো অন্তর্ভুক্ত করুন; রিডাইরেক্ট, এরর, noindex পেজ, প্যারামিটার ডুপ্লিকেট, এবং প্রটেক্টেড URL বাদ দিন। Google পূর্ণযোগ্য ফর্মে absolute URL ব্যবহারের পরামর্শ দেয় এবং সাইটম্যাপ অন্তর্ভুক্তিকে canonical hint হিসেবে দেখে, গ্যারান্টি হিসেবে নয়।
সাইটম্যাপটি যাচাই করুন এবং এটি intended-index তালিকার ও ন্যাভিগেশনের সাথে তুলনা করুন। Google UTF-8 এনকোডিং এবং প্রতি সাইটম্যাপে 50 MB (আনকমপ্রেসড) বা 50,000 URL সীমা নির্দেশ করে। বড় সাইটের জন্য কার্যকরী গ্রুপে বিভক্ত করুন এবং একটি ইনডেক্স ব্যবহার করুন। lastmod শুধুমাত্র গুরুত্বপূর্ণ, যাচাইযোগ্য পেজ পরিবর্তনের জন্য আপডেট করুন।
intended URL, সাইটম্যাপ এন্ট্রি, এবং অভ্যন্তরীণ লিংক্স-এর মধ্যে অর্থপূর্ণ পার্থক্য তদন্ত করুন।
রাউটিং বা CMS পরিবর্তনের পরে জেনারেটেড সাইটম্যাপ এবং তালিকাভুক্ত URL-গুলোর একটি নমুনা পরীক্ষা করুন।
পারফরম্যান্স মাপুন এবং অডিট প্রতিষ্ঠিত করুন
যেখানে সম্ভব ফিল্ড ডেটা ব্যবহার করুন এবং ল্যাব টেস্টিং ব্যবহার করে Core Web Vitals (মূল ওয়েব ভিটালস) পরীক্ষা করুন: লোডিং-এর জন্য Largest Contentful Paint (LCP), রেসপন্সিভনেস-এর জন্য Interaction to Next Paint (INP) বা অন্যান্য প্রাসঙ্গিক মেট্রিক, এবং দৃশ্যগত স্থিতিশীলতার জন্য Cumulative Layout Shift (CLS)। পেজ টাইপ ও ডিভাইস দ্বারা সেগমেন্ট করুন কারণ গড়গুলো উচ্চ-মূল্যের ভাঙা টেমপ্লেটগুলো লুকাতে পারে।
চিত্র, CSS ও JavaScript, তৃতীয়-পক্ষ ট্যাগ, ফন্ট, এম্বেড, ও ক্যাশিং-এর মাধ্যমে ধীর বা অস্থিতিশীল ডেলিভারির ট্রেস করুন। একটি মাত্র পরিমাপ করা পরিবর্তন করুন, তারপর রেন্ডারিং ও ব্যবহারকারীর ফ্লো পুনরায় পরীক্ষা করুন। ফিল্ড ডেটা বাস্তব ব্যবহারকারীদের প্রতিফলন করে; ল্যাব ডেটা পুনরুত্পাদনে সহায়ক। কোনোটাই ভবিষ্যৎ ক্রলার বা ভিজিটরের প্রতিটি আচরণ ভবিষ্যদ্বাণী করে না। ঝুঁকিপূর্ণ রিলিজের পরে মনোযোগী রিগ্রেশন চেক পুনরাবৃত্তি করুন এবং মাইগ্রেশন বা প্ল্যাটফর্ম পরিবর্তনের পরে পূর্ণাঙ্গ অডিট চালান।
রাজস্ব-গুরুত্বপূর্ণ বা বহুল ব্যবহৃত টেমপ্লেটগুলোর ত্রুটি আগে মেরামত করুন, ছোট স্কোর উন্নতির আগে।
বন্ধ করার আগে রেসপন্স, canonical, রেন্ডার করা কনটেন্ট, সাইটম্যাপ অবস্থা, এবং প্রাসঙ্গিক পারফরম্যান্স প্রমাণ পুনরায় যাচাই করুন।