By Mehdi HassanWhat security basics does a marketing website need?
A marketing website needs secure accounts, a protected domain, HTTPS, spam-resistant forms, safe handling of secrets, controlled third-party scripts and up-to-date software. On modern stacks like Framer, Webflow and Next.js on a managed host, the platform secures the servers. Your job is everything around them.
That's a shift from the old picture of website security, which centered on patching WordPress plugins and hardening servers. Those still matter if you run WordPress. But for most startup sites, the realistic threats are a stolen password, a domain that expires or gets hijacked, a spammed form and a risky script. Security is one strand of the upkeep covered in our guide to website maintenance.
Realistic threat | What it looks like | Main protection |
|---|---|---|
Account takeover | Someone logs into your CMS or host with a leaked password | Two-factor login and access reviews |
Domain loss or hijack | Domain expires or is transferred away | Registrar lock, auto-renew, 2FA |
Email spoofing | Phishing sent as your domain | SPF, DKIM and DMARC |
Form spam and abuse | Bots flood forms and your inbox | Honeypot and bot checks |
Leaked secrets | API keys exposed in the browser or repo | Server-side secrets, rotation |
Risky third-party code | A script or package is compromised | Fewer scripts, updated dependencies |
What is on a website security checklist?
A website security checklist covers accounts, the domain, transport, forms, secrets, scripts and software, in roughly that order of impact. Work through it once properly, then repeat the access and update items monthly as part of your website maintenance checklist.
- Turn on two-factor login for the domain registrar, DNS provider, host, CMS, analytics, tag manager and code repository. Prefer an authenticator app or security key over text messages.
- Review who has access. Remove former employees, freelancers and past agencies. Give everyone their own login with the lowest role they need.
- Lock the domain. Enable the registrar lock, turn on auto-renew with a current card, and keep the registrar account in your company's name.
- Serve everything over HTTPS. Modern hosts issue certificates automatically. Make sure HTTP redirects to HTTPS and no page loads insecure assets.
- Authenticate your email domain with SPF, DKIM and DMARC, so nobody can easily send phishing as you.
- Protect forms with a honeypot field and a bot check, and validate input on the server.
- Keep secrets on the server. API keys for your CRM or email service must never ship in browser code or sit in the repository.
- Audit third-party scripts and remove anything without a clear owner and purpose.
- Keep software updated. Patch dependencies or plugins on code-based and WordPress sites, and act on security advisories within days.
Why are domain locks and account security the first priority?
Domain locks and account security come first because they protect the assets every other layer depends on. If someone takes over your registrar account, they control your website, your email and your password resets everywhere else. If someone takes over your CMS, they can change what your site says to every visitor.
Most account takeovers rely on reused or leaked passwords, which two-factor login stops. The domain has an extra risk: expiry. Renewal reminders often go to an inbox that belonged to whoever registered it, which is why the registrar account should use a shared company address. Our website ownership checklist walks through putting each account in your company's name, which is the foundation for securing it.
For example, suppose a former contractor still has CMS access
For example, suppose a freelancer who worked on your site last year still has an admin account in your CMS. They aren't malicious, but they reuse a password that later appears in a breach of another service. An attacker tries it on your CMS, gets in and adds a hidden link or a fake announcement.
Nothing about your hosting was weak. The gap was an account nobody remembered. A monthly access review, plus two-factor login required for every CMS user, closes it. This is a hypothetical scenario that illustrates a common path in.
How do you protect website forms from spam and abuse?
You protect website forms by stopping bots before they submit, validating what arrives on the server and limiting what a submission can trigger. Spam isn't just annoying: a flood of junk can bury real leads, train inbox filters to treat your notifications as spam and, on poorly built forms, be used to send email to strangers through your domain.
- Add a honeypot field that people can't see but bots fill in, and reject submissions that fill it.
- Use a bot check such as Cloudflare Turnstile, which is less intrusive for real visitors than image puzzles.
- Validate on the server, not just in the browser, and limit the size of each field.
- Rate-limit submissions from the same source.
- Never send email to an address typed into the form without confirmation, or the form becomes a spam relay.
Delivery is the other half of form safety. If notifications land in spam, real leads get lost too; our guide to website form emails not being delivered covers SPF, DKIM and DMARC in detail.
How do secrets, scripts and dependencies affect security?
Secrets, third-party scripts and dependencies are where code-level risk sits on a modern marketing site. A leaked API key lets someone use your CRM or email account. A compromised third-party script runs with the same access as your own code. An unpatched framework can be exploited once a vulnerability is public.
Secrets
Keep API keys in your host's environment variables and use them only in server-side code. In Next.js, any variable prefixed with NEXT_PUBLIC_ is bundled into browser code, so never use that prefix for a secret. If a key has ever been committed to the repository, rotate it, because Git history keeps it even after deletion.
Third-party scripts
Every analytics tag, chat widget, heatmap and pixel can read and change the page. Keep the list short, load scripts only where they're needed and remove ones nobody uses. On sites with stricter needs, a Content Security Policy limits which domains can run scripts at all.
Dependencies
Code-based sites rely on frameworks and packages that ship security fixes through the year. In 2025, both Next.js and React shipped urgent fixes that sites had to apply quickly. A monthly update habit makes patches like those quick to apply; our guide to Next.js maintenance explains how.
Does a marketing site need a security page?
A marketing site for a B2B company usually benefits from a security or trust page that explains how you protect customer data, even though the marketing site itself holds little sensitive data. Buyers, especially larger ones, look for it during evaluation. It's a sales asset more than a technical control.
What goes on it depends on your product: certifications you actually hold, how data is hosted and encrypted, a way to report vulnerabilities and a link to a status page. Our guide to trust pages every B2B website needs covers structure, and what procurement and security teams look for on an enterprise AI website covers the procurement side. Only list certifications and practices that are true today.
How does security fit into ongoing website upkeep?
Security fits into upkeep as a monthly habit rather than a one-time project. Most items on the checklist only need setting up once, but access drifts as people come and go, dependencies age and scripts accumulate. A short monthly review keeps it from sliding.
Monthly access review
Remove anyone who no longer needs access and confirm two-factor login is still required everywhere.
Monthly updates
Apply dependency or plugin updates through a preview, and check for security advisories affecting your stack.
Quarterly script audit
List third-party scripts, confirm each has an owner and remove the rest.
Yearly domain and license check
Confirm domain renewal, registrar lock and that all accounts are in your company's name.
Pair this with uptime monitoring, so you hear quickly if something goes wrong. If you're launching a new site, our technical SEO checklist for new websites covers HTTPS, redirects and other launch settings that overlap with security.
