तीन साल पहले मैंने एक क्लाइंट के ब्लॉग को लिया -- 400 पोस्ट्स, 60k मासिक ऑर्गेनिक विज़िट्स, आठ साल की संचित PageRank -- और इसे एक शानदार Next.js फ्रंट-एंड में माइग्रेट किया। छह हफ्ते के भीतर हमने उस ट्रैफिक का 34% खो दिया। इसलिए नहीं कि नई साइट धीमी थी। इसलिए नहीं कि कंटेंट गायब हो गया। क्योंकि मैं चार विशिष्ट चीजों के साथ लापरवाह था जिन्हें मैं इस पोस्ट में आपके साथ लेकर चलूँगा ताकि आप मेरी गलती दोहराएँ न।
Headless WordPress with Next.js सचमुच performance और developer experience के लिए शानदार है। लेकिन Google को आपके Lighthouse score से कोई मतलब नहीं है अगर आपके canonical tags गलत हैं, आपका XML sitemap पुराने domain की ओर इशारा कर रहा है, और आपका structured data WPGraphQL और getStaticProps के बीच कहीं गायब हो गया है। Migration का खतरनाक हिस्सा खुद migration ही है। इसे सही तरीके से करना ज्यादातर discipline के बारे में है, magic नहीं।getStaticProps. The migration itself is the dangerous part. Getting it right is mostly about discipline, not magic.
---
यह माइग्रेशन पहली जगह में SEO को क्यों तोड़ता है
यहाँ वह बात है जिसे ज्यादातर tutorials नज़रअंदाज़ कर देते हैं: WordPress आपके लिए बिना आपको पता चले ही एक बहुत बड़ी SEO heavy lifting करता है। Yoast या Rank Math आपके meta tags generate कर रहा है। WordPress core आपकी permalink structure को handle कर रहा है। आपका theme शायद किसी न किसी तरह का schema markup output कर रहा है। आपका XML sitemap हर बार जब आप publish करते हैं तो ख़ुद-ब-ख़ुद regenerate होता है।some kind of schema markup. Your XML sitemap auto-regenerates every time you publish.
जब आप content layer को WPGraphQL API के ज़रिये Next.js में pull करते हैं और इसे एक नए front-end से serve करते हैं, तो वह सारी infrastructure आपकी समस्या बन जाती है replicate करने के लिए। हर। एक। चीज़।WPGraphQL API and serve it from a new front-end, all of that infrastructure becomes your problem to replicate. Every. Single. Piece.
दूसरी समस्या URL structure है। ज्यादातर WordPress साइटों में /category/post-slug/ या /year/month/post-slug/ या सिर्फ /post-slug/ होता है। Next.js आपको routing के लिए एक खाली कैनवस देता है। अगर आप इसे सावधानी से plan नहीं करते, तो वह खाली कैनवस ranking का कब्रिस्तान बन जाता है।/category/post-slug/or/year/month/post-slug/or just/post-slug/. Next.js gives you a blank canvas for routing. That blank canvas is a ranking graveyard if you don't plan it carefully.
दो Failure Modes जो मुझे लगातार दिखते हैं
पहली बात यह है कि कुछ टीमें URLs को भी माइग्रेट करती हैं और फिर भी चीजें खराब कर देती हैं -- आमतौर पर क्योंकि रीडायरेक्ट्स असंगत तरीके से लागू होते हैं या नया sitemap रीडायरेक्ट्स के पहले लाइव हो जाता है। दूसरी बात यह है कि कुछ टीमें जानबूझकर URL संरचना को बदलती हैं (अक्सर इसे साफ करने के लिए) और रीडायरेक्ट मैपिंग को बाद की बात मानती हैं। दोनों ही ठीक किए जा सकते हैं। दोनों ही स्वीकार्य नहीं हैं।
---
कुछ भी छुए से पहले Audit करें
Next.js का एक भी लाइन कोड मत लिखिए जब तक आपके पास एक संपूर्ण URL इन्वेंटरी न हो। मैं Screaming Frog का उपयोग करता हूँ -- लाइव WordPress साइट को crawl करें, हर indexable URL को export करें, और इसे एक स्प्रेडशीट में डालें। 400-पेज साइट के लिए वह शायद एक घंटे का काम है। 4,000-पेज साइट के लिए भी वह सिर्फ एक घंटा है, क्योंकि टूल यह स्वचालित रूप से करता है।Screaming Frog -- crawl the live WordPress site, export every indexable URL, and dump it into a spreadsheet. For a 400-page site that's maybe an hour of work. For a 4,000-page site it's still just an hour, because the tool does it automatically.
आप जो capture कर रहे हैं:
- हर canonical URL जो currently indexed है
- हर एक का HTTP status (पहचानें 404s और 301s जो पहले से exist करते हैं)
- हर पेज के लिए मेटा टाइटल और विवरण
- कौन से पेजों के पास स्ट्रक्चर्ड डेटा है (Rich Results Test का उपयोग करें या बस सोर्स इंस्पेक्ट करें)
- इनबाउंड इंटरनल लिंक्स -- ताकि आप जानें कि कौन से पेजेस किस पेज को लिंक करते हैं
Google Search Console से अपने शीर्ष 50 पेज भी खींचें, क्लिक्स के आधार पर सॉर्ट किए गए। ये वो हैं जिन्हें आप गलत नहीं कर सकते। स्प्रेडशीट में उन्हें फ्लैग करें। उन्हें प्रोडक्शन डिपेंडेंसीज़ की तरह ट्रीट करें।
Seahawk के पास 2022 के अंत में एक ई-कॉमर्स क्लाइंट था -- 1,200-प्रोडक्ट WooCommerce स्टोर जो हेडलेस सेटअप में जा रहा था। कोड लिखने से पहले हमने दो पूरे दिन ऑडिट पर बिताए। क्लाइंट को लगा हम समय बर्बाद कर रहे हैं। हमने उनके 90k मासिक ऑर्गेनिक सेशन्स बचाए।
---
WordPress को True Headless CMS के रूप में सेट अप करना
यह हिस्सा ज्यादातर सीधा है। WPGraphQL इंस्टॉल करें और GraphQL API के माध्यम से अपनी कंटेंट को एक्सपोज़ करें। लेकिन कुछ चीजें हैं जिनके बारे में जानबूझकर सोचना लायक है।
WordPress साइड पर Yoast (या Rank Math) को चलता रखें
भले ही आप अब WordPress को पब्लिक फ्रंट-एंड के रूप में serve नहीं कर रहे हैं, अपना SEO प्लगइन सक्रिय रखें। WPGraphQL for Yoast SEO (या समकक्ष Rank Math एक्सटेंशन) सभी SEO मेटा को expose करता है -- टाइटल्स, डिस्क्रिप्शन्स, canonical URLs, OG डेटा, robots directives -- सीधे GraphQL API के माध्यम से। इसका मतलब है कि आप इसे Next.js से query कर सकते हैं और इसे ठीक वैसे ही रेंडर कर सकते हैं जैसे Yoast ने इरादा किया था।WPGraphQL for Yoast SEO(or the equivalent Rank Math extension) exposes all the SEO meta -- titles, descriptions, canonical URLs, OG data, robots directives -- directly through the GraphQL API. That means you can query it from Next.js and render it exactly as Yoast intended.
यह उस 2019 ट्रैफिक ड्रॉप का सबक था जिसका मैंने जिक्र किया था। मैंने मान लिया था कि हम Next.js में post title + site name से titles फिर से generate कर सकते हैं। हम कर सकते थे। लेकिन Yoast ने लगभग 80 top-performing posts के लिए meta titles को manually customize किया था, और हमने सब कुछ खत्म कर दिया। रिकवर होने में आठ हफ्ते लगे।
WordPress Front-End को सावधानी से Disable करें
एक बार जब आप Next.js की ओर traffic point करने के लिए तैयार हों, तो आप WordPress को अपना ख़ुद का front-end simultaneously serve नहीं करना चाहते। बड़े पैमाने पर duplicate content। सबसे साफ़ तरीका है अपने WordPress install पर robots.txt set करना Disallow: / के साथ जब आपकी Next.js site live हो जाती है, और फिर eventually WordPress URL को पूरी तरह firewall कर दो ताकि यह सिर्फ internally या VPN के ज़रिये accessible हो।robots.txt on your WordPress install to Disallow: /while your Next.js site goes live, then eventually firewall the WordPress URL entirely so it's only accessible internally or via VPN.
robots.txt स्टेप को स्किप न करें। मैंने teams को WordPress को CDN level पर block करते हुए देखा है और फिर उन्हें पता चला कि Googlebot के पास एक cached route था। Cleanup होने में महीनों लगते हैं।
---
URL Structure को बिल्कुल Replicate करना
मेरी strong default recommendation: अपने URLs को identical रखें। Same slug, same permalink structure, same trailing slash behaviour। जितना अधिक Next.js routes WordPress routes को mirror करते हैं, उतने कम redirects की जरूरत है, और कम risk आप carry करते हैं।keep your URLs identical. Same slug, same permalink structure, same trailing slash behaviour. The closer the Next.js routes mirror the WordPress routes, the fewer redirects you need, and the less risk you carry.
Next.js dynamic routes यह आसान बनाता है। अगर आपकी WordPress posts /blog/[slug] पर रहती हैं, तो pages/blog/[slug].js बनाओ। हो गया।dynamic routes make this easy. If your WordPress posts live at/blog/[slug], create pages/blog/[slug].js. Done.
यह जहां messy हो जाता है वह है category archives, author pages, tag pages, और paginated archives (/blog/page/2/)। WordPress ये सब automatically generate करता है। Next.js में आप इन्हें खुद build कर रहे हैं। बहुत सारी teams इन्हें deprioritise करती हैं और फिर सोचती हैं कि crawl coverage क्यों drop हुई।/blog/page/2/). WordPress generates all of these automatically. In Next.js you're building them yourself. A lot of teams deprioritise these and then wonder why crawl coverage dropped.
यहाँ URL parity के लिए मेरी numbered checklist है:
- सिंगल पोस्ट्स/पेजेस -- स्लग को ठीक से मैच करें, किसी भी सबफोल्डर सहित -- match the slug exactly, including any subfolder
- कैटेगरी आर्काइव्स -- /category/[slug]/ को फिर से बनाएँ, getStaticPaths के साथ WPGraphQL से सभी कैटेगरीस को pull करते हुए -- recreate
/category/[slug]/withgetStaticPathspulling all categories from WPGraphQL - टैग आर्काइव्स -- ऊपर की तरह ही, अगर इन्हें ऑर्गेनिक ट्रैफिक मिल रहा हो तो इन्हें स्किप न करें -- same as above, don't skip these if they get organic traffic
- लेखक आर्काइव्स -- पहले Search Console में देख लें; अगर उन्हें ज़ीरो क्लिक मिल रहे हों तो आप उन्हें होमपेज पर 301 कर सकते हैं -- check Search Console first; if they get zero clicks, you can 301 them to the homepage
- पैजिनेटेड आर्काइव्स -- /blog/page/[num]/ को सुरक्षित रखने लायक है अगर आपके पास बहुत सारी पोस्ट हों --
/blog/page/[num]/is worth preserving if you have a lot of posts - अटैचमेंट पेज -- लगभग हमेशा इन्हें पेरेंट पोस्ट पर 301 करें; ये WordPress में भी SEO के लिहाज़ से बेकार हैं -- almost always 301 these to the parent post; they're SEO dead weight in WordPress too
- फ़ीड URL -- /feed/ को आपने नए RSS फ़ीड पर 301 करना चाहिए अगर आपके पास एक हो, या फिर 410 रिटर्न करें अगर न हो --
/feed/should 301 to your new RSS feed if you have one, or return 410 if not
---
रीडायरेक्ट: वह हिस्सा जिसे हर कोई कम आंकता है
अगर आप कोई भी URL बदल रहे हैं -- जिसके ख़िलाफ़ मैं दलील दूंगा, लेकिन कभी-कभी ज़रूरी होता है -- आपके रीडायरेक्ट मैप को लॉन्च से पहले बनाया जाना चाहिए और स्टेजिंग एनवायरनमेंट में टेस्ट किया जाना चाहिए।are changing any URLs -- which I'd push back on, but sometimes it's necessary -- your redirect map needs to be built before launch and tested in a staging environment.
Next.js में, रीडायरेक्ट्स next.config.js में रहते हैं। छोटी साइट्स के लिए (200 से कम रीडायरेक्ट्स) वो ठीक है। बड़ी साइट्स के लिए, इन्हें JSON फ़ाइल में रखें और इम्पोर्ट करें, या उन्हें डायनामिक्ली हैंडल करने के लिए मिडलवेयर का इस्तेमाल करें। Vercel का एज मिडलवेयर इसके लिए शानदार है क्योंकि ये पेज रेंडर होने से पहले चलता है -- कोई लेटेंसी पेनल्टी नहीं।next.config.js. For small sites (under 200 redirects) that's fine. For anything larger, put them in a JSON file and import it, or use middleware to handle them dynamically.Vercel's edge middleware is excellent for large redirect tables because it runs before the page is rendered -- zero latency penalty.
next.config.js में format यह है:next.config.js:
``redirects: [ { source: '/old-slug', destination: '/new-slug', permanent: true } ]``redirects: [ { source: '/old-slug', destination: '/new-slug', permanent: true } ]``
permanent: true एक 301 भेजता है। सभी असली URL बदलावों के लिए इसका इस्तेमाल करें। 302 (अस्थायी) का इस्तेमाल न करें जब तक कि आप वाकई इसे वापस लाने का इरादा न रखते हों -- Google इन्हें बहुत अलग तरीके से ट्रीट करता है। sends a 301. Use it for all genuine URL changes. Don't use 302 (temporary) unless you actually intend to revert it -- Google treats them very differently.
launch से पहले हर redirect को test करें। मैं एक सरल bash script का उपयोग करता हूँ जो spreadsheet के through loop करता है और हर पुरानी URL को curl करके 301 response की जांच करता है सही destination के लिए। लिखने में दस मिनट लगते हैं, launch के बाद की घबराहट में घंटों बचाता है।
---
Next.js में Meta Tags, Canonical URLs, और Structured Data
यह वह जगह है जहाँ अधिकांश migrations चुपचाप points खो देते हैं। content वहाँ है, URLs काम करते हैं, लेकिन SEO signals गलत हैं।
Meta Tags
next-seo का इस्तेमाल करें। ये स्टैंडर्ड है। इसे वो डेटा पास करें जो आपने WPGraphQL Yoast से क्वेरी किया हो। आपकी app.js को DefaultSeo कॉन्फ़िग मिलता है, और हर पेज को NextSeo कंपोनेंट मिलता है जिसमें पेज-स्पेसिफ़िक ओवररাइड्स होते हैं। टाइटल, डिस्क्रिप्शन, OG टाइटल, OG इमेज, canonical URL, और robots डायरेक्टिव्स को Yoast GraphQL रिस्पांस से सीधे लें -- इन्हें दोबारा से बनाने की कोशिश न करें।next-seo. It's the standard. Pass it the data you've queried from WPGraphQL Yoast. Your_app.js gets a DefaultSeo config, and each page gets a NextSeo component with the page-specific overrides. Take the title, description, OG title, OG image, canonical URL, and robots directives directly from the Yoast GraphQL response -- don't reinvent them.
एक चीज़ जो लोगों को परेशान करती है: canonical URLs। WordPress में, Yoast automatically canonical सेट करता है। Next.js में आपको canonical को explicitly पास करना होता है। अगर आप भूल जाते हैं, तो Next.js बिना canonical tag के pages render करेगा, और अगर आपके पास कहीं भी query strings हैं (pagination, filters), तो आप expected से ज़्यादा तेज़ी से duplicate content issues का सामना करेंगे।
Structured Data
WordPress थीम और प्लगइन अक्सर JSON-LD को स्वचालित रूप से आउटपुट करते हैं। यह headless में गायब हो जाता है। आपको इसे फिर से बनाना होगा। लेख के लिए, Article स्कीमा का उपयोग करें। प्रोडक्ट के लिए, Product। स्थानीय व्यवसायों के लिए, LocalBusiness। मैं इन्हें React कॉम्पोनेंट्स के रूप में लिखता हूँ जो props स्वीकार करते हैं और <script type="application/ld+json"> टैग रिटर्न करते हैं। प्रत्येक स्कीमा प्रकार के लिए एक कॉम्पोनेंट, पूरे ऐप में दोबारा इस्तेमाल किया जाता है।Article schema. For products,Product. For local businesses,LocalBusiness. I write these as React components that accept props and return a<script type="application/ld+json">tag. One component per schema type, reused across the app.
माइग्रेशन से पहले Rich Results Test में आपके पास पहले से मौजूद हर स्कीमा प्रकार को चेक करें। उन्हें डॉक्यूमेंट करें। उन्हें फिर से बनाएँ। लॉन्च के बाद नए स्कीमा को उसी टूल से टेस्ट करें।before migration. Document them. Recreate them. Test the new ones with the same tool post-launch.
The XML Sitemap
स्टैटिक साइटमैप का इस्तेमाल न करें। इसे डायनामिक्ली जेनरेट करें। छोटी साइट्स के लिए, /sitemap.xml रूट पर getServerSideProps काम करता है। बड़ी साइट्स के लिए जिनके पास हज़ारों पोस्ट हों, साइटमैप को बिल्ड टाइम पर एक कस्टम स्क्रिप्ट के ज़रिए जेनरेट करें और इसे public/ फ़ोल्डर में आउटपुट करें। Vercel हर डिप्लॉयमेंट पर ये करता है -- आपका साइटमैप हमेशा अपडेट रहता है।getServerSideProps on a/sitemap.xml route works. For large sites with thousands of posts, generate the sitemap at build time via a custom script and output it to the public/folder. Vercel runs this at every deployment -- your sitemap is always current.
नए sitemap URL को Google Search Console में submit करें — नई site के live होने के पहले दिन। तीसरे दिन नहीं। पहले दिन।
---
Post-Launch Monitoring (The 90-Day Window)
माइग्रेशन लॉन्च होने पर खत्म नहीं होती। यह तब खत्म होती है जब आपकी रैंकिंग स्थिर हो जाती है -- जिसके लिए गूगल के डॉक्यूमेंटेशन के अनुसार कुछ हफ्तों से लेकर कई महीने तक का समय लग सकता है, यह क्रॉल बजट और साइट अथॉरिटी पर निर्भर करता है।
मैं हर कार्य दिवस पहले महीने में जो देखता हूँ:
- Google Search Console → Coverage रिपोर्ट नए 404s या 'Excluded' URLs के लिए जो बाहर न किए जाने चाहिए for new 404s or 'Excluded' URLs that shouldn't be excluded
- Search Console → Performance -- अपने टॉप 50 पेजों के लिए हफ्तों के आधार पर क्लिक और इंप्रेशन की तुलना करें -- compare clicks and impressions week-on-week for your top 50 pages
- नई साइट के लिए Screaming Frog को फिर से क्रॉल करें ताकि किसी आंतरिक 404 या गलत तरीके से कॉन्फ़िगर की गई canonical टैग को पकड़ा जा सके of the new site to catch any internal 404s or misconfigured canonical tags
- Core Web Vitals -- हां, Next.js साइट तेजी से लोड होनी चाहिए, लेकिन इसे फील्ड डेटा (CrUX) में वेरिफाई करें, सिर्फ Lighthouse में नहीं -- yes, the Next.js site should be faster, but verify it in the field data (CrUX), not just Lighthouse
अगर आप पहले दो या तीन हफ्तों में एक महत्वपूर्ण drop देखते हैं, तो तुरंत घबराएँ नहीं। Google के re-crawl और re-index करते समय लगभग हमेशा एक अल्पकालिक उतार-चढ़ाव होता है। आप जो ढूंढ रहे हैं वह सप्ताह चार के बाद sustained drops हैं। यही संकेत है कि कुछ संरचनात्मक रूप से गलत है।
2022 के अंत में वापस जाएं -- ई-कॉमर्स वाली प्रोजेक्ट से अलग -- हमने एक SaaS ब्लॉग के लिए Next.js माइग्रेशन लॉन्च किया और दूसरे हफ्ते में 20% इंप्रेशन में गिरावट देखी। पता चला कि हमारा डायनामिकली जेनरेटेड sitemap noindex पेजों को शामिल कर रहा था क्योंकि हमने WPGraphQL क्वेरी को सही तरीके से फिल्टर नहीं किया था। इसे चार घंटों में ठीक किया। तीन हफ्तों में रैंकिंग वापस आ गईं। मॉनिटरिंग ने इसे पकड़ा, इससे पहले कि यह बिगड़ता।noindex pages because we hadn't filtered the WPGraphQL query properly. Fixed it in four hours. Rankings recovered in three weeks. The monitoring caught it before it compounded.
---
FAQ
WordPress से Next.js migration में कितना समय लगता है?
ईमानदारी से कहूँ तो यह पोस्ट की संख्या से ज्यादा साइट की जटिलता पर निर्भर करता है। एक 100-पेज ब्रोशर साइट जिसके पास क्लीन URLs हों, उसे सही तरीके से दो से तीन हफ़्तों में बना सकते हैं। एक 2,000-पोस्ट वाला ब्लॉग जिसमें कस्टम पोस्ट टाइप्स, ACF फील्ड्स और WooCommerce इंटीग्रेशन हो, अगर आप SEO का काम सही तरीके से डेवलपमेंट के साथ कर रहे हैं तो कम से कम छह से आठ हफ़्तों का प्रोजेक्ट है। किसी को भी यह न कहने दें कि यह वीकेंड का काम है।
क्या मुझे Next.js में Pages Router या App Router का इस्तेमाल करना चाहिए?
मध्य 2024 तक मैं नई प्रोजेक्ट्स के लिए App Router को डिफॉल्ट के रूप में चुन रहा हूं। लेकिन अगर आपकी टीम Pages Router के साथ अधिक आरामदायक है और यह एक समय-संवेदनशील माइग्रेशन है, तो वह इस्तेमाल करें जो आप जानते हैं। SEO निहितार्थ न्यूनतम हैं -- दोनों स्टैटिक जेनरेशन, सर्वर-साइड रेंडरिंग, और डायनामिक रूट्स को सपोर्ट करते हैं। next-seo पैकेज के पास अब App Router सपोर्ट भी है।next-seo package has App Router support now too.
क्या मुझे WordPress होस्टिंग से पूरी तरह दूर हटना चाहिए?
नहीं। WordPress अपने वर्तमान होस्ट पर रह सकता है -- WP Engine, Kinsta, Cloudways, जो भी आप इस्तेमाल कर रहे हैं -- और पूरी तरह से कंटेंट API के रूप में काम कर सकता है। Next.js फ्रंट-एंड Vercel या Netlify पर डिप्लॉय होता है। दोनों HTTP के माध्यम से संचार करते हैं। कुछ क्लाइंट्स को यह पसंद है क्योंकि एडिटोरियल टीम को WordPress एडमिन मिलता रहता है जिसे वे पहले से जानते हैं।Netlify. The two communicate via HTTP. Some clients actually prefer this because the editorial team keeps the WordPress admin they already know.
WordPress प्लगइन्स के बारे में क्या जो SEO को प्रभावित करते हैं -- जैसे Redirection में मैनेज किए गए रीडायरेक्ट्स?
माइग्रेट करने से पहले इन्हें एक्सपोर्ट करें। Redirection प्लगइन के पास CSV एक्सपोर्ट है। सभी मौजूदा रीडायरेक्ट्स ले लें और उन्हें अपने next.config.js या edge middleware में जोड़ें। यह मत मानिए कि वे स्वचालित रूप से कैरी ओवर हो जाएंगे -- नहीं होंगे, क्योंकि वे WordPress डेटाबेस में रहते हैं और Next.js को इसका कोई अंदाजा नहीं है।Redirection plugin has a CSV export. Take all those existing redirects and add them to your next.config.js or edge middleware. Don't assume they'll carry over automatically -- they won't, because they live in the WordPress database and Next.js has no idea they exist.
क्या मेरी Google रैंकिंग चाहे कुछ भी हो ड्रॉप हो जाएगी?
लगभग हमेशा कुछ अल्पकालीन अस्थिरता होती है। एक अच्छी तरह से निष्पादित माइग्रेशन जिसमें शून्य URL परिवर्तन, उचित रीडायरेक्ट्स (जहां आवश्यक हो), दोहराए गए मेटा और स्ट्रक्चर्ड डेटा, और एक फिर से सबमिट किया गया sitemap हो, चार से छह हफ्तों में स्थिर हो जाना चाहिए। जो ड्रॉप्स मैंने देखे हैं जो महीनों तक चले, वे सभी विशिष्ट तकनीकी त्रुटियों के कारण थे -- माइग्रेशन के कारण नहीं।
---
माइग्रेशन मुश्किल हिस्सा नहीं है। मुश्किल हिस्सा अनुशासन है हर उबाऊ, बेजान कदम को करने का -- ऑडिट, रीडायरेक्ट मैपिंग, स्कीमा का पुनर्निर्माण -- इससे पहले कि आप कोई चतुर Next.js कोड लिखें। उस क्रम को सही रखें और आप दूसरी ओर से एक तेजी से फ्रंट-एंड के साथ बाहर आएंगे और वही रैंकिंग जिनके साथ आपने शुरुआत की थी। संभवतः बेहतर भी, एक बार Core Web Vitals सुधार कार्यान्वित हो जाएं।Core Web Vitals improvements feed through.