How I Got Deindexed by Google (And How I Fixed It)

The goal here was simple: get something on screen fast, then load the rest. Users should see content within 200-300ms, not wait for fonts and non-critical CSS.

Changes made:

The meta media="print" trick is clever: browsers don’t block rendering for print stylesheets. Once loaded, JavaScript swaps the media attribute to all and the styles apply. Meanwhile, the page has already painted with system fonts.

Fonts using font-display: swap render immediately with fallback fonts, then swap to custom fonts once loaded. No invisible text, no layout shift timing.

This needed a complete build pipeline overhaul. Images were the single biggest performance bottleneck, and fixing them required both tooling and template changes. The gains here were substantial — both in terms of file sizes and user experience.

Implementation:

The Sharp-based pipeline runs during Maven’s package phase. It detects images over 800px, generates three responsive sizes, converts to WebP, and keeps original format as fallback. The HTML processor then transforms <img> tags to <picture> elements with proper srcset attributes.

Here’s what the compression achieved in practice. Each row shows an actual image from the blog, with its original size and the WebP variants generated at different widths. The percentage shows how much smaller each WebP version is compared to the original:

¹ Small PNG images may increase in size at 1200w due to WebP encoding overhead, but the 400w and 800w versions still provide significant savings for mobile users.

The results show dramatic differences between PNG and JPEG compression to WebP. PNG images with large solid color areas (like the mail-regex featured image) achieve 88-96% compression ratios. JPEG images compress moderately but still meaningfully, typically 60-80% at the 1200w size and 90%+ at mobile sizes.

The real performance win comes from responsive sizing. A mobile user loading the 400w version uses only 4-8 KB for images that were originally 200+ KB. Desktop users on 2K displays get the 1200w version, which still saves 20-88% depending on the source format.

Here’s what the build script generates from a simple AsciiDoc image:: directive:

The browser automatically selects the best format and size. WebP-capable browsers get WebP; older browsers fall back to PNG. Mobile devices get smaller files, desktops get higher resolution.

The JavaScript was causing re-rendering steps which made the text reflow (forced reflows) — the browser had to recalculate layout mid-execution. This kills performance because layout calculation is expensive. Google and other search engines will penalize this behavior.

The following fixes to the jbake-author-template resolved these issues:

The main idea was: batch all DOM reads together, then batch all DOM writes. This will enable rewrites in an early rendering stage, avoiding interleaved reads and writes that cause reflows.

The core idea here:

The sidebar scroll fix was particularly tricky — it needed to track scroll position without constantly triggering reflows during scroll events.

Because the blog is based on jbake, I »naturally« started with Apache Maven as the build tool. However, it did not take long to see that enourmous post-processing was needed: Minification and compression of HTML and images, responsive image generation, and so on. Maven alone is not well-suited for these tasks, but can be used as an orchestrator to start npm/yarn/node-based tasks.

The build consists of several steps:

For the bmarwell.de landing page specifically, I also implemented pre-compression at build time — generating .br, .gz, and .zst files to avoid on-the-fly compression overhead. The results were significant and impressive: HTML compressed from 26KB to 8KB with Brotli (69% reduction), and the avatar image went from 20KB JPG to 13KB WebP (35% reduction).

The blog uses my custom JBake Author theme, available as a template repository.

The build is reproducible and deterministic — same input always produces same output. No manual steps, no "works on my machine" issues.

Getting the basics right: one H1, proper hierarchy, semantic elements. This seems obvious, but it’s easy to break when templates get complex. All those little details added up into the following changes:

The single H1 rule is critical — it tells search engines what the page is about. Heading hierarchy (H1 > H2 > H3) creates a document outline that screen readers and search engines can parse. Semantic elements like <article> and <section> add meaning beyond just visual structure.

JSON-LD (JavaScript Object Notation for Linked Data) is structured data that can be embedded in web pages to describe their content in a machine-readable format. Unlike HTML, which is targeted at humans, JSON-LD is designed to be easily parseable for bots or tools. It is a formal JSON-based language that search engines, social media platforms, and other automated systems commonly understand.

I have actually worked with JSON-LD before — back in 2015, I wrote a plugin that added JSON-LD markup to the webtrees genealogy software. That early experience taught me the value of structured data, but somewhere along the way, I forgot to apply those lessons to my own blog.

JSON-LD is an addition to semantic HTML and schema.org microdata — they’re complementary, not competing. Think of semantic HTML as document structure, HTML microdata as inline annotations, and JSON-LD as explicit metadata that doesn’t clutter your markup.

The three layer together: semantic elements provide structure, microdata annotates specific content, and JSON-LD delivers the complete picture in one clean block.

Google will check for the existence for any of these formats. I do not know which one will be used, but all of them are understood by Google. My best guess is that Google favours blogs with multiple formats, as this shows effort and dedication to structured data.

I would really love to see rich snippets for my articles in Google search results. Be it a definition, a person card or article details — rich snippets make results stand out and are really helpful for users. They are generated from structured data like JSON-LD and schema.org markup we discussed earlier.

In my (this) blog’s case, the structured data enables:

These rich results aren’t just cosmetic — they increase click-through rates significantly. A search result with author info and a clear breadcrumb looks more trustworthy than plain blue links.

The connection here is the following: JSON-LD provides the raw data, schema.org defines the vocabulary, and Google transforms that into rich snippets. Without the structured data, Google has to guess at this information (and often guesses wrong and probably shows nothing at all). With it, you can control what might appear in search results.

Every page needs metadata — for search engines, for social media, for users. Missing metadata means search engines have to guess, and they often guess wrong.

Additions:

Meta descriptions appear in search results — they’re your pitch to potential visitors. Open Graph tags control how links look when shared on Facebook, LinkedIn, etc. Twitter Cards do the same for Twitter.

Without these, your content might be great but look terrible when shared.

Full-text RSS feeds are an invitation to content scrapers. The idea here: Scrapers might just repost my blog contents with better markup, SEO, performance and faster indexing. This means: They can republish your content instantly, potentially getting indexed before you do.

So I made the following changes to my feed:

Excerpts give readers enough context to decide if they want to read more, while forcing them to visit your site for the full article. This protects your content while still providing a useful feed.

Not every page should be in Google’s index. Tag and archive pages create duplicate content — the same article appearing on multiple URLs.

Implementation:

noindex, follow tells Google "don’t index this page, but do follow the links on it." This keeps tag pages out of search results while still allowing Google to discover articles linked from them.

Canonical URLs and next/prev links help Google understand pagination — that /page/2/ is part of a series, not duplicate content.

Sitemap priorities should reflect actual importance and update frequency, which was not something I configured before. The sitemap was just a collection of links without priorities and/or frequencies. Setting everything to 0.8 or nothing at all tells Google nothing.

For me, I think these are realistic priorities and change frequencies:

Posts are high priority because they’re the main content. More recent posts get slightly higher priority since they’re more relevant. Since I do not publish new content frequently, weekly for the homepage is probably a reasonable change frequency. Archives are lower because they are merely navigational. The feed changes more frequently but shouldn’t compete with actual content for crawl budget.

These values guide Google’s crawler toward the content that matters most.

I modified and added pages that establish expertise and personality:

These aren’t just random additions. This content establishes who I am beyond just technical articles — a musician, a certified professional, someone with interests outside coding. Google wants to see real people with diverse backgrounds, not content farms.

For multilingual content, structure matters as much as translation quality:

The parallel structure of translated pages helps Google understand that these are translations, not duplicate content. Any human-made natural translation sounds better and reads better than literal word-for-word translations.

I established standards for maintainable content and created an internal copilot-instructions.md file with guidelines:

These guidelines will make future content consistent and easier to manage in version control. This will also help me to use copilot to check for deviations from these standards. But the corrections will still be done manually.

Eliminated code duplication that made maintenance difficult:

When image path logic existed in five different templates, fixing a bug meant five separate edits. By extracting a single macro this means one fix needs to be done for future bugs. This reduces bugs and makes the codebase more maintainable.

As stated before, I created a file .github/copilot-instructions.md with comprehensive guidelines:

The documentation captures decisions and rationale that would otherwise be lost. Future contributors (including future me) can understand why things work the way they do.

While I usually have tools and strict coding standards configured in Apache Maven (or in my IDE or just in my head), I did not apply them to this blog so far. Here is what I added as code standards for this blog project:

These standards prevent issues like inconsistent line endings breaking shell scripts, or trailing whitespace causing Git noise. They’re not about aesthetics — they’re about reliability.