How to guides

How to create an author website that actually sells books

Learn how to create an author website with practical steps on setup, costs, marketing, and monetization. See how Scrile can help you launch a branded product.

Author website planning concept with a writer in a bright home studio and a clean book-focused website on screen

Author website planning concept with a writer in a bright home studio and a clean book-focused website on screen

Quick answer

If your plan is “buy a domain and add a bio,” you are probably building a rebuild later. The fastest way to create an author website is to choose the site model first, decide which pages are mandatory, and then pick the platform and launch order that fit your publishing goals. That gives you a lean presence site, a reader-growth site, or a direct-sales-ready site without overbuilding on day one. If you only need a placeholder for now, keep it simple. If you want a site that can support book marketing, email capture, and future monetization, start with the structure below.

Most author-site advice starts in the wrong place. It jumps to colors, templates, or platform names before the writer has decided what the site must do. That is how authors end up with a polished homepage that does not help anyone find a book, join a list, contact the author, or buy anything. A site can look finished and still fail at the only job that matters.

The first decision is not design. It is scope. Ask a harder question: What should this site do in the next 12 months? A debut novelist who needs a public face does not need the same structure as a self-published nonfiction author who plans to sell direct. Jane Friedman’s long-term lens on platform choice is useful precisely because it starts with durability, cost, and control, while IngramSpark’s author-website guide pushes the same principle from the content side: purpose first, pages second.

Think of the site as a reader path, not a pile of pages. A person should land, understand who you are, see the books, and know the next step without digging. When that path is clear, the site can support search traffic, media inquiries, newsletter signups, and sales later. When it is not, the site becomes a dead end that costs time to maintain and does not move readers anywhere.

The scope mistake is easy to miss because it feels productive at first. A writer spends weeks tweaking the homepage, adds a few generic tabs, and delays the parts that actually matter. Three months later the site is live, but the books are hidden, the contact form is awkward, and the newsletter has no place to live. That is not a website problem; it is a planning problem.

If you are building the broader book-marketing system next, the companion guide on how to sell a book online shows how the site turns into traffic and conversion. For the publishing side that often feeds the site later, where can I post my writing is the useful follow-up.

Choose the right author website model

Not every author website should try to do everything. The right launch is the one that matches the actual job of the site. Some writers only need a public home page. Others need email growth. A smaller group needs a site that can sell directly without sending every reader to a third-party store.

Presence-only site

This is the leanest version: homepage, bio, book list, contact page, and maybe a press page. It works for authors who need legitimacy, a stable public URL, and a place to send editors, event hosts, or podcast producers. The upside is speed. You can launch without a long build cycle or a pile of maintenance tasks.

The downside is just as clear: a presence-only site rarely creates repeat visits by itself. If readers come once and leave, the site is doing visibility work but very little marketing work. That is fine for a new author who mainly needs a public footprint. It is not enough for someone who wants the website to become a growth asset.

Reader-growth site

This version adds book pages, a newsletter signup, and sometimes a short blog or resource page. It fits writers who want repeat visits and a direct line to readers. This is usually the point where the site stops acting like a static profile and starts behaving like a marketing tool.

The hidden cost is maintenance. Once you promise fresh content, readers expect rhythm. If you can only update once a quarter, do not fake a weekly blog schedule. A thin blog with two posts looks unfinished, not active. Better to publish less often and keep the site clean than to force a content treadmill you cannot sustain.

Direct-sales-ready site

This model is for authors who want the site to do more than refer readers to Amazon or another retailer. It needs product pages, clear purchase paths, tracking, and a checkout strategy that does not confuse the buyer. That is where many standard author-site templates run out of room.

Direct sales can be powerful, but they change the tool choice. A site that can only host pages is not enough if the goal is to own the audience and the sale path. Some creators use a system like Scrile Connect or another owned platform stack when direct monetization matters more than a simple brochure site.

Website domain planning for an author website with a laptop and clean branding setup
Site model Best for Breaks when Typical complexity
Presence-only New authors, event visibility, credibility You need email growth or direct sales Low
Reader-growth Authors building audience and repeat visits You cannot update content regularly Medium
Direct-sales-ready Authors selling books or memberships from the site You only need a simple public profile Medium to high

Minimum viable author website: what belongs on day one

Minimum viable does not mean thin. It means nothing on the site should exist only because other author sites have it. If a page does not help a reader decide, trust, contact, or buy, it is probably optional. That is the easiest way to keep the build small without making the site useless.

Page Status Purpose Owner
Home Mandatory Show who you are and where to go next Author
About / Bio Mandatory Build trust and context Author
Books Mandatory Let readers find every title quickly Author or assistant
Contact Mandatory Support readers, media, and event requests Author or assistant
Newsletter signup Strongly recommended Capture returning readers Author
Media kit Optional early Help journalists and hosts use the right assets Author or publicist
Blog or updates Optional Support search and repeat visits Author
Store or direct-sale pages Optional until needed Sell directly from the site Author or developer

The most common launch failure is not missing pages. It is missing structure. A reader should be able to reach the books in one click from the home page, the bio in one click from the home page, and contact in one click from anywhere. If someone needs four clicks to reach a book page, the site is already leaking attention.

In practice, the books area has to do more than list titles. Each book needs enough space to stand on its own when a reader searches, shares, or lands directly on that title. A single list page is fine as an index, but it is not enough if you want search visibility or if you plan to send people to one specific book. That is why individual book pages matter: they keep the title easy to find and easy to share instead of burying it inside a long catalog.

It also helps to treat the book page as a decision page, not a decorative page. Show the title, subtitle, cover, format, short description, and the next step. If the reader has to hunt for where to buy or what the book is about, you have already lost some of the traffic you paid to attract. That is a practical loss, not a cosmetic one.

For authors who want stronger ownership later, the same minimum structure becomes the base for more advanced pages. The site can start as a simple reader hub and later grow into a sales layer, a membership layer, or both. That is much easier than trying to bolt those pieces onto a homepage that was never planned for them.

How to choose platform, domain, and hosting

This is where many guides get generic fast. The real question is not “Which platform is best?” It is “Which platform can handle the amount of control, upkeep, and future change you are willing to live with?” A beginner who wants almost no maintenance has different needs from an author who may later move into ecommerce or custom content.

Selection criteria that matter

Three filters matter more than design demos: cost, ease of use, and portability. Cost is the obvious one. Ease of use determines whether the site actually gets updated after launch. Portability is the hidden one, and it matters because no one wants to rebuild a site two years later when the platform or theme turns into a dead end.

That is why WordPress keeps showing up in long-term guidance. It is still the default open ecosystem for many sites, and Jane Friedman has argued for years that open-source options reduce lock-in. Squarespace, Ghost, Wix, and Weebly each solve a different problem, but they do not protect the future in the same way. If your only goal is a straightforward public site, you do not need the heaviest stack. If your goal includes direct sales, subscriptions, or a more controlled reader experience, the platform choice changes.

Domain choice is part of the same decision. The safest domain is usually the author name, because the name can span every book, series, and format you publish later. If you can, secure the cleanest version of your name early. Changing the domain later is possible, but it is one of the easiest ways to create extra redirects, broken links, and SEO cleanup work.

If your site may later carry monetization, choose the platform with that future in mind. A simple brochure site can live on a lightweight builder. A site that needs owned payments, gated content, or a more controlled sales flow needs more than a visual template. That is one reason some creators compare systems like Scrile Connect against pieced-together stacks when the website is supposed to become a revenue surface, not just a public profile.

Lock-in and longevity risks

The easiest systems are not always the safest systems. Proprietary builders can be fast to launch, but they can also make migration harder when the site grows. Open-source systems usually ask for more learning up front, yet they often give you a better exit if you outgrow them.

Platform lock-in does not feel expensive at first. It feels cheap. The bill shows up later when URLs change, templates do not transfer cleanly, or content is hard to export without damage. That is why the “cheap now” choice can become the most expensive one by year two.

For a clear public reference on how authors think about these trade-offs, Jane Friedman’s author website guide is still one of the most useful sources. It is not valuable because it lists the most tools. It is valuable because it treats longevity as a selection criterion, not an afterthought.

Prepare the assets before you build

Do not start with fonts. Start with the material the site needs to function. A build moves quickly when the raw assets already exist, and it stalls when someone has to write copy while the designer waits for missing photos, bios, or book details.

What to gather first

You need a third-person bio, a shorter bio for the home page, author photos, book covers, blurbs, retailer links, and one clean contact email. If you have more than one book, collect the title, subtitle, series number, publication date, format, ISBN, and short description for each title before the build begins. That prevents launch delays and keeps the pages consistent.

If you expect press coverage, add a small media folder with downloadable images and a short press note. It does not need to be fancy. It just needs to exist when a journalist, host, or event organizer asks for it. A missing asset at this stage often creates the second round of revisions that nobody planned for.

Why the asset list matters

Each missing item slows the launch in a different way. Missing photos delay the About page. Missing book data delays the catalog. Missing links delay the sales path. Missing a contact form means the site looks live but does not actually open a conversation. These are small gaps individually, but together they turn a one-week build into a month of back-and-forth.

That is also why the site should not wait for a perfect content strategy. You do not need a full blog calendar to launch a functional author website. You do need the basics that let a reader understand who you are, what you wrote, and what to do next. Everything else can come later.

Launch the site in the right order

The fastest builds are the ones that follow a sequence. When the order is wrong, the site looks busy but stays incomplete. When the order is right, the author can launch early and improve the site without redoing the foundation.

Build the minimum structure first

Start with the home page, bio page, books page, contact page, and newsletter form. Then connect navigation so the route to each page is obvious. A reader should never have to guess where the books live or whether the site is current.

Keep the menu small. Five to seven top-level items are usually enough. Once the menu starts behaving like a filing cabinet, the site becomes harder to scan and more annoying to use on mobile.

Verify before publishing

Before launch, test the site on mobile, confirm every button works, and check that contact forms actually deliver mail. Also check the book pages for broken retailer links. One broken link is not a technical detail; it is a lost sale or a lost inquiry.

Teams that skip this step usually discover the problems through readers, which is the worst possible testing method. A 20-minute prelaunch check can save hours of cleanup later, and it prevents the “the site is live but nothing works” message that authors hate hearing after they announce the launch.

If you want the deeper content-side sequence after launch, the next step is usually to shape the book-specific pages and search paths. That is where how to make an author website becomes the more practical follow-up for the cluster.

What changes the cost most

Cost is driven less by “having a website” and more by how much the site needs to do. A simple profile site can stay relatively cheap. The moment you want custom pages, ecommerce, integrations, or handoff between content and sales, the budget starts moving.

At the low end, an author may pay only for a domain and a basic builder plan. That can stay in the rough range of $50 to $200 per year if the site is simple and you do most of the work yourself. A more serious custom build can climb into the low thousands once design, copy, and migration are included. If you add direct sales, payment processing, or a more branded owned platform, budget for setup and ongoing maintenance separately.

The cheapest path is not always the cheapest outcome. A site that needs a rebuild six months later is usually more expensive than the one that cost a little more up front and stayed stable. In practice, the main cost trigger is not the homepage; it is the first extra requirement that the original platform cannot support cleanly.

That trigger is easy to recognize. If you already know you will need a store, gated content, or subscriptions, the platform should be chosen for that future now, not patched later. A system that bundles audience management, payments, and content delivery can reduce the number of moving parts. That is one reason creators compare systems like Scrile Connect against pieced-together tools when the site is expected to produce revenue rather than just visibility.

IngramSpark’s guide on what to put on an author website is helpful here because it reminds you that scope is the hidden cost driver. More pages mean more content to write and maintain. More features mean more things to test and repair. That is why “small and usable” is often a better launch target than “fully packed.”

Mistakes that force a rebuild

Three mistakes show up again and again. The first is choosing a domain that centers the book instead of the author. The second is using a platform that cannot grow with the site. The third is building pages that look complete but do not move readers anywhere.

A bad domain is annoying. A bad domain plus a bad platform is expensive. Changing both later means redirects, SEO cleanup, design work, and often a content migration. Even a small site can burn 10 to 30 hours in that process, and a site with multiple books or an active archive can take longer.

Another common failure is overbuilding too early. Some authors spend weeks on extras before they have a usable home page or a working contact form. By the time they finish, the site has polish but no purpose. Readers arrive, glance, and leave because nothing tells them where to go next.

The quiet failure is worse: no newsletter path, no book-specific pages, and no clear next step. That site may look nice, but it behaves like a dead end. It does not collect readers, it does not support sharing, and it does not make the next purchase easier.

When the site is meant to support direct sales or membership later, the rebuild risk gets sharper. A brochure site can survive small flaws. A revenue site cannot. Once payments, access, and content flow are involved, the architecture matters. If that is the direction you are heading, plan for it now rather than patching it later.

When standard author website advice does not fit

Standard advice assumes every author wants the same thing. They do not. A debut novelist, a nonfiction writer with workshops, and a self-published author building direct sales all need different first versions of the site.

If you are a debut author, simplicity wins. You need a name, a face, a book, and a way to collect interest. If you are self-published, the site should usually do more work on discovery and conversion. If you already sell directly or plan to, the platform and payment layer matter from the start.

There is also a group that should ignore the pressure to blog immediately. If you do not have a repeatable content angle, do not force one. A thin blog with two posts is not a strategy. It is an unfinished obligation. A clean site with strong book pages usually helps more than a half-maintained feed.

Different story for authors whose catalog is the product. They may need a stronger sales structure earlier than a traditional path would suggest. That is the point where a content-only site starts to feel incomplete, and why some independent publishers move toward systems built for ownership and direct monetization rather than just publishing presence.

What this foundation unlocks next

Once the basic site exists, the cluster branches into the decisions that sit on top of it. The next questions are not “Do I need a website?” They are “How do I make it easier to build,” “How do I make it easier to sell from,” and “How do I keep the site useful after launch?”

If you are still comparing the mechanics of launch, the sister guide on how to make an author website goes deeper on implementation choices. If your next step is selling rather than just publishing, how to sell a book online is the natural follow-on. Writers who want to broaden the model beyond books can use make a living as an artist to see how owned sites support broader monetization. And if your site will eventually support media or lessons, sell music online shows the structure shift that happens when content becomes commerce.

The point is not to build everything now. The point is to build the first version so it does not block the second.

Where Scrile Connect fits this picture

For authors who already know the website is not just a brochure, the next question is whether the site should stay informational or become an owned revenue surface. That is where Scrile Connect fits: it serves writers, solo publishers, and other independent creators who need subscriptions, pay-per-view content, tips, direct payments, and branded control instead of a simple public profile.

It is not the right answer for every author, especially if all you need is a lightweight bio page. But if your site is expected to carry audience ownership and monetization later, it helps keep those pieces under one roof rather than scattering them across separate tools.

Musician Website: Examples, Templates & How to Build Yours

Build your setup →

Ready to build the setup behind this?

If this is the operating problem you need to solve, use the product page as the next step. It shows where build your setup fits and what the platform covers beyond a single payment widget.

Build your setup →

Frequently asked questions

When is a very small author website enough?

A very small site is enough when your main need is visibility, not conversion. If readers, event hosts, or editors only need to confirm who you are and how to contact you, a lean site works. The moment you want email growth or sales paths, the structure needs to expand.

What if I only have one book right now?

One book is not a reason to delay. It is a reason to keep the site narrow. Give the book its own page, make the author bio strong, and avoid filler pages that exist only to make the menu look full.

What happens if I choose the wrong platform now?

Usually you pay twice: once for the original build and again for the migration. If the platform blocks export, custom pages, or direct sales later, the rebuild cost can easily reach 10 to 30 hours for a small site and much more once the site has grown.

How do I know when the site has outgrown the basic version?

You have outgrown it when the site needs features the current setup cannot support cleanly: better book segmentation, newsletter automation, store pages, membership logic, or stronger analytics. At that point, patching becomes more expensive than moving.

Do I need a blog to create a useful author website?

No. A blog helps only if you can keep it active and relevant. A stale blog does not build authority. A focused book site with strong pages often does more for the reader than a half-maintained feed.

What if I want the site to sell directly later, but not now?

Design the foundation with that future in mind. Keep the domain tied to your author name, choose a platform that can grow, and make sure the structure can accept store or membership pages later without a full rebuild.


0 comments
comment-outline
No comments yet