Two Small Fires: An SEO Cleanup and an AI That Almost Overstated Our Acreage

Most of what keeps a venue's website healthy never makes it into a blog post, because it is not interesting. Dead links. Redirect rules. An AI tool double checking its own homework before it publishes something. This week gave me two small examples of that kind of work, and I think they are worth writing down, because the failure mode in both cases was the same: something looked done, and it was not.

Cleaning Up What an Audit Already Found

I reran an Ahrefs audit and it came back with the usual list: five dead links worth redirecting, a handful of internal blog links pointing at pages that no longer exist, a missing cluster of local-area links in the footer, and a gap in how fast new static pages get announced to search engines.

The links and redirects were the easy part. I added five new redirect rules and fixed the broken internal links inside the posts that referenced them. Then I found something that explained a problem I did not know I had.

The redirect table that looked right and did nothing

We have a database table built specifically so redirects can be added without a code deploy. It has a clean API, it is documented, and I added the five new rules to it exactly the way it is supposed to work. Then I checked whether the redirects actually fired on the live site, and they did not.

The reason: the process that actually serves page requests on scarboroughhouse.com has its own, separate, hardcoded list of redirects. It has never read from that database table. The table only ever affected API traffic, not the pages a visitor or a search engine crawler actually requests. It looked like a working system because the API side of it worked fine when tested in isolation. It just was not wired to the part of the stack that matters for this.

I added the five rules directly to the list that actually runs in production, verified them with a real production build (your everyday preview environment does not run that part of the code at all, which is its own lesson), and confirmed all five now return a proper redirect instead of a dead page. The database table is still there, still half-wired, and now flagged as a cleanup project so a future redirect does not quietly go nowhere the same way.

The lesson is not "redirects are hard." It is that a system can pass its own tests and still not be connected to the thing it was built for. Worth checking the whole path, not just the piece you touched.

Catching an AI Before It Published a Fact We Don't Claim

Separately, I had an AI browser tool going through our YouTube channel, writing new descriptions and pinned comments for our ten most watched videos. The drafts were genuinely good: clear pricing links with UTM tracking, consistent calls to action, the kind of boilerplate paragraph you want repeated across every video so the channel reads as one voice instead of ten different ones.

All ten drafts also repeated the same line: that the property sits on "400 acres." We never make that claim, in any amount. It is not that 400 is wrong and some other number is right. We deliberately never quote a specific acreage figure anywhere, because it is not something we can stand behind precisely, and a specific wrong number in ten video descriptions is ten places it has to be found and fixed later. The AI tool had pulled the figure from an old draft somewhere in the channel's history and treated it as an established fact worth repeating. It also did the right thing by flagging it and asking for confirmation before publishing anything, which is exactly why this got caught instead of going live.

The fix was a one-line swap: instead of a number, the approved language is "surrounded by hundreds of acres of active NC farmland," which is both true and does not commit us to a figure. That correction went back to the tool before a single description was pasted into YouTube Studio.

One of the ten was the "Pool Party Wedding with Baptism" video, our most memorable upload, where guests jumped into the pool fully dressed, tuxedos and all, right after a baptism during the reception. It is a good example of why the review step matters: a video that distinctive gets watched and read closely, so a wrong number in its description is not quietly ignored.

Why this is a process problem, not a one-time fix

The actual risk here was never "the AI got a fact wrong." Tools get facts wrong; that is expected. The risk is publishing ten copies of the same wrong fact in one afternoon because it reads as settled once it is repeated that many times. A single error in a single draft is a typo. The same error baked into a boilerplate paragraph and pasted ten times is now your brand's stated position, and it takes real effort to walk back once it is live and indexed.

The practical takeaway for anyone using AI tools on marketing copy: keep a short list of facts you will never state a specific number for, and check every AI-drafted batch against that list before anything goes live, especially when the same paragraph gets reused across many pieces of content. Catching it once in a review step is cheap. Catching it after it is published ten times is not.

What Carries Over If You Run This Yourself

• A redirect, a feature flag, or any "configure without a deploy" system is only as good as what actually reads it. Verify the real request path, not just the admin side.
• Your dev preview environment may not run the same code your live site runs. Test redirects, SEO middleware, and anything else in that category against an actual production build before trusting the result.
• Write down the specific facts and figures your business will never state precisely, and check AI-drafted content against that list every time, especially boilerplate that gets reused across many pieces.
• An AI tool that pauses to ask "can you confirm this is accurate" before publishing is doing exactly what you want it to do. Build that pause into your process even where you are not using AI.