If you've been working with Next.js lately, you've probably seen the use client directive pop up in components. It's just one line at the top of a file, but it raises an important question: does it affect SEO? Short answer: No. Client components don't hurt SEO. Let me explain why. What use client actually does In Next.js 13 and above, components are server components by default. When you add use client to a component, you're telling Next.js this component needs client-side features like: State (useState, useEffect) Event handlers Browser-only APIs (like window or localStorage) Animations or heavy interactivity Here's the key thing: Client components are still pre-rendered on the server and included in the initial HTML. Search engines see them immediately, exactly the same as server components. The difference is that client components are also bundled and sent to the browser for hydration—making them interactive. Why people think use client hurts SEO (and why they're wrong) There's a common misconception that client components aren't server-rendered. This isn't true. Both server components and client components appear in the initial HTML that gets sent to the browser. From a crawler's perspective, there's no difference. Google sees the content immediately either way. So putting an <h1>, product description, or blog content in a client component is totally fine for SEO. The content is there in the HTML from the start. What actually matters for SEO While use client itself doesn't hurt SEO, there are two things that DO matter: 1. Don't hide content behind interactivity This is the real SEO risk. If content only appears after a user clicks a button, opens a tab, or submits a form, crawlers won't see it. Crawlers load the page and run JavaScript, but they don't interact with it. They don't click buttons or switch tabs. Bad for SEO: Product details hidden behind a "Read More" button Pricing shown only after selecting a tab Content that requires form submission to view Fine for SEO: Interactive components that render content immediately Client components with state that shows content on load Animations that don't hide initial content 2. Be mindful of performance Client components increase your JavaScript bundle size. If you're overusing use client across your entire app, you can end up with a bloated bundle that slows down your site. Performance affects SEO indirectly through Core Web Vitals and page speed rankings. But this is a holistic concern about your app's architecture, not a per-component decision. You shouldn't avoid putting an <h1> in a client component just because it's an <h1>. If that component needs interactivity, use use client. The performance cost comes from the component being in the bundle, not from what content it contains. The actual decision tree When deciding between server and client components, ask yourself: Does this component need client-side features? State management? Event handlers? Browser APIs? Interactivity after page load? Yes? → Use use client No? → Keep it as a server component That's it. It's about functionality, not SEO. How to use use client correctly DO use use client for: Forms with validation Interactive widgets Modals and dialogs Tabs (as long as content is visible on initial render) Animations Any component that needs state or browser APIs DON'T worry about: Whether the component contains an <h1> or important text Search engine indexing—crawlers see client components just fine Per-component performance decisions based on content type DO worry about: Hiding content behind clicks, tabs, or interactions Overall bundle size if you're using use client everywhere Whether you actually need client features or just defaulted to use client out of habit The bottom line use client doesn't hurt SEO. Both client and server components appear in the initial HTML that crawlers see. The choice between them should be based on whether you need client-side features, not whether the content is important for SEO. The real SEO concerns are: Hiding content behind interactivity that requires user action Overall app performance from excessive JavaScript bundles Get those right, and you can use client components wherever you need them without worrying about SEO.

Introduction Imagine this: you’re building a dynamic Next.js app where data must refresh every two minutes. Easy, right? Just use setInterval in useEffect and call it a day! Well, that’s what I thought until I ran into an unexpected challenge. As I opened multiple browser tabs, I noticed each tab was fetching data independently, at different intervals. They weren’t in sync, and that wasn’t ideal for user experience. This blog post is about the solution I arrived at: a frontend “cron job” approach to synchronize data-fetching intervals across multiple tabs. I’ll walk you through my process, the issues I faced, and the satisfying solution I found. Starting Out: The Initial Timer-Based Fetch At first, I set up my Next.js component to fetch data at a fixed interval. Here’s what it looked like initially: The Problem: Out-of-Sync Tabs Everything seemed great, until I opened a second tab. With each tab running its own instance of setInterval, data fetching became unsynchronized. Tabs would refresh at different times, creating a disjointed user experience. To illustrate, here’s how things looked: Opened the first tab at 12:01, so it fetches every odd minute (12:03, 12:05, etc.). Opened the second tab at 12:02, which then fetches every even minute (12:04, 12:06, etc.). The issue became clear: I needed every tab to fetch at the same time, preferably at exact two-minute marks (like 12:00, 12:02, 12:04), regardless of when a user opened the tab. Solution: Syncing Fetches at Even-Minute Marks To achieve sync across multiple tabs, I decided to align all data fetches with even two-minute intervals (e.g., 12:00, 12:02, 12:04). This approach ensures all tabs are fetching data at the same time. Here’s how I tackled it: Calculate Time to the Next Even Minute: First, determine how long it is until the next two-minute mark. This will be the initial delay. Set a Timeout for the First Fetch: Once we know the time until the next even minute, use setTimeout to start the first fetch exactly at that point. Set a Consistent 2-Minute Interval Thereafter: After the initial fetch, set up a regular setInterval to continue fetching every two minutes. This is how the final code turned out: Breaking Down the Code Calculate Initial Delay: By checking the current time in minutes and seconds, I computed the milliseconds remaining until the next two-minute interval. Start Fetching with a Timeout: The setTimeout uses the calculated delay to ensure that the first data fetch happens exactly at the next even minute. Set Interval After the First Fetch: Once the initial timeout triggers, setInterval starts the two-minute cycle, aligning all data fetches to happen in sync, every even minute across every open tab. Result: Perfectly Synchronized Fetching With this approach, I achieved a unified experience across all tabs. Now, no matter when a user opens the page, the data refreshes in sync at every two-minute mark. Here’s how it behaves now: Open a tab at 12:01:29, it waits until 12:02:00, then fetches every two minutes thereafter. Open another tab at 12:01:58, it waits only two seconds, then fetches at 12:02:00, staying in sync with other tabs. Final Thoughts This solution might feel like a small change, but it significantly improved the consistency of data display across tabs and browsers. This approach, aligning fetches to specific intervals, is sometimes called a “frontend cron job” because it emulates the regular scheduling of a backend cron job right in the browser. When to Use This Approach This sync method is useful when: You’re working with time-sensitive data that should be consistent across tabs. A traditional setInterval wouldn’t align with other instances in different tabs.

Introduction Building a data-driven application in Next.js is generally smooth, but things got tricky when I faced an SSL certificate error. The journey turned into a deep dive into client-server interactions, SSL certificates, and a workaround involving custom API routes. If you’re working with data fetching in Next.js and need to dodge SSL verification errors, this post is for you. Starting Out: A Simple Server Component The project began with a server component meant to fetch data directly from an external API and display it on the page. The logic was simple: call the API and render the data immediately on the server side. Here’s the initial setup: It seemed straightforward, but as soon as I deployed the component and ran it in production, I hit a wall. I was greeted by a net::ERR_CERT_AUTHORITY_INVALID error, indicating that the SSL certificate wasn’t fully trusted. This halted the entire process and left the page unable to fetch or display any data. SSL Errors Explained: Why This Happens SSL errors like ERR_CERT_AUTHORITY_INVALID usually mean that the server’s SSL certificate can’t be verified as trustworthy. In my case, the API’s SSL certificate didn’t meet the standard trusted certificate authorities in the browser. This is a common issue when working with certain staging APIs or self-signed certificates. The Workaround: Creating an API Route in Next.js To avoid this SSL error, I decided to set up an API route in Next.js. This approach allowed me to make the initial API call from the Next.js server, bypassing the SSL error by ignoring the certificate verification only server-side. Here’s how I set it up: 1. Create a new API route: This API route serves as a proxy between my Next.js app and the external API, handling the data fetching server-side. In this setup: The httpsAgent instance is configured with rejectUnauthorized: false, which skips SSL verification, avoiding the error. The Next.js API route /api/fetchGlobalData acts as a go-between, making the request to the external API and returning the data to my frontend. 2. Fetch Data in the Client Component: With the API route ready, I updated my client component to fetch data from this new endpoint. The Benefits of This Approach SSL Error Bypassed: By fetching data on the server side, the browser is shielded from any SSL certificate issues. Secure Data Handling: Sensitive data remains secure, as it’s handled entirely on the server. Consistent Refetching: With setInterval, I could refetch every 2 minutes, ensuring the data stays up-to-date without worrying about SSL issues impacting the client. Wrapping Up Converting my server component to an API route was a game-changer for this project. By letting the server handle SSL verification, I kept the client-side data flow smooth and reliable. The final implementation of this clever workaround allowed me to bypass SSL errors entirely while providing an effective and synchronized data-fetching setup. So, if you’re working in Next.js and encounter SSL issues, consider this approach, it’s a straightforward solution to a frustrating problem.

Conquering the SEO game with Next.js Ever feel like your website is buried under a pile of search results? If you're nodding in agreement, it might be time to SEO-ify your site. SEO, or search engine optimization, is the art and science of getting your website seen by the right people at the right time. And guess what? Next.js can be your secret weapon in this battle for search engine glory. Pre-rendering to the rescue! Unlike traditional React apps that wait for the browser to render content, Next.js can pre-render pages on the server. This means search engines see fully formed HTML, making it a breeze for them to understand your website's content. Speed is king with SEO. Next.js helps you create lightning-fast websites. Features like code-splitting and image optimization keep your pages lean and mean, which keeps visitors happy and search engines impressed. Don't forget user experience (UX)! Websites that offer smooth, interactive experiences tend to rank higher. Next.js makes it easy to build user-friendly interfaces that keep visitors engaged. After all, happy visitors are more likely to stick around and explore your content, sending positive signals to search engines. Meta magic! Next.js makes it easy to manage meta tags and descriptions, those little snippets of text that appear in search results. With clear and concise meta tags, you can give search engines (and users) a clear understanding of what each page on your website is about. The SEO benefits of Next.js go beyond these points. It offers features like automatic sitemap generation and built-in support for structured data, both of which can further improve your website's ranking potential. In conclusion, Next.js provides a comprehensive toolkit for building websites that search engines love. From pre-rendering and speed optimization to user-friendly features and meta management, Next.js has everything you need to create an SEO-friendly website that thrives in the ever-competitive world of search.