You are building a blog for a Haeeum client. Read all of this before starting, then build. Do not summarise the brief back to me or produce a plan — build, then hand over files. # The client Client: {{client_name}} Their website: {{site_url}} Blog address: {{blog_url}} Blog is called: {{publication_name}} What they do: {{field}} Colours from their site: Primary: {{primary_colour}} Accent: {{accent_colour}} Background: {{background_colour}} Text: {{text_colour}} Logo: {{logo_url}} Links back to their site (label → URL, one per line): {{nav_links}} End-of-article call to action: "{{cta_text}}" → {{cta_url}} Notes from the client manager: {{notes}} # What we're doing Haeeum hosts blogs for businesses on a subdomain of their own site. The client's website is untouched. We publish articles that earn search traffic and send readers to the client's pages. This blog is the base — it will be refined later if the client warrants it, but it needs to be good enough to publish on today. # Calibration — read this twice The client's website is the reference for colour, logo and tone of voice. It is NOT the reference for quality. Most client sites are basic, dated, or a barely-customised theme. Do not reproduce their weaknesses. Do not match a poor site's poverty. But do not overshoot either — a blog that is dramatically more polished than the site it belongs to looks like a different company built it, and readers notice. Aim for one clear notch above the client's site: clean, well-spaced, obviously theirs, nothing a reader would remark on. If their site is dark with several neon accents, the blog is dark with one of those accents used sparingly. If their site is a plain white WordPress theme, the blog is plain white with better typography and more air. Use at most two colours from the list above on any reading surface: one primary, one accent. If the site uses more, pick the two that appear most often together and leave the rest. # Hard rules Typography: Figtree, and only Figtree. No second typeface for headings, quotes, captions, code samples, anything. If the client's site uses a serif or a display face, do not carry it over. Personality comes from scale, weight, spacing and restraint. Load Figtree from Google Fonts with display=swap. Do not use any of these: decorative italic serif headings, glassmorphism, gradients without a purpose, floating shapes, rounded cards everywhere, pill labels, badges, glowing buttons, feature-card grids, dashboard layouts, drop shadows as decoration, emoji as bullet points, hero sections with a giant photo and a slogan. These make a site look generated. Restraint beats manufactured personality. Content presentation is editorial, not card-based. An index of articles should read like a publication's contents, not a grid of thumbnails. Static HTML and CSS only. No frameworks, no build step, no bundler. Client-side JavaScript only where genuinely needed, and it must degrade gracefully. This will be dragged into Cloudflare Pages as a zip. # Pages to build 1. index.html — the publication homepage - Masthead: publication name, the client's logo, and the nav links back to their site. - A short line stating what the publication covers. - Six sample article entries, with varied title lengths (one short, one two-line, one long) so the layout is proven against real content. Each entry: title, one-line description, date, category. No thumbnails required; if you use image placeholders, plain grey blocks are fine. - Footer: client name, link to their site, a "Managed by Haeeum" line. - Must still look right with 5 entries or 100. Design it as an archive that grows. 2. article.html — one complete sample article This is the product. Spend most of your effort here. - Category, title, description, author, publish date, reading time. - Roughly 1,200 words of sample text on a topic plausible for this client's field, so the design is judged against realistic length. Mark clearly at the top that the text is sample content. - Must include: H2s and H3s, paragraphs of varied length, an unordered list, an ordered list, a text link, a pull quote or blockquote, one inline image placeholder with a caption, one full-width image placeholder, a mid-article contextual link to one of the client's pages written naturally into a sentence, and the end-of-article CTA. - Reading width between 60 and 75 characters. Let some elements break out of that width — images, pull quotes — so a long read does not feel like one monotonous column. - Three related-article entries at the end. - The CTA is a quiet block, not a banner. This is an article, not a landing page. 3. 404.html — matches the site, links back to the index. 4. styles.css — one file, all pages. Use CSS custom properties for the client colours so a colour change is a one-line edit. 5. robots.txt — allow everything, reference the sitemap. 6. sitemap.xml — the two pages, absolute URLs on the blog address. 7. _headers — Cloudflare Pages format. Security headers only (X-Content-Type-Options, Referrer-Policy, a sensible Permissions-Policy). Absolutely no X-Robots-Tag. # SEO and technical requirements - Exactly one H1 per page. Logical H2/H3 order below it. - Title tag and meta description on every page, written for search results. - Canonical tag on every page, absolute, on the blog address — never a .pages.dev address. - Open Graph title, description, type and image on the article page. - Article structured data (JSON-LD, type Article) on the article page with headline, author, datePublished, dateModified. - No noindex anywhere. No robots meta tag at all. The holding page that was on this address used noindex; this replaces it and must not carry that over. - Every image element has a descriptive alt attribute. Decorative placeholders use alt="". - Body text contrast against background at least 4.5:1. Check it. - Visible focus states on every link and button. - Responsive without simply stacking columns. Mobile is a composition of its own — most readers arrive from search on a phone. - Fast: no web fonts beyond Figtree, no external scripts, images lazy-loaded below the fold. # Content architecture Articles will eventually come from Markdown with frontmatter. Structure article.html so the head and body correspond cleanly to these fields, in this order, and comment where each one is placed: title, description, slug, author, publish_date, updated_date, category, tags, reading_time, hero_image, hero_image_alt, hero_image_caption, meta_title, meta_description, canonical_url, og_image # Before you hand over, check every one of these - Search your CSS for font-family. Figtree is the only family named. - Search every file for "noindex" and "robots". The only hit is robots.txt itself. - Every page: exactly one H1. - Every page: canonical present and on {{blog_url}}. - Every img has alt. - Colours used on reading surfaces: two at most from the client's set. - Nothing from the "do not use" list is present. - The zip has files at its root — index.html directly inside, not inside a folder. No __MACOSX, no .DS_Store, no README, no notes. # Hand over Deliver a single zip. Files at the root. Nothing in it that isn't meant to be public. Then, in three or four sentences: which two colours you chose and why, one design decision that was a judgement call, and anything you'd flag for the client manager to look at.