Building a Website with Claude Code, Hostinger & WordPress: a Hands-On Report

You’ve probably tried ChatGPT or Claude before and had it generate a nice piece of text. Maybe even a few lines of code. Cool. But have you ever built a complete business website with it? Not some toy with flashy colors, but a real, professional website with security headers, GDPR compliance, and a deploy script that pushes your changes live in 30 seconds?

That’s exactly what we did. With a stack that works surprisingly well: Claude Code as an AI development partner right inside VS Code, Hostinger as the hosting platform, and WordPress as the CMS. Add Git for version control, a custom deploy script, and a file called CLAUDE.md that makes the whole thing really take off.

Everything you read in this article comes from a real project: trail1.de. No theory, no made-up examples. Every code snippet comes straight from the codebase.

What you need (and what you don’t)

Forget everything you think you know about website builders. We need exactly five things:

• VS Code – the code editor that half the world already uses
• Claude Code – the AI extension for VS Code that actually thinks along
• Git – for version control (because something always goes wrong)
• An SSH key – so you can connect to your server securely
• A Hostinger account – with SSH access and WordPress pre-installed

Why Hostinger? Their servers are in Frankfurt (EU, great for GDPR), LiteSpeed Cache is built in, PHP 8.2+ is available, and you get real SSH access. This isn’t some shared-hosting basement from the 2000s.

After setup, create an SSH alias so you don’t have to type the full server configuration every time:

# ~/.ssh/config
Host my-server
  HostName <your-server-ip>
  User <your-username>
  Port <your-custom-port>
  IdentityFile ~/.ssh/id_ed25519

Then initialize your Git repository in the project folder and you’re good to go. Which brings us to the real secret of this setup.

The secret ingredient: CLAUDE.md

This is where it gets interesting. Most people open Claude Code and just start typing: “Make me a website.” The result speaks for itself. It kind of works, but professional? Not quite.

The difference between “AI spits out something” and “AI works like a developer who knows your project rules” is a file called CLAUDE.md. It sits in your project root and acts as a specification document for your AI. Claude Code reads it on every start and then knows which coding standards apply, what’s allowed, what’s forbidden, and which tools are available.

Here’s an excerpt from our actual CLAUDE.md:

## Code Style
- PHP: WPCS, always escape (esc_html(), esc_attr(), esc_url(), wp_kses_post())
- SQL: $wpdb->prepare() for every query, no exceptions
- JS: ES Modules, no jQuery unless WP Core requires it
- CSS: BEM classes, tokens via CSS Custom Properties, no !important
- functions.php only require_once -- logic in inc/<feature>.php

With this in place, Claude knows: every PHP output gets escaped. No exceptions. No “I’ll do it later.” And it actually works. Claude follows through.

But there’s more. In CLAUDE.md you also define Skills and Slash Commands:

## Skills
| Skill          | Description                                               |
|----------------|-----------------------------------------------------------|
| wp-block       | Custom Block: block.json + render.php + style.css + edit.js |
| wp-security    | Security audit: headers, escaping, nonces, permissions    |
| wp-performance | Lighthouse audit, query analysis, asset optimization      |

## Slash Commands
| Command            | Purpose                                             |
|--------------------|-----------------------------------------------------|
| /wp-commit         | Analyze Git diff, create Conventional Commit        |
| /wp-audit          | Security + GDPR + performance in one pass           |
| /wp-deploy-staging | Build, validate, backup, deploy to staging          |

Skills are specialized knowledge packages. With wp-security, Claude knows exactly what to check. Commands are one-liner workflows: /wp-commit analyzes the Git diff and automatically creates a clean commit. Invest time in a good CLAUDE.md. It’s the single best investment in your entire project.

How you really work with Claude Code

Now that Claude knows your rules, the way you work changes completely. Instead of coding for hours yourself, you describe what you want. Claude delivers. Not blindly, though. There’s a structured process:

Plan first, then build. Claude Code has a plan mode. You activate it, describe your feature, and Claude creates a detailed implementation plan. Code is only written once the plan is solid. Sounds like overhead, but it saves hours because you don’t end up starting over three times.

Work incrementally. One feature at a time. Contact form done? Test it. Works? Commit. Next feature. Never touch three things at once.

A practical example: our contact form. Based on the CLAUDE.md rules, Claude built a form with seven security layers, all in a single pass:

// 1. Nonce check (CSRF protection)
if ( ! wp_verify_nonce( $_POST['_wpnonce'], 'my_contact_nonce' ) ) {
    my_form_redirect( 'error', 'Security check failed.' );
    return;
}

// 2. Honeypot (invisible field -- bots fill it in, humans don't)
if ( ! empty( $_POST['website_url'] ) ) {
    my_form_redirect( 'success' ); // Bot gets fake success
    return;
}

// 3. Timing check (< 3 seconds = bot, no human types that fast)
if ( ( time() - (int) $_POST['_ts'] ) < 3 ) { /* Too fast */ }

// 4. Rate limiting (max 3 per hour per IP)
// 5. Input sanitization (sanitize_text_field, sanitize_email)
// 6. Required field validation + privacy checkbox
// 7. Email domain MX check (does the domain even exist?)

Seven security layers. No reCAPTCHA, no external service, no data transfer to Google. All server-side. Claude built this because CLAUDE.md clearly states: “Nonce validation on all forms. No exceptions.”

After every feature comes verification: Does it compile? Are coding standards met? Does it work in the browser, on both desktop and mobile? Is Lighthouse performance above 90? Only then do you move on.

Live in 30 seconds, safely

At some point your code needs to go from your local machine to the server. This is where many people make the mistake of uploading files via FTP or, even worse, editing directly on the server. Please don’t.

Our approach: a single Bash script called deploy.sh that automates everything:

#!/bin/bash
set -e  # Abort immediately on any error

REMOTE="my-server"
REMOTE_PATH="~/domains/example.com/public_html"
THEME_PATH="wp-content/themes/my-theme"

# [1/4] Upload theme files via SCP
echo "[1/4] Uploading theme files..."
scp -r "$THEME_PATH"/* "$REMOTE:$REMOTE_PATH/$THEME_PATH/"

# [2/4] Upload .htaccess (security headers!)
echo "[2/4] Uploading .htaccess..."
scp .htaccess "$REMOTE:$REMOTE_PATH/.htaccess"

# [3/4] Reset OPcache (IMPORTANT!)
echo "[3/4] Resetting OPcache..."
ssh "$REMOTE" "php -r 'opcache_reset();' || curl -s localhost/opcache-endpoint"

# [4/4] Clear LiteSpeed cache
echo "[4/4] Clearing cache..."
ssh "$REMOTE" "wp litespeed-purge all 2>/dev/null || wp cache flush"

Four steps, fully automated. SCP transfers files encrypted over SSH. The .htaccess goes along for the ride because that’s where the security headers live. Then come the two steps we learned the hard way: reset OPcache and clear cache.

Without an OPcache reset, your server will happily serve the old PHP version after deployment. You’ll stare at the screen, wondering why nothing changed. You’ll question your sanity. Spoiler: it wasn’t you. PHP caches bytecode, and without an explicit reset the old version stays in memory.

Why SCP instead of rsync? Because rsync doesn’t run natively on Windows. SCP works everywhere, is simple and secure. Pragmatism beats perfection.

The whitelist trick: only track what you wrote yourself

WordPress projects and Git aren’t natural friends. WordPress ships with thousands of core files, plus plugins, uploads, cache folders. You don’t want all of that in your repository. The classic solution is a .gitignore that excludes certain folders. Our approach flips this on its head: we ignore everything and whitelist only what we wrote ourselves.

# IGNORE EVERYTHING, ONLY TRACK EXCEPTIONS
/*

# Track these files
!.gitignore
!.htaccess
!CLAUDE.md
!content/
!.claude/
!deploy.sh

# Only track our theme
!wp-content/
wp-content/*
!wp-content/themes/
wp-content/themes/*
!wp-content/themes/my-theme/

# NEVER track
wp-config.php
wp-content/uploads/
wp-content/plugins/

The result: a repository with fewer than 100 files instead of thousands. Clean, organized, and most importantly secure. wp-config.php and credentials simply can’t be accidentally committed.

For commits we use Conventional Commits. Claude generates them automatically via /wp-commit:

feat: Implement contact form with 7-layer security
fix: Switch .gitignore to whitelist approach
style: Adjust mobile nav breakpoint to 768px

One feature, one commit. Clear, traceable, auditable.

GDPR is no obstacle if you get it right from the start

Now it gets serious. Most WordPress tutorials handle GDPR with “just install a cookie plugin.” That’s like putting a band-aid on a burst pipe. GDPR is not an afterthought. It’s a quality standard that belongs in the architecture from day one.

Here are five concrete measures from our project:

1. Self-hosted fonts instead of Google Fonts CDN

Every call to Google Fonts transmits your visitors’ IP addresses to Google, straight to the USA. Without explicit consent, that’s a GDPR violation. The fix is simple: download the fonts and host them locally.

/* GDPR-compliant: No Google Fonts CDN */
@font-face {
  font-family: 'Source Sans 3';
  src: url('./assets/fonts/SourceSans3-Latin.woff2') format('woff2');
  font-weight: 400 900;
  font-style: normal;
  font-display: swap;
}

The WOFF2 files live in the theme folder. No external request, no data transfer, no problem. font-display: swap ensures text is visible immediately, even while the font is still loading.

2. Security headers in .htaccess

Professional websites set security headers. They protect against clickjacking, enforce HTTPS, and control which external resources can be loaded:

<IfModule mod_headers.c>
  Header set X-Content-Type-Options "nosniff"
  Header set X-Frame-Options "SAMEORIGIN"
  Header set Referrer-Policy "strict-origin-when-cross-origin"
  Header set Permissions-Policy "camera=(), microphone=(), geolocation=()"
  Header set Strict-Transport-Security "max-age=31536000; includeSubDomains; preload"
  Header always set Content-Security-Policy "default-src 'self'; font-src 'self'; ..."
</IfModule>

The Content-Security-Policy (CSP) is especially important: it only allows resources from your own domain. No hidden trackers, no injected scripts. The Permissions-Policy disables camera, microphone, and geolocation. Features a business website simply doesn’t need.

3. No tracking, no marketing cookies

Our website has no Google Analytics, no Facebook Pixel, no Hotjar. Only technically necessary cookies for the WordPress session and LiteSpeed Cache. This means: no cookie banner needed. Technically necessary cookies are exempt from consent requirements. Fewer banners, better user experience, full compliance.

4. Contact form without reCAPTCHA

Google reCAPTCHA sends user data to Google. That’s a GDPR problem. Our alternative: seven server-side security layers (nonce, honeypot, timing, rate limiting, sanitization, validation, MX check). No external service, no data transfer. Works at least as reliably against bots.

5. Privacy checkbox as a required field

Every form needs explicit consent with a link to the privacy policy. No pre-checked checkbox, no hidden notice. The user must actively agree before the form can be submitted.

Together, these measures create a website that’s GDPR-compliant without installing a single privacy plugin. The trick: build it right from the start instead of patching it later.

Your next step

Let’s recap what you now know:

• CLAUDE.md is the foundation – invest time in good rules and Claude Code will deliver professional-grade code
• Build incrementally – one feature, one commit, validate, move on
• deploy.sh automates the most tedious part of your workflow and prevents errors
• Git with a whitelist approach keeps your repository clean and secure
• Plan GDPR from the start instead of bolting it on afterwards. It saves time, money, and headaches

The beauty of this setup is that it scales. Whether you’re building a single landing page or a complex enterprise portal, the tools and workflows stay the same. Claude Code gets better with every iteration because CLAUDE.md preserves project knowledge. Your deploy script works today just as it will in six months. Your Git history tells a clean story of your project.

The website trail1.de was built with exactly this stack. Every line of code, every security header, every font file. Everything you’ve read in this article runs there in production. No prototype, no demo project. The real deal.

Want to build your own website to these standards but need support? Schedule a free initial consultation. 30 minutes, no obligation, confidential. We’ll figure out together which approach is right for your project.