How to set up your website's essential features

A page builder came with a few things already wired in. A contact form that dropped messages in your inbox, a counter that told you someone had visited, the little tags that make a link look right when you paste it into a chat. You never set any of it up, and you never owned it either. It worked while you paid, and it left when you did.

On your own site you add these yourself, and it is lighter work than it sounds: you describe what you want and the agent wires each part in.

You already have what this builds on. Back in Foundations you learned how agents reach outside tools and the .env shape that keeps keys safe. In the last two lessons you built the pages and made them sound like you. We do each part on the demo site, and you follow on yours.

A working contact form

A contact page is only useful if the form on it actually sends. On a static site that runs into one wall: there is no server of your own sitting there to catch the message. Building one for a personal site would be a lot of work for a small job, so we skip it entirely and let a form service do the catching.

Form service

A service that receives your form and emails you every submission, with no server or backend code on your side. You point the form at their address and paste in one key, and it works. Free for the volume a small site sees.

The one I reach for is Web3Forms.

Assignment: wire the contact form

This builds the form on the Contact page and wires it to Web3Forms, spam trap included, styled to match the rest of the site.

On the Contact page, build a form with fields for name, email, and a message, and a send button. Wire it to Web3Forms: post the form to their submit address, include a placeholder for my access key, and add their hidden honeypot field so simple spam bots get caught. After a message sends, show a short thank-you in its place. Match the styling to the rest of the site.

Done when you send yourself a test message and it lands in your inbox.

Two things to do by hand after. Sign up at web3forms.com, which is free, and copy your access key into the spot the agent left for it. The key only routes mail to you, so pasting it into the page is fine. And keep the honeypot the prompt asked for. It adds a field a real person never sees but a bot fills in, and anything that arrives with it filled gets dropped.

Here is the demo contact page with the form wired in and styled to match:

localhost:4321/contact

That is the simple version, and it will carry you a long way. When you outgrow it, the agent is not married to Web3Forms. Tell it the service you already use and it wires that one in instead. On my own sites the form writes straight into Airtable, so I keep an organized list of who reached out rather than scrolling my inbox for it. A newsletter box hands new addresses to Beehiiv. Those two need one extra piece, a small function that keeps the secret key out of sight, which is the only reason we do not start there.

Analytics without a cookie banner

You will want to know whether anyone is coming by, which pages hold them, and where they arrived from. The reflex answer is Google Analytics. It works, and it is powerful, but it sets cookies, and cookies are what drag in the consent banner you have dismissed a thousand times on other people’s sites. A small site can skip the whole ritual.

Start with Cloudflare Web Analytics. It is free, and it counts visits without storing anything on the visitor’s machine. Because it sets no cookie, the rule that forces those banners does not bite. That clears the cookie requirement rather than all of privacy law, and for a site that collects nothing else it keeps you off the banner honestly.

Assignment: add cookieless analytics

Run this, then get the snippet from a free Cloudflare account and paste it where the agent leaves the placeholder, the same as the form key. It works without moving your domain or changing any settings.

Add Cloudflare Web Analytics to the site. Put the tracking snippet in the shared layout so it loads on every page and only there. Do not add anything that sets cookies, and do not add a consent banner, since this is meant to stay cookieless.

Done when the snippet sits in the shared layout and nothing on the site sets a cookie.

Google Analytics still shows more, and on a larger site the extra depth can be worth the banner it brings. This very site runs it, banner and all, because I want that detail. A personal site rarely needs it. If you later want the depth without the banner, Plausible is the paid option that sits in between.

The SEO tags a builder added for you

Paste a link to your site into a message and a tidy preview often appears: a title, a line of description, sometimes an image. None of that is automatic. It comes from a small set of tags in each page’s head, and a builder wrote them for you without ever showing you. The agent writes them now, and four things are worth having.

• A title and a short description on every page. The text that shows in a search result and in the browser tab.
• The share tags, called Open Graph. These make a link to your site look right when it lands in social feeds and chats.
• A sitemap. One file listing all your pages so search engines can find every one. Astro builds it on each save, once you tell it your site’s address.
• A small block of structured data, in a format called JSON-LD. It states plainly who you are for the search engines that read it.

Assignment: set up the SEO basics

One instruction covers all four pieces. Give it the address you plan to buy, and a best guess is fine; the sitemap only builds once Astro has one, and next lesson you set the real thing.

Set up the SEO basics. Give every page its own clear title and meta description, and add Open Graph tags so shared links show a proper preview. Set my site’s address in the Astro config, then add the official Astro sitemap integration so a sitemap is generated on every build, plus a robots.txt that welcomes search engines and points them to it. Add JSON-LD structured data on the home page describing me as a person. Ask me for anything you need, such as my name and a one-line description.

Done when every page carries its own title and description and the build produces a sitemap.

After it runs, glance over the pages to see each has its own title rather than the same one repeated, and if you want to check a share preview, the big platforms publish small debugger tools that show exactly how your link will look.

A quick security pass

A static site is a small target. Nothing of yours is running on a server, and there is no database to break into, so most of the alarming headlines about hacked sites simply do not apply to this one. What remains is short, and the agent runs most of it with you.

Any secret key, a token for whichever service you add later, belongs in this project’s .env, the shape you learned in Foundations, never typed into a page and never committed to git. That habit closes the most common way people leak a key, which is pasting it into code that later goes public. If you wired the form to Web3Forms alone, you have no such secret yet. The day you add a key-based service, this is the rule.

Beyond that: keep the project’s dependencies current, and have the agent flag any with a known problem. Use a form backend with a real reputation, which the ones here have. And confirm the site is served over HTTPS, the padlock in the address bar, which your host handles and we check together at go-live.

Assignment: run the security pass

This runs the checklist you just read and reports back. Nothing gets changed without you seeing the list first.

Run a security pass on this project. Confirm .env is listed in .gitignore and that no keys or secrets appear anywhere in the code or the git history. Check whether the dependencies are current and flag any with a known vulnerability. Tell me what you find and what I should fix, and change nothing without asking me first.

Done when the report is clean, or you know exactly what to fix.

A builder ran checks like these where you could not see them, and you trusted that it did. Here you run them yourself in a few minutes, and you actually know the state of your own site.

A first speed check with Lighthouse

Everything you added in this lesson loads a little something extra: the form service, the analytics snippet, the spam check. Outside pieces like these are the usual reason a quick page turns sluggish, so now is the right moment for a first look, before more piles on. Have the agent run Lighthouse, the standard health check for a web page, and read the scores back.

Assignment: run the first speed check

Report only, run on the site as it sits on your machine. The scores here are your baseline for the real run at go-live.

Run Lighthouse on the site and show me the scores for performance, accessibility, best practices, and SEO. If anything I added in this lesson pulled performance down, tell me what and why. Do not change anything yet, just report.

Done when you have the four scores and a reason for anything performance lost this lesson.

Do not chase a perfect number here. All you are checking is that nothing you added did real harm, and on a site this lean the answer is almost always that it did not. The full tune, lifting every score near the top and holding it there, is the next and last lesson, where the site goes live and that number finally counts for something.

What you have now

The demo site can do its job now. The form sends, the analytics respect the person reading, the tags make your link look right when it travels and let search engines read the site, and a security pass came back clean. Every one of those was a thing a builder kept behind its monthly bill, and each now runs on a service you picked and can walk away from.

One piece is left, and it is the one that makes all of this real. The site still lives only on your computer. In the last lesson you put the site online, buy the address, and run the full performance pass until the scores sit where you want them. After that it is out in the world, at a name that is yours.