About

6 Hole Ocarina Tabs is a free library of ocarina tablature for the 6-hole (pendant) ocarina. Every song is a plain HTML table you can read with or without JavaScript; turn sound on to hear each note as you hover. There are no accounts, no ads (currently), and no tracking, just tabs. We do track aggregate statics, dns queries, scans, and various anonymous usage and speed metrics.

How this site is built (and why it is different)

#

Most sites are WordPress running on a rented server. That stack needs constant security patching, leans on PHP and a stack of plugins, can be slow under load, and costs money every month whether anyone visits or not. This site takes the opposite approach: it is a set of pre-built HTML files served straight from a global content-delivery network. There is no server to break into, no database to leak, no plugins to patch, and nothing to go down at 2am. Below is what that decision buys a reader, and the work that went into it. None of this is required to enjoy the tabs, but a lot of care is behind them, so here it is in plain sight. If you want the full engineering writeup (the email infrastructure, the security model, the exact protocols and standards), read the technical deep dive.

Every song works with JavaScript turned off

#

The tablature is a real HTML table in the page. Note letters, SVG finger charts, and lyrics are all in the delivered markup, so a screen reader, a text-only browser, a search engine, or a phone on a weak connection gets the entire song. JavaScript only adds the extras: the hover-to-play sound and the note highlight. Switch it off and nothing you need to learn the song disappears. This is the single most important design choice on the site, and everything else is built to protect it.

Accessibility, held to a real standard (WCAG 2.1 AA)

#

Accessibility here is treated as a requirement, not a nicety, and the site targets WCAG 2.1 Level AA (the benchmark US web-accessibility law points at). Concretely:

• Every playable note cell is operable by keyboard, not just the mouse, with a visible focus outline and no keyboard trap.
• Each note is named for assistive technology (for example “C5 - A”), so a screen-reader user hears the note, not a shrug.
• State is never shown by color alone; an active note also changes shape and weight, and users who ask their system for reduced motion get no animation.
• Sound is an enhancement only. It never autoplays, and the note name is always present as text, so no information is carried by sound alone.
• Text and controls meet AA contrast in both the light and dark themes.
• There is a dedicated accessibility statement with a working way to report any barrier.

These are not claims on trust. An automated axe-core plus keyboard test suite checks the song pages, the editor, and the contact form on every change, so an accidental regression is caught before it ships.

Fast, because it carries almost nothing

#

Speed comes from sending less, not from a caching trick bolted on afterward:

• Finger charts are SVG line drawings, not photos or PNGs. They stay razor-sharp at any zoom and weigh next to nothing.
• Note sounds are synthesized in the browser on demand. There are no MP3 or WAV files to download.
• No song page ships a single binary media file.
• There is no front-end framework and no heavy JavaScript bundle; the site uses only what Hugo produces.
• The build itself trims the fat: Hugo minifies the CSS and JavaScript (strips every comment, space, and line break) and bundles many small files into one, so the browser makes fewer, smaller requests. The result is the compact .min files the site actually ships.
• Third-party requests are kept to the minimum, both for speed and for privacy.
• Those minified assets are fingerprinted (their name includes a hash of their contents), so a browser can cache them forever and safely, yet a change ships instantly under a new name.
• Pages are delivered from Netlify’s global CDN, close to the reader.

See for yourself: test this site on Google PageSpeed Insights.

Locked down (security headers and HTTPS)

#

The site sends the full set of security response headers that hardening scanners look for:

• HTTP Strict Transport Security (HSTS), including subdomains, so browsers only ever connect over HTTPS.
• A strict Content-Security-Policy that whitelists exactly what may load and upgrades any insecure request.
• X-Content-Type-Options, X-Frame-Options, Referrer-Policy, and a tight Permissions-Policy that switches off device APIs the site does not use (camera, microphone, geolocation, and the rest).

Because there is no server-side code, no PHP, and no database in the request path, the classic WordPress attack surface simply is not here. DNS is managed at Cloudflare, and HTTPS is enforced end to end. You do not have to take this on faith: scan the live site on securityheaders.com to see the headers it returns.

Findable (SEO and structured data, done properly)

#

• Each song page carries valid JSON-LD structured data (a MusicComposition record), so search engines understand it is a piece of music, not a random web page.
• Pages use a correct, single-H1 heading structure (H1, H2, H3) that both readers and crawlers can follow.
• A truthful sitemap.xml lists every page, with last-modified dates derived from the actual Git history rather than guessed.
• An llms.txt file offers a clean, plain-text map of the site to AI assistants.
• Every page ships a genuine meta description, and each song has a unique, human-written background introduction rather than filler.
• Related songs are generated automatically from each song’s category, so the internal linking stays honest and complete.

Search performance is monitored directly in Google Search Console (an owner-only dashboard, so there is no public link to share here).

See where the pages rank

#

The site already ranks at the top of Google for its own name. Here is the result for the head term this whole library targets:

Individual songs are built the same way, to win the exact search a real person types (a specific long-tail query like “song of time 6 hole ocarina tab”) rather than fighting a broad, generic term. Run one and see where this site lands. Results vary by location and shift over time, so treat it as a live check rather than a fixed claim, and the same structured data and llms.txt that feed classic search also help AI answers (Google’s AI Overviews and assistants like ChatGPT) surface and cite the right page:

• Song of Time - run the search
• Zelda’s Lullaby - run the search
• Amazing Grace - run the search
• Twinkle Twinkle Little Star - run the search

Moved off WordPress without breaking a link

#

The site is a straight lift-and-shift from the original WordPress site: every song keeps the exact same web address it had before. That parity is deliberate and strict, so old bookmarks, shared links, and search-engine rankings all keep working the day the new site goes live, with no chain of clumsy redirects in the way. The handful of redirects that do exist are tidy, permanent (301) ones for a few genuinely relocated pages and for the old category and tag archive paths, handled cleanly at the CDN rather than bolted on in code.

The move also unlocked the good parts of a modern static toolchain (Hugo):

• A custom 404 page that, instead of a dead end, points a lost visitor to search, the melody categories, and the homepage.
• Fast client-side search across the whole library, with no search server to run.
• Clean, permanent redirects for the small set of pages that genuinely moved, so nothing 404s that used to resolve.

Private by design

#

No accounts. No ads. No third-party analytics or tracking scripts following you around. The site does not need to know who you are to hand you a tab.

A contact form with no server and no middleman

#

The contact form still avoids a server and avoids handing your message to a third-party form host. A submission goes to a small serverless function (a Cloudflare Worker) that stores it in a database the site owner controls and sends a notification by email through Amazon SES. Spam is filtered with Cloudflare Turnstile rather than a puzzle that annoys real people, and if you have JavaScript off there is still a plain email fallback so you are never locked out.

Print a clean tab sheet

#

A dedicated print stylesheet means the browser Print command gives you a tidy practice sheet: the site navigation, sharing controls, and page furniture drop away, the title and tab stay, finger charts print as clear black-on-white, and the layout tries to keep each note (its letter, chart, and lyric) from splitting across a page break.

Built from reusable pieces, not copy-and-paste

#

Anything that repeats across the site is written once and reused everywhere, using Hugo’s shortcodes and shared templates. The contact form, the auto-updating song count, the related songs at the foot of each page, the sitemap, the structured data, and the support buttons are each a single component that every page pulls in. Drop a short tag like the contact one into a page and the whole form appears, wired up and consistent. The practical payoff: a change made in one place updates every page at once, there is no stale copy of the same code drifting out of sync, and there is no risk that page 40 is subtly different from page 4. It is the opposite of the WordPress habit of pasting a widget or a tracking snippet into dozens of pages by hand.

Backed up and guarded against regressions

#

The whole site lives in version control and is backed up on GitHub, so its full history is recoverable. The automated test suite mentioned above does double duty as a regression guard: each accessibility feature and each important route is pinned by a test, so a future edit cannot quietly break something that used to work.

A built-in ocarina tablature editor

#

Beyond the song library, the site includes a browser-based ocarina tablature editor for composing and sharing your own 6-hole ocarina snippets. Like everything else, it is plain JavaScript with no build step and no account required.

“Looks plain” is a choice, not a limit

#

A fast, text-first page can read as plain, and that is deliberate: every kilobyte not spent on decoration is a page that loads sooner and stays accessible. But nothing here forces a plain look. The design is driven by a mature, highly configurable theme (Blowfish), and its appearance is set in configuration, not baked into the pages.

Any look you want

#

Colors, fonts, spacing, the header, the menus, and the homepage style are all settings. This site uses a custom warm color scheme (burnt orange on slate) defined in a single small file; swapping it for a different palette, a photo-led hero, big featured images, a card grid, or a completely different homepage layout is a configuration change, not a rebuild. You can go as visual as you like, including graphics and imagery, without disturbing the fast, secure foundation underneath. Plain is simply the setting chosen here.

It already looks right on a phone

#

The layout is responsive from the start: it adapts from a wide desktop down to a narrow phone, switches between light and dark automatically, and the wide tab tables scroll inside their own frame so they never blow out the page or force sideways scrolling, even at small sizes or high zoom. There is no separate mobile site to maintain.

Share buttons, built in

#

Every article carries a row of share buttons (X, Facebook, Reddit, LinkedIn, WhatsApp, Telegram, email, and more) so a reader can pass a song along in one tap. Which networks appear is a single list in the configuration, on or off in seconds. It is the kind of feature people expect, and it is here without a plugin.

Tips and payments

#

The support buttons at the foot of each page (a tip jar or “buy me a coffee,” a song request, and a hire-me link) come from one small list of URLs. Point them at Ko-fi, a Stripe or PayPal link, or any donation or checkout page and the button updates everywhere; leave one blank and it simply disappears, so there are never dead links. Taking tips or payments does not require a store plugin or a database.

What this really means for a site owner

#

The technology is only interesting because of what it does for the person who owns the site. Here is the bottom line, in plain terms.

The WordPress trap

#

This is not a hypothetical. Before this rebuild, the site itself ran on WordPress, and a very old Perl CGI scripts, on a paid virtual server. That older tech stack was insecure, did not scale, and was never free. It is exactly the setup being left behind, so it is worth being specific about why it is a liability.

A typical WordPress site is a live program running on a rented server, backed by a database, extended by plugins, and reachable at a public address with an admin login. That convenience has a standing cost:

• It is a moving target for attackers. WordPress core, its theme, and every plugin need security updates, and a single missed patch or a weak password on the login page is how most small sites get defaced, injected with spam, or held for ransom.
• It needs ongoing care. Updates, backups, broken plugins after an update, and the occasional hacked-site cleanup are a recurring chore or a recurring bill.
• It costs money whether or not anyone visits, and it can slow to a crawl exactly when a page gets popular and the traffic spikes because of the way most people host wordpress sites (cheaply).
• A single wordpress server running on apache simply cannot scale like a static CDN tech stack can.
• Hugo has plugins just like wordpress, and a thriving ecosystem of safe, fast, secure plugins.

The payoff here

#

This site removes the whole category of problem rather than managing it:

• There is nothing running to hack. The live site is just finished HTML files. No admin login, no plugins, no database in front of visitors, so the common WordPress attack does not apply.
• There is almost nothing to maintain. No security-patch treadmill, no plugin conflicts, no surprise “your site was hacked” email.
• It is faster for everyone and it does not buckle under a traffic spike, because a global CDN simply hands out the same pre-built file to everyone, caching large portions of output.
• Server usage is offloaded to client javascript where possible, further enabling greater scale.
• It is cheap to keep online, and it stays online.

For a site owner that is the difference between renting a machine you must guard forever and owning a set of files that just work.

Security and speed from an invisible origin

#

Visitors never touch a server that belongs to this site. They reach the nearest edge of a global CDN, which hands back a file that was built ahead of time. The source lives in a private code repository (GitHub) and is compiled and published automatically (Netlify); the machine that builds it is not exposed to the public at all. There is no public server address to probe, no login page to brute-force, no database port to find. Compared with a WordPress box sitting at a fixed public IP with an open admin page, the attackable surface is effectively gone, and because the CDN caches the files worldwide, the site is both safer and faster at the same time.

What it actually costs to run

#

Rough figures, because prices change, but the shape is the point:

• Hosting: served from a CDN on a free tier that comfortably covers a site like this. No monthly server bill. The previous WordPress and Perl CGI setup ran on a virtual server at about $10 a month, paid every month whether the site had one visitor or a thousand.
• Contact and notification email: Amazon SES includes a free tier for the first year (a few thousand emails a month at no charge). After that it is about $0.10 per 1,000 emails, so even 100,000 emails in a month is roughly $10.
• For comparison, mainstream email platforms (Mailchimp and similar) bill by list size and volume; at 100,000 emails a month they commonly run from tens to several hundred dollars a month, often many times the SES cost, for the same delivery.

So the everyday cost of this site is close to zero, and even scaled up to serious email volume it stays a rounding error next to a typical marketing-email subscription plus a managed WordPress host.

Maintained a smarter way

#

Because the entire site is plain text (the content, the templates, and the settings all live as readable files in one code repository), an AI coding assistant like Claude Code can read every page, template, and configuration file at once and reason about the whole site together. A request like “document the technical features on the About page” or “check every song page for a broken heading” can be carried out consistently across the site in one pass, then previewed locally, checked by the automated test suite, saved to version history, and published automatically. This very page was updated that way.

That is a different world from WordPress, where the content sits in a database behind an admin screen, edits are made one page at a time by clicking through a dashboard, plugins are updated by hand, and every change goes straight to the live site with no preview and no automatic test. Here, changes are fast, reviewable, reversible, and safe by default.

The tech stack change that was made allows for AI to do much more of the work natively, vs requiring human labor (and cost) to do the same.

Who made this

#

This site was designed, built, and is maintained by James, the developer behind Digital Crunch. The goal was a small, free resource that also quietly does the engineering right: accessible, fast, secure, private, and durable, on hosting that costs almost nothing to keep running. If you want a site that works like this one, that is exactly the kind of work Digital Crunch does.

Questions or a song request? Get in touch.