A Full Day Under the Hood: Four Rounds of SEO Auditing

We run regular audits on scarboroughhouse.com with an outside team called SiteBuilder Solutions. The idea is simple: the website is how most couples find us, so it has to work perfectly for search engines and for real people on their phones. An audit is a systematic check of every page, every link, and every signal we send to Google.

Today we ran four rounds in one day. That is unusual. Normally an audit is a quarterly thing. But we had just shipped a significant set of new pages, and we wanted to make sure everything landed cleanly before Google crawled them. Here is an honest account of what we found, what broke, and what we fixed.

Why This Matters for Couples

When a bride in Raleigh types "wedding venue with lodging eastern NC" into Google, the search engine sends a robot to read our pages before it decides whether to show us in results. That robot does not run JavaScript. It reads raw HTML the same way a screen reader does. If our pages do not have real, readable text in that raw HTML, Google treats them as blank, and we do not rank.

Beyond text, Google checks dozens of signals: does the page return the right HTTP status code, does it have a unique title and description, does every image have a descriptive label, does the phone number link to an actual dial action on mobile? Getting all of these right is unglamorous infrastructure work, but it is the difference between showing up on page one and not showing up at all.

Round One: Soft 404s and Missing Prerendered Text

The first audit pass caught two problems.

The bigger one was that our photo pages, of which we have over 2,000 in the sitemap, were all returning a valid 200 HTTP response but with no readable content. Google calls these "soft 404s." The page technically loads, but a robot sees nothing useful. We fixed this by pre-rendering a real text body into the page's HTML before JavaScript runs, so the robot gets a proper title, description, and contact information without needing to execute any code.

The second issue was our wedding announcement pages. We had built out individual pages for 37 couples who have married at Scarborough House, and those pages were prerendered correctly at build time. But the wedding data (the actual couple names, dates, and stories) lives in a database, and publishing the code does not publish the data. The 37 rows needed to be seeded into the production database separately. We built a one-click seed tool in the admin panel to handle this.

Round Two: We Fixed One Thing and Broke Another

This is the most honest part of the report.

To fix the soft 404 problem, we added a rule to the server: if a URL has no matching entry in our SEO index, return a real 404 status code instead of a misleading 200. This was the right fix. But we forgot to account for one category of pages: the 2,020 individual photo detail pages.

Those photo pages are in the sitemap and have real content, but they are generated dynamically at runtime rather than from a pre-built index file. So our new rule treated all 2,020 of them as unknown URLs and started returning 404. The auditor caught this immediately on the second pass. We fixed it the same day: added photo pages to the protected route list so the server always returns 200 for them, and updated the index-generation script to include individual photo SEO entries so each page has its own unique title and description going forward.

We are documenting this here because honest post-mortems are useful. A regression like this is embarrassing but recoverable. The audit process exists specifically to catch it.

Round Three: Two Details That Add Up

After the critical fixes, the auditor flagged two smaller items that still have real impact, especially on mobile.

Lazy loading on images

The web standard for non-hero images is a simple HTML attribute called loading="lazy". It tells the browser not to download an image until it is about to scroll into view, which dramatically reduces how much data a phone has to download before the page becomes usable. A venue website with hundreds of photos is exactly the kind of site that benefits most from this. We added the attribute to every image that was missing it across the entire codebase.

Tap-to-call links on every page

Our phone number appears in the header on every page, but it was rendered by JavaScript after the page loaded, not in the raw HTML. A bride on her phone browsing while she is at work, or a robot auditing our mobile experience, would not see a tappable phone link. We added a small contact block to the prerendered HTML on every page so the number is always there, always tappable, without needing JavaScript to run first.

Round Four: Clean

The fourth pass came back clean. All 124 sampled pages returned 200 with unique titles, unique descriptions, one h1, and correct canonical links. Photo pages spot-checked at 20 of 20. Unknown paths returned real 404s. The tap-to-call link was present on 74 of 124 pages after the third pass (we had missed the hand-written content blocks), and fully 124 of 124 after a follow-up fix the same day.

The 37 Real Wedding Pages

The part we are most excited about is the real weddings section. Every couple who has married at Scarborough House now has their own page, with their names, their wedding date, and a photo from their day. These pages are not just for Google. They are for the next couple who is researching us and wants to see that real families have actually stood in this yard and said their vows.

Couples like Kylie and Noah, Sarah and Steve, and 35 more are now part of the permanent record of what happens at this house. Over time, these pages will also help us rank for searches that include specific wedding styles, seasons, and party sizes, because real wedding stories contain exactly the language that real brides use when they search.

What Is Next

Lighthouse performance scores are coming tomorrow. The outside audit team exhausted their daily Google quota running four crawl passes, so the speed and layout stability numbers wait until morning. We expect a few mobile image optimizations to come out of that pass.

The next tech post will cover how the journal itself is built: the static prerender system that makes our blog posts instantly readable by Google without a server-side rendering framework, and why that approach matters for a site that publishes new content every week.

If you are a couple researching the venue, the short version of all of this is: we take the work seriously. The same attention that goes into the grounds, the lodging, and the Magnolia Pavilion goes into making sure you can actually find us when you search. Book a private tour and see the rest in person.