WordPress internal links returning 404: scheduled checks, diagnosis, and repair workflow

When WordPress internal links return 404 errors, do not rush to replace them in bulk. The correct sequence is to identify which article contains the link, check the final URL after redirects, find the actual target page on the site, update the original content, and then crawl it again for verification. If the site has a large amount of content, scheduled tasks can handle the crawling, evaluation, generation of repair recommendations, and rechecking, but manual confirmation should still be retained before publishing any changes.

Why a link can look normal but return a 404 when visited

In most cases, the page has not simply disappeared; its path has changed. After an article is moved to a new category, the old URL may be missing part of the directory path; an editor may have copied a preview link; the target article’s Slug may have changed; or the site may redirect HTTP to HTTPS and then pass through another incorrect redirect. Looking only at the link text in the editor makes it difficult to distinguish among these possibilities.

Another detail that can easily lead to misclassification is that an initial response of 301 or 302 does not mean the link works. The checking tool must continue following redirects until it receives the final status. If the redirect chain ultimately lands on a 404 page, the internal link still needs to be fixed.

Define the scope first to prevent a single task from overwhelming the site

Small sites can check all published posts. Content and e-commerce sites are better suited to batch processing, such as checking recently updated articles, traffic landing pages, and product-related content first. Do not treat admin editing links, login URLs, logout links, or URLs with one-time parameters as ordinary internal links.

• Source scope: crawl only published content; do not process drafts or private pages.
• Domain scope: check only the site’s own domain and explicitly permitted subdomains.
• Request limits: set timeouts, concurrency limits, and retry counts to avoid excessive requests within a short period.
• Result records: save the source article, anchor text, original URL, final URL, status code, and check time.

A reusable workflow for checking broken WordPress internal links

1. Retrieve the actual article URLs from WordPress

Use the WordPress REST API or sitemap to retrieve published articles whenever possible; do not guess URLs from titles. A news section may include a /news/ prefix, while a tutorial section may use a different path. A guessed URL may look valid but not exist at all.

2. Extract internal links from the content

Parse each article’s href values, convert relative URLs to absolute URLs, and remove interference from in-page anchors during status checks. When the same URL appears in multiple articles, it only needs to be requested once, but the report must retain every source location so that all occurrences can be fixed in one pass.

3. Follow redirects and record the final status

Try a lightweight request for each link first. If the server does not handle HEAD correctly, switch to GET. A 200 response usually means the page is accessible. For 301 and 302 responses, continue checking the final destination. Add 404 and 410 responses to the list requiring attention. When encountering a 403, 429, or timeout, do not immediately classify the page as unavailable, as these responses are more likely to be related to access restrictions, request frequency, or network conditions.

4. Find the correct target instead of deleting the link

First confirm the target page using the article ID, Slug, internal search results, or the permalink returned by the API. If only the directory has changed, replace the link with the actual URL. If the content has been merged, link to the new page that now addresses the original topic. Only consider removing the link if no suitable target exists. Check the anchor text as well so that the URL is not fixed while the text still refers to the old topic.

5. Crawl the front-end page again after making changes

An API response indicating a successful update is not enough. Caching, content filters, or incorrect update fields may cause the front end to continue displaying the old link. After making the repair, request the public page again, confirm that the old URL has disappeared and the new URL is actually present, and recheck every internal link. The task is complete only after it passes this verification.

How to turn the check into a scheduled task

If new articles are published every week, you can schedule checks at a fixed frequency in SmaugBrain. Task inputs include the site URL, check scope, permitted domains, and notification target. The output is a list of items requiring repair. For related scheduled-task concepts, see AI-powered office automation and scheduled-task workflows.

It is advisable to divide the automation into two stages. The first stage is read-only: crawl articles, check statuses, and provide candidate targets. The second stage writes to WordPress and processes only confirmed replacement mappings. This prevents links from being deleted incorrectly if a site temporarily returns a 403 response or times out.

If the team already automates content publishing, add internal-link verification to the end of the publishing workflow instead of creating a separate, isolated task. For the complete content process, see the SEO content workflow from keyword research to WordPress publishing. The boundaries and review methods for multichannel content tasks can also be planned in conjunction with the content marketing automation workflow.

Do not automatically modify these types of results

• The target page returns 403 or 429, but opens when accessed manually in a browser.
• Multiple similar pages exist, making it impossible to determine which one addresses the original search intent.
• The old page is scheduled to be merged, but the site owner has not yet decided whether to set up a 301 redirect.
• The link points to a checkout, account, download, or access-restricted page.
• The repair would change wording related to products, prices, regulations, or compatibility.

These cases should be placed in a manual review queue. Automation should narrow the scope, not make irreversible content decisions on behalf of the site owner.

Common mistakes

Checking only status codes without saving the source articles. You end up with a list of 404 errors but do not know which pages need to be edited.

Constructing a new URL from the title. WordPress category prefixes, Slugs, and redirect rules may differ from the title, so you should retrieve the actual permalink.

Treating every non-200 response as a broken link. Access controls, rate limiting, and temporary timeouts require further investigation and should not lead to immediate deletion.

Ending the task as soon as the update is complete. A genuinely reliable completion condition is that the public page returns 200, the content changes have taken effect, and every internal link in the article passes rechecking.

FAQ

How often should WordPress internal links be checked?

It depends on the update frequency. Content sites that publish continuously can check new and modified pages weekly, then cover the entire site monthly. Small sites that are rarely updated do not need frequent crawling.

Is a 301 redirect considered a broken link?

Not necessarily. If the final page returns 200 and covers the same topic, the link is still accessible. However, it is usually worth updating an internal link to point directly to the final URL to reduce unnecessary redirects.

Can an AI Agent automatically fix every 404?

Technically, confirmed URLs can be replaced automatically, but processing every result unconditionally is not recommended. Pages with unclear targets, pages involved in mergers, or access-restricted pages should be confirmed manually.

Clearly define what “fixed” means

Managing broken internal links is not about generating a report; it is about completing a closed-loop process: identify the source, confirm the target, update the content, crawl the front end, and recheck each link. You can first have SmaugBrain run a read-only check to see whether the report accurately identifies the source articles and final statuses, then decide whether to grant WordPress write access. For important pages, retaining manual confirmation is the safer approach.