DEV Community: Genglin Zheng

My side project just had its best month ever. I have no idea why. Here's what happened.

Genglin Zheng — Mon, 30 Mar 2026 12:50:00 +0000

Okay so this is a little embarrassing to admit —

I launched bulkpictools.com three months ago and genuinely forgot to check
the analytics for like two weeks straight.

When I finally opened Google Search Console, I had to look twice.

Month 3 traffic was more than Month 1 and Month 2 put together.

I'm not going to pretend I have a clean explanation for this. I did some SEO
work around the end of Month 2 — rewrote a bunch of meta descriptions, cleaned
up the page content so it actually matched what people were searching for,
stopped being lazy about alt text. Basic stuff. The kind of stuff you tell
yourself you'll do later and then actually do later.

Did that cause the jump? Maybe. Probably? Google took its time, which, honestly,
very on-brand for Google.

But while I was waiting for the SEO stuff to kick in (or not), I shipped
something that I've been wanting to build for a while.

A background remover. Except the whole model runs in the browser.

No server. Zero backend calls. The image never goes anywhere.

I know "client-side AI" sounds like it should be complicated but the actual
core of it is pretty straightforward once you get ONNX Runtime Web set up:

const session = await ort.InferenceSession.create('./model.onnx');
const tensor = preprocessImage(imageData);
const { output } = await session.run({ input: tensor });
applyAlphaMask(canvas, originalImage, output);

The annoying part wasn't the model. It was memory. When someone tries to
process 10 high-res photos back to back, things get ugly fast. Still working
through that. Releasing > perfect, etc.

The thing nobody mentions about client-side inference is how weird it feels
the first time it actually works. You drag in a photo, the model loads,
and suddenly the background is just... gone. Locally. No spinner waiting
on a server response. It's fast in a way that feels slightly wrong.

Privacy-wise it's also just cleaner. I don't have to store anything,
process anything server-side, or explain to users where their photos go.
They go nowhere. That's the whole point.

Quick note on how this actually gets built:

I have a full-time job. This entire project gets worked on during my commute —
phone in one hand, trying not to miss my stop with the other. Most of the
testing happens on my phone screen, which is a chaotic way to do QA but
also weirdly effective because if it works on a moving subway, it works.

I'm not romanticizing the grind or whatever. It's just the actual situation.
You ship with the time you have.

Anyway. Month 4 starts now. Continuing to validate the AI tools,
fix what's broken, and figure out which features people actually use
vs which ones I thought they'd use (always humbling).

If you've built anything client-side AI recently — especially anything
dealing with image processing in the browser — drop a comment.
I'm curious what models you're running and what memory headaches
you've run into.

bulkpictools.com — go break something and tell me what breaks.

Introducing BulkPicTools:Why Your Images Belong on Your Hard Drive, Not the Cloud

Genglin Zheng — Thu, 26 Feb 2026 10:36:49 +0000

The Cloud is a Lie (And I learned it the hard way in 2025)

Let's be real for a second. For the last decade, we have been conditioned to think that for a tool to be powerful, it has to happen on a server. We have been told that to resize a hundred photos, we need to hand over our files to a cloud provider and hope their privacy policy is more than just marketing fluff.

I used to believe that too. Until June 2025.

I was working on a high-stakes project with over 200 sensitive client photos. I used a popular "cloud-based" batch converter because I thought it was easier. Halfway through the 400MB upload, the server glitched. Not only did the conversion fail, but the site refreshed, and my original upload queue vanished. Even worse, three days later, I started seeing "targeted ads" related to the content of those private photos. That was my wake-up call. The cloud isn't just a convenience; it's a security hole you are paying to fall into.

But it is 2026. Your browser is no longer just a window for text; it is a high-performance engine. Your computer GPU is sitting there, bored, waiting for something to do.

This is why we built BulkPicTools.

We did not just build another image editor. We built a manifesto for the modern web. A place where batch processing and privacy finally live in the same room. The era of uploading your life just to change a file extension is officially dead.

A Rant: Why is "Simple" Image Editing so Broken?

Before we dive into the tech, can we talk about how annoying "online tools" have become?

You find a site that promises to resize a photo. You click "Upload," and suddenly you are hit with a popup: "Please create an account to see your results." You give them your email, wait for a verification code that never arrives, and finally, when you get back in, you see a giant "PREMIUM ONLY" watermark over your image.

Or my personal favorite: The tools that make you watch a 30-second ad for a mobile game just to download a single 100KB WebP.

It is exhausting. It is disrespectful to your time. And frankly, it is predatory. At BulkPicTools, we have a simple rule: No accounts. No watermarks. No "waiting in line" for a server to process your file. You open the page, you drop your images, and you are done.

The Technical Renaissance: Why Local-First is the Only Way Forward

Most online tools are black boxes. You send your data in, something happens on a server you do not own, and a file comes back. But what happens to the copy on their server? Who is training their AI models on your proprietary designs?

Actually, the security risks of cloud-side processing are growing every day. Metadata leakage and server-side logs are weekly headlines.

BulkPicTools is fundamentally different. When you use our Bulk Image Editor, the processing happens inside your browser RAM and CPU. 100% of the mathematical operations are done locally. If you unplug your internet cable halfway through, the tool keeps working. Why? Because your images belong to you, and they should never leave your sight. This local-first architecture is not just a feature; it is a philosophical commitment to the user.

The Magic Under the Hood: WebAssembly & GPU Acceleration

How can a website be faster than a professional desktop app? The answer is WebAssembly (WASM).

In the past, browsers were limited by JavaScript—great for clicking buttons, terrible for crunching pixels. We compiled low-level C++ and Rust libraries into a binary format that your browser executes at near-native speeds.

When you drag 500 high-resolution photos into our Image Resizer, we trigger a multi-threaded, GPU-accelerated pipeline. We utilize SIMD (Single Instruction, Multiple Data) instructions to process multiple pixels at once. It is the reason we can crunch through a gigabyte of images while the other guys are still "Waiting for Upload."

A Full Ecosystem for the Modern Content Creator

We did not stop at just resizing. We looked at the daily friction points for photographers, developers, and e-commerce managers.

1. Precision Resizing without the Blur

Most resizers use cheap algorithms that leave your photos looking soft. We use high-fidelity Bicubic and Lanczos interpolation. Whether you are prepping for a 4K display or a Shopify store, our Image Resizer ensures every pixel is exactly where it should be. We give you granular control over padding and background fills—perfect for that "Instagram Frame" look without the manual work in Photoshop.

2. The Great Format Migration: Mastering WebP & AVIF

In 2026, if you are still using 5MB JPEGs on your blog, you are losing money. Large images kill your Largest Contentful Paint (LCP). Our Image Converter makes the transition to next-gen formats seamless.

By switching to AVIF, you can often see a 90% reduction in file size without any perceptible loss in quality. This isn't just about saving storage; it's about making your site load instantly on a mobile device in the middle of a subway station.

3. Controlling Your Digital Shadow with EXIF Editing

Every photo you take has a digital fingerprint. This EXIF data contains your GPS coordinates and even your camera serial number.

Our EXIF Editor gives you the power to strip this data entirely. Before you post that "For Sale" ad on a marketplace, you should probably make sure your home address isn't embedded in the metadata. BulkPicTools makes it easy to sanitize hundreds of photos at once.

Deep Dive: The Performance Gap

Let's talk numbers. We ran a benchmark against three of the most popular "cloud-based" image converters. The task: resize and convert 50 high-res JPEGs (average 8MB per file).

Cloud Tool A: 4 minutes and 12 seconds (Upload/Download latency).
Cloud Tool B: 5 minutes and 45 seconds (Throttled free tier).
BulkPicTools: 14 seconds.

The bottleneck in the cloud model isn't the processing—it's the pipe. Moving 400MB of data to a server and back will always be slower than processing it in your machine's local memory. We cut out the middleman.

The Developer’s Perspective: How WASM is Changing the Web

For years, developers were forced to make a compromise. If you wanted to build a powerful photo application, you had to build a desktop app (C++, Swift, or Java). If you wanted the reach of the web, you had to settle for slow, JavaScript-based processing or expensive server-side APIs.

WebAssembly (WASM) has shattered that wall. By compiling low-level C++ libraries into a binary format that the browser can execute at nearly the speed of a local machine, we have turned the web browser into a professional-grade execution environment.

Why our architecture is "Zero-Knowledge"

From a security engineering standpoint, BulkPicTools follows a "Zero-Knowledge" philosophy. Because we never see your data, we cannot leak it. In an era of strict GDPR and CCPA regulations, using a local-first tool like ours isn't just a personal preference—it is a smart business move. Developers can use our tool to prep assets for their projects without ever worrying about their company's proprietary designs hitting a third-party server.

The E-commerce Efficiency Gap: A Real-World Use Case

Let's look at a typical day for a Shopify or Amazon seller in 2026. You just received 500 product photos from a professional photographer. They are high-resolution, 50MB TIFF files.

The Old Way (Cloud-based):

Open a browser and find a batch converter.
Attempt to upload 25GB of data.
The browser crashes halfway through because of a timeout.
You try again in smaller batches. Total time wasted: 3 hours.
You pay a "Premium Subscription" because the free tier limits you to 10 files.

The BulkPicTools Way:

Open our Bulk Image Editor.
Drag and drop all 500 files.
Your local CPU cores light up. Our multi-threaded engine starts processing 8 to 16 images simultaneously.
Within 5 minutes, all 500 files are resized to 1200px, converted to WebP, and renamed.
You download a single ZIP file or individual images. Total time: 5 minutes.

This is the "Efficiency Gap." For businesses, time is literally money. BulkPicTools reclaims those hours so you can focus on selling, not waiting for an upload bar.

Beyond Simple Edits: The Future of Browser-Based AI

As we move deeper into 2026, the horizon for what is possible in a browser is expanding. We are currently testing Local AI Models (using WebGPU) that will allow for even more advanced features without sacrificing our privacy-first mission.

Imagine being able to:

Remove Backgrounds Locally: No more sending your photos to an AI server to remove a background. Our upcoming tools will use your computer's NPU (Neural Processing Unit) to mask objects in milliseconds.
Smart Upscaling: Using local super-resolution models to turn a blurry 400px thumbnail into a crisp 1600px hero image.
Auto-Color Correction: Batch adjusting the white balance and exposure of 1,000 photos based on a single reference image—all happening on your device.

We aren't just building a tool for today; we are building a platform for the future of decentralized, private, and high-performance creative work.

FAQ

1. Is BulkPicTools really free?

Yes. Because we do not have massive server bills to pay (since your computer does the work), we can offer a powerful free tier that beats most paid competitors.

2. Does it work on my phone?

Absolutely. Modern smartphones have incredibly powerful processors. You can batch resize or convert photos directly in your mobile Safari or Chrome browser while on the go.

3. What about browser compatibility?

We support all modern browsers that handle WebAssembly, including Chrome, Firefox, Edge, and Safari. If your browser is updated to a version from the last 2-3 years, you are good to go.

4. Is there a file size limit?

The only limit is your computer’s RAM. We have successfully tested batches of over 1,000 images and individual files as large as 200MB.

Final Thoughts: Joining the Privacy Revolution

The internet is at a crossroads. We can continue down the path of centralized "Cloud Everything," where our data is a commodity used to train corporate models, or we can choose a local-first future.

BulkPicTools is our contribution to that second path. It is a fast, free, and uncompromisingly private way to manage your digital life. Whether you are a professional photographer, a web developer, or someone just trying to clear up space on their phone, we are here to make your workflow smoother.

Stop waiting for the cloud. Start processing at the speed of your own hardware.
👉 Try BulkPicTools for free today and reclaim your digital sovereignty.

Nuxt 4 War Stories: The Errors I Never Want to See Again

Genglin Zheng — Thu, 29 Jan 2026 15:55:08 +0000

Nuxt 4 + Tailwind + Cloudflare. Sounds like the dream stack, right?

When I decided to rebuild BulkPicTools, that’s exactly what I thought. "Nuxt 4 is built for speed," I told myself. "This is going to be an easy win."

Well, reality hit me pretty hard.

Honestly, this is the "Bleeding Edge Tax." Everything runs perfectly on localhost, but the moment you try to deploy, things start breaking. Since I’ve already spent the sleepless nights fixing this stuff, I’m writing it down so you (hopefully) don’t have to.

1. That Lighthouse Score That Hurt My Feelings

When I deployed the first version, I was feeling pretty good. The UI was snappy, Tailwind was doing its job. I ran a Lighthouse test just to see that sweet 100/100.

Score: < 60. 🔴

(Caption: Ouch. The initial mobile performance score was a disaster.)

I was shocked. Nuxt 4 is supposed to be a performance beast!

I stared at the screen for a solid minute. Isn't Nuxt 4 supposed to be a performance beast?

Turns out, it was the CSS. By default, the build was generating a bunch of separate CSS files for Tailwind. The browser had to wait for all those network requests before it could paint anything. My First Contentful Paint (FCP) was trash.

The fix was a bit aggressive: I forced the styles directly into the HTML.

I stopped using <style> blocks in my Vue components entirely (strict discipline required) and forced Nuxt to inline the Tailwind config.

Here is the "magic switch" I added to nuxt.config.ts:

// nuxt.config.ts
export default defineNuxtConfig({
  // Centralize all Tailwind styles here
  css: ['~/assets/css/tailwind.css'],
  features: {
    // This is the lifesaver: inline the styles to kill network requests
    inlineStyles: true
  },
})

After this? The score shot back up to 90+. It feels a bit weird to inline everything in 2025, but hey, if it makes the site fast, I’ll take it.

Finally seeing green. The "Inline Styles" config brought the mobile score from <60 back to 99.

2. The "It Works on My Machine" Nightmare (Cloudflare Edition)

This is the sentence every developer dreads.

I chose Cloudflare Pages because it’s free and fast. Locally, npm run generate worked flawlessly. I pushed to GitHub, poured a coffee, and waited for the green checkmark.

Build Failed. 💥

The error was complaining about a missing queryCollection. This is a core function I use to fetch blog content. It turns out Cloudflare’s build environment handles module resolution differently than my local Mac.

Did I have time to debug Cloudflare's internal Node environment? No.

So, I decided to "lie" to the compiler.

I wrote a Mock Adapter to trick the build process into thinking those modules existed.

First, I aliased the missing modules in the config:

// nuxt.config.ts
import { fileURLToPath } from 'url'

export default defineNuxtConfig({
  alias: {
    // Can't find it? Redirect to my fake file.
    '@nuxt/content/server': fileURLToPath(new URL('./adapter-content.ts', import.meta.url)),
    '@nuxt/content/dist/module.mjs': fileURLToPath(new URL('./adapter-content.ts', import.meta.url))
  },
})

Then, I created the "liar" file, adapter-content.ts:

// adapter-content.ts

// 1. Mock queryCollection for the Content v3 API
export const queryCollection = () => {
  return {
    all: () => Promise.resolve([]),
    where: () => ({
      all: () => Promise.resolve([])
    })
  }
}

// 2. Mock the legacy API too, just in case the Sitemap module asks for it
export const serverQueryContent = () => {
  return {
    find: () => Promise.resolve([]),
    where: () => ({
      find: () => Promise.resolve([])
    })
  }
}

export default {
  queryCollection,
  serverQueryContent
}

Is it a dirty hack? Yes. Did it work? Absolutely. The build passed, and the site went live. Good enough for me.

3. Launching a Landing Page in 30 Minutes? You Can't Code That by Hand

My plan is to launch dozens of specific tools, like "WebP to JPG" or "HEIC to PNG."

If I had to manually code the Title, Meta Description, JSON-LD Schema, and i18n support for every single one... I’d be stuck writing boilerplate code for the rest of my life. Plus, trends move fast. If I see a keyword opportunity, I need that page live in under 30 minutes.

So I stopped writing pages and started writing config.

I built a Configuration-Driven Engine:

The Config: Everything is a JSON object. Input format, output format, FAQs, titles.
The Template: One generic .vue file that reads the config.
The SEO Layer: This is the secret sauce. The template automatically generates complex JSON-LD based on the config.

Breadcrumbs? Generated from the route.
Tool Schema? Filled in automatically.
Translations? It looks up the keys based on the ID.

Now, if I want to launch a new tool, I just commit a few lines of JSON. That’s how it should be.

Building with bleeding-edge tech like Nuxt 4 is a bit of a rollercoaster. You get the incredible performance, but you also have to be ready to patch the holes in the ecosystem yourself.

Is the code perfect? Definitely not. But BulkPicTools is live, it loads instantly, and I didn't lose all my hair building it.

Want to see if my hacks held up? Go check it out:
👉 BulkPicTools.com

I spent a year chasing AI hype and buying courses. Here is why I went back to Vue.

Genglin Zheng — Mon, 19 Jan 2026 10:29:31 +0000

I’ll be honest: I got lost.

For the past year, I abandoned my comfort zone. As a veteran Vue 2 developer, I felt the "Fear Of Missing Out" (FOMO) hitting me hard. Everywhere I looked, people were shouting:

"AI will replace you!" > "Learn LLMs or become obsolete!" > "Make passive income with AI-generated videos!"

I have two kids to feed. The anxiety was real.

So, I did what many terrified developers did. I stopped writing code and started chasing the wind. I bought the expensive courses on "AI App Development". I tried to become a "Content Creator" using AI tools to churn out soulless videos. I tried to force myself to love the React ecosystem just because "it has more AI libraries."

I became a "Leek" (a term we use in China for people who get harvested by hype).

After a year of burning cash and time, I looked at my portfolio. I had zero real users, a bunch of "Hello World" AI demos, and a lingering feeling of emptiness. The AI tools improved my efficiency, sure, but they didn't solve the core problem: I wasn't building anything valuable.

The Return to Reality

I had a reality check one late night. I realized that while everyone is trying to build the next ChatGPT wrapper, regular people still struggle with basic things.

I create content, and I work with images daily. I realized that simple tasks like bulk resizing, converting formats, or compressing images without uploading them to a shady server (privacy matters!) are still annoying.

Photoshop is too expensive and heavy for quick tasks.
Most online tools are ad-ridden nightmares that steal your data.

So, I made a decision. Stop chasing the hype. Start shipping utility.

From Vue 2 to Nuxt 4

I went back to my roots, but I leveled up. I skipped the legacy Vue 2 patterns I was used to and dove straight into Vue 3 (Composition API) and Nuxt.

It was refreshing. No more fighting with Python environments or prompt engineering. Just pure, clean JavaScript/TypeScript.

I built BulkPicTools.

It’s not an "AI-powered, Blockchain-backed, Metaverse-ready" platform. It’s a boring, useful tool.

⚡️ Client-side only: It runs entirely in your browser using WebAssembly and modern JS APIs.
🔒 Privacy-first: Your photos never leave your device. No server uploads.
🛠 Solves a real problem: Bulk processing for creators who value their time.

Why I'm sharing this

I’m writing this for any other developer who feels inadequate because they aren't an "AI Expert" yet.

You don't need to ride every wave. Your engineering skills—whether it's Vue, Rails, or PHP—are still valuable if you use them to solve real problems.

I’m still learning the ropes with the latest Nuxt features, and the journey from "Corporate Employee" to "Indie Hacker" is terrifying. But at least now, I'm building something real again.

If you have feedback on the tool or the Nuxt implementation, I’d love to hear it!

Thanks for reading.

Next.js Multilingual Sitemap Optimization: Dodge Redirect Issues & Boost SEO

Genglin Zheng — Mon, 21 Apr 2025 01:38:37 +0000

Introduction

Ever been annoyed by this? You put in the work to generate a sitemap.xml for your multilingual site, only to check it on Ahrefs or Google Search Console and—bam!—a ton of “redirect issue” warnings. Take my site, solomakerstudio.com, for example. Links without a language code (like solomakerstudio.com/) all 301 redirect to the default language (say, solomakerstudio.com/en/). It’s not just annoying—it can make search engines think your site’s messy, hurting your SEO.

No stress, though! This article’s gonna walk you through optimizing your multilingual sitemap.xml to squash those redirect issues and make your site a search engine’s best friend. It’s super practical, beginner-friendly, and even if you’re new to SEO, you’ll be able to follow along!

Why Does sitemap.xml Have Redirect Issues?

Let’s get to the root of the problem. Many multilingual sites (using subdirectories like /en or /zh) set non-localized links (e.g., solomakerstudio.com/) to auto-redirect to a default language (like /en/). That’s fine for users, but it causes headaches in sitemap.xml:

Search engines hate redirects: If solomakerstudio.com/ is in your sitemap but redirects to /en/, crawlers have to jump through an extra hoop. It slows them down and makes your sitemap look less “direct.”
SEO tools throw warnings: Tools like Ahrefs or SEMrush flag redirects in your sitemap as “issues,” which is just frustrating.
Duplicate content risks: If both / and /en/ are in your sitemap, search engines might think they’re separate pages, diluting your page’s ranking power.

The fix? Only include final, non-redirecting URLs in your sitemap.xml—no “middleman” links that trigger redirects.

4 Practical Steps to Optimize Your sitemap.xml

Alright, let’s get to the good stuff! Here are four dead-simple steps to make your multilingual sitemap clean and SEO-friendly.

Step 1: Only Include Localized Links

The golden rule: Don’t put non-localized links (like solomakerstudio.com/) in your sitemap.xml. Only include URLs with language subdirectories, like this:

<url>
    <loc>https://solomakerstudio.com/en/</loc>
    <lastmod>2025-04-17</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
</url>
<url>
    <loc>https://solomakerstudio.com/zh/</loc>
    <lastmod>2025-04-17</lastmod>
    <changefreq>weekly</changefreq>
    <priority>0.8</priority>
</url>

How to do it?

CMS users (e.g., WordPress): Check your sitemap plugin (like Yoast SEO or Rank Math) settings to ensure it only generates URLs with language codes (e.g., /en/ or /zh/).
Custom scripts: If you’re generating your sitemap manually, tweak the code to filter out non-localized URLs. For a Next.js project, add a sitemap.tsx file in the root and use this script:

import type { MetadataRoute } from 'next';
import { appConfig } from '@/lib/appConfig';

// Helper function to generate localized URLs
const getLocalizedUrl = (baseUrl: string, path: string, locale: string) => {
  const localePath = `/${locale}`;
  const routePath = path === '' ? '' : `/${path}`;
  return `${baseUrl}${localePath}${routePath}`;
};

export default async function sitemap(): Promise<MetadataRoute.Sitemap> {
  // Define static routes
  const staticRoutes = [
    { path: '', changeFrequency: 'daily' as const, priority: 1 },
    { path: 'tools', changeFrequency: 'daily' as const, priority: 0.9 },
  ];
  const sitemapData: MetadataRoute.Sitemap = [];
  // Get supported languages
  const locales = appConfig.i18n.locales;

  // Loop through languages to generate localized links
  for (const locale of locales) {
    staticRoutes.forEach(route => {
      sitemapData.push({
        url: getLocalizedUrl(BASE_URL, route.path, locale),
        lastModified: new Date(),
        changeFrequency: route.changeFrequency,
        priority: route.priority,
      });
    });
  }

  // All generated links include language prefixes
  return sitemapData;
}

Pro tip: This applies to your homepage too! If solomakerstudio.com/ redirects to solomakerstudio.com/en/, only include the /en/ version in your sitemap.

Step 2: Add hreflang Tags to Clarify Language Versions

For multilingual sites, you gotta tell search engines which pages are the same content in different languages. That’s where hreflang tags come in. Add them to your sitemap.xml like this:

<url>
    <loc>https://solomakerstudio.com/en/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://solomakerstudio.com/en/" />
    <xhtml:link rel="alternate" hreflang="zh" href="https://solomakerstudio.com/zh/" />
    <lastmod>2025-04-17</lastmod>
</url>
<url>
    <loc>https://solomakerstudio.com/zh/</loc>
    <xhtml:link rel="alternate" hreflang="en" href="https://solomakerstudio.com/en/" />
    <xhtml:link rel="alternate" hreflang="zh" href="https://solomakerstudio.com/zh/" />
    <lastmod>2025-04-17</lastmod>
</url>

Why bother?

Tells Google which page is English, which is Chinese, preventing duplicate content issues.
Improves user experience by helping search engines serve the right language version based on user preferences.
Saves crawler resources—search engines have tons of sites to crawl, so making their job easier helps your site get indexed faster!

How to add them?

WordPress users: Plugins like Yoast SEO or Polylang can auto-generate sitemaps with hreflang tags.
Manual sitemaps: Make sure your sitemap XML includes the xmlns:xhtml="http://www.w3.org/1999/xhtml" namespace, like this:

Step 3: Ensure Redirects Use 301

If non-localized links (like solomakerstudio.com/) redirect, make sure they use 301 permanent redirects, not 302 temporary ones. Why? A 301 tells search engines, “This page has moved for good,” passing SEO juice smoothly.

How to check?

Open your browser’s developer tools (F12 -> Network tab), visit solomakerstudio.com/, and check if the status code is 301.
Or use an online tool like redirect-checker.org to confirm.

How to fix?

Server config (Nginx/Apache): Ensure redirects are set to 301. For Nginx, it looks like this:

  rewrite ^/$ /en/ permanent;

CMS users: Check your language-switching plugin to confirm it’s using 301 redirects.
Next.js example (e.g., solomakerstudio.com hosted on Vercel): Use a custom middleware.ts file:

import { NextRequest, NextResponse } from 'next/server';
import createMiddleware from 'next-intl/middleware';
import { appConfig } from './lib/appConfig';

const intlMiddleware = createMiddleware({
  locales: appConfig.i18n.locales,
  defaultLocale: appConfig.i18n.defaultLocale,
  localePrefix: 'always',
});

export function middleware(request: NextRequest) {
  const { pathname } = request.nextUrl;

  // Handle root path (/) for 301 redirect based on Accept-Language
  if (pathname === '/') {
    const acceptLanguage = request.headers.get('accept-language') || '';
    let targetLocale = appConfig.i18n.defaultLocale; // Fallback
    // Match language based on Accept-Language header
    if (acceptLanguage.includes('zh')) {
      targetLocale = 'zh';
    } else if (acceptLanguage.includes('en')) {
      targetLocale = 'en';
    }
    // Perform 301 redirect
    const redirectUrl = new URL(`/${targetLocale}`, request.url);
    return NextResponse.redirect(redirectUrl, 301);
  }
  return intlMiddleware(request);
}

export const config = {
  matcher: [
    '/((?!api|_next|.*\\..*).*)',
    '/rss.xml',
    '/:locale/rss.xml',
    '/admin/:path*',
  ],
};

Step 4: Validate Your sitemap.xml

Before submitting your shiny new sitemap.xml, double-check it to avoid any oopsies.

How to validate?

Submit your sitemap to Google Search Console’s “Sitemaps” tool and check the “Coverage” report after a few days for errors.
Run Ahrefs’ Site Audit to see if there are any redirect warnings in your sitemap.
Locally, use an XML validator (like xmlvalidation.com) to ensure your sitemap’s format is correct.

Pro tip: After submitting to Google Search Console, hit “Resubmit” to nudge crawlers to grab the updated version. Here’s what our optimized sitemap looked like after running it through Ahrefs:

Extra Tips to Keep in Mind

A few bonus pointers to make your sitemap even better:

Dynamic sitemaps: If your site has tons of pages, use a script or plugin to auto-generate your sitemap—saves time!
Regular updates: Keep your sitemap fresh with accurate <lastmod> dates whenever your site changes.
Multilingual plugins: For WordPress, plugins like WPML or Polylang make multilingual sitemaps a breeze—set them up and relax.

Wrapping Up

Fixing your multilingual sitemap.xml isn’t rocket science. The key? Skip redirecting links, use localized URLs, add hreflang tags, and stick to 301 redirects. Follow these four steps, and your sitemap will be squeaky clean—no more Ahrefs warnings, and Google’s crawlers will love your site.

Give it a shot! If you hit any snags (like how to tweak your CMS or code), just let me know, and I’ll break it down for you!

From Vue to Next.js: How I Let Go and Built a Curated Tool Hub 🌟

Genglin Zheng — Tue, 01 Apr 2025 07:33:55 +0000

Intro

As a Vue frontend dev, I initially just wanted to whip up a simple static site with Next.js—learn a hot framework while I was at it. But guess what? Building from scratch took forever, totally clashing with my goal of helping indie devs ship fast! 😅 So, I pivoted hard, turning SoloMakerStudio.com into a dynamic, multilingual platform. This is my story—tech choices, struggles, and all—hoping it sparks something for you! ✨

Where It All Started

I’ve always been a Vue fan, dabbling in React Native too. One night, I got this itch: create a site curating free tools to help indie devs turn ideas into reality, pronto. My first plan? A static Next.js site—simple, and a chance to level up my skills. But here’s the kicker: hand-coding pages and tweaking styles ate up so much time, my MVP was nowhere in sight. I started panicking—wasn’t this just a waste? 🤔

The Shift from Static to Dynamic

Once I saw the issue, I hit pause and thought: if I can’t launch fast, how can I help others do it? I scrapped the static idea and went dynamic. Next.js’s dynamic routing gave me flexibility, Supabase’s real-time database made tool suggestions snappy, and Vercel’s one-click deploys saved my sanity! 🚀 Later, I tossed in multilingual support—shifting from “just messing around” to “actually serving users.” It was exhausting, but it got me closer to the mission! 😊

Curating Only the Good Stuff

After drowning in tool overload myself, I decided SoloMakerStudio wouldn’t be a chaotic pile of options. It’s all about free, practical tools indie devs can actually use—easy to pick up and quick to ship with. Think a lightweight prototyping gem that gets you live in two days, not some bloated framework you’d need a month to master. “Less is more” became my mantra, born from my own trial and error. 🌟 Ever felt paralyzed by too many choices?

Tech Hurdles and Wins

Jumping from Vue to Next.js wasn’t a cakewalk—JSX drove me nuts, and server-side rendering had me spinning. 😵 Configuring Supabase and Vercel felt like a puzzle too. But every hurdle I cleared brought me closer to the goal. Now, Next.js lets me iterate fast, Supabase keeps things lively, and Vercel makes deploying as easy as hitting enter. Looking back, sticking to a static site would’ve left me stuck—probably still offline! 😂

Launch Day Joy

March 2025 rolled around, and SoloMakerStudio finally went live! 🎉 It’s not the static page I first pictured—it’s a dynamic tool hub tailored for indie devs. When the first user said, “Finally, a platform that doesn’t lose me!” I was over the moon. That’s when I knew the Vue-to-Next.js grind paid off. ✨

What’s Next?

SoloMakerStudio’s heart is “less is more”—giving you just the tools you need to go from idea to reality, fast. Check it out at solomakerstudio.com! 🌈 Drop a comment: what’s tripped you up shipping an MVP? I’d love to hear your tales! And which free tools are must-haves for indie devs? Let’s chat! 😉