How To Build A Website, Blog, or Portfolio with Next.js

The next time you’re tasked with building a website, blog, or portfolio of any size, it's tempting to reach for popular drag-and-drop WYSIWYG solutions like Webflow, SquareSpace, or Wix.

But it's hard to even type (or hear) those words because you are not a simple click-ops engineer. So while those platforms have a place in this world, they are certainly off the table for you.

Besides, your project may be much bigger than that, so you’re leaning toward (or instructed to use) trusty old WordPress. If you have ever worked in an agency or with clients, this probably cuts deep, and we empathize dearly.

A driving principle of Payload is that it is code-first by design. But this does not have to come at the expense of those on your team who are not engineers. You can build your biggest, baddest stack, then turn around and spoil them with the best admin editing experience of their lives—even the most complex site structures and menu systems are completely manageable.

To enable and accelerate your ambitions, we've introduced our official Website Template—a starter that puts together all the best practices, without the roadblocks.

This template is built in the same way we’d build a site for ourselves, making all the right decisions so you don’t have to. Have strong branding or your own UI library? Build on top of what’s already there instead of chipping away at some opinionated setup.

This template is right for you if you are building:

• A personal website that pushes the boundaries of the front-end, a portfolio that lands you your next job, or a blog that only you and your grandma will read
• A globally distributed, multilingual website that receives extremely heavy traffic and has very specific demands that require quick turnaround with high stakes for everyone involved (no pressure)
• A content publishing platform with complex, nested relationships, whose pages are grouped into sub-sites, related by taxonomy, and localized
• An agency or business website used to funnel users into customer leads, where there is real monetary value in this work and your metrics are being recorded

Everything you need is ready to go, including:

• Admin Dashboard
• Authentication
• Pages, Posts, Projects
• Layout Builder
• Draft Preview
• Forms
• Comments
• SSG, ISR, ODR
• Dark Mode
• Redirects
• Sitemap
• SEO
• And much more.

Quick Start

Option 1 (Recommended)

Head to Payload Cloud, clone the Website Template and deploy it on a free trial. This process may take a few minutes, and once it's done you'll have a fully working website, complete with a live domain. This will have created a new repo for you in your GitHub account. You can clone this repo down for local development, and when you push, your commits will automatically deploy.

Option 2

The code for this template is completely open source and can be found here.

To quickly clone this template, run the following command in your terminal:

npx create-payload-app my-project -t website

Then follow the instructions in the README to get started. You can always deploy this repo to Payload Cloud later.

Features

While each of the the use cases for this template might sound wildly different, each requires essentially the same base set of features.

Admin Dashboard

Unless you want to manage your site’s content entirely in code (there’s a time and place for this), your site needs a content management system. Site admins will need to log in and do this from an easy-to-use interface. It’s going to need to be beautifully designed and support some pretty advanced features.

If you have ever rolled your own admin interface on top of your own CRUD app, you know well how this is a bottomless pit of work. Significant features like versions, drafts, and translations are not as simple as you made them out to be in your pitch. The admin interface needs to be stable, secure, and intuitive. Ideally, it sits on top of the same headless API that your app will consume.

A good CMS should double as an ORM and never limit or restrict your access to data.

Layout Builder

Now that admins have an interface to make edits, they are free to build unique page layouts. Nearly every site, large or small, can think on their page layouts through the lens of a “hero” followed by “blocks”. While you may think this will lead to generic pages, this pattern is be masked quite easily through thoughtful design. Most (but not all) pages across the web could probably be broken up into this pattern, no matter how disguised it might feel.

• Heroes One highly successful pattern in page layout building is to categorize each hero into levels of visual impact. When a page is built, its hero is chosen based on the value of that page’s content as it relates to your overall user journey. A simple pattern of HighImpact, MediumImpact, and LowImpact is a great starting point for even large sites. A high impact hero might be placed on your home page, while a low impact hero probably belongs on an “about” page. Or, you might also turn the hero off completely on some pages. As one-off heroes are needed, they can be built and added into the design system. Heroes typically have additional controls too, like inverting orientation, or using an optional image, which together scales the number of unique heroes that can be created with the same underlying three or four types.

• Blocks Blocks are very similar to heroes in that they have varying degrees of content. The same block can be used multiple times while still appearing unique. Blocks also ensure that your unique pages follow consistent spacing rules. But if you have ever been in something like WP Bakery before, you know exactly how complete open-endedness can quickly lead to horrible design. Instead, your code should enforce that your design system is strictly followed so that your page looks beautiful no matter what changes are made.

There are a few common blocks that nearly every site needs: Content to create arbitrary rows and columns, Media to render images and videos in various ways, CallToAction to give the user a path forward through the funnel, and Archive to easily create landing pages or display related content.

• Header/Footer Global site content is just as simple to manage. Things like headers, footers, and other settings are handled just the same as everything else. Editors can adjust whole site navigation.

Draft Preview

As content is entered into your database, you may not want it all to be publicly available. Maybe you are writing about new, unreleased features, or you are updating an existing document in real-time. It’s important that you do not publish your content until the announcement has cleared and you have fully e2e tested every single one of your changes. Draft Preview is completely setup and ready to go, but if you maintain an existing site and you’re looking to add draft preview into it, it's easy. Check out the Draft Preview Example, there are isolated examples of both the App Router and Pages Router so you can clearly see how each works.

SSG

You’re finally publishing content and users are visiting your page to read your posts…but it’s slow. If your server is dynamically rendering the HTML on each request it will not only cost your users valuable wait time, it increases server computation (by a lot). Static Site Generation allows us to build the entire site once, as plain HTML and JavaScript, then serve simple files to the browser that do not require compilation when they are requested. This means that when users land on any given page, the server responds with precompiled, cached files, that feel nearly instantaneous to load. On top of this your APIs are hit way less often, saving on some serious CPU bandwidth. It’s now called something different in the App Router, but the principles are the same.

On-demand Revalidation

Now you save your changes, visit your site, and...your content is stale. This is because your statically generated site is serving a cached page that was built when you last deployed. Over time the number of posts you have written may have doubled, but only half of them were actually built. Next.js provides two good ways to get around this, starting with Incremental Static Regeneration. This simply rebuilds your site’s pages one-by-one after x number of seconds (or hours or days), in the background, without your users ever noticing. But this does not allow you to publish your documents at precisely the moment in time it was last saved, or on some future published date. This is where On-demand Revalidation comes in, allowing you to programmatically rebuild a single page at your discretion.

Payload Admin Bar

Payload has long been “putting the head back in headless”. By this we mean that the boundary between your site and the tooling that controls its content should be as narrow as possible. Now that you have a site rendering statically, and you’re drafting content, your editors will need a good way of navigation back and forth between your admin panel and your website. Remember WordPress’ admin bar? I bet your editors loved it, and rightfully so. Even though we’re using a headless CMS, we can still render the Payload Admin Bar to provide this same-level of functionality. And this is only the begining. We're soon rolling out Live Preview, then eventually Visual Editing.

Forms

One elephant in the room is forms. They can be incredibly tedious to build but they are often the lifeblood of your website. They might be used to gather information, handle contact requests, or even generate leads. Between field state, accessibility, error handling, styling, and everything in between, it’s no understatement to say that working with forms is a lot of work. On top of this, marketers will need a way to build dynamic forms on-the-fly, complete with field validation and custom email confirmations. Form submission data will need to be collected and saved to the database, and potentially even integrated into a CRM like HubSpot. This is something we talk about in depth using the official Form Builder Plugin to make it all happen. If you’re wondering how to implement the form builder into your existing site, here’s an isolated example so you can see how it all works.

SEO

Without a doubt site admins will need to make fine-grained adjustments to page metadata like title and description. They need need just as much control over page meta as they do with page content, able to control meta tags on-the-fly in order to achieve the Google ranking of their dreams. This in combination with a proper sitemaps and redirects provide great SEO power over your site. The next time you are tasked with swapping out an og:image, just send them to the field in your CMS that controls it (along with an optional lmgtfy). 🤪

Redirects

Whether you are migrating an entire site to a new codebase or simply updating an old post, at some point in time there is a big need for redirects. You may have migrated your app’s internal routing, or maybe you need to re-title your post and change its slug. In either case, search engines will need to be aware of these changes in real-time, otherwise your content may never be indexed, could get indexed twice, or even wrongly penalized. If your page URLs have changed in any way for any reason, and you care about their SEO value, they must properly redirected. We talk about this at length and maintain this Redirects Example if you are looking for an isolated example of this.

Sitemap

Sitemaps are one of those things that everyone needs but no-one actually wants to setup. Sitemaps are critical, though. They are responsible for outlining the structure of your site for the robots that crawl it (and even some humans…yes they exist). If you do not know what a sitemap is, it is an XML file (or many files), that simply list out all of your site’s public pages. Search engines find these sitemap files which they use to decipher the structure of your entire site at a glance. Pages are then indexed so that all important content is easily found.

Search

Many sites probably won’t require search at first, but once they reach a certain size, will inevitably need it. At some point, you’d probably want to reach for something like Algolia for this. Its fast CDN and vast library of components and APIs is hard to match. But for the vast majority of use cases, a simpler, first-party search does the job just fine. You don’t necessarily have to reach for third-party services and learn their integrations until there's a real need.

The official Payload Search Plugin has essentially no learning curve and scales extremely well. It saves a shallow, static copy of only the most essential fields of your posts in a separate, indexed collection within your database. Then, you can perform search directly on that collection just as you would another API. The only caveat here is that unlike Algolia, you’d have to build your own front-end components (for now...we're actively working on a library for this).

Live Preview (Coming soon)

Draft preview is nice and all, but this forces your editors to save drafts and navigate away to view them. We’re going to fix this. Right now we’re exploring Live Preview which will allow you to view changes to your site directly within Payload without ever hitting save. This require a significant overhaul to our admin panel UI, but this work is going to set us up for some significant improvements to the editing experience within Payload. We’re cookin’ up some big things over here.

E-commerce

Okay so our website is now up and running like a well-oiled machine, but you are now tasked with selling something to the crowds of users who are now flooding your site. The good news is that this does not have to be a huge lift. You can easily transform your site into an e-commerce powerhouse, something we’ve written about extensively.

Get Started

Use this template to enjoy building anything from your next microsite to a global powerhouse. Deploy in minutes on Payload Cloud or clone it from GitHub. Or, run npx create-payload-app. Happy building.