Nusantara Post

Nusantara Post reached the top of Google for its own name within ±5-6 months, ahead of older sites that use the same name. That happened because the site was built as one connected system: the content tools and the pages readers see. Every choice served one of the client’s goals.

What the client needed

Nusantara Post is a national news outlet covering Indonesia’s new capital, IKN, and the Kalimantan region, published by PT Media Ibu Kota Nusantara. It launched from nothing, into a name several other outlets already use in some form (“Nusantara Post”, “Nusantara Pos”).

Four goals set the direction:

• Be found for the brand name, fast. Turning up for “nusantara post” was a launch requirement, not a later fix.
• Publish at news speed. The newsroom had to run day to day on its own, posting and editing straight from WordPress.
• Work for the real audience. Most readers are on mid-range Android phones and patchy mobile data.
• Stay steady when a story gets big. When a lot of readers show up at once, the site should keep working and the cost should not jump.

Designing it

The look was not my call alone. It came from working through the brief with the client: how they want the brand to feel, how the newsroom actually works, where they see the outlet going. My part was turning that into a layout that looks sharp and is easy to move around.

The rule I set for the design was plain: straightforward, easy to reach, easy to take in. Nothing decorative gets between the reader and the story; the hierarchy is obvious at a glance; and the things that matter, headline, section, time, byline, sit in the same place on every card. Typography carries most of that: Crimson Pro, a serif built for legibility, for the article text; Plus Jakarta Sans for headlines and interface; and Playfair Display for the drop cap that opens a story.

Accessibility got attention from the start: colour contrast holds in both light and dark, and readers can make the article text larger.

One layout choice is worth calling out. The first draft followed the common pattern: thumbnail on the left of each list row, headline and meta on the right. I flipped it, headline and meta on the left, thumbnail on the right.

A left column of stacked thumbnails is visually noisy: every image a different crop, subject, and colour, so scrolling the feed the eye snags on each one and it takes a moment to tell what a story is about. A left column of headlines is uniform, one clean edge to run the eye down, and the photo still earns its place on the right, as confirmation rather than a gate.

Larger international papers lay their list rows out the same way, text first, the Washington Post and the New York Times among them. The newsroom felt the difference too, and found the new layout cleaner. It keeps the list quick to skim and the pages light. Eye-tracking and usability research on how people read web pages points the same way: Nielsen Norman Group’s F-shaped reading pattern and its work on minimizing cognitive load.

Why this stack

Every tool was picked to serve one of those four goals. Put simply: keep the CMS the newsroom already runs on, send readers finished pages instead of a heavy app, host it somewhere that stays up when traffic jumps, and treat search as a first-class job from day one.

In practice that meant keeping WordPress as the place editors write, building a fast new site in front of it that assembles each page on the server, running that on a plain rented server as a self-contained package, and shipping updates with a single command. Readers get quick pages that hold up on a weak signal. The client gets a site they can run themselves, one that keeps working on a busy day. Search engines get clean, clearly labelled pages from the start.

The decisions

Keep WordPress as the newsroom’s CMS. The team came in already knowing WordPress from past work, so there was no case for building a CMS from scratch or retraining anyone. It stays the editorial back office behind the new front end, and the effort went into getting the most out of a tool they already trust. Serves: publishing at news speed, straight from WordPress.

Astro for the public site, not WordPress itself. WordPress could have served the pages directly with a theme, but a public install is a large surface to keep patched and secure, and its speed leans on plugins and caching. Astro is built for content-heavy sites: it turns content into plain, fast pages with almost no JavaScript. Keeping it in front means visitors only ever hit simple pages, while the database and the admin stay private to the newsroom. Serves: fast pages for the real audience, and less that can go wrong.

Fetch content with GraphQL. Each page asks for exactly the data it shows, in one request, so pages come together quickly and are easy to change later. Serves: speed on weak connections, and low-effort upkeep.

Build pages on the server, host on a plain server. A news site changes all day, so it cannot be regenerated from scratch on every update. Assembling each page as it is requested keeps it current, and running it as a self-contained package on a rented server keeps the cost flat. One command ships a new version. Serves: always current, and steady when traffic jumps.

Send as little code to the browser as possible. The small interactive bits (dark mode, text size, search, share) each run on a few lines of script, so a page arrives as readable text first and stays usable when the connection is patchy. That is how most readers arrive, on a mid-range phone over mobile data. Serves: working for the real audience.

Handle search from the first commit. Because the name is contested, being findable could not wait for a later phase. Every page ships correct titles and descriptions, a preview image, and a place in the sitemaps, including a news sitemap, so Google picks stories up within minutes. Serves: being found for the brand name, fast.

Keep a changelog the client can actually read. Next to the technical log, a plain-language one grouped by part of the site, so the newsroom sees what changed without reading code. Serves: keeping non-technical stakeholders in the loop.

SEO Optimization

Because the name was contested, being findable could not wait for a later phase. The goal was concrete: rank nusantarapost.news first on Google for “nusantara post” within months of launch, above the older sites that share the name, and keep organic traffic growing for a mostly mobile audience. The work split four ways.

Keyword and structure planning. I mapped the site around the newsroom’s real coverage, IKN, the Kalimantan region, and the national desks, so section and article URLs form a shallow hierarchy a crawler can walk in full. Keyword research focused on the brand term and its variants (“nusantara post”, “nusantara pos”), plus the head news terms the outlet competes on, sorted by intent: navigational brand queries first, informational news queries next. The brand query was the explicit launch target, with the older same-name domains as the benchmark to beat.

On-page. Every page’s title, description, and social markup is generated from the article’s own fields through GraphQL, so nothing is filled in by hand and nothing is left blank or duplicated. Each page carries a unique templated <title> and meta description, a single <h1> for the headline with a real h2/h3 outline through the body, and a clean section/slug URL with no query strings or IDs. The slug is fixed at publish time, so editing a headline never moves the URL. Open Graph and Twitter Card tags are complete, with a preview image generated per article and served from the CDN, so shared links render properly on social and chat apps. Articles ship NewsArticle structured data (headline, author, publisher, published and modified times, section) so Google can treat them as news. The page arrives as full, semantic HTML with almost no JavaScript: an <article> per story, <time datetime> on dates, landmark elements (<header>, <nav>, <main>, <footer>), a heading order that follows the content, and alt text from the WordPress media field. A crawler, or a screen reader, gets the whole story on first load.

Off-page. I advised on the pre-launch social build-up so the brand had a consistent footprint, profiles and early posts under one name, before the site went live, feeding the navigational and brand-signal demand that helps Google tell the outlet apart from the similarly named sites. An RSS feed lets aggregators and readers syndicate stories, widening the surface that links back. Editorial link building ran through the client’s own PR and newsroom activity; my role there was advisory.

Technical. Pages are assembled on the server per request on a VPS, so content is always current and every URL returns a fast, complete HTML response, with the cost staying flat when traffic jumps. The rest follows from keeping the browser payload small:

• XML sitemaps including a dedicated Google News sitemap, so new stories are discovered within minutes of publishing.
• Canonical tags on every page, correct robots directives (articles and sections indexed, preview and utility pages not), and honest HTTP status codes with no soft 404s.
• HTTPS throughout, sensible caching from the server and CDN, and a service worker for caching and offline reads without serving stale pages to crawlers.
• An image pipeline with a CDN: responsive sizes, modern formats, explicit dimensions so nothing shifts as the page loads.
• A published llms.txt, with a fuller llms-full.txt, listing the sections and key pages as plain Markdown links, so LLM answer engines can read and cite the outlet without scraping rendered pages.
• Push-to-deploy with separate staging and production, so changes that touch markup, canonicals, sitemaps, or redirects are verified before crawlers see them.

What I delivered

• Brand and design. The visual identity, typography, and colour system, then wireframes and final layouts for every page type, search and forms, light and dark themes, and component states.
• Advisory. The early social media build-up, in a consulting capacity.
• Backend. WordPress set up as a headless source, a GraphQL layer over it, a custom image plugin and a preview plugin, and the content model for articles, sections, and authors.
• Infrastructure. The server, the packaged build, an image CDN, and a push-to-deploy setup with separate staging and production.
• Front end. Every page type, the data layer, paginated lists, RSS, sitemaps, and a preview image per article.
• SEO. Page markup search engines can read, sitemaps including a news sitemap, preview images, clean URLs, and the right crawler headers.
• Handover. Documentation, the technical and plain-language changelogs, and a newsroom running the site on its own.

How I worked with AI

Working closely with AI is about leverage. A workflow that is genuinely tuned lets one person move at the pace of a small team, and it puts options on the table that would otherwise be out of reach: too slow, too costly, or just not worth starting. The shift is not doing the same work faster; it is taking on more of it, and trying things you would have skipped.

This one was solo, on a deadline. Early on I used Gemini to think out loud, weighing structure, tradeoffs, and names before committing to anything. Once the shape was clear, Claude Code did the mechanical work with me: scaffolding components, wiring the data layer and its types, boilerplate, chasing bugs to a fix.

The architecture, design, and priority calls stayed mine. I fed it the project’s own conventions, so its output matched the codebase instead of needing a cleanup pass. The payoff was time: far less on repetitive work, far more on the decisions that shaped the site, and one person shipping a scope this size in months.

Result

Within ±5-6 months of launch, nusantarapost.news is the top organic result on Google for “nusantara post”, shown with sitelinks, above the older domains that share the name (nusantara-pos.com, nusantarapost.id).

The four goals it launched with were met: findable for the brand name, run by the newsroom itself, fast for readers, and steady when traffic jumps.

Stack

Astro, TypeScript, Tailwind CSS, Headless WordPress, a service worker for offline use and caching, an image pipeline with a CDN, running as a self-contained package on a VPS.