Build a website

This path takes you from an installed Arc CMS to a live content website that collects sign-ups. Follow the pages in order; each one says what to do in the admin area or the files, and links to the feature page for the detail.

What you will have at the end

• Content types (articles, guides, case studies) that editors write and publish from the admin area, each published as a static page at /{type}/{item}.
• Your own HTML templates for the list and detail pages and the cards of each type, with your header and footer.
• Static pages such as the privacy and cookie policies.
• Structured data, a sitemap, robots.txt, llms.txt and RSS feeds, written on every publish.
• A search box in the header and a /search results page.
• A signup form on the home page, with a verification code and a welcome email. Every sign-up becomes a contact you can email.

Before you start

You need an installed Arc CMS with its first admin, deployed once. If you have not done that yet, follow Install, Configure a project, Create the first admin and Deploy for the first time. Publishing builds each page from the files on the live site, so a template folder of your own must be deployed before an item that uses it can be published. The first-run wizard creates an Articles content type and a default signup form, so you do not start from nothing.

Have these ready:

The steps

Converting an HTML site you already have? Turn an HTML site into an Arc CMS site walks through every step below on a small blog, with the files before and after.

1. Plan your content: decide what is a content type, a static page or a form, and what each URL looks like.

2. Define content types: create them in the admin area with their fields.

3. Design templates: give each content type its list and detail layout.

4. Build your home page: your front door, with your own design, animation and signup form.

5. Let editors change your home page: services, a hero, questions and contact details that admins edit without touching HTML.

6. Write static pages: fill in the ready-made About, Contact, FAQ and policy pages, and hand-write anything that never changes.

7. Brand the sign-in page: your name, logo, words and colours where people sign in.

8. Manage media: set image sizes and upload images.

9. Add authors and tags: bylines and topics.

10. Get found by search engines and AI: fill in your site identity and write pages that get quoted.

11. Publish in more than one language: only if you need it.

12. Add search: choose what visitors can search.

13. Collect sign-ups: set up the form, its emails and where sign-ups land.

14. Choose your website's features: switch off what a website does not use.

15. Launch checklist: check everything before you point your domain at it.

Recommended features

A content website with lead generation uses content, templates, media, authors and tags, SEO, search, signup forms, the contact form, audience and email. Keep them all on. Switch off payments and SMS unless you sell or use phone sign-in; Choose your website's features shows how. The full list is in All features.

How you work

Most of the work happens in the admin area at /admin. The rest is your website's own files, which live in one folder, src/custom/site/. It is part of the custom space: Arc CMS never ships or changes anything in it, so an upgrade never conflicts with your site.

Every file is optional. Where you have none, Arc CMS's own is used (from public/_site/), and it keeps improving with each upgrade. Where you have one, yours replaces Arc CMS's. The build puts the two together, and the app and the publish functions both read the result, so what you see locally is what publishes. The full list is in Design templates and Use the custom space.

None of these is a core file, so npm run check:core stays clean and an Arc CMS upgrade never conflicts with your site. All of them are plain HTML, CSS and JavaScript. The home page, header, footer and static pages have no special rules for {, } or @. Templates are different: in them {{ }} marks a value to fill in (see Design templates).

Which files are served, and where

Only files with these names and places are part of the website:

Folder and page names use lowercase letters, digits, - and _, and start with a letter or digit, such as case-studies or terms. A language is its code, such as hi or pt-br. A template folder holds only those three files, plus layouts named detail-{name}.html (see Layouts). Anything else, such as robots.txt, pages/About.html or templates/articles/card.html, is not served: npm run dev and npm run build name each such file in a warning. A README.md is allowed and stays quiet.

Run the site locally with npm run dev while you build; it reads and writes your real Firebase project (see Run it locally). A change to any of these files shows in npm run dev at once: the page reloads by itself for the header, footer and sign-in panel; reload it yourself for the rest. A strings file that is not valid JSON stops npm run dev and npm run build with a message; while npm run dev runs, it keeps the last good copy.

On the live site, publishing an item puts its page there straight away. A change to a file reaches the live site only when you deploy the website with npm run deploy, which then publishes every page again so they all use the new files (see Deploy).

Next

Start with Plan your content, or follow the worked example, Turn an HTML site into an Arc CMS site.