What changed, why it changed, and how each update improves the media tracking experience.
OmniTrackr is a live media tracking app, not a static demo. Publishing a changelog gives users and reviewers a clear place to see that the site is actively maintained, that security work is taken seriously, and that public content is being improved over time. It also helps new users understand which parts of the app are mature, which areas recently changed, and what the product is trying to become.
The July update continues the AdSense-readiness work by making the public website easier to evaluate, easier to browse, and less dependent on thin user-generated snippets. The goal is not to create more pages for their own sake; it is to make the existing media tracker clearer and more useful before someone signs up.
min_chars=1 so existing public API callers can still request short opt-in notes without deleting or rewriting user content.This update is intentionally conservative. It improves what visitors and crawlers see on public pages while leaving the user-owned data model intact. It does not modify account records, private libraries, ratings, friendships, imports, exports, or dashboard workflows. Short personal notes still belong in private libraries; public discovery now defaults toward reviews that include enough context to help another person.
The June update focused on making OmniTrackr clearer to first-time visitors while protecting the existing app experience for signed-in users. The largest theme was turning the public website into a useful resource library instead of a thin shell around the login page.
These changes do not alter existing user libraries, accounts, ratings, reviews, friendships, or privacy settings. They add public routes, templates, metadata, and tests around the edges of the app so the logged-in tracker can keep behaving the same way.
OmniTrackr recently received several hardening updates focused on safer rendering and dependency hygiene. The app removed the need for CSP unsafe-inline, improved nonce handling for public pages, replaced risky HTML rewriting patterns with parser-based handling, and upgraded dependency versions flagged by security scanning. These updates are important because a media tracker stores user-created libraries, reviews, account settings, and privacy preferences.
Security scanning feedback also led to more focused regression tests. The test suite now checks that public content pages use nonce-based scripts, that generated API documentation is noindexed, that the AdSense loader is limited to eligible public pages, and that review text is not reinterpreted as HTML in the browser.
The public side of OmniTrackr now includes more than a sign-in page. Visitors can read guides, compare tracking methods, learn how TV and game tracking workflows work, review privacy practices, and browse public reviews when users choose to share them. That public content helps people decide whether OmniTrackr fits their habits before they create an account.
Category guides were expanded around real decisions: movies need ratings and review context, TV shows need season and episode memory, anime often needs seasonal backlog notes, games need platform and completion tracking, music needs album and relisten context, and books need reading status plus author notes. This gives each page a reason to exist beyond repeating the same feature list.
Public-page changes are covered by automated tests for sitemap entries, robots.txt rules, page metadata, navigation links, content markers, CSP behavior, ad-loader behavior, public review filtering, and frontend safety checks. The purpose is simple: search and policy improvements should not break account registration, login, media CRUD operations, import/export, statistics, privacy controls, or friend features.
That verification matters because OmniTrackr is already live. A content update is only successful if it improves the public site while leaving user-created media collections and account data untouched.
Planned improvements include more category-specific guides, clearer onboarding for new accounts, richer sample workflows, and continued dependency/security maintenance. The goal is to keep OmniTrackr useful for active users while making the public website easier for new visitors, search engines, and policy reviewers to understand.