How We Fixed 2,092 Broken Redirects for a US Expat Tax Firm

Tax Samaritan is a US expat tax firm led by Randall Brody, Enrolled Agent. The firm has been publishing tax guides since 2013 and has rebuilt its website several times. Each rebuild left behind redirects: rules that forward an old web address to a new one.

By October 2026 the site had 2,092 of these rules, split across two WordPress plugins that did not know about each other. Visitors clicking tagged ad links got error pages. Hundreds of redirects bounced through two or more steps before reaching a page. Some form submissions ended on pages that no longer existed.

We replaced the whole system in one day and tested every rule before signing off.

At a glance	Before	After
Redirect rules	2,092 across two plugins	1,187 in one plugin
Rules that broke on tagged links	1,081	0
Redirects with two or more hops	802	0
Rules ending on a missing page	47	0
Rules aimed at the wrong domain	50	0
Rules sending visitors to other websites	4	0

The problems the site was having

1. Tagged ad links returned error pages. In 1,081 rules the old address only matched when the visitor arrived with no tracking tags. A link like /tax-quote/?utm_source=facebook failed to match, so the visitor saw a “page not found” screen instead of the quote form. Every paid click on an old link was wasted.
2. Two plugins were handling redirects. Redirection and Yoast SEO Premium each held their own set of rules. Neither could see the other, so rules overlapped, conflicted and chained together.
3. Redirects took multiple steps. 802 rules forwarded to an address that was itself forwarded again. Each extra step slows the page and makes search engines less likely to pass full ranking value to the final page.
4. Forms ended on missing pages. At least eight thank-you pages that forms sent people to after submitting no longer existed. The visitor saw an error and assumed the form had failed. Analytics never recorded the lead.
5. Analytics was blind to errors. Google Analytics recorded missing pages under the wrong address. Its largest error row, 149 views, was logged against the home page, which loads normally. Detailed data was also only kept for two months, the default.
6. Outdated tax content was still reachable. About 75 FAQ entries written in 2018 were still published. One described the IRS Offshore Voluntary Disclosure Program, which closed in September 2018. On a tax site, stale answers are an accuracy risk, especially when AI tools can quote them.
7. Smaller leaks. The blog feed returned an error 84 times a week, a paid Yoast News add-on was producing a broken news sitemap, and text pasted from Google Docs had left broken links inside three articles.
8. Google Ads counted every page view as a quote request. The tag that tells Google Ads a visitor requested a quote sat in the site-wide header, so it fired on every page, including blog articles. Google Ads reported far more conversions than really happened, and automated bidding learns from those numbers. We flagged it so the tag fires only on the page visitors see after submitting the quote form.

How we found them

We did not start from the redirect list. We started from what visitors and crawlers were actually hitting.

1. Read the error log. Redirection’s 404 log showed which missing addresses were being requested, how often, and from where. Old ad links, recycled social posts, short links and a directory banner were all still sending traffic to dead addresses.
2. Exported every rule from both plugins. We combined the Redirection and Yoast exports into one list of 2,092 rules and checked each rule’s matching settings, not just its addresses.
3. Traced every rule to its final destination. Following each forward to the end showed which rules chained, which looped, and which ended on a missing page or the wrong domain.
4. Kept the hit history. Each rule’s lifetime hit count and last-used date went into an evidence file. Some rules look dead but are not: one category address had 674 lifetime hits and had last been used months earlier.
5. Checked the pages around the redirects. We loaded every thank-you page the forms used, compared Analytics error reports with the server’s real responses, and read the site’s sitemaps and feeds.

One finding came from a crawler. Applebot, Apple’s search crawler, was requesting long, stacked FAQ addresses. That led us to the 2018 FAQ entries, which nobody on the current team knew were still live.

What we did to fix it

Repairing 2,092 rules one at a time would have taken weeks and left the same settings problem in place. We rebuilt the set instead.

1. Backed up everything. Both plugins were exported before anything changed. Those files are the rollback.
2. Fixed the settings before importing. Redirection’s import applies whatever defaults are set at the moment of import. We set matching to ignore trailing slashes, ignore capitalization, and “ignore and pass” tracking tags. That last choice matters: the similar “ignore” setting also fixes the errors, but it strips the tracking tags, so every paid visit would show up in Analytics with no campaign.
3. Collapsed every chain. Each rule now points straight at its final page. 2,092 rules became 1,168, plus 15 added by hand.
4. Handled the risky ones by hand. Fifteen old addresses differed only by a page number after a question mark, such as /?page_id=16765. Under the new defaults those would all match the home page. Each was added individually with exact matching.
5. Moved everything into one plugin. Yoast’s redirect rules were exported, then removed, and Yoast was stopped from creating new ones when a page address changes. Redirection now watches posts and pages and creates those forwards itself.
6. Caught the patterns with three rules. Instead of one rule per old FAQ entry, three pattern rules send any old FAQ address to the current FAQ page. Specific rules still take priority.
7. Added tracking for errors. A “page not found” event now records missing pages in Google Analytics, and Analytics keeps 14 months of data.
8. Protected privacy. Visitor IP addresses in the redirect logs are now masked.

What testing caught after launch

A rebuilt redirect file can look perfect on paper and still fail on the live site. Our first full test found problems the planning data could not show.

• One manual rule was sending the home page elsewhere. One of the fifteen hand-added rules had not saved its exact-matching setting, so the home page forwarded to a services page. We found it by reading the plugin’s own export, fixed it in seconds, and confirmed the home page loaded.
• WordPress was adding hidden second steps. WordPress quietly forwards some old addresses on its own. 26 rules pointed at addresses like that, so they still took two steps. One article had moved to a different folder, and 17 rules were pointing at its old location.
• Two rules pointed at each other. Two old Form 5471 addresses forwarded to each other in a loop, which gives visitors an error. Both now go to the current Form 5471 guide.
• 22 rules ended on missing pages. Each was pointed at the closest live article instead.
• A pattern rule had been imported as plain text. The rule meant to handle old mobile (AMP) addresses never matched anything. It was rebuilt as a proper pattern rule.

The final test crawled all 1,169 standard rules with Screaming Frog and followed every forward to the end. Every one finished on a live page in a single step.

Results

Every rule now reaches a live page in one step. We confirmed this on launch day by crawling all 1,169 standard rules and following each one to its final page.

• Tagged links now land on the right page with their tracking tags intact, tested with ?utm_source=test&gclid=test.
• Addresses with or without a trailing slash, and in any mix of capital letters, forward the same way.
• The home page loads normally, and every old page-number address reaches its intended page.
• Old FAQ addresses, including the stacked ones Applebot was crawling, reach current content.

At 30 days we will review each rule’s real hit count. Rules with no hits and no history go on a removal list. Rules with past traffic but no recent hits go on a check-first list, because some old addresses are used only a few times a year. At 30 days, about 137 genuinely used rules would look unused, so we check before we delete. A second review at 90 days removes the rest with far less risk.

What other WordPress site owners can learn from this

Most sites that have been rebuilt more than once have some version of these problems. Few owners know, because redirects fail quietly.

• Use one redirect plugin. If Yoast SEO Premium and Redirection are both active, pick one and turn off redirects in the other, including the automatic ones Yoast creates when a page address changes.
• Test with tracking tags. Load an old address with ?utm_source=test&gclid=test on the end. If it shows an error, or the tags are missing when it lands, your ad tracking is leaking.
• Pick “ignore and pass” for query settings. It matches tagged links and keeps the tags for Analytics and Google Ads.
• Check where your conversion tags fire. A Google Ads conversion tag belongs only on the confirmation page. Open a blog article and confirm no conversion is counted.
• Set defaults before a bulk import. Imported rules take on the settings in place at the time.
• Check where your targets go. A rule can look correct and still land on an address WordPress forwards again. Crawl the destinations, not just the rules.
• Load every thank-you page. If a form ends on an error, you are losing leads and not counting them.
• Do not delete on 30 days of data. Low-traffic rules can go months between uses. Check their history first.
• Look at what crawlers request. Search and AI crawlers often find old content that your own team has forgotten.

Frequently asked questions

What is a redirect chain, and why does it matter?

A redirect chain is when an old address forwards to another address that forwards again before reaching a page. Each extra step slows the page. Googlebot follows up to 10 redirect hops. If a page redirects more than 10 times without returning content, Google Search Console logs a redirect error and Googlebot stops following the chain. Shorter chains also load faster for visitors.

Why would a tagged ad link show an error when the plain link works?

In WordPress redirect plugins, a rule can be set to match the address exactly, including anything after the question mark. A link with tracking tags then no longer matches the rule, so the visitor gets a “page not found” error.

How do I know if my WordPress redirects are broken?

Check your redirect plugin’s 404 log, test a few old addresses with tracking tags on the end, and crawl your redirect list with a tool like Screaming Frog with “Always Follow Redirects” turned on. Any result with more than one step, or ending in an error, needs fixing.

Should I delete old redirects?

Only with evidence. Track hits for at least 30 days, check each rule’s history, and keep any rule that has links from other websites. Export a backup before deleting anything.

Is your site leaking traffic?

If your site has been rebuilt or moved more than once, it is worth checking. VegasGeek audits WordPress redirects, tracking and forms, and fixes what we find. Contact us to start with a redirect review.