A web-technology case study for builders — filed under "look before you assume."
The assumption worth killing first
Show most people a slick, content-heavy casino brand site — big hero banner, a welcome-bonus offer, a slots grid, payment tables, an FAQ block, a multi-language switcher — and ask them what it's built on. Nine out of ten will say WordPress. It's a reasonable guess. WordPress powers something in the neighborhood of 40% of the web, the casino-affiliate niche leans on it heavily, and the genre has a house style that screams "premium WP theme with a page builder."
So when you land on spinboss.io, the instinct is to file it under "custom WordPress template" and move on. That instinct is wrong, and the reason it's wrong is the whole point of this article. Spinboss is not WordPress. It's a static site generated by Hugo, served from Netlify's edge, styled with Tailwind CSS. There is no PHP, no MySQL, no wp-admin, no plugin stack. It's a folder of pre-built HTML files sitting on a CDN.
This teardown walks through how I know that, what the real stack looks like, why a casino brand would deliberately skip WordPress, and how you'd rebuild something equivalent yourself. If you write about how sites are made, the Spinboss build is a clean, real-world illustration of the static-site shift that's been eating into WordPress's territory for the last several years.
How to check what a site is really built on
Before making a single claim about anyone's stack, you look. Here's the exact evidence trail on Spinboss, in the order any careful reviewer should follow — because the credibility of everything downstream depends on it.
1. Read the generator meta tag. View source on the homepage and you find this in the <head>:
html
<meta name="generator" content="Hugo 0.148.2">That single line settles the WordPress question. WordPress emits <meta name="generator" content="WordPress 6.x">. Spinboss emits Hugo — a static site generator written in Go — at version 0.148.2. Generator tags can be stripped or spoofed, so it's not proof on its own, but it's the first and strongest tell, and everything else corroborates it.
2. Read the response headers. A quick look at the HTTP response is even more revealing than the HTML:
HTTP/2 200
server: Netlify
cache-status: "Netlify Edge"; fwd=miss
cache-control: public,max-age=0,must-revalidate
strict-transport-security: max-age=31536000
etag: "…-ssl"server: Netlify and cache-status: "Netlify Edge" tell you the site is hosted on Netlify and served from their global edge network. A WordPress site typically answers with Apache or Nginx and carries cookies, X-Pingback headers, or headers from a caching plugin. None of that is here. The etag and accept-ranges: bytes are the signature of a plain file being served off a CDN, not a page assembled on the fly by PHP.
3. Look at the asset paths. Spinboss loads a stylesheet at /css/custom.css, references Tailwind CSS in its markup, and serves its imagery as .webp files from /images/ (hero.webp, logo.webp, feature.webp, spinboss-bonus.webp). These are flat, static paths. There is no /wp-content/themes/…, no /wp-content/plugins/…, and no /wp-json/ REST endpoint anywhere in the page — the three fingerprints that betray a WordPress install almost every time. Their absence is conclusive.
4. Look at the URL structure. Every internal link is a clean, trailing-slash directory URL: /games/, /live-casino/, /promotions/, /bonus-guide/, /withdrawal-guide/, /terms-and-conditions/. That pattern — one physical index.html per directory — is exactly what a static generator outputs. WordPress can be coaxed into pretty permalinks too, but combined with everything above, this seals it.
5. Check the language variants. The header exposes four locales — English at the root, plus /pl-pl/, /it-it/, and /nl-nl/. Those are Hugo's multilingual directory conventions, not WPML or Polylang query strings.
Five independent signals, all pointing the same way. That's how you make a technology claim you can defend — not by eyeballing the design and guessing the genre.
The real stack, layer by layer
Static site generator: Hugo
Hugo is the engine. It's a single Go binary that takes content written in Markdown, merges it with HTML templates, and spits out a complete folder of static HTML, CSS, and assets. There's no database and no server-side language at request time — all the "thinking" happens once, at build time, on the developer's machine or in a CI pipeline. Hugo is famous for being blisteringly fast at this; it builds thousands of pages in the time other generators take to build dozens.
For a casino brand site, Hugo's content model fits naturally. Each guide — the login guide, bonus guide, withdrawal guide, the about page, the T&Cs — is almost certainly a Markdown file with some front-matter (title, description, offer figures) at the top. Repeated visual components like the slots grid, the "Why choose us" feature cards, the payment-method tables, the testimonials, and the FAQ accordion are Hugo partials and shortcodes — reusable template fragments fed by structured data. That's why the page reads like a system of repeating blocks rather than a one-off hand-coded page: it's templated, just templated at build time instead of on every request.
The version string, 0.148.2, tells you they're on a current release (Hugo moves quickly), which suggests an actively maintained build rather than something scaffolded once and abandoned.
Styling: Tailwind CSS plus a custom sheet
The markup carries Tailwind CSS. Tailwind is a utility-first framework: instead of writing semantic classes like .hero and .btn-primary in a separate stylesheet, you compose styling directly in the HTML from small single-purpose utilities (flex, px-4, text-center, bg-gray-900, and so on). It's the dominant styling approach in modern static and JAMstack builds because it keeps design decisions next to the markup and, when run through its build step, ships only the classes you actually use.
Alongside Tailwind, Spinboss loads /css/custom.css for the things utilities don't cover cleanly — bespoke animations (the withdrawal-speed timeline, the payout counter), gradients, and brand-specific tweaks. The <meta name="theme-color" content="#030712"> — a near-black slate — signals a deliberate dark, premium palette defined as a design token rather than ad-hoc colors. This Tailwind-plus-thin-custom-layer pattern is the standard modern setup, and it's the opposite of a WordPress theme's typical enqueue of a large, monolithic style.css.
Hosting and delivery: Netlify edge
The site is on Netlify, one of the anchor platforms of the JAMstack movement. The typical workflow is: push to a Git repository, Netlify runs hugo to build the site, and the resulting static folder is deployed across a global CDN. Every visitor gets a pre-built HTML file from an edge node geographically near them. There's no origin server executing code per request, which is why the cache-status: "Netlify Edge" header shows up and why time-to-first-byte on a build like this is usually excellent.
Security-wise the response advertises HSTS (strict-transport-security: max-age=31536000), forcing HTTPS for a year, and the site's own copy claims 256-bit SSL. On a static host, TLS and these headers are platform defaults rather than something you bolt on with a plugin.
Content and imagery
Images are served as WebP, a modern format that's typically 25–35% smaller than equivalent JPEG or PNG at the same visual quality. The Open Graph image is declared at a proper 1200×630, so link previews on social and chat apps render cleanly. Everything about the asset handling points to a build pipeline that optimizes images ahead of time rather than serving whatever was uploaded through a CMS media library.
WordPress vs. static: why skip the obvious choice?
Here's the interesting part for a builder audience. WordPress would have been the path of least resistance for this kind of site. So why did whoever built Spinboss go static instead? The trade-offs are worth laying out honestly, because "static is always better" is as lazy as "it must be WordPress."
Where static (Hugo + Netlify) wins for a site like this:
Speed. Pre-built HTML off a CDN is about as fast as the web gets. No database queries, no PHP execution, no plugin overhead on the critical path. For a landing-page-driven business where bounce rate and conversion track closely with load time, that's a direct commercial advantage.
Security and attack surface. This is the big one for the gambling niche, which is a relentless target for automated attacks. WordPress's power comes from its plugin ecosystem, and that ecosystem is also its largest vulnerability surface — outdated plugins are the single most common way WordPress sites get compromised. A static site has no login endpoint, no database, and no server-side code to exploit. There is literally no wp-admin to brute-force. You can't SQL-inject a site that has no SQL.
Operational simplicity and cost. No server to patch, no PHP version to babysit, no database backups, no caching plugin to configure. A static site on a CDN scales to a traffic spike without anyone touching anything, and hosting is cheap or free at modest volume.
Reproducibility. The whole site is a Git repository. Every change is versioned, every deploy is atomic, and rolling back a bad change is instant. Multi-language expansion — the EN/PL/IT/NL setup here — is a first-class Hugo feature rather than a plugin you have to trust.
Where WordPress would have won:
Non-technical editing. WordPress's killer feature is that a marketer can log in and change the bonus figure or publish a promo without touching code or running a build. On Spinboss's stack, updating the "200% up to €4,000" offer means editing a Markdown file or data file and triggering a rebuild — trivial for a developer, a barrier for someone who only knows a CMS dashboard. (Static builds can close this gap with a headless CMS layered on top, but out of the box it's a developer's workflow.)
Dynamic, per-user features. Anything genuinely personalized — a real logged-in account area, a live cashier, real-time game feeds — can't be static. And notably, Spinboss doesn't try. Every "Login," "Play Now," "Deposit," and "Claim Bonus" button routes to /play, which is the handoff point to the actual gaming platform. That's the key architectural insight: the marketing site and the gaming application are two different systems. The static Hugo site is a fast, cheap, hard-to-hack brochure-and-SEO layer; the moment a user needs to do something dynamic, they're punted to the real platform. This separation is why a static generator is a perfectly rational choice here — none of the hard, dynamic work happens on this site at all.
Plugin ecosystem. Need a forum, a review-aggregation widget, a specific analytics integration? WordPress probably has a plugin. On static you either find a third-party embed or build it.
The takeaway isn't "static beat WordPress." It's that Spinboss's builder correctly identified this as a content-and-conversion site, not an application, and picked the stack that optimizes for speed, security, and low overhead while delegating all the dynamic behavior elsewhere. That's a deliberate architectural decision, and a defensible one.
Design and content architecture
Even though it's not a page builder, the site is clearly built from a component library. Walking the homepage top to bottom you can see the reusable blocks: a fixed header with a slide-out menu and language switcher; a hero with the headline offer and wagering microcopy; anchor-link navigation to on-page sections; a slots grid with per-game badges (Popular, High RTP, Jackpot, Bonus Buy) and provider labels; a live-casino grid; a four-up "why choose us" feature row; a Trustpilot-style social-proof band; a "slot of the week" feature card; a testimonials row; long-form guide sections for bonus, login, deposit, withdrawals; comparison tables for payment methods; a security section; a verdict; an app section; a support block; a final CTA; an FAQ; an author bio; and a dense footer.
Each of those is the kind of thing you'd implement once as a Hugo partial or shortcode and then drive with data. The payment tables in particular — identical structure, different rows for deposits vs. withdrawals — are the giveaway of a data-driven template rather than hand-typed HTML. The FAQ is almost certainly generated from a data file and rendered with FAQ schema for search engines. The author bio ("Daniel Morrison," a Malta-based analyst) and the "last updated" stamp are classic E-E-A-T signals injected via template to satisfy Google's quality guidelines for YMYL (your-money-your-life) content, which gambling squarely is.
One honest note for accuracy's sake: the visible footer copyright reads "© 2026" while the author block says "Last updated: January 2024." That kind of mismatch is common when the footer year is auto-generated by the template ({{ now.Year }} in Hugo) but a content block carries a hard-coded date — itself a small tell of a templated static build.
How you'd rebuild this yourself
If you wanted to replicate the Spinboss approach as a learning exercise, the recipe is approachable:
Install Hugo (the extended edition, which bundles the asset pipeline). Run
hugo new site mybrandto scaffold the project.Set up Tailwind via Hugo's asset pipeline or a small Node build step, plus a thin
custom.cssfor animations and brand flourishes.Model your content as Markdown files with front-matter for the pages, and YAML/TOML/JSON data files for the repeating structures — game lists, payment methods, FAQ entries.
Build the components as partials and shortcodes: header, hero, game grid, feature cards, tables, FAQ, footer. Drive them from the data files so content edits never touch markup.
Add multilingual config for your target locales, mirroring the
/pl-pl/,/it-it/,/nl-nl/pattern with translated content files.Optimize images to WebP as part of the build, and set your Open Graph tags.
Deploy to Netlify (or Cloudflare Pages, Vercel, GitHub Pages) by connecting the Git repo and setting the build command to
hugo. Push to deploy; the CDN handles the rest.Route dynamic actions off-site — login, cashier, gameplay — to whatever application backend actually handles them, exactly as Spinboss routes everything to
/play.
That's the entire architecture. No database to provision, no server to harden, no plugin updates to chase.
The verdict for builders
Spinboss.io is a textbook example of the modern static-first brand site: Hugo for generation, Tailwind for styling, WebP for imagery, Netlify for edge delivery, multilingual by design, and a clean separation between the static marketing layer and the dynamic platform it hands users off to. It is emphatically not a custom WordPress template, and the two-minute evidence trail — generator tag, Netlify headers, Tailwind classes, static URLs, zero wp-* paths — makes that unambiguous.
The broader lesson is the one worth carrying into your own reviews: the genre of a site tells you nothing reliable about its stack. Casino sites feel like WordPress, so people assume WordPress. But a growing number of them have quietly moved to static generators precisely because the security and speed math favors it, and because the genuinely dynamic parts of a gambling business live in a separate application anyway. When you write about how sites are built, check the generator tag and the response headers first. The design is the costume; the headers are the truth.