The problem I kept seeing
I've spent years in SEO across enterprise teams and different niches. Then I became a full-stack developer.
And I kept running into the same issue:
The SEO-Dev gap.
In every company I worked for, SEO tasks were stuck in a backlog. Changing an H1, adding a FAQ block, or updating a phone number — these are 2-minute tasks that take 2 weeks because they need a developer.
I've been on both sides. I know why devs hate these tickets. And I know why SEOs get frustrated.
The enterprise solution?
In big companies, they build internal landing constructors. Custom tools where SEOs can build pages themselves — no designers, no frontend devs, no waiting.
But every company rebuilds the same thing from scratch. Expensive. Time-consuming. Only big players can afford it.
So I built an open-source alternative.
Introducing SEO Landing Constructor
A free, self-hosted landing page builder with SEO at its core.
Built with: Next.js 15 (App Router), Payload CMS 3, TypeScript, Tailwind CSS, shadcn/ui, PostgreSQL + Drizzle
MIT licensed. Deploy on your own infrastructure. No vendor lock-in.
What it does right now (MVP)
For SEOs & Marketers:
- Blocks-based builder — Hero, Pricing, FAQ, Testimonials, CTA, Features. Assemble pages in minutes.
- Visual Block Customization — adjust padding, margins, background, theme (dark/light) directly from admin panel.
- Global shortcodes — change price, phone, company name in ONE place. Updates across ALL pages instantly.
- Bulk JSON import — migrate entire page structures or generate pages via AI in seconds.
For Developers:
- SEO out of the box — SSR, metadata, sitemap, schema.org, Open Graph, optimized Core Web Vitals
-
overrides/blocks/system — customize any block without touching core code. Keep your design system. - Self-hosted — deploy on your domain, subdomain, or separate domain. Full control.
- Clean codebase — well-structured, TypeScript, modern stack
Architecture deep dive
Here's the high-level structure:
├── payload/blocks/ # Block schemas for admin panel
├── components/blocks/ # React components for frontend
├── components/overrides/ # Safe customization layer (!!)
├── payload/globals/ # Global settings & shortcodes
└── components/ui/ # shadcn/ui base components
The key design decision: the overrides/ folder.
Developers can override ANY block without modifying the core package. This means:
- You keep your design system intact
- You can add custom business logic
- You don't fight with the CMS when you need to customize something
- Upgrades don't break your customizations
Why this matters: Most open-source CMS tools force you to either accept the default UI or fork the entire project. This approach gives you the best of both worlds — a working system out of the box, with escape hatches when you need them.
What's coming (Roadmap)
In progress:
- Live Preview & Draft mode — see changes before publishing
Next:
- Advanced SEO blocks — Stats, Trust Bar, Comparison Table, Logos, Countdown, FAQ with schema
- Custom HTML Block
- Built-in form handling with server actions
- Page templates — reusable structures
- A/B testing for individual blocks
- Multi-language (i18n) support
Future:
- Reusable Widgets system
- AI-assisted content generation
- Analytics integration (GTM/GA4)
- CLI improvements
- Smart page templates with block inheritance
Where I need YOUR help
This is an MVP. There are bugs. The UI isn't perfect. And I'm not sure if I'm building the right thing.
So I have some open questions for the community:
Is this actually useful? — Would you (or your marketing team) use something like this? Or is the problem not painful enough?
What blocks are missing? — What landing page components do you constantly rebuild? What would make you switch from Webflow/Carrd/your current solution?
Devs — what would make this easier to adopt? — Better CLI? More documentation? Video tutorials? Docker setup?
SEOs — what's the #1 feature you wish existed? — I've built what I think you need, but I might be wrong.
How should I grow this? — Focus on more blocks? Better developer experience? Marketing site? Community?
Is the
overrides/approach actually useful? — Or should I make customization even simpler?
Try it. Break it. Tell me what sucks.
Live Demo: https://create-seo-landing.vercel.app/
Admin Panel: https://create-seo-landing.vercel.app/admin/
login: demo@demo.com
pass: Demopassword
GitHub Repo: https://github.com/AntonAmbarov/create-seo-landing
Quick start:
git clone https://github.com/AntonAmbarov/create-seo-landing.git
cd seo-landing-constructor
cp .env.example .env
pnpm install
pnpm dev
The bigger picture
I've seen this work in enterprise. Now I want to make it available for everyone — indie founders, small teams, agencies, and anyone tired of the SEO-Dev gap.
But I can't build this alone
I need feedback. I need people to break it. I need to know if I'm solving a real problem or just building something that seems cool.
So if you have 5 minutes:
Try the demo
Break something
Leave a comment telling me what you think
GitHub: https://github.com/AntonAmbarov/create-seo-landing
Open to: Contributors, feedback, feature requests, and brutal honesty.
Thanks for reading 🙌