{"slug":"solving-disqus-comment-fragmentation","locale":"en","isFallback":false,"translationAvailable":["en","id"],"translationUrls":{"en":"/api/notes/solving-disqus-comment-fragmentation?locale=en","id":"/api/notes/solving-disqus-comment-fragmentation?locale=id"},"title":"Case Study: Solving Disqus's URL Fragmentation Bug","description":"Why dev, preview, and production URLs fragment Disqus comment threads — and the fix to isolate comments to the production domain only.","date":"2026-02-16T10:00:00Z","updated":"2026-02-16T10:00:00Z","tags":["nextjs","vercel","disqus","debugging"],"content":"\nIt's a familiar moment for every site owner: you get that long-awaited email notification, \"Someone just commented on your article!\" You eagerly click the \"View Comment\" link, but your browser opens a strange, long URL like `https://...cloudworkstations.dev/...` or `https://ir-web.vercel.app/...`, not your production domain `https://snipgeek.com`.\n\nThis isn't just annoying; it's a symptom of a deeper technical problem that can fragment your comment base and ruin the user experience. We recently faced this issue firsthand. This is a transparent case study of its cause, our various repair attempts, and the final solution that ultimately resolved the problem.\n\n## Chapter 1: Initial Diagnosis - Different Environments, Different URLs\n\nThe problem is rooted in how Disqus identifies a page. The comment service locks a discussion thread to the **first URL** where it is rendered.\n\n- When we work in a development environment, the URL is `http://localhost:3000` or `https://...cloudworkstations.dev`.\n- When Vercel creates a preview, the URL is `https://ir-web.vercel.app`.\n- Only on the live site is the URL `https://snipgeek.com`.\n\nBecause Disqus sees these three URLs as three completely different pages, the comment threads become fragmented. The email notification will always point to the URL where the comment was first \"seen\".\n\n## Chapter 2: The Hunt for a Solution - From `NODE_ENV` to Domain Name\n\nWe tried several fixes, each with its own lesson.\n\n#### Attempt #1: Checking `process.env.NODE_ENV`\nThe initial idea was to load Disqus only if `NODE_ENV` was `\"production\"`. **This failed**. We quickly realized that *preview deployments* on Vercel also run in `production` mode, so the problem persisted.\n\n#### Attempt #2 (The Final Solution): Isolation by Domain Name\nAfter several failures, we arrived at the most robust and foolproof solution: **prevent Disqus from loading at all unless it is accessed from the final production domain.**\n\nThis solves the problem at its root. If the Disqus component never renders on `localhost`, `cloudworkstations.dev`, or `vercel.app`, it's impossible for it to register the wrong URL.\n\nWe implemented this directly within the `PostComments.tsx` component by checking `window.location.hostname`.\n\n```javascript\n'use client';\n\n// ...\n\nconst productionHostname = 'snipgeek.com'; // Final production domain\n\nexport function PostComments({ article }: PostCommentsProps) {\n  const [shouldLoad, setShouldLoad] = useState(false);\n  const commentsRef = useRef<HTMLDivElement>(null);\n\n  useEffect(() => {\n    // Observer for lazy-load\n    const observer = new IntersectionObserver(([entry]) => {\n      // When the component enters the viewport...\n      if (entry.isIntersecting) {\n        // ...check if the hostname is the production domain.\n        if (window.location.hostname === productionHostname) {\n            setShouldLoad(true);\n        }\n        observer.disconnect(); // Stop observing after the check.\n      }\n    });\n\n    if (commentsRef.current) observer.observe(commentsRef.current);\n    return () => observer.disconnect();\n  }, []);\n\n  if (!shouldLoad) {\n    // Display a placeholder if not on the production site\n    return (\n      <div ref={commentsRef} className=\"text-center ...\">\n        <p>Comments are only available on the production site (snipgeek.com).</p>\n      </div>\n    );\n  }\n\n  // If on the production site, render Disqus with the correct URL\n  const canonicalUrl = `https://${productionHostname}/blog/${article.slug}`;\n\n  return (\n    <DiscussionEmbed\n      shortname={disqusShortname}\n      config={{ url: canonicalUrl, ... }}\n    />\n  );\n}\n```\nThis approach is very specific: it checks **where** the user is, not just the *mode* the application is running in.\n\n## Chapter 3: A Fresh Start with a Clean Shortname\n\nEven after the code fix, we decided to take one extra step to ensure no future problems: **using a completely new Disqus *shortname* (site ID)**.\n\n**The reason:** The old *shortname* was already \"contaminated\" with development and preview URLs from our previous tests. Although we could use Disqus's migration tools, starting with a \"clean\" *shortname* that has never seen any URL other than the production domain is the best guarantee for long-term stability. We decided to use the ID `snipgeek-com` for the final production.\n\n## Conclusion: Lessons Learned\n\nThis debugging journey taught us an important lesson: when dealing with third-party services that are sensitive to URLs (like Disqus or other comment systems), the safest solution is to strictly isolate them to the **final production domain**, not just to \"production mode\". This prevents configuration \"leaks\" from preview environments and ensures the integrity of your data on the live site. Sometimes, starting over with a clean configuration is the fastest path to a stable solution.\n"}