Blog · 2026-08-30

নতুন সাইটের একটা পাতাও ইনডেক্স হচ্ছে না? আগে দেখুন canonical আর sitemap পরস্পরের সঙ্গে লড়ছে কি না

ইনডেক্স শূন্য দেখে তড়িঘড়ি কনটেন্ট বদলাতে যাবেন না: URL Inspection API দিয়ে lastCrawlTime দেখুন, সব ফাঁকা মানে সংকেতগুলো নিজেদের মধ্যে লড়ছে; canonical, og:url, JSON-LD আর sitemap এই চার জায়গা মিলিয়ে দিন, প্রতিটা এন্ট্রি 200 ফেরত দিচ্ছে কি না যাচাই করুন, sitemap আবার জমা দিন, সাধারণত এতেই সমাধান হয়ে যায়।

সাইট কয়েক সপ্তাহ ধরে লাইভ, sitemap জমা দেওয়া, কনটেন্টও পাতলা নয়, অথচ Google Search Console-এ ইনডেক্সের সংখ্যা এখনও 0। সবচেয়ে প্রচলিত প্রতিক্রিয়া হলো ফিরে গিয়ে লেখা বদলানো, শিরোনাম পাল্টানো, নয়তো নিজেকে সান্ত্বনা দেওয়া যে "নতুন ডোমেইনে তো সময় লাগেই"। একটু থামুন: একটা পাতাও ইনডেক্স না হওয়া সাধারণত মানের সমস্যা নয়, এটা হলো সাইট সার্চ ইঞ্জিনকে দুটো পরস্পরবিরোধী কথা বলছে; এই সমস্যা কনটেন্ট বদলে সারে না, ঠিক জায়গায় খুঁজলে তবেই সারে।

আগে lastCrawlTime দেখুন: সব ফাঁকা = Google আসেইনি, এসে অপছন্দ করেনি

Google Search Console-এর URL Inspection API (urlInspection().index().inspect()) দিয়ে গোটা সাইটের URL একবার স্ক্যান করুন, আর মূলত দুটো ফিল্ড দেখুন: coverageState আর lastCrawlTime। এই দুটো ফিল্ড মিলে "ইনডেক্স হয়নি" অবস্থাটাকে সম্পূর্ণ আলাদা দুই রোগে ভাগ করে দেয়:

• lastCrawlTime-এ মান আছে, অবস্থা "Crawled - currently not indexed": Google এসেছে, দেখেছে, আর আপাতত না নেওয়ার সিদ্ধান্ত নিয়েছে। তখনই কনটেন্টের মান আর টেমপ্লেটের পুনরাবৃত্তির প্রশ্ন আসে।
• lastCrawlTime পুরো ফাঁকা, অবস্থা আটকে আছে "Discovered - currently not indexed"-এ, এমনকি "URL is unknown to Google"-এ: Google ক্রলই করেনি। লেখা যত ভালোই হোক, সে পড়েনি। সমস্যাটা টেকনিক্যাল সংকেতে, লেখায় নয়।

আমরা যে "গোটা সাইট শূন্য" কেসটা সামলেছি, স্ক্যান করে দেখা গেল lastCrawlTime সবগুলোই ফাঁকা। এই ফিল্ড ফাঁকা হলেই কনটেন্ট নিয়ে দুশ্চিন্তা বাদ দিয়ে সোজা সংকেতগুলো দেখতে যান।

আসল অপরাধী দেখতে এমন: sitemap বলছে A, canonical বলছে B, আর B আবার 308 হয়ে A-তে ফিরছে

আসল কেস থেকে পরিচয় মুছে দেওয়া, তিন লাইনেই পুরো গল্পটা বোঝা যায়:

sitemap-এর <loc>  →  https://example.com/reviews/foo        (এক্সটেনশন ছাড়া)
পাতার canonical   →  https://example.com/reviews/foo.html   (.html সহ)
বাস্তবে foo.html  →  308 ফেরত দেয়, এক্সটেনশন ছাড়া /reviews/foo-তে ফিরিয়ে দেয়

Google-এর দৃষ্টিকোণ থেকে একবার হেঁটে দেখুন: sitemap ধরে A ক্রল করা হলো, A পাতার canonical বলছে "আসল সংস্করণ হলো B", B আনতে গেলে 308 হয়ে আবার A-তে ফিরে আসে। দুটো সংকেত পরস্পরের দিকে বল ঠেলতে থাকে, আর কোনটা গোনায় ধরা হবে তা Google আন্দাজ করে দেবে না; তার পদ্ধতি হলো পাতাটা পিছিয়ে দেওয়া, নয়তো ইনডেক্স করার চেষ্টাই ছেড়ে দেওয়া।

স্ট্যাটিক হোস্টিং প্ল্যাটফর্মে এই ফাঁদে পড়া বিশেষ সহজ: যেমন Cloudflare Pages নিজে থেকেই /foo.html-কে 308 করে /foo-তে পাঠিয়ে দেয়; ফাইল সিস্টেমে রাখা আছে foo.html, কিন্তু বাইরের আসল URL এক্সটেনশন ছাড়া /foo। জেনারেটর ফাইলের নাম ধরে .html সহ canonical বের করে, আর sitemap বের করে এক্সটেনশন ছাড়া loc; দুই টুকরো কোড আলাদা করে দেখলে দুটোই "ঠিক", ভুলটা অসঙ্গতিতে।

যে চার জায়গা মেলাতে হবে, একটা বাদ পড়লেই লড়াই চলতেই থাকবে

একটা পাতার আসল URL সাইটে একবারের বেশি জায়গায় থাকে, নিচের চার জায়গায় অক্ষরে অক্ষরে মিল থাকতে হবে:

1. <link rel="canonical">
2. <meta property="og:url">
3. JSON-LD-তে WebPage / Article ধরনের নোডের "url"
4. sitemap.xml-এর <loc>

সমাধান চারটা ফাইল খুলে আলাদা আলাদা করে বদলানো নয়, সমাধান হলো জেনারেটরের ভেতরে "আসল URL"-এর একটাই ফাংশন সংজ্ঞায়িত করা আর চার জায়গাতেই সেই একই মান থেকে আউটপুট দেওয়া। চারটা স্ট্রিং হাতে হাতে মিলিয়ে রাখলে দেরিতে হলেও আবার লড়াই বাধবেই।

পাশাপাশি আরেকটা প্রচলিত সমস্যা: sitemap-এর loc-এ বিল্ড ডিরেক্টরির পাথ প্রিফিক্স ঢুকে যাওয়া, ফলে লাইভে সরাসরি 404। আমরা আরও ধূর্ত একটা সংস্করণে পা দিয়েছিলাম: যাচাইয়ের স্ক্রিপ্টে "উপকার করতে চাওয়া" একটা fallback লাইন নিজে থেকেই প্রিফিক্সটা ছেঁটে তারপর মেলাত, ফলে ভুল লেখা loc প্রতি রাউন্ডের চেক পাস করে যেত আর টানা বহু রাউন্ড সবুজ থাকার পরও কেউ ধরতে পারেনি। শিক্ষা: fallback শুধু জানা এবং সঠিক ফর্মের পার্থক্য শুষে নিতে পারে (যেমন প্ল্যাটফর্মের এক্সটেনশন ছাড়া URL), ভুল শুষে নেওয়ার জন্য নয়। প্রতিটা fallback লাইন লেখার আগে একবার নিজেকে জিজ্ঞেস করুন: এটা কি ত্রুটি সামলাচ্ছে, নাকি bug ঢেকে দিচ্ছে?

যাচাইয়ের মানদণ্ড মাত্র একটা: প্রতিটা loc সরাসরি 200 ফেরত দেবে

ঠিক করার পর শুধু "পাতা খুলছে" দেখলেই হবে না। ব্রাউজার আর -L সহ curl দুটোই নিজে থেকে রিডাইরেক্ট অনুসরণ করে, ফলে 308 চোখেই পড়ে না, তাই স্বয়ংক্রিয় অনুসরণ বন্ধ করে মাপতে হবে:

# -L ছাড়া, তবেই আসল স্ট্যাটাস কোড দেখা যায়
curl -s -o /dev/null -w "%{http_code}\n" "https://example.com/reviews/foo"

মানদণ্ড: sitemap-এর প্রতিটা <loc> সরাসরি অনুরোধ করলে 200 ফেরত দিতে হবে। 308 ফেরত এলে সেটা ব্যর্থতা, তার মানে loc-এ আসল ফর্মটা লেখা নেই; আর 404 তো বলাই বাহুল্য। এর সঙ্গে কয়েকটা পাতা বেছে ত্রিমূর্তি মিলিয়ে দেখুন: যে URL-এ অনুরোধ করা হলো, পাতার canonical আর og:url, তিনটাই হুবহু এক হতে হবে।

শেষ ধাপটাই সবচেয়ে বেশি মানুষ বাদ দেয়: Google Search Console-এ ফিরে গিয়ে sitemap আবার জমা দেওয়া। আবার না পাঠালে Google-এর হাতে পুরনো ফাইলটাই থেকে যায়, পরস্পরবিরোধী সংকেত তার শিডিউলেই বসে থাকে, আর আগের সব সংশোধন বৃথা যায়।

মিলিয়ে দেওয়ার পরেও "Discovered"-এ আটকে আছে? এবার ইন্টারনাল লিঙ্ক দেখুন

চার জায়গা মেলানো দিয়ে "সংকেত পরস্পরবিরোধী বলে ক্রল করছে না" সমস্যাটা মেটে। সংকেত পরিষ্কার হওয়ার পরেও পাতা যদি দীর্ঘদিন "Discovered - currently not indexed"-এ আটকে থাকে, তাহলে পরের প্রচলিত অপরাধী হলো ইন্টারনাল লিঙ্ক বড্ড পাতলা: পাতাটা শুধু sitemap-এ ঝুলে আছে, সাইটের ভেতরে প্রায় কোনো পাতাই তাকে উল্লেখ করে না, তাই Google তাকে গুরুত্বহীন ধরে নিয়ে ক্রল করার সারিতে বসায় না।

উচ্চ প্রতিযোগিতার একটা ইন্ডাস্ট্রির কনটেন্ট সাইটে আমরা ইন্টারনাল লিঙ্ক ভারসাম্য করেছিলাম: ভারসাম্যের আগে 49টা পাতায় মাত্র 1টা করে ইনবাউন্ড লিঙ্ক ছিল, গোটা সাইটের 116টা পাতার প্রতিটায় ইনবাউন্ড লিঙ্ক ≥ 4 করার পর ওই সাইটের ইনডেক্স হার দাঁড়ায় 153/173 পাতা (প্রায় 88%)। পদ্ধতিটাও একইভাবে স্বয়ংক্রিয়: "প্রতিটা পাতা কতবার উল্লেখ হয়েছে" সংখ্যাটাকে বিল্ডের সময়কার গেটকিপিং সূচক বানানো হয়, আউটপুটের আগে একবার হিসাব হয়, আর যেসব পাতায় ঘাটতি থাকে সেগুলোর জন্য সম্পর্কিত পাতা থেকে স্বয়ংক্রিয়ভাবে লিঙ্ক যোগ হয়ে যায়, এডিটরের মনে রাখার ওপর ভরসা করতে হয় না।

শেষ কথা: এই চেকগুলো স্ক্রিপ্টে লিখে ডিপ্লয় পাইপলাইনে ঝুলিয়ে দিন

তদন্তের ক্রমটা গুছিয়ে নিই: URL Inspection API-তে lastCrawlTime দেখা → সব ফাঁকা হলে canonical / og:url / JSON-LD url / sitemap loc চার জায়গা মেলানো → প্রতিটা loc 200 ফেরত দিচ্ছে কি না যাচাই (রিডাইরেক্ট অনুসরণ বন্ধ করে) → sitemap আবার জমা দেওয়া → তাও আটকে থাকলে ইন্টারনাল লিঙ্ক দেখা। প্রতিটা ধাপই প্রোগ্রাম করে ফেলার মতো চেক, তাই স্ক্রিপ্টে লিখে ডিপ্লয় প্রবাহে ঝুলিয়ে দেওয়ার মূল্য আছে, প্রতিবার লাইভে যাওয়ার সময় নিজে থেকেই চলবে, লাইভে যাওয়ার পর মনে পড়ার ভরসায় থাকতে হবে না। আপনার নতুন সাইটও যদি ইনডেক্স শূন্যে আটকে থাকে, বা এই ধরনের চেক স্বয়ংক্রিয় করে বারবার খোঁজাখুঁজির সময় বাঁচাতে চান, আমাদের সঙ্গে কথা বলতে পারেন; URL Inspection API-এর আসল রেসপন্সটা টেনে বের করলে সাধারণত খুব দ্রুতই ধরা পড়ে কোন স্তরে লড়াই চলছে।

নতুন সাইট চালু করার এই অংশটা আমরা সার্ভিস বানিয়ে ফেলেছি

canonical আর sitemap-এর লড়াই মরার অনেক উপায়ের একটা মাত্র। নতুন সাইট ইনডেক্স না হওয়ার কারণ সাধারণত একটার বেশি থাকে, একটা একটা করে বাদ দিয়ে এগোতে হয়।

• সাইট আর্কিটেকচার আর টেকনিক্যাল SEO: canonical, sitemap, robots, স্ট্রাকচার্ড ডেটা একসঙ্গে মিলিয়ে দেওয়া
• ইনডেক্স মনিটরিং: পাতা ধরে ধরে ইনডেক্স অবস্থা যাচাই, যেগুলো ঢোকেনি তাদের কারণ বের করে আবার পাঠানো
• কনটেন্ট উৎপাদন: মৌলিক কনটেন্ট থাকলে তবেই ইনডেক্স হওয়ার কারণ থাকে, আর এই ধাপটাই সবচেয়ে বেশি বাদ পড়ে

চার সপ্তাহে ডেলিভারি, প্রতি সপ্তাহেই আউটপুট। স্পেসিফিকেশন আছে iGaming SEO সাইট বিল্ড সার্ভিস পাতায়।