Vishal Solanki

I built an Android file viewer that has no internet permission

Vishal Solanki — Sun, 01 Nov 2026 08:09:56 GMT

Most file viewer apps I tried on Android wanted access to all my storage, showed ads between pages, or asked me to sign in just to open a PDF someone sent me on WhatsApp. So I built my own. It's called Folio, it's free, and the one rule I set on day one was simple: the app gets no INTERNET permission. Not "we don't collect data". Android itself won't let it open a socket.

That one rule shaped almost every decision after it. Here's what it was like to build.

What it opens

PDF, with search and password-protected files
Word (.docx), Excel (.xlsx) and PowerPoint (.pptx)
CSV, TXT, Markdown, logs, subtitles, contacts (.vcf) and calendars (.ics)
JSON, XML, YAML, HTML and 40+ programming languages with syntax colours
Images including HEIC, AVIF and SVG
Audio and video
ZIP files: browse them and open what's inside

Text, Markdown, CSV and code can be edited. Word, Excel and PowerPoint stay view-only on purpose. I'd rather show you a slightly simplified slide than ship an editor that quietly breaks your layout when you save.

No storage permission either

Folio also doesn't ask for storage access. It only sees files you open with it (from WhatsApp, Gmail or the Files app), files you pick inside it, or folders you add yourself. All of that goes through Android's Storage Access Framework, so access is per file or per folder, and you can take it back.

The catch: a file can reach the app under several different URIs. The Downloads provider alone has more than one form. So Recents has to dedupe by name, size and type, or the same PDF shows up three times.

The stack

Kotlin and Jetpack Compose, one app module, no backend because there can't be one.

PDF: PDFium, the engine Chrome uses. All rendering runs on a single background thread so renders, search and close never overlap. Pages re-render sharper after you zoom, with a cap of about 8 MP per page so memory stays sane on a 200-page file.
Word: mammoth converts .docx to HTML, shown in a locked-down WebView. Mammoth didn't work on Android out of the box (Android's XML parser rejects one of the features it sets), so I ship a patched copy of one small class.
Excel: my own streaming XLSX reader. The grid draws each row in one pass instead of one composable per cell, which is the difference between smooth and unusable on a 50,000-row CSV.
PowerPoint: my own PPTX reader. Getting text styles right meant following inheritance from shape to layout to master, which was most of the work.
Code and text: Sora Editor with TextMate grammars from VS Code.
Images and media: Coil (without its network module) and Media3 ExoPlayer.

The WebView used for Word and HTML has JavaScript off, network loads blocked, and file access off. HTML files also get their scripts stripped before they're shown. If a page needs scripts, there's an "Open in browser" option that says so before you tap it.

Features you can't build the normal way offline

Some things every app has turned out to be interesting without internet.

Feedback. There's no API to call, so "Send feedback" opens an email draft in your mail app. You read it and decide whether to send it.

Crash reports. When the app crashes, it writes the stack trace to a local file. Next launch, it asks if you want to email it. Nothing leaves the phone unless you press send.

Updates. No push, no background checks. "Check for updates" opens my website in your browser with your installed version in the URL, and the page tells you if there's something newer. The page does the comparison in your browser, so the site stays static.

Shipping without the Play Store

I can't pay for a Play developer account right now, so Folio ships as an APK on GitHub Releases. Things I learned doing that:

The signing key is the app. Without Play App Signing, every update must be signed with the same key forever. Lose it and every user has to uninstall to update. Mine is backed up in two places.
Chrome can sit at 100% on APK downloads. It runs a safety check after the download finishes and can hang there. Closing the download panel and opening Chrome's Downloads usually unsticks it. Other browsers like Brave don't do it.
Play Protect will warn people. It says "App scan recommended" for any app it hasn't seen. My download page shows every warning screen in advance so nobody is surprised.
Obtainium can track GitHub releases and update the app automatically, which is the closest thing to auto-update outside the Play Store.

Try it

Folio needs Android 8.0 or newer and is about 25 MB. Screenshots, the download and step-by-step install instructions are here:

Download Folio

Built this because I was tired of file viewers full of ads and permissions. If you’ve felt the same, I hope it helps.

It’s my first public app, so if it fails on one of your files or there’s something you’d want it to do, let me know. There’s a feedback form on the page, and I read all of it.

Securing Next.js Server Actions: a 10-point checklist for 2026

Vishal Solanki — Tue, 27 Oct 2026 19:04:01 GMT

Server Actions are the nicest way to write mutations in Next.js. You write an async function, mark it "use server", pass it to a form, and you're done: no API route, no fetch call, no loading-state plumbing.

That convenience hides one fact you need to keep in mind every time: each exported Server Action is a public HTTP endpoint. Anyone can call it with a POST request, from anywhere, with any arguments, whether or not your UI shows the button.

On real products I've moved sensitive operations out of the browser and into server-side code built on Server Actions and secure cookies. This is the checklist I use for every action since.

What Next.js already does for you

It's worth knowing exactly where the built-in protection stops.

Built in	What it means
Encrypted, non-deterministic action IDs	The client calls an action by an ID, not by its name. IDs change between builds.
Dead-code elimination	Actions your app never uses are removed at build time and don't become endpoints.
POST only	Actions can't be triggered by a link, an image tag or a prefetch.
Origin check	When the browser sends an `Origin` header, it must match the host. That blocks most cross-site request forgery.
Body size limit	Request bodies are capped at 1 MB by default.

What it does not do: check who is calling, check whether they're allowed to touch this record, validate the arguments, or limit how often they can call. Those are your job, inside every action.

1. Authenticate inside the action, every time

A login check on the page does not protect the actions defined on that page. The page check runs when the page renders. The action runs later, on its own request, and can be called without ever loading the page.

"use server";

import { getSession } from "@/lib/auth";

export async function updateProfile(formData: FormData) {
  const session = await getSession();
  if (!session) throw new Error("Not signed in");
  // ...
}

2. Authorise the specific record

Being signed in only proves who the caller is. It doesn't prove they own the thing they're changing. If an action takes an ID, check ownership, or someone will change the ID and edit another user's data. This bug has a name, insecure direct object reference (IDOR), and it's one of the most common ones I find.

export async function deleteAddress(addressId: string) {
  const session = await getSession();
  if (!session) throw new Error("Not signed in");

  const address = await db.address.findUnique({ where: { id: addressId } });
  if (!address || address.userId !== session.userId) throw new Error("Not found");

  await db.address.delete({ where: { id: addressId } });
}

Return the same "Not found" whether the record doesn't exist or belongs to someone else, so the action can't be used to probe which IDs exist.

3. Validate every argument

TypeScript types disappear at runtime. A caller can send any shape, any length and any type. Validate on the server with a schema:

import { z } from "zod";

const Profile = z.object({
  name: z.string().trim().min(1).max(100),
  email: z.string().trim().email().max(200),
  city: z.string().trim().max(80).optional(),
});

export async function updateProfile(formData: FormData) {
  const session = await getSession();
  if (!session) throw new Error("Not signed in");

  const parsed = Profile.safeParse(Object.fromEntries(formData));
  if (!parsed.success) return { error: "Please check the highlighted fields." };

  await db.user.update({ where: { id: session.userId }, data: parsed.data });
  return { ok: true };
}

You don't need a library for small forms. A plain function that trims, checks lengths and checks values against a fixed list works just as well, as long as it runs on the server and has a small test.

4. Keep the database and secrets behind a server-only layer

Put database access, API keys and permission checks in one data access layer, and mark it so it can never end up in a client bundle:

// lib/data/addresses.ts
import "server-only";

export async function deleteAddressFor(userId: string, addressId: string) {
  // ownership check + delete, as in step 2
}

Then actions stay thin: read the session, validate the input, call the data layer. Auditing one folder is much easier than auditing every "use server" function in the app.

5. Return only what the client needs

Whatever an action returns is sent to the browser. Don't return the whole database row with password hashes, internal flags or other users' data. Pick the fields the UI needs.

The same goes for errors. Log the real error on the server, and send the user a short, generic message. A stack trace or a raw SQL error tells an attacker far more than it tells your user.

6. Keep sessions in httpOnly, secure cookies

Tokens in localStorage can be read by any script that runs on your page, including a compromised third-party one. An httpOnly cookie can't. Set it from a Server Action or Route Handler, where Next.js can send the Set-Cookie header:

import { cookies } from "next/headers";

export async function signIn(formData: FormData) {
  // ...verify credentials, create a session...
  (await cookies()).set("session", sessionId, {
    httpOnly: true, // not readable from JavaScript
    secure: true, // HTTPS only
    sameSite: "lax", // not sent on most cross-site requests
    path: "/",
    maxAge: 60 * 60 * 24 * 7, // one week
  });
}

Store a random session ID in the cookie and keep the session data on the server, or sign or encrypt the cookie's contents. Never put anything in a cookie you'd be unhappy for the user to edit.

7. Rate-limit, and stop the obvious bots

Sign-in, sign-up, password reset, OTP and contact forms get hammered. Limit how often a client can call them, and enforce those limits on the server.

import { headers } from "next/headers";
import { rateLimit } from "@/lib/rate-limit";

export async function requestOtp(formData: FormData) {
  const requestHeaders = await headers();

  // Use the trusted client-IP header provided by your hosting platform.
  // Replace this with the header documented by your provider.
  const ip = requestHeaders.get("YOUR_TRUSTED_CLIENT_IP_HEADER");

  if (!ip) {
    throw new Error("Unable to determine client IP");
  }

  // Apply limits by trusted IP and by normalized account identifier.
  const email = String(formData.get("email") ?? "")
    .trim()
    .toLowerCase();

  if (!email || email.length > 254) {
    return { error: "Please enter a valid email address." };
  }

  const ipAllowed = await rateLimit(`otp:ip:${ip}`, {
    limit: 10,
    windowSeconds: 600,
  });

  const accountAllowed = await rateLimit(`otp:email:${email}`, {
    limit: 5,
    windowSeconds: 600,
  });

  if (!ipAllowed || !accountAllowed) {
    return {
      error: "Too many attempts. Try again in a few minutes.",
    };
  }

  // Validate the request and continue with OTP generation and delivery.
}

Important: YOUR_TRUSTED_CLIENT_IP_HEADER is a placeholder, not a literal header name. Replace it with the client-IP header documented by your hosting provider, and verify that clients cannot spoof it. If you're self-hosting behind a reverse proxy, configure trusted proxies correctly before relying on forwarded IP headers. Never blindly trust the first X-Forwarded-For value.

The example uses separate IP-based and email-based limits. The limits shown are illustrative and should be adjusted to your traffic, abuse risk and OTP provider's limits. Apply account-based limits carefully to avoid allowing attackers to lock legitimate users out. Your rate limiter should use a shared store, such as Redis or your hosting platform's KV service, with atomic updates so concurrent requests cannot bypass the limit.

Turn on your hosting provider's firewall or bot protection as an additional layer, not as a replacement for application-level rate limiting.

For public forms, a hidden honeypot field can catch simple bots cheaply: legitimate users should leave it empty, so submissions that fill it can be rejected. The contact form on this site uses that approach. Honeypots are only a supplementary defense; sophisticated bots can bypass them.

8. Understand the CSRF protection, and don't break it

Next.js compares the request's Origin header with the host the request arrived at, and rejects actions that don't match. That covers most cross-site request forgery, together with SameSite cookies.

Two ways to break it by accident:

Behind a reverse proxy that forwards its own host instead of the public one, valid requests start failing. Add the public host to experimental.serverActions.allowedOrigins in next.config.ts, rather than disabling anything.
Mutations in GET Route Handlers. A GET request can be triggered by a link or an image tag from any site. Anything that changes data should be a Server Action or a POST, PUT or DELETE handler.

9. Mind the size of what's sent

The 1 MB default body limit is there to stop huge payloads from tying up your server. If you need file uploads, don't just raise the limit: upload straight from the browser to object storage with a short-lived signed URL, then send the resulting file key to a Server Action.

10. Keep Next.js patched

Framework bugs are part of your attack surface too. On 14 October 2026, Next.js fixed two critical remote code execution flaws (one in image optimisation of SVG files, CVE-2026-96889, and one in use cache functions returning typed arrays) and a high-severity denial-of-service issue in App Router apps that use Server Actions. The fixes are in 16.4.1 and 15.5.28. Make sure sharp resolves to 0.35.5 or later as well.

Run npm audit regularly, read the advisories it reports, and update to the patched release. If you also run PHP anywhere, see PHP2Shell: is your website affected.

The audit checklist

Run through this for every file that contains "use server":

#	Question	Fix if not
1	Does the action check the session itself?	Call your auth helper first thing
2	Does it check the caller owns the record?	Compare the owner ID before reading or writing
3	Are all arguments validated on the server?	Schema or validation function
4	Is database and secret access in a `server-only` layer?	Move it, keep the action thin
5	Does it return only what the UI needs?	Pick fields, generic errors
6	Are sessions in `httpOnly`, `secure` cookies?	Move tokens out of `localStorage`
7	Are public or sensitive actions rate-limited?	Shared-store limiter, honeypot, host firewall
8	Does anything mutate data on GET?	Move it to a Server Action or a POST handler
9	Are uploads going through the action body?	Signed direct-to-storage uploads
10	Does `npm audit` report Next.js advisories?	Update to the patched version

FAQ

Are Server Actions secure?

They're as secure as the code inside them. The transport is solid: POST only, an origin check and unguessable IDs. But authentication, authorisation, validation and rate limiting are always your responsibility, just as they would be in an Express route.

Should I use Server Actions or Route Handlers for mutations?

Use Server Actions for mutations that come from your own UI. Use Route Handlers when something outside your app needs to call you, like a webhook, a mobile app or a partner integration. I compare the options in detail in Next.js as a backend: Server Actions, Route Handlers or a separate Node.js API.

Do I need my own CSRF tokens?

Usually not. The built-in origin check plus SameSite cookies covers the common cases. You'd add tokens if you have to support very old browsers, or you've deliberately relaxed cookie or origin settings.

Want a security review of your Next.js app's actions and API routes? Get in touch.

Originally published on vishalsolanki.online.

PHP2Shell (CVE-2026-109618 and CVE-2026-109619): is your website affected, and how to fix it

Vishal Solanki — Tue, 27 Oct 2026 19:03:49 GMT

On 21 October 2026, the PHP project released emergency updates for two critical vulnerabilities, CVE-2026-109618 and CVE-2026-109619, now known as PHP2Shell. They let an attacker run commands on a web server with a single crafted request, without an account and without touching your site's own code.

If your website, shop or admin panel runs on PHP, and that includes most WordPress, WooCommerce, Laravel, Drupal and Magento sites, this is worth ten minutes of your time today.

Short version: update the PHP runtime that serves your site to 8.2.35, 8.3.36, 8.4.27 or 8.5.12 (or your vendor's patched package), then restart PHP. Updating WordPress or your plugins does not fix this. The widely shared session.upload_progress.enabled=0 setting is not a complete fix.

Last checked: 24 October 2026. This is a fast-moving story; follow PHP's official advisories for changes.

What PHP2Shell is, in plain words

Both flaws are in the PHP engine itself, not in WordPress, Laravel or any plugin. That's what makes them unusual: a site with perfectly secure code is still exposed, because the attack happens while PHP is still reading the incoming request, before your application runs at all. Security researchers have shown that even a one-line "Hello World" page on a vulnerable PHP version can be attacked.

CVE-2026-109618: when PHP runs out of memory partway through reading a form submission, it leaves half-built data behind, and its cleanup code later treats that data as valid. An attacker who shapes that leftover data can make the cleanup run a command.
CVE-2026-109619: a PHP worker can carry stale data from one request into the next. Researchers confirmed command execution through this route as well, including via the upload-progress feature, which is on by default.

Both are rated 9.2 out of 10 (CVSS v4.0). Researchers also showed that an attacker can read memory from a PHP worker, which can include other visitors' session tokens, passwords and API keys, even without running a command.

They were found by Wiz Research, Calif and OpenAI's Codex Security team. Details leaked a day before the planned disclosure, so PHP released the fixes early.

Is it being exploited?

Exploitation attempts started before the patches shipped. AWS reported attempts as early as 17 October, Cloudflare saw attack traffic and attackers changing their payloads to get past its firewall rules, and watchTowr reported active exploitation attempts against both flaws on 21 October. At the time of writing, public reports hadn't confirmed a specific successful break-in, but several organisations took services offline as a precaution.

Treat this as urgent, not theoretical.

Which sites are affected?

Any server where PHP answers web requests, in any of these setups:

How PHP runs	Affected?	Notes
Apache with `mod_php`	Yes, highest risk	A single request can trigger the attack before any of your code runs
PHP-FPM (Nginx, Apache, most VPS setups)	Yes	Confirmed command execution through the second flaw
php-cgi	Yes
FrankenPHP	Yes
LiteSpeed / LSAPI (common on shared hosting)	Yes
PHP only used on the command line, never serving web requests	Lower risk	Still update, but the web attack path doesn't apply

Affected versions go back to PHP 5.4. These are the first fixed releases:

PHP branch	Vulnerable	First fixed
8.5	below 8.5.12	8.5.12
8.4	below 8.4.27	8.4.27
8.3	below 8.3.36	8.3.36
8.2	below 8.2.35	8.2.35
8.1, 8.0, 7.4	all	No official release. PHP published source patches; check your host or distribution, or upgrade to 8.2+

PHP 8.2 itself reaches end of life on 31 December 2026, so if you're upgrading anyway, go to 8.3 or newer.

Not affected: sites with no PHP at all, such as a static site, or a Next.js or Node.js app. But if your Next.js front end talks to a PHP backend (for example headless WordPress), that backend server is affected.

How to check and fix it, by type of hosting

Shared hosting (cPanel, Hostinger, GoDaddy, Bluehost and similar)

You usually can't patch PHP yourself here. Your host does it.

Find your PHP version. In WordPress, go to Tools → Site Health → Info → Server. In cPanel, look for Select PHP Version or MultiPHP Manager.
Ask your host directly whether their PHP builds include the fixes for CVE-2026-109618 and CVE-2026-109619. Hosts often patch without changing the version number you see, so the version alone doesn't tell you.
If you're on PHP 7.4, 8.0 or 8.1, ask the host to move you to 8.3 or newer, and test your site afterwards. Older plugins sometimes need updating first.

A short message you can send:

Hi, my site [domain] runs on your PHP. Can you confirm the PHP version serving it includes the patches for CVE-2026-109618 and CVE-2026-109619 (PHP2Shell)? If not, when will it be patched?

WordPress, WooCommerce, Laravel and other PHP apps

Keep your app and plugins updated as always, but understand that this isn't an application bug. Updating WordPress, a plugin or Laravel does not update the PHP engine underneath. That comes from your host, your server's package manager or your container image.

VPS or dedicated server (Ubuntu, Debian, RHEL)

Check what actually serves your site. php -v on the command line can be a different build from the one PHP-FPM or Apache uses, so check the web runtime too (your control panel, or a temporary phpinfo() page that you delete straight after).
Update through your package manager and restart every PHP process:

# Debian / Ubuntu (package names vary, e.g. php8.3-fpm)
sudo apt update && sudo apt upgrade
sudo systemctl restart php8.3-fpm   # PHP-FPM
sudo systemctl restart apache2      # if you use mod_php

Distribution packages often carry the fix under an older-looking version number. Confirm the fix is in the package's changelog rather than trusting the version string:

apt changelog php8.3-fpm | grep -m1 CVE-2026-109618

Docker and Kubernetes

Rebuild your images on a patched PHP base image, redeploy, and make sure no old containers are still running. Also check images you didn't build yourself: some third-party apps bundle their own PHP.

If you can't patch today

PHP is clear that only updating fully fixes this. These steps reduce exposure while you arrange the update:

Put a firewall in front of PHP. Cloudflare switched on protective rules for its customers before disclosure, but it also saw attackers changing payloads to get around them, so treat this as a stopgap.
Limit request sizes at your web server or proxy, and keep post_max_size low.
PHP's temporary guidance for CVE-2026-109618 is to enforce memory_limit=-1 at the administrator level, together with request-size limits in front of PHP and a memory limit on the container.
For CVE-2026-109619: session.upload_progress.enabled=0, plus fatal_error_backtraces=0 on PHP 8.5, then restart every worker. This blocks the confirmed paths but not every variant, and does nothing for CVE-2026-109618.
Restrict access to anything that doesn't need to be public, such as admin panels, staging sites and internal tools.

Signs you might have been attacked

If your server ran an unpatched PHP version while exposed to the internet, look back through your logs for:

Unusually large form or multipart POST requests, followed by memory-limit errors or bursts of HTTP 500 responses.
Oddly large PHPSESSID cookies in responses.
PHP workers restarting without explanation.
Shell commands or processes started by your web server user (for example www-data).

If you see any of these, assume secrets in memory may have leaked: rotate database passwords, API keys and admin passwords, invalidate active sessions, and check for new admin users or modified files.

After you patch

The fix adds a new hard memory limit. Hitting it ends the process, so review memory_limit and post_max_size against what your site actually needs, and test uploads and large forms.
PHP has since published an advisory for a related issue, CVE-2026-115560, in the session upload progress feature, which affects even the patched releases. It's due to be fixed in PHP's next regular release. Watch PHP's advisories and update again when that's out.

Running Next.js? Different bug, same month

If your site is built with Next.js, PHP2Shell doesn't apply, but there's a separate security release to install. On 14 October 2026, Next.js fixed:

CVE-2026-96889, a critical remote code execution flaw in the Image Optimization API when SVG files are processed, through the sharp image library on Linux.
A second critical remote code execution flaw in use cache functions that return typed arrays (Next.js 16).
A high-severity denial-of-service issue affecting App Router apps that use Server Actions.

Upgrade to Next.js 16.4.1 or 15.5.28 or later, and make sure your lockfile resolves sharp to 0.35.5 or later. Running npm audit will flag both. More on hardening Server Actions in my security checklist.

FAQ

I updated WordPress and all my plugins. Am I safe?

Not from this. PHP2Shell is in the PHP engine, which your host or server provides. Check the PHP version and ask your host to confirm the patch.

Does a WordPress security plugin protect me?

A plugin runs inside your application, after PHP has already read the request. This attack happens before that point, so an in-app plugin can't block it. A firewall in front of the server can reduce the risk; only patching removes it.

My site is small. Would anyone really target it?

Attacks like this are automated: bots scan the whole internet for vulnerable servers, regardless of size. Security researchers estimate tens of millions of internet-facing PHP servers may be exposed.

How do I know the patch worked?

Confirm the version serving web requests (not just the command line) is a fixed release, or that your distribution's package changelog mentions both CVEs, and that every PHP process has been restarted since the update.

Sources

Not sure what your site runs on, or whether your host has patched it? I can check your setup, apply the fix or move you to a supported version. Get in touch.

Originally published on vishalsolanki.online.

Next.js SEO checklist for 2026: 12 fixes for the App Router

Vishal Solanki — Tue, 27 Oct 2026 19:03:36 GMT

Most Next.js sites that don't rank aren't missing a secret trick. They're missing basics the framework already gives you: a unique title per page, one canonical URL, a sitemap with honest dates, and content that's actually in the HTML.

This is the checklist I run on every App Router site, including this one. Each item comes with code you can copy.

Short version: set metadataBase, give every page its own title and description, pick one canonical host, generate sitemap.ts and robots.ts, add JSON-LD, keep one real H1 with real text, make sure your content is server-rendered, and set up Search Console and Bing.

1. Set `metadataBase` and a title template

In the root layout, tell Next.js your production URL once. Every relative URL in your metadata (canonicals, Open Graph images) is resolved against it.

// app/layout.tsx
import type { Metadata } from "next";

export const metadata: Metadata = {
  metadataBase: new URL("https://www.example.com"),
  title: { default: "Example — What you do, where you do it", template: "%s — Example" },
  description: "One or two sentences a searcher would actually click on.",
};

With the template, a page that sets title: "Pricing" shows up in search as "Pricing — Example", so your brand is on every result without repeating it by hand.

2. Give every page its own title and description

Duplicate titles are the most common problem I find in audits. For dynamic routes, use generateMetadata:

// app/blog/[slug]/page.tsx
export async function generateMetadata({ params }) {
  const post = await getPost((await params).slug);
  return {
    title: post.title,
    description: post.description,
    alternates: { canonical: `/blog/${post.slug}` },
  };
}

Keep titles around 50–60 characters with the main keyword near the start. Descriptions don't change rankings directly, but they decide whether people click, so write them like a small ad: who it's for, what they get, one proof point.

3. Pick one canonical host and redirect the rest

example.com, www.example.com, your *.vercel.app address and http:// are four copies of the same site as far as Google is concerned. Pick one, use it as metadataBase, add a canonical to every page (as above) and permanently redirect the others.

On Vercel, set the primary domain in the dashboard. For an old deployment address, a host-based redirect in next.config.ts does the job. This one sends an old Vercel URL, and everything it ranked for, to the real domain:

// next.config.ts
async redirects() {
  return [
    {
      source: "/:path*",
      has: [{ type: "host", value: "old-project.vercel.app" }],
      destination: "https://www.example.com/:path*",
      permanent: true,
    },
  ];
}

4. Generate the sitemap, with honest dates

// app/sitemap.ts
import type { MetadataRoute } from "next";

export default async function sitemap(): Promise {
  const posts = await getPosts();
  return [
    { url: "https://www.example.com", lastModified: "2026-10-24" },
    ...posts.map((p) => ({
      url: `https://www.example.com/blog/${p.slug}`,
      lastModified: p.updated ?? p.date,
    })),
  ];
}

Two details matter. Google ignores priority and changeFrequency, so don't spend time tuning them. It does use lastModified, but only while it stays accurate. If every URL shows the build date on every deploy, Google learns to ignore it. Change the date when the content changes, and only then.

5. Add `robots.ts`, and don't block what you want

// app/robots.ts
import type { MetadataRoute } from "next";

export default function robots(): MetadataRoute.Robots {
  return {
    rules: { userAgent: "*", allow: "/" },
    sitemap: "https://www.example.com/sitemap.xml",
  };
}

If you want to show up in ChatGPT search and Perplexity answers, keep their crawlers (OAI-SearchBot, PerplexityBot) allowed. Also check your hosting firewall or CDN: some bot-protection settings block AI crawlers even when robots.txt allows them. I go deeper on this in how to get cited by ChatGPT, Perplexity and Google AI Mode.

6. Describe the page with JSON-LD

Structured data tells search engines what a page is: a person, a business, an article, a product. Render it as a script tag from a server component:

const schema = {
  "@context": "https://schema.org",
  "@type": "BlogPosting",
  headline: post.title,
  datePublished: post.date,
  author: { "@type": "Person", name: "Your Name", url: "https://www.example.com" },
};

return (