How to create a Nuxt project (and what to do next)

Prerequisites

Install a current Node.js LTS (even major version). Nuxt 3 expects a reasonably modern Node; if your global install is years old, upgrade first — it saves opaque build errors later.

Package manager is up to you. I often use pnpm via Corepack (corepack enable) for faster installs; npm and yarn work fine with Nuxt.

Create the project

From a terminal, in the folder where you keep projects, run Nuxt’s CLI initializer. The package name is nuxi:

npx nuxi@latest init my-app
cd my-app

Replace my-app with your folder name. The wizard will ask for TypeScript, ESLint, modules, and other defaults — for learning and for most sites I ship, I enable TypeScript and a linter; the rest you can accept and refine once the app runs.

Install dependencies and start the dev server:

npm install
npm run dev

Open the URL the CLI prints (usually http://localhost:3000). You should see Nuxt’s welcome screen. If the port is busy, Nuxt will suggest another.

Folders that matter on day one

Typical Nuxt 3 layout (names may vary slightly with your template):

• nuxt.config.ts — app config: modules, runtime config, Nitro, build hooks. This is where much of the “framework” behaviour is declared.
• app.vue — root component. Often wraps layout slots and <NuxtPage /> for page output.
• pages/ — file-based routes. pages/about.vue → /about. Dynamic routes use bracket folders, e.g. pages/blog/[slug].vue.
• components/ — auto-imported Vue components (no manual registration for standard use).
• composables/ — auto-imported composables such as shared logic for data fetching or UI state.
• public/ — static files served as-is at the site root (favicons, robots.txt, images that must keep exact URLs).
• server/ — API routes and server middleware (Nitro). Handy for contact forms, webhooks, or proxying without a separate backend repo.

Newer Nuxt versions may offer an app/ directory for some of this — the docs stay the source of truth. Conceptually: pages define URLs, components compose UI, server handles HTTP you don’t want in the browser.

Add a page and a link

Create pages/hello.vue with a minimal template. Save, and the dev server should hot-reload. Visit /hello — that’s file-based routing doing its job.

Use <NuxtLink to="/hello"> from another page for client-side navigation (prefetching and no full reload in the SPA sense). For external URLs, a normal <a href="..."> is appropriate.

Titles, meta, and “real” SEO

Per-route SEO in Nuxt usually means useSeoMeta, useHead, or a small composable that sets title and description from page data. The important part is one canonical intent per URL — not stuffing keywords into a single component. I go deeper on structure and internal linking in the SEO & content architecture write-up on this site.

Build and deploy

A production build compiles client and server bundles (Nitro). Locally:

npm run build
node .output/server/index.mjs

The exact run command depends on your Nitro preset (Node server, static, serverless target, etc.). For a traditional VPS or Node host, the Node preset is common. For static hosting, nuxt generate (or preset-driven prerendering) outputs files you can drop on a CDN. Pick the preset to match where the site will live — that choice matters more than which CSS framework you used on day one.

Summary

• nuxi init → install → npm run dev.
• Learn pages/, components/, nuxt.config.ts, and server/ before optimising.
• Ship SEO as structure + accurate metadata, not as a bolt-on string in one layout file.
• Align build preset with your host — it’s part of the architecture.

If you’re a business in Grimsby or NEL and want this kind of stack for a real site, get in touch — I’m happy to be specific about scope and trade-offs.