SEO Sitemap Library for TypeScript: A Complete Guide to @power-seo/sitemap
Mitu Das
super admin

I've built sitemaps for tiny five-page brochure sites. I've also built them for catalogs with half a million product pages. The small site forgives almost any mistake. The big site does not. One bad <loc> tag, one memory spike from string concatenation, one missing sitemap index, and Google quietly stops trusting your file.
The frustrating part is that nobody warns you until it's already broken. You ship the build, check Search Console a week later, and see a wall of "couldn't fetch" errors on a file you barely thought about. I've been there more than once, and it's always an avoidable mistake.
That's the problem I want to solve here. I'll walk you through what a good SEO sitemap library for TypeScript should do, where most existing tools fall short in 2026, and how a newer option called @power-seo/sitemap handles the messy parts: streaming, auto-splitting, image and video extensions, and validation.
By the end, you'll know how to generate a sitemap, scale it past 50,000 URLs, and wire it into Next.js, Remix, or any edge runtime, all without hand-building XML again.
A solid TypeScript sitemap library should give you typed XML output, handle the 50,000-URL spec limit automatically, and stay light on your bundle. @power-seo/sitemap does all three, with zero runtime dependencies of its own.
What a Sitemap Actually Does (and Why TypeScript Projects Need a Real Library)
A sitemap is a plain XML file. It lists every URL you want search engines to crawl. Google, Bing, and now AI crawlers all read this file to find your pages faster.
Sounds simple. It is, right up until your site grows.
Why Hand-Rolling XML Sitemaps Goes Wrong
I've seen teams write their own sitemap function in an afternoon. It works fine for 50 URLs. Then the catalog hits 10,000 products, and three things break at once.
The namespace declaration is wrong, so Search Console flags errors you didn't expect. String concatenation across thousands of entries spikes memory on every build. And nobody remembers the 50,000-URL limit until the file gets quietly rejected.
A dedicated SEO sitemap library for TypeScript catches all three before they happen, because the types and the limits are built in, not bolted on later.
Three Sitemap Mistakes I Still See All the Time
Even experienced teams trip on the same handful of issues. Worth checking your current setup against this list before moving on.
- Wrong or missing namespace: Add image, video, or news tags without declaring the right XML namespace, and Search Console silently ignores them.
- Listing pages that shouldn't be there: Redirects, 404s, and
noindexpages have no business in a sitemap. They waste crawl budget and confuse the signal you're sending. - Stale
lastmoddates: Flipping every date to "today" on every deploy isn't a freshness hack. It just trains Google to stop trusting the field.
The Market Gap: Why Most Sitemap Tools Fall Short in 2026

I looked at what TypeScript and Next.js developers actually reach for today. Two names dominate: next-sitemap and the plain sitemap package on npm. Both are solid, well-used tools. Both also show their age.
next-sitemap built its reputation as a postbuild script for the Pages Router. It still works that way: Next.js builds your site, then next-sitemap crawls the output and writes static XML files. That's fine for a static export. It's a worse fit for the App Router, edge runtime, or content that changes between deploys.
The plain sitemap package is a streaming workhorse with millions of weekly downloads. But it has no typed image, video, or news extensions in one cohesive API, no app/sitemap.ts adapter for Next.js, and no URL validator you can drop straight into CI.
By the Numbers: Popular Doesn't Mean Modern
Download counts tell an honest story here. The plain sitemap package pulls in well over three million weekly downloads, and next-sitemap sits north of 370,000 a week. Those numbers prove demand, not architecture. Both tools predate the App Router, predate edge runtimes becoming standard, and predate AI crawlers reading sitemaps at all. Popularity buys trust, but it doesn't rewrite a tool's core design after the fact.
That's the gap. Developers want one sitemap library for TypeScript that's type-safe, edge-compatible, and handles huge catalogs without a separate crawler step.
What to Look for in a Modern TypeScript Sitemap Generator
When I'm picking a sitemap generator for a TypeScript project, I check for five things:
- Full TypeScript types for every URL field, not a loose object shape.
- Streaming or chunked output, so a 200,000-URL catalog doesn't crash a build.
- Automatic splitting at the 50,000-URL spec limit, with an index file generated for you.
- Image, video, or news extensions, for sites that need them.
- Zero or near-zero runtime dependencies, so the bundle stays light on edge runtimes.
@power-seo/sitemap happens to check every one of those boxes, which is why I want to walk through it next.
Meet @power-seo/sitemap: A TypeScript-First XML Sitemap Generator
@power-seo/sitemap is one of the sitemap-focused packages inside the larger power-seo toolkit, built by CyberCraft Bangladesh. It does one job well: turn a hostname and a list of typed URLs into spec-correct sitemap XML.
Type Safety and Zero Runtime Dependencies
Every URL you pass in is typed as a SitemapURL. Your editor warns you if priority is a string instead of a number, or if changefreq doesn't match one of the seven allowed values. The package ships with only @power-seo/core as a peer dependency: no XML builder, no string-templating library hiding underneath.
It also skips install scripts, runtime network calls, and eval. Small details, but they matter if you're running this in CI or on the edge.
Six Tree-Shakeable Functions
The whole library comes down to six functions: generateSitemap, streamSitemap, splitSitemap, generateSitemapIndex, validateSitemapUrl, and toNextSitemap. Each one is independently importable, so your bundler only ships the code you actually call.
Part of a Bigger SEO Toolkit, If You Need It
You don't have to adopt anything beyond the sitemap package. It stands on its own. But it's worth knowing it sits inside a larger collection of separately installable tools from the same team, covering structured data, redirects, content analysis, and Search Console reporting. If your roadmap eventually includes JSON-LD schema or a redirect engine, you're not starting from zero on a second tool with a different design philosophy.
Getting Started: Install and Generate Your First Sitemap
Installing it is the easy part:
npm install @power-seo/sitemap
Generating a sitemap takes one function call:
import { generateSitemap } from '@power-seo/sitemap';
const xml = generateSitemap({
hostname: 'https://example.com',
urls: [
{ loc: '/', lastmod: '2026-01-01', changefreq: 'daily', priority: 1.0 },
{ loc: '/products', changefreq: 'weekly', priority: 0.9 },
{ loc: '/blog', changefreq: 'daily', priority: 0.8 },
],
});
// Serve as application/xml
res.setHeader('Content-Type', 'application/xml');
res.send(xml);
Notice the loc values are relative paths, like /products. You set hostname once, and the function prepends it for every relative path. If a loc is already an absolute URL, it's left alone.
Handling Big Catalogs Without Breaking Memory or the 50,000 Rule
This is where most homemade sitemap scripts fall apart. Here's how @power-seo/sitemap handles scale.
Streaming Sitemaps So Memory Stays Flat
streamSitemap() is a synchronous generator. It yields one XML chunk per URL, instead of building one giant string in memory.
import { streamSitemap } from '@power-seo/sitemap';
const urls = fetchAllProductUrls(); // Iterable<SitemapURL>
const stream = streamSitemap('https://example.com', urls);
for (const chunk of stream) {
response.write(chunk);
}
response.end();
I like this pattern for e-commerce catalogs pulling from a database cursor. You never load every product into memory at once.
Auto-Splitting at the 50,000-URL Limit
Google still caps every sitemap file at 50,000 URLs or 50MB uncompressed. That limit hasn't moved in years. If your catalog crosses it, splitSitemap() chunks the URLs and writes a matching sitemap index for you.
import { splitSitemap } from '@power-seo/sitemap';
const { index, sitemaps } = splitSitemap({
hostname: 'https://example.com',
urls: largeUrlArray, // more than 50,000 entries
});
// Write each sitemap file
for (const { filename, xml } of sitemaps) {
fs.writeFileSync(`./public${filename}`, xml);
}
// Write the index (default filenames: /sitemap-0.xml, /sitemap-1.xml, ...)
fs.writeFileSync('./public/sitemap.xml', index);
You can also change the filename pattern, if your team prefers something like /sitemaps/part-{index}.xml over the default.
Going Beyond Basic URLs: Images, Video, News, and Validation
A plain <url> entry covers most pages. Some sites need more.
Image Sitemaps for Product Galleries
If you run an online store, product images often hide behind JavaScript that crawlers skip past. Adding an images array to any URL entry fixes that.
import { generateSitemap } from '@power-seo/sitemap';
const xml = generateSitemap({
hostname: 'https://example.com',
urls: [
{
loc: '/products/blue-sneaker',
lastmod: '2026-01-10',
images: [
{
loc: 'https://cdn.example.com/sneaker-blue.jpg',
caption: 'Blue sneaker, side view',
title: 'Blue Running Sneaker',
},
{
loc: 'https://cdn.example.com/sneaker-blue-top.jpg',
caption: 'Blue sneaker, top view',
},
],
},
],
});
Video and news entries work the same way, through videos and news fields on the same SitemapURL object. The library only declares the namespaces it actually needs, so a plain page sitemap stays clean and small.
Catching Bad URLs Before Google Does
validateSitemapUrl() checks one entry against the spec and returns errors and warnings, without throwing. I like running this in CI, right before deploy.
import { validateSitemapUrl } from '@power-seo/sitemap';
const result = validateSitemapUrl({
loc: '/about',
priority: 1.5, // out of range
changefreq: 'daily',
});
// result.valid → false
// result.errors → ['priority must be between 0.0 and 1.0']
// result.warnings → []
A bad sitemap that ships quietly is worse than one that fails your build loudly.
Wiring It Into Next.js, Remix, and the AI Crawlers of 2026
The app/sitemap.ts Convention
Next.js App Router expects a typed array, not XML, from app/sitemap.ts. toNextSitemap() handles that conversion and filters out invalid entries automatically.
// app/sitemap.ts
import { toNextSitemap } from '@power-seo/sitemap';
export default async function sitemap() {
const urls = await fetchUrlsFromCms();
return toNextSitemap(urls);
// Returns NextSitemapEntry[]. Next.js renders the XML automatically
}
Need full control over image or video tags? Drop down to a route handler and call generateSitemap() directly instead.
Remix gets the same treatment through a plain resource route:
// app/routes/sitemap[.xml].ts
import { generateSitemap } from '@power-seo/sitemap';
import type { LoaderFunctionArgs } from '@remix-run/node';
export async function loader({ request }: LoaderFunctionArgs) {
const urls = await fetchUrlsFromDb();
const xml = generateSitemap({
hostname: 'https://example.com',
urls,
});
return new Response(xml, {
headers: { 'Content-Type': 'application/xml' },
});
}
Why Sitemaps Now Matter Beyond Google
Here's something that surprised me this year. Sitemaps aren't just a Google and Bing thing anymore. AI crawlers, including GPTBot, ClaudeBot, Google-Extended, and PerplexityBot, read the same files to decide what's worth citing in AI-generated answers. If you want your content showing up as a source in ChatGPT or Perplexity, an accessible, well-structured sitemap helps those crawlers find your best pages faster.

I think of it this way: a sitemap used to answer one question: "what does Google need to crawl?" Now it answers a second one too: "what should an AI model treat as a trustworthy, canonical source?" Both answers come from the same file, as long as that file is accurate and easy to fetch.
That's the answer-engine angle most SEO articles skip. A sitemap library for TypeScript isn't only a Google-ranking tool anymore. It's also part of how AI search tools find you at all.
Final Thoughts
A sitemap feels like a small file. It carries a lot of weight anyway. It's the difference between Google finding your new pages in hours instead of weeks, and between an AI answer engine citing you instead of a competitor down the road.
If you're building in TypeScript, don't hand-roll XML again. The bugs it hides are boring ones, like a missing namespace or a stray priority value over 1.0, but they're exactly the kind that quietly cost you crawl budget and rankings over months, not days.
Install @power-seo/sitemap, run the quick start above, and let the types catch your mistakes before Google, or an AI crawler, ever sees them. Your future self, debugging a Search Console error at 11 PM, will thank you for it.
Frequently Asked Questions About SEO Sitemap Library for TypeScript
What is the best SEO sitemap library for TypeScript?
It depends on your stack, but if you want full type safety, zero runtime dependencies, streaming for large catalogs, and built-in image, video, and news extensions, @power-seo/sitemap covers more ground than older tools like next-sitemap or the plain sitemap package.
How many URLs can one sitemap file hold?
Google caps a single sitemap at 50,000 URLs or 50MB uncompressed. Past that limit, you need a sitemap index file pointing to several smaller sitemaps. This rule has stayed unchanged for years, so it's safe to build automation around it.
Do priority and changefreq tags still matter?
Not much. Google has said it largely ignores priority and changefreq values. Spend your effort on accurate lastmod dates and clean, crawlable URLs instead. That's where the real ranking signal lives now.
Can I generate sitemaps on edge runtimes like Cloudflare Workers?
Yes, as long as the library avoids Node-specific APIs like fs and path. @power-seo/sitemap is built this way, so it runs on Vercel Edge, Cloudflare Workers, and Deno without changes.
Do AI tools like ChatGPT and Perplexity actually use sitemaps?
Yes. Several AI crawlers follow the same sitemap discovery pattern as traditional search engines, using it to find pages worth citing in their generated answers.
FAQ
Frequently Asked Questions
We offer end-to-end digital solutions including website design & development, UI/UX design, SEO, custom ERP systems, graphics & brand identity, and digital marketing.
Timelines vary by project scope. A standard website typically takes 3-6 weeks, while complex ERP or web application projects may take 2-5 months.
Yes - we offer ongoing support and maintenance packages for all projects. Our team is available to handle updates, bug fixes, performance monitoring, and feature additions.
Absolutely. Visit our Works section to browse our portfolio of completed projects across various industries and service categories.
Simply reach out via our contact form or call us directly. We will schedule a free consultation to understand your needs and provide a tailored proposal.


