Next.js development
The framework is a means. Being found is the point.
App RouterTypeScript throughoutCode handed over
- Built
- Crawled
- Cited
The honest version
A framework does not rank you. It stops you being your own obstacle.
- The HTML is in the first response
- The page arrives as a finished document rather than as a blank shell that JavaScript fills in afterwards. Nothing depends on a crawler choosing to execute your scripts, and a slow phone sees content immediately.
- The technical layer is generated
- Metadata, canonicals, sitemaps and structured data come from your content at build time. The single most common SEO failure is a page shipped with the previous page's title, and that becomes impossible.
- Performance is the starting point
- Code splitting, image handling and font loading are decisions the framework has already made well. Core Web Vitals stop being a remediation project.
- It scales down as well as up
- A five-page site exported to static files costs nothing to host and cannot fall over. The same codebase grows a server the day you need one.
When we will tell you not to
If what you need is a blog your marketing team updates daily and nothing more, WordPress is a perfectly good answer and we will say so. If your site is already fast, already ranks and already converts, a rebuild is not the thing to spend money on — the content and the links are.
Selling someone a rebuild they do not need is a bad way to start a relationship, and it is the most common thing that happens in this part of the market.
connect@myfloww.in
Rendering strategy
Four ways to render a page, and how we pick.
- Static export (SSG)
- Every page generated at build time and served as a plain file. Nothing runs at request time, so nothing can be slow under load and there is no server to patch. Right for marketing sites, brochure sites, documentation and answer libraries where every visitor sees the same thing.
- Server rendering (SSR)
- The page is built per request on a Node server. Right when the content genuinely differs per visitor — a logged-in dashboard, a live search over your own inventory, personalised pricing. It costs you a server and a cold-start budget, so it should be a decision rather than a default.
- Incremental regeneration (ISR)
- Static pages that rebuild themselves on a schedule or on demand. Right for catalogues and listings that change often but not per visitor — a few thousand product pages that must stay current without a full rebuild every time a price moves.
- Client rendering, deliberately
- The parts that genuinely need to run in the browser — a map, an editor, a chart that responds to a control — isolated to their own components so they cannot drag the rest of the page's performance down with them.
The useful property of Next.js is that these are not separate codebases. A project can start statically exported and grow a server later without a rewrite, and a single application can use all four at once — one route per strategy, chosen per route.
SEO engineering
What we actually do to a build for search.
- Metadata generated from content
- Titles, descriptions, canonical URLs, Open Graph and Twitter cards produced by one helper reading your content, with length rules enforced at build time. A page cannot ship with a truncated title because nobody can type one.
- Structured data from the same source
- Organization, WebSite, Service, FAQPage, BreadcrumbList and Article nodes generated from the data the page renders — so the markup cannot drift away from what a reader sees, which is both the ranking requirement and the honest thing to do.
- A sitemap that cannot go stale
- Generated from the route table rather than maintained by hand, so a new page cannot be added to the navigation and forgotten by the sitemap.
- Core Web Vitals engineered, not chased
- Fonts self-hosted and subset, the largest paint preloaded, explicit dimensions on every image so nothing shifts, and no third-party render-blocking requests in the document at all.
- llms.txt for the answer engines
- A plain-text summary written for AI crawlers, stating what the company is and what it sells in the same words as the pages. If a model is going to summarise you, write the summary yourself.
- Real HTML structures
- Prices in a table, processes in an ordered list, definitions in a definition list. Assistive technology can navigate them and an AI system can extract them — a grid of styled divs offers neither.
Migration
Moving an existing site without losing what it has earned.
01 · Before anything moves
Inventory what exists
Every current URL, what it ranks for, what links to it and what traffic it gets. You cannot protect what you have not written down.
02 · Planning
Map every URL
The new structure decided against the old one, with a 301 for every address that has to move and a deliberate decision for every page that should not exist any more.
03 · The build
Rebuild and carry the signals
Content, metadata, structured data and internal linking carried across rather than recreated from memory — with the chance to fix what was wrong the first time.
04 · Weeks after
Launch and watch
Search Console monitored through the reindexing period, so a redirect that was missed is found in days rather than discovered in a quarterly report.
Questions
About Next.js, honestly.
Why Next.js rather than WordPress?
Next.js renders your pages ahead of time into plain HTML files, so there is no database query, no theme and no plugin stack between a visitor and your content — which is why it is faster and why there is far less of it to keep patched.
WordPress is a genuinely good answer when a non-technical team needs to publish constantly and the site is mostly articles. It is a poor answer when performance, custom functionality or security maintenance matter more than a familiar admin screen, because the speed problems it creates are usually plugin problems and cannot be fixed from inside the admin screen.
We will say so if WordPress is the better fit for what you are doing. Selling you a rebuild you do not need is a bad way to start.
Is a Next.js site actually better for SEO?
Next.js does not rank you on its own — no framework does — but it removes most of the technical reasons a site fails to rank, and it makes the rest cheap to get right.
Concretely: the full HTML is in the first response rather than assembled by JavaScript afterwards, so there is nothing for a crawler to miss. Metadata, canonical tags, sitemaps and structured data are generated from your content at build time rather than typed in per page, so they cannot be forgotten. And the performance the Core Web Vitals measure is the default rather than something chased afterwards.
What still decides rankings is the content, the internal linking and the authority of the domain. The framework decides whether the technical layer is helping or quietly in the way.
Static export or a Node server — which do I need?
Static export if the pages are the same for everyone, and a Node server if they are not — a logged-in area, a live search over your own data, personalised content, or anything that has to change between builds.
Static is the cheaper, faster and more robust of the two: the whole site is files on a disk, so there is nothing at request time that can be slow or fall over. This site is statically exported for exactly that reason.
The useful thing about Next.js is that it is the same codebase either way. Starting static and adding a server later does not mean rebuilding.
Can you rebuild my existing site in Next.js without losing rankings?
Yes, provided the migration keeps the URLs, the content and the internal linking intact — a rebuild loses rankings when those change, not because the framework changed.
The work that protects rankings is unglamorous: a full inventory of the current URLs and what they rank for, a 301 for every URL that has to move, the metadata and structured data carried across, and monitoring in Search Console for the weeks after launch. We do that as part of the project rather than as an upsell.
Which version of Next.js do you build on?
We build on the current stable release of Next.js using the App Router, React Server Components and TypeScript throughout.
This site is built the same way, so the answer is checkable rather than a claim: the whole of it is in this repository's dependency list, and every page you are reading was generated at build time.
Will my team be able to update the site?
Yes. Content that changes often is separated from the code, so editing a price, a service or an article does not require a developer.
How that is set up depends on the project — a headless CMS where a non-technical team publishes daily, or plain content files in the repository where the site changes a few times a year and a CMS would be overhead nobody wanted.
Wondering whether your project needs any of this? Send us the URL and we will tell you what we would actually change — including when the answer is nothing structural.
Where to next
- The website service in full
The commercial version of this page: what a project includes, how it runs and what it costs.
- SEO and GEO management
The build gets the technical layer right; this is the work that continues after launch.
- Everything MyFloww builds
Apps, custom software, AI agents and WhatsApp automation, all on one page.
Send us the site, or the idea.
Whether it is a rebuild, a migration or something that does not exist yet, the first useful step is a look at what you have. We will tell you what is worth doing before anyone signs anything.
Or message us on WhatsApp · connect@myfloww.in