Getting a site on Steeren: build, migrate, or integrate
Steeren sits behind your website. You write posts in Steeren, your site shows them to visitors, and the lead-capture forms, page views, and call-to-action clicks all flow back to you. But a visitor still lands on a real website, and that website has to live somewhere. There are three ways to get one connected to Steeren, depending on what you're starting with:
- Build - you have nothing yet (or close to it), and want a site created for you from scratch.
- Migrate - you already have a live site somewhere (WordPress, Webflow, Squarespace, something hand-built), and want to move it onto Steeren without losing content or your search rankings.
- Integrate - you already have your own website built in Next.js, and want to add the Steeren-managed pieces (blog, lead capture, analytics) to it rather than replace it.
This article is about choosing between the three and knowing what each one actually gives you.
[!NOTE] Build and migrate both produce the same kind of result: a brand-new website that Steeren hosts and keeps deployed for you. Integrate keeps your existing site and codebase - you only add the Steeren pieces to it.
What all three routes share
No matter which route you take, your site connects to Steeren the same way. Understanding what that connection does makes the trade-offs easier to weigh.
- Your blog renders content; you write it in Steeren. The blog index and each post page pull from Steeren and display your posts. You author and edit everything in Steeren - the site is just the window your readers look through.
- Lead capture and analytics come built in. Page views, call-to-action clicks, and the inline forms inside your posts all report back to Steeren automatically, so you can see what's working without bolting on a separate analytics tool.
- Gated content works out of the box. You can lock any post behind an email form (for lead magnets or members-only content). Visitors see the opening of the post and a form; once they sign up, the rest unlocks. This works the same across all three routes.
[!TIP] If you're hands-on with code, one detail matters: render post bodies with Steeren's official renderer, not your own Markdown parser. Posts can contain interactive pieces - trackable buttons, inline sign-up forms - that only come alive through the official renderer. A do-it-yourself renderer turns them into dead text: no clicks counted, no sign-ups captured.
The takeaway: the Steeren connection is identical in all three cases. What differs is where the rest of your site comes from - created for you, brought over from your old site, or already yours.
Route 1: Build from scratch
Pick this when you're starting cold - a brand-new business, or an existing one whose current site isn't worth keeping. Steeren researches your business, sets up the site, and hands you something you can publish to.
What it does
- Researches your business. It reads through your existing web presence, finds a handful of likely competitors, works out who your customers are, and pulls together what makes you different. You then get to correct anything it got wrong - this step isn't optional, and it's where the rough edges get fixed.
- Sets up your Steeren workspace from what it learned. This is the part that makes building from scratch worthwhile: the brand details, your differentiators, your target customers, and your competitors all get saved into Steeren. That means everything else you do later - blog posts, campaigns, social, email - starts from the same picture of your business, not a blank slate.
- Optionally drafts a few starter posts (around three to five) so your blog doesn't launch as an empty page. These land as drafts for you to review, edit, and publish.
- Creates and hosts the site. Steeren generates the website, wires up the blog and lead capture, and takes over hosting and deployment from there.
When it fits
- A brand-new business with no website, or a thin one that isn't worth bringing over.
- You want the rest of Steeren - campaigns, social, email - to understand your brand from day one, not just your website.
Trade-offs
| Time | Roughly 15-25 minutes, most of it research and setup. The site itself comes together quickly. |
| Content | Created for you. Starter posts are drafted from the research - realistic, but you review and edit each one before it goes live. Capped at five, so you're reviewing a few good drafts, not drowning in them. |
| Honesty | The research is fast but imperfect, which is exactly why the correction step exists. It won't invent testimonials or make up statistics - gaps are flagged for you to fill rather than papered over. |
Route 2: Migrate an existing site
Pick this when your content already lives on the public web and the job is to bring it across - not to start over. The goal is a platform switch, not a redesign: your content and your search rankings come with you.
What it does
- Reads your existing site. It works through your current pages and gathers your posts.
- Sorts the pages for you - blog posts, marketing pages, about, legal, and so on - and shows you the breakdown so you can adjust what gets brought over before anything is imported.
- Brings your blog posts into Steeren in your own words, keeping your existing post addresses (URLs) by default, which is better for search. You can choose to clean them up instead if you'd rather.
- Carries your brand across - your logo, colors, and fonts - so the rebuilt site looks like you, not a generic template.
- Builds and hosts the new site, with your imported posts already in place.
- Sets up redirects so every old web address sends visitors (and search engines) to its new home, and checks that they work after launch.
Preserving your search rankings
This is the heart of a migration, and the part worth getting right:
- Your posts come over as written. They're your words and your voice, so they're imported, not rewritten. Rewriting an entire back catalogue would lose both your voice and the search history you've built up - so it isn't done.
- Redirects are the most important step. Without them, every inbound link to an old post address would hit a dead page on the new site, and you could lose a real chunk of your search traffic on launch day. Setting up permanent redirects tells search engines to follow your content to its new home while old bookmarks still work.
[!NOTE] Imported posts start as drafts, so a freshly migrated blog will show "no articles" until they're published - that's expected, and the migration publishes them for you as it goes.
When it fits
- You have real existing content and search rankings you can't afford to drop.
- You're switching platforms, not redesigning - your brand should carry over exactly.
Trade-offs
| Time | Roughly 30-60 minutes, most of it reading and importing your old site rather than generating anything. |
| Content | Brought over as written. Light tidying (fixing links, cleaning up formatting) is fine; rewriting isn't. |
| Scale | Sensible by default for a normal-sized blog. A massive archive (thousands of posts) takes much longer and is worth scoping deliberately rather than importing wholesale. |
| Rough edges | Some images may still point at your old host unless you ask to bring them across too. Unusual one-off page layouts can come over a little messy. Legal pages often reference tools your old site used that the new one doesn't, so they're worth a quick review. |
[!TIP] Three quick decisions shape the whole migration, so settle them up front: import everything or cap it at a number; keep your existing post addresses or generate fresh ones (keeping them is usually right for search); and any pages or sections to skip entirely (old campaign landing pages, for example).
Route 3: Integrate into your own app
The first two routes hand you a whole new website. Integrate is for when you already have your own - your own codebase, your own design, your own repository - built in Next.js, and you only want to add the Steeren-managed pieces to it.
This is the developer route. There's no guided automation here; you wire it up by hand against Steeren's published integration contract. What you're adding is, concretely:
- A connection to Steeren that your app uses to fetch posts and report analytics.
- Two blog pages - a list of your posts and an individual post page - styled however you like, but reading their content from Steeren and rendering it with the official renderer.
- Search Console verification so your site can be verified with Google and start submitting its sitemap.
- Connecting your repository to Steeren so it can host and deploy the result.
The official packages you'll use are @nukipa/site-sdk to talk to Steeren, and @nukipa/post-renderer-react (or @nukipa/post-renderer-vue) to render post bodies. Detailed wiring steps live in the developer integration guide.
[!TIP] Render post bodies through the official renderer rather than your own Markdown parser. Posts can include trackable buttons and inline forms that only work through it - a custom renderer silently turns them into plain, dead text.
What you get vs. what you give up
Integrate keeps your app exactly as it is - but you take on keeping the Steeren pieces wired correctly. The build and migrate routes ship a pre-wired, hosted site and keep that plumbing healthy for you. On the integrate route, that's yours to maintain: a future refactor that swaps out the official renderer or rewires how your pages fetch content can quietly break a Steeren feature, so it's worth treating those touchpoints as fixed.
When it fits
- You have an existing Next.js app you're committed to and don't want regenerated.
- You want Steeren's blog, lead capture, and analytics inside your design and routing, not a fresh template.
- You're comfortable owning the integration rather than leaning on a hosted, pre-wired starter.
When it doesn't
- Your app isn't built with Next.js (App Router). The integration assumes that setup; other frameworks would mean rebuilding the glue by hand and are off the supported path for now.
- You don't actually have a site worth keeping - in that case build or migrate is less work, not more.
Choosing
| Question | Build | Migrate | Integrate |
|---|---|---|---|
| Do you already have a site? | No / negligible | Yes, live on the web | Yes - your own Next.js app |
| Where does content come from? | Created for you (+ optional starter posts) | Brought over as written | Wherever it already lives + Steeren |
| Result | A new, hosted site | A new, hosted site | Your existing site, connected |
| Search-ranking continuity? | Not applicable (no old URLs) | Yes - redirects are the point | You own your URLs and redirects |
| Who maintains the Steeren wiring? | Steeren | Steeren | You |
| Rough time | ~15-25 min | ~30-60 min | Depends on your app |
A quick way to decide:
- Already have a Next.js app you want to keep? -> Integrate.
- Have a live site (any platform) with content and rankings to preserve? -> Migrate.
- Starting cold, or your current site isn't worth keeping? -> Build from scratch.
[!NOTE] If your Steeren workspace is already set up - your brand details in place and content already written - you can skip straight to generating the site without the research (build) or the import (migrate). This article is about the three ways to get there in the first place.
FAQ
Can I switch routes partway through? Build and migrate are separate flows, so you pick one at the start. But they both produce the same kind of hosted site, and either one can later be edited by hand exactly like an integrated app. Nothing locks you in.
Will build or migrate overwrite my existing files? No. The result is a fresh website that Steeren hosts and deploys. Re-running build or migrate is safe - it won't duplicate your brand details or content in Steeren.
I migrated but my blog still says "no articles." Why? Imported posts arrive as drafts, and drafts don't show publicly until they're published. The migration publishes them for you as it goes; if you imported anything by hand, publish those yourself.
Why is my Google Search Console verification stuck on "pending"? Almost always because the verification tag isn't being served on your site yet, or your custom domain isn't resolving to the right place. On the integrate route this is yours to wire up; on build and migrate it's handled for you. The developer integration guide covers the details.
Can I integrate into something other than Next.js? Not on the supported path today. The integration assumes Next.js (App Router). Other frameworks would mean rebuilding the connection and renderer glue by hand - Next.js is the one wired route for now.