<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom" xmlns:dc="http://purl.org/dc/elements/1.1/">
  <channel>
    <title>DEV Community: Pavel Molyanov</title>
    <description>The latest articles on DEV Community by Pavel Molyanov (@pavel_molyanov_2ef90f9e5c).</description>
    <link>https://dev.to/pavel_molyanov_2ef90f9e5c</link>
    <image>
      <url>https://media2.dev.to/dynamic/image/width=90,height=90,fit=cover,gravity=auto,format=auto/https:%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Fuser%2Fprofile_image%2F4061137%2F566e891b-5176-4104-945f-255aaca6e09f.jpg</url>
      <title>DEV Community: Pavel Molyanov</title>
      <link>https://dev.to/pavel_molyanov_2ef90f9e5c</link>
    </image>
    <atom:link rel="self" type="application/rss+xml" href="https://dev.to/feed/pavel_molyanov_2ef90f9e5c"/>
    <language>en</language>
    <item>
      <title>A practical workflow for checking broken links after a content update</title>
      <dc:creator>Pavel Molyanov</dc:creator>
      <pubDate>Mon, 03 Aug 2026 19:57:39 +0000</pubDate>
      <link>https://dev.to/pavel_molyanov_2ef90f9e5c/a-practical-workflow-for-checking-broken-links-after-a-content-update-218a</link>
      <guid>https://dev.to/pavel_molyanov_2ef90f9e5c/a-practical-workflow-for-checking-broken-links-after-a-content-update-218a</guid>
      <description>&lt;h1&gt;
  
  
  A practical workflow for checking broken links after a content update
&lt;/h1&gt;

&lt;p&gt;A small content edit can quietly turn a working page into a bad user journey: a changed slug, a moved PDF, a redirected campaign URL, or a link that was already stale when it was added. The useful habit is not waiting for a full-site crawl. It is making a fast, page-level link check part of the publishing and QA workflow.&lt;/p&gt;

&lt;h2&gt;
  
  
  What to check
&lt;/h2&gt;

&lt;p&gt;For each important page, collect every anchor and verify four things:&lt;/p&gt;

&lt;ol&gt;
&lt;li&gt;
&lt;strong&gt;Does the URL respond successfully?&lt;/strong&gt; A 2xx response is usually the baseline.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Did it redirect?&lt;/strong&gt; A redirect may be intentional, but chains and unexpected destinations deserve a look.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Is the link pointing at the right place?&lt;/strong&gt; A technically valid URL can still land on an irrelevant or retired page.&lt;/li&gt;
&lt;li&gt;
&lt;strong&gt;Can the reader use it?&lt;/strong&gt; Mail links, telephone links, in-page anchors, and download links need separate judgment from normal HTTP pages.&lt;/li&gt;
&lt;/ol&gt;

&lt;h2&gt;
  
  
  A lightweight pre-publish routine
&lt;/h2&gt;

&lt;p&gt;I use this before publishing a large edit or after a migration:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Open the final page in the same browser context a visitor will use.&lt;/li&gt;
&lt;li&gt;Scan all links and group the results into valid, redirected, and failed.&lt;/li&gt;
&lt;li&gt;Start with error responses and fix the links in the source content.&lt;/li&gt;
&lt;li&gt;Review redirects one by one: a single intentional 301 is often fine; an old redirect chain is usually worth replacing with the final destination.&lt;/li&gt;
&lt;li&gt;Re-run the check after the edit, then keep a short CSV or ticket attachment for the release record.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;This is deliberately different from a crawler. A crawler is right for inventorying a whole domain and finding patterns at scale. A page-level check is ideal for the human moment when an editor, developer, or QA tester is already looking at the page that changed.&lt;/p&gt;

&lt;h2&gt;
  
  
  Why exports still matter
&lt;/h2&gt;

&lt;p&gt;A browser result view is convenient, but a CSV makes the follow-up easier. It can include the anchor text, destination URL, HTTP status code, and result description. That lets a writer fix copy, a developer investigate a route, and a project manager attach the evidence to a release checklist without passing screenshots around.&lt;/p&gt;

&lt;h2&gt;
  
  
  Common false positives to handle intentionally
&lt;/h2&gt;

&lt;p&gt;Some links should not be treated like normal web pages:&lt;/p&gt;

&lt;ul&gt;
&lt;li&gt;Mail and telephone links do not return HTTP status codes.&lt;/li&gt;
&lt;li&gt;Links blocked by CORS or authentication can need a manual check.&lt;/li&gt;
&lt;li&gt;An in-page anchor may be valid even though it never makes a network request.&lt;/li&gt;
&lt;li&gt;A redirect to a consent, login, or geo-specific page may be technically successful but still wrong for the intended audience.&lt;/li&gt;
&lt;/ul&gt;

&lt;p&gt;The goal is not to chase a perfect green dashboard. It is to know which links need a human decision.&lt;/p&gt;

&lt;h2&gt;
  
  
  The tool I built for this
&lt;/h2&gt;

&lt;p&gt;I made &lt;a href="https://broken-links-checker.com/" rel="noopener noreferrer"&gt;Broken Link Checker&lt;/a&gt; for this manual, page-level workflow. It is a Chrome extension that checks every link on the page being viewed, color-codes valid links, redirects, and failures, lets you jump to the affected element, and exports the results to CSV. It runs locally in the browser, with no account, ads, or tracking.&lt;/p&gt;

&lt;p&gt;You can also install it from the &lt;a href="https://chromewebstore.google.com/detail/broken-link-checker/cipdlgmjblnniiicohcmcafcncippbha" rel="noopener noreferrer"&gt;Chrome Web Store&lt;/a&gt;.&lt;/p&gt;

&lt;p&gt;If you already have a link-QA step, I would be interested in the edge cases that make it into your checklists.&lt;/p&gt;

</description>
      <category>productivity</category>
    </item>
  </channel>
</rss>
