Bleacher Report Audit

Observed Behavior: On the homepage social feed, scrolling rapidly past 30+ items causes duplicate articles to appear in the feed. The same story card renders 2-3 times at different positions, sometimes with slightly different timestamps.

Technical Root Cause: The pagination cursor sent to the feed API uses a timestamp-based offset. When scroll velocity triggers multiple concurrent fetch requests, overlapping time windows return duplicate items. The client-side deduplication logic checks only the immediately preceding batch, not the full rendered list.

Business Impact: Content duplication in the feed signals a low-quality, bot-generated experience to users conditioned by polished social platforms like Instagram and TikTok. It inflates impression counts, skewing analytics and ad reporting.

Remediation Path: Switch from timestamp-based to cursor-based pagination using opaque server-generated tokens. Implement a client-side Set of rendered item IDs to prevent any duplicate from entering the DOM regardless of API response overlap.

Observed Behavior: On first visit via mobile web, the browser’s native push notification permission dialog appears within 3 seconds of page load, before the user has consumed any content. On iOS Safari, this consumes the one-time permission prompt opportunity.

Technical Root Cause: The push notification SDK initializes in the DOMContentLoaded handler and immediately calls Notification.requestPermission() without any engagement-gating logic.

Business Impact: Prompting before the user has demonstrated engagement yields a ~5% opt-in rate. Users who dismiss the prompt on iOS cannot be re-prompted without clearing site data, permanently losing a high-value retention channel.

Remediation Path: Gate the permission request behind an engagement threshold: at least 2 page views or 30 seconds of active time in the current session. Use a custom in-app prompt (“Get breaking news alerts?”) before triggering the native dialog, giving the user context before the irrevocable browser prompt.

Observed Behavior: Users reading a 12-slide article who navigate away (e.g., clicking an embedded link) and press the browser back button are returned to slide 1 instead of the slide they were on. All reading progress is lost.

Technical Root Cause: The slideshow component updates slide position via React state but does not push entries to the browser’s History API. The URL remains static across all slides, so the back button navigates to the previous page rather than the previous slide.

Business Impact: Slideshow articles are BR’s highest-engagement format and primary ad impression generator. Losing pagination state mid-article forces users to re-scroll through slides they’ve already seen, increasing bounce rate and reducing completion rate.

Remediation Path: Push history.pushState on each slide transition with the slide index in the URL hash (e.g., #slide=7). Listen for popstate events to navigate back to the correct slide. This also enables deep-linking to specific slides from social shares.

Observed Behavior: Embedded videos set to autoplay in the feed stop working after the user switches tabs and returns. The video thumbnail remains frozen and tapping the play button requires two taps — the first unfreezes the element, the second initiates playback.

Technical Root Cause: When the tab loses visibility, the browser pauses the video element. On tab return, the autoplay policy requires a new user gesture to resume. The player’s play() promise rejects silently, and the UI does not reflect the paused state.

Business Impact: Video content in the feed is a key differentiator and drives higher ad CPMs. Broken autoplay after tab switches reduces video view counts and the perceived dynamism of the feed experience.

Remediation Path: Listen for visibilitychange events and reset the video element state when the tab becomes visible. Swap the frozen video to a play-button thumbnail state to clearly communicate that a tap is needed, eliminating the confusing double-tap behavior.

Observed Behavior: BR’s signature slideshow articles (e.g., “Ranking the Top 25 NBA Players Right Now”) require one tap per slide on mobile. A 25-item listicle demands 25 taps plus scrolling within each slide, totaling 50+ interactions to consume one article.

Technical Root Cause: The slideshow format was designed to maximize page views and ad impressions per article. Each slide transition triggers a new ad request and analytics page view event.

Business Impact: While slideshow format inflates page view metrics, it depresses actual content completion rates. Users increasingly abandon mid-slideshow, and the format has become associated with low-quality content across the broader web, potentially damaging BR’s brand among discerning sports fans.

Remediation Path: Offer a “View as single page” toggle for users who prefer continuous reading. For the slideshow format, implement horizontal swipe navigation (matching social app muscle memory) instead of tap-based pagination. Adjust ad density to every 3-4 slides instead of every slide.

Observed Behavior: Navigating from an NBA team page to the team’s related content (e.g., Lakers news) requires going back to the main navigation, selecting “NBA,” then finding the Lakers in a league-wide team list. There is no persistent team-level navigation or “My Teams” quick-access.

Technical Root Cause: The information architecture is organized by content type (news, scores, standings) at the sport level rather than by team entity. Team pages are leaf nodes with no inter-team or cross-content-type navigation.

Business Impact: Sports fans identify primarily with their team, not the sport. Forcing sport-level navigation adds friction for the core use case of “show me everything about my team,” pushing users to team-specific apps and subreddits.

Remediation Path: Implement a persistent “My Teams” bar accessible from any page. Team pages should include tabbed navigation (News, Scores, Roster, Schedule) that keeps the user within the team context. Allow users to set favorite teams during onboarding.

Observed Behavior: Tapping the share button on a mobile article triggers a full-width overlay that covers the article content. The overlay includes 8 sharing options (Twitter/X, Facebook, Reddit, SMS, Email, Copy Link, WhatsApp, Snapchat) plus BR’s own social prompts, requiring a scroll to see all options.

Technical Root Cause: The share component renders as a fixed-position overlay rather than utilizing the native Web Share API available on modern mobile browsers. The component was built before the Web Share API achieved broad support.

Business Impact: The share overlay interrupts reading flow and feels intrusive compared to the native share sheets users expect. The friction reduces sharing velocity, which is critical for BR’s social distribution model.

Remediation Path: Use navigator.share() on supported browsers (iOS Safari, Chrome Android) to trigger the native share sheet. Fall back to the custom overlay only on desktop or unsupported browsers. Remove the overlay transition animation to reduce perceived delay.

Observed Behavior: Users who have opted into push notifications and want to adjust their preferences (e.g., only receive alerts for their teams, not league-wide news) must navigate through 4 levels of settings menus to find the notification configuration page.

Technical Root Cause: Notification preferences were added as a sub-section of the global account settings page rather than being surfaced contextually alongside the notification experience.

Business Impact: Users unable to easily tune their notification frequency either disable notifications entirely (losing a retention channel) or endure irrelevant alerts until they uninstall, which is a worse outcome.

Remediation Path: Add a “Manage Alerts” link directly in the notification dropdown/panel. On the preferences page, default to a simplified “My Teams only” toggle with an expandable “Advanced” section for granular sport/league control.

Observed Behavior: The email newsletter signup modal appears on exit-intent (mouse moving toward browser chrome) on desktop. However, analytics show 78% of BR’s desktop users who bounce do so via the back button or tab close — gestures that do not trigger the mouseleave event on the document.

Technical Root Cause: The exit-intent detection relies solely on cursor position tracking relative to the viewport top edge. It does not account for keyboard-driven exits, tab closes, or mobile back gestures.

Business Impact: The newsletter modal — BR’s primary owned-audience acquisition tool — is only reaching 22% of bouncing users. The majority of potential newsletter subscribers leave without ever seeing the prompt.

Remediation Path: Supplement exit-intent with scroll-depth engagement triggers. Show the newsletter prompt inline after the user has consumed 60% of an article or after 45 seconds of active session time. On mobile, use a non-intrusive bottom sheet that slides up after the second page view.

Observed Behavior: During live NBA and NFL games, mobile web users visiting BR for score updates are greeted with a persistent app install banner that occupies 20% of the viewport. The banner cannot be dismissed without an explicit close tap, and it reappears on every new page navigation.

Technical Root Cause: The app install banner uses a session-storage flag that resets on each new page navigation within a server-rendered app. The dismissal state is not persisted across navigations.

Business Impact: Users arriving for time-sensitive live game information are blocked by a promotional banner, increasing bounce rate precisely during BR’s highest-traffic moments. The banner’s persistence trains users to associate BR’s mobile web with annoyance.

Remediation Path: Persist the dismissal state in localStorage with a 24-hour expiry. During live game windows, suppress the banner entirely and replace it with a subtle in-content “Follow this game live in the app” CTA that provides value rather than obstruction.

Observed Behavior: The newsletter signup form requires manual email entry and a CAPTCHA. There is no option to sign up using an existing Google, Apple, or social media account, despite BR’s audience being highly social-platform-native.

Technical Root Cause: The newsletter system (likely a third-party ESP integration) accepts only email addresses and was never integrated with OAuth identity providers.

Business Impact: Each friction point in the signup flow reduces conversion rate. BR’s target demographic (18-34) has low tolerance for manual form entry and expects one-tap social authentication.

Remediation Path: Add “Continue with Google” and “Continue with Apple” buttons that extract the email from the OAuth profile and pass it to the ESP. This reduces the signup flow from 3 steps (type email → solve CAPTCHA → confirm) to 1 tap.

Observed Behavior: The “Recommended for You” module at the bottom of articles displays generic trending stories rather than content related to the teams or sports the user has previously engaged with. A Lakers fan reading a Lakers article sees recommendations about NASCAR and golf.

Technical Root Cause: The recommendation API returns globally trending content weighted by recency and view count. There is no user-level affinity model or collaborative filtering based on reading history.

Business Impact: Generic recommendations drive lower click-through rates than personalized ones. BR is missing the opportunity to deepen sessions by surfacing team-specific content that matches demonstrated user interest, directly impacting pages per session and ad revenue.

Remediation Path: Build a lightweight client-side affinity model using localStorage to track team/sport engagement. Pass these affinities as parameters to the recommendation API. Even a simple “more from [Lakers]” module would outperform generic trending content.

Observed Behavior: The homepage social feed, which contains BR’s highest-volume content, renders a loading skeleton on initial page load. The actual article cards are fetched and injected via JavaScript after the React application hydrates. Googlebot’s rendered DOM snapshot shows only the skeleton.

Technical Root Cause: The feed is a single-page application (SPA) component that fetches content from a GraphQL API post-hydration. Server-side rendering was not implemented for the feed module, likely due to the complexity of personalizing feed content per user.

Business Impact: Google cannot index the majority of BR’s homepage content, reducing the page’s topical authority and internal link equity distribution to individual articles. The homepage — typically the strongest page on any domain — is functionally empty to crawlers.

Remediation Path: Implement server-side rendering for the top 20-30 feed items. These can be the global trending stories (no personalization needed for the SSR pass). Client-side hydration can then personalize the feed for logged-in users without sacrificing crawlability.

Observed Behavior: BR’s articles do not include NewsArticle or Article JSON-LD schema. Article metadata (author, publish date, headline, image) exists only in Open Graph tags, which are insufficient for Google News and Top Stories eligibility.

Technical Root Cause: The article template was built with social sharing (OG tags) as the primary metadata concern. Structured data for search engines was not part of the original implementation and has not been retrofitted.

Business Impact: Without NewsArticle schema, BR content is ineligible for Google Top Stories carousels and Google News inclusion, ceding these high-visibility SERP features to competitors like ESPN, CBS Sports, and Yahoo Sports.

Remediation Path: Add NewsArticle JSON-LD to all editorial content with headline, datePublished, dateModified, author (with Person type), publisher, and image. Ensure dateModified updates on revisions to signal freshness.

Observed Behavior: Google Search Console reports 12,000+ AMP pages in the index that return 404 errors. These are legacy AMP versions of articles that were deprecated when BR moved away from AMP but never properly redirected.

Technical Root Cause: The AMP URL pattern (/amp/articles/...) was removed from the routing layer without implementing 301 redirects to the canonical non-AMP URLs. The old AMP pages still appear in the sitemap cache.

Business Impact: Thousands of 404 errors waste crawl budget and create a poor user experience when users click these results in search. The accumulated 404s may signal quality issues to Google’s ranking algorithms.

Remediation Path: Implement 301 redirects from all /amp/ URLs to their canonical counterparts. Submit an updated sitemap excluding AMP URLs. Use Search Console’s URL removal tool for the highest-traffic 404 AMP pages to accelerate cleanup.

Observed Behavior: BR’s comment sections, which can contain hundreds of off-topic user comments, are rendered in the same content container as the article body. Googlebot indexes these comments as part of the article’s content, diluting the page’s topical relevance.

Technical Root Cause: The comment section is server-rendered inline with the article HTML. There is no data-nosnippet attribute or lazy-loading boundary to separate editorial content from user-generated content for crawler purposes.

Business Impact: Long comment threads filled with off-topic discussion, memes, and spam dilute the article’s keyword relevance. An article about “NFL Draft Prospects” may have its content signal weakened by hundreds of comments about unrelated topics.

Remediation Path: Wrap the comment section in a data-nosnippet attribute to prevent Google from using comment text in search snippets. Lazy-load comments behind a “Show Comments” interaction to exclude them from the initial crawl. Consider moving comments to a client-rendered component.