Applying the SEO guide to Heliocite

Start with what already works

The audit followed all eight areas in the SEO good practices guide. The site already delivered complete HTML, declared canonical URLs, allowed crawling and returned real 404s. HTTP and www addresses redirected to the HTTPS domain, and directory URLs without a trailing slash redirected to the slash version.

Those checks established a starting point. They did not establish whether Google had crawled or indexed the pages. The first Search Console baseline remains a dated observation; no fresh authenticated Search Console data was available for this audit.

One page, two addresses

The guide was available at both /practices/ and /practices/index.html, each returning 200 OK. The homepage also loaded at /index.html. Canonical tags pointed to the preferred addresses, but the server still served both copies.

Firebase Hosting now has permanent redirects for the explicit file paths:

• /index.html redirects to /.
• /practices/index.html redirects to /practices/.
• Nested post paths, such as /blog/day-one/index.html, redirect to their directory URLs too.

The nested case mattered. The first rule worked for a section but failed for a post two levels down. Testing in the Firebase Hosting emulator caught that, and a revised rule passed the nested-path check. Query strings survive the redirect. Unknown pages still return a real 404.

Make the publisher and the connections visible

The posts already named Heliocite as their author in structured data, but readers had no visible byline. Each post now has one, linking to a new About page. That page identifies Kubernetikos AB as the publisher and explains the guide’s research method, including AI assistance.

Every footer links to About. Each post also has a breadcrumb trail and a short related-reading section, connecting the implementation stories with the relevant part of the guide. The guide links back to the case studies. These are ordinary HTML links that readers can follow without JavaScript.

The practices heading now explicitly says “SEO good practices”. The sitemap includes the new About page and the existing Privacy page, bringing it into line with the indexable public pages.

Bring the markup and the prose into line

The posts retain their BlogPosting markup. Their author URLs now point to About, and their BreadcrumbList markup matches the visible trails. Publication dates are preserved; modification dates reflect the substantive edits.

Older posts also needed a few corrections:

• The day-one post now qualifies its performance and cause-and-effect claims, and links to the later analytics change.
• The sitemap post labels its five-URL list as the first version and links to the current sitemap.
• The baseline post distinguishes speculation about backlink discovery from observation and cites Google’s criteria for using the disavow tool.
• The analytics post no longer suggests that dividing Analytics sessions by Search Console clicks establishes a consent acceptance rate. They count different things.

That last correction follows Google’s explanation of the differences between the two tools. A comparison can help investigate trends; it cannot isolate consent from all the other reasons their totals differ.

What was checked

The initial audit checked ten HTML pages at two mobile sizes, 320 × 568 and 375 × 667, and at a 1280 × 900 desktop size. None produced document-level horizontal overflow. Local checks covered 130 internal links and fragments, the JSON-LD, titles, descriptions, headings and sitemap coverage.

The browser made no Analytics script requests before consent. Declining hid the banner and remembered the choice. The site still uses the same self-hosted font and deferred consent script; this work added no JavaScript.

A cached browser performance check reported no layout shift, but it supplied no interaction sample. It was a lab observation, not a field Core Web Vitals assessment. There is no measured performance gain to report.

What remains to be measured

Google’s Rich Results Test was attempted with the updated article code. It returned “Log in and try again”, and that external check was deferred. Local markup checks passed, but Google’s validation is still pending.

After release, the redirects need a production check. Search Console can then show whether Google’s chosen canonicals match the declarations and whether the changed pages have been crawled and indexed. Available field performance data and comparable search impressions and clicks will need a later review.

These changes make the site more consistent with its own advice. They do not yet tell us anything about a change in rankings or traffic.