From 21 Indexed Pages to 200+: Our SEO Repair Story

For a long time, Scarborough House had only 21 pages indexed. We are now at over 200.

That is the indexing progress we have been tracking as the owners of this wedding venue in Stantonsburg, North Carolina. It is not a claim that the latest round of repairs created that entire increase, or that every page and photograph we have prepared is already in Google. Those are different numbers, and mixing them together would make this story less useful.

We wanted more than a website that looked good when someone typed in our name. We wanted couples searching for a wedding weekend near Raleigh, lodging near Wilson, or real ceremony photos to find useful answers from the people who actually operate the property.

That meant building the content. It also meant finding the gaps between what we had built, what visitors could use, and what a search engine could discover and understand.

This is a candid account of our October 2026 SEO audit and repair work. The latest repair set has been implemented and tested in our working site, but it still needs to be published and checked on the live website. We are sharing the reasoning and the results we can support, not announcing that every audit warning has disappeared.

A pretty website and an indexed website are not the same thing

A couple can click around a site and see photos, open a gallery, and read an article. That does not automatically prove that Google discovered those pages, successfully rendered them, or chose to index them.

We had to separate three questions:

• Can someone find the page? Are there real links to it, and does it appear in the right sitemap?
• Can someone understand the page? Does it have useful content, an accurate title, working images, and a clear identity?
• Has Google indexed it? That needs indexing evidence, not just a successful website test.

Ranking adds another question: is the page useful and relevant enough to show prominently for a particular search? Being indexed gives a page the opportunity to appear. It does not promise a position or a booking.

That distinction matters to a venue owner. Two hundred useful indexed pages are not the same as two hundred versions of the same sales pitch. Our goal is more helpful answers and real evidence of the experience we offer, not a larger number for its own sake.

What the report actually told us

The audit materials tracked 51 issue categories. That did not mean we had exactly 51 broken pages. A category can affect one page, many pages, or a shared piece of code used across the site.

We reconciled the report into 23 work items and reviewed 39 named problem destinations. The image inventory covered 2,817 assets and 12,723 references to them. That gave us a more practical question than “How do we raise the score?” We asked which underlying problems were creating repeated failures.

Some were straightforward broken links or incorrect image paths. Others were more subtle: page information disappearing after a browser loaded the site, gallery pages that were not making their photographs easy to discover, and information from one photo remaining attached to the next photo after navigation.

We also found evidence gaps. A screenshot of a report is not the same as the complete list of affected URLs. A crawl is not a Search Console indexing report. A local test is not a live production test. We kept those limits in the work records rather than quietly treating missing evidence as proof that everything was fixed.

We fixed shared causes, not just individual warnings

One issue affected the way titles and other page information moved from the server to the browser. A page could arrive with sensible information, then lose it or accumulate conflicting information as the interactive website took over.

We repaired that handoff. The browser checks confirmed one primary title, description, canonical address, and the expected social image information on the tested pages. A canonical address tells search engines which URL represents a page; it should not change into an unrelated page just because someone clicked a gallery card.

We also repaired the lifecycle of the structured information describing a photograph. When a visitor moved from one image to another, the first image's description should disappear and the second image's description should take its place. We tested that sequence, including returning to the category. The old photo information no longer accumulated.

Then we deliberately made a detail request fail. That is the kind of test an ordinary screenshot misses. If a visitor has already clicked an approved photograph from a successfully loaded gallery, a temporary request failure should not falsely declare that the photograph does not exist.

The updated behavior retains that photograph's known, approved page information and offers a retry. A confirmed missing page is treated differently. That makes the site more honest for visitors and avoids confusing a temporary technical problem with a permanent absence.

Why we built a website sitemap and an image sitemap

A website sitemap tells search engines about pages and other important resources. Google's sitemap documentation explains that it can help crawlers work more efficiently, especially on larger, more complex sites and sites with substantial media.

Our website is not just a home page, a price page, and a contact form. It includes lodging information, grounds and ceremony information, vendor profiles, planning resources, articles, and photographs. A page sitemap helps us describe that public content consistently.

The image sitemap answers a related but different question: which actual image belongs to which page?

Google's image sitemap guidance specifically discusses images that it might not otherwise discover, including images reached through JavaScript. That is relevant to a modern gallery where photos load as people navigate or request more results.

There is an important detail here: Google accepts a separate image sitemap or image information inside a regular sitemap. A separate file is not a special ranking advantage. We chose a separate image sitemap because it makes our large photo inventory easier to manage, inspect, and reconcile with our public pages.

In our prepared release, the sitemap inventory covers 2,020 approved photo-detail pages and their image references. That is a discovery inventory, not a claim that Google has indexed 2,020 photographs or 2,020 new pages.

A sitemap is also not a shortcut around broken links, private access, missing content, or Google's decision about whether a page belongs in the index. We still have to make the pages work and give people a reason to use them.

A photograph needs more than a place in a slideshow

Wedding venue shopping is visual. Someone wants to know what a ceremony setting looks like, how the entrance photographs, or whether a particular space fits the celebration they have in mind. Real photographs help answer those questions in a way a generic paragraph cannot.

But a photograph in a slideshow is not automatically a useful search landing page. We are connecting approved photographs to individual pages, relevant categories, descriptive text, and routes back to the broader gallery.

You can explore the public photo categories to see the visitor-facing purpose of that work. Categories are not there merely to make more URLs. They help someone find the part of the property or the kind of moment they are trying to understand.

Google's image SEO best practices support this approach: use standard image elements, provide meaningful surrounding content and alt text, make image landing pages useful, and balance image quality with loading speed. Google also says it does not index CSS background images, which is one reason a visual design alone is not a complete image-discovery strategy.

Two photographs can show the same couple in the same doorway and still record different moments. We found that relying on a shared album caption could hide the information that distinguished those images.

We now put the approved, photo-specific description first. In the local generated metadata, duplicate-description groups fell from 159 to 7. That is a measured improvement in our prepared content inventory, not proof of a live ranking increase.

We did not make the remaining duplicates appear unique by attaching arbitrary numbers. Nor are we claiming every title is now ideal. Many descriptive photo titles are still long and need thoughtful editorial shortening. Cutting every title at a fixed character count can remove the very words that distinguish one image from another.

We checked that image URLs were actually images

One of the clearest defects involved vendor share images. An incorrect shared path was dropping a necessary part of the image address. The result was a broken image even though the underlying file existed.

We identified 65 corrected vendor image candidates and confirmed that all 65 returned actual image content in live probes. We also replaced two known broken fallback image references with an existing, verified share image.

That last distinction matters: an address that returns a web page is not necessarily a working image. A website can answer a bad image request with its normal page shell. Checking only that the request “worked” can miss the problem.

We checked the returned content type as well. We also checked that the selected photo and its social information agreed, instead of letting the previous page's image or dimensions remain attached to a new page.

Those source fixes still have to reach the published site before we can call the original live references repaired. We are not confusing a verified replacement with a completed production rollout.

Not every old link should point to the home page

When an old address breaks, the easy response is to redirect it to the home page. That can be a poor experience. Someone who followed a link to a particular room or location should arrive at the matching place, not start the whole search over again.

We restored handling for nine shared destinations and three existing owner-facing pages. We also added four proven, one-step redirects for the same places or rooms under their current addresses.

We did not redirect an old vendor page to a different company just because the names looked similar. We did not make private screens public so an audit tool would stop complaining. Some historical destinations remain unresolved because their intended replacement or retirement needs a real decision.

We are also keeping private, action-only, and unsuitable utility addresses out of the public sitemap. More indexed pages is not the right goal for an account screen, a private invitation flow, or a page that has no useful public purpose.

Higher-value content comes from operating the place

The technical work helps a search engine find and interpret content. It cannot replace having something worth finding.

Google's people-first content guidance asks whether a page provides original information, demonstrates firsthand experience, and helps its intended audience accomplish something. Those are useful standards for a venue website.

For Scarborough House, that means showing real spaces, explaining how an overnight wedding weekend works, answering practical planning questions, and making our limitations clear. Someone researching a venue near Wilson or Raleigh should leave with a better understanding of the property, not just another list of flattering adjectives.

A strong article answers a specific question. A lodging page explains an actual room. A vendor profile helps someone evaluate a real provider. A photograph shows a real setting and carries an accurate description. Relevant links connect those answers without forcing the visitor to guess where to go next.

We do not need hundreds of near-identical city pages or articles that repeat other people's advice with a new headline. Publishing more of that would increase our inventory without necessarily increasing its value.

We are treating the content and the technical system as one job: create useful material, make it accessible, verify it, and maintain it when the underlying facts change.

What we verified, and what we still need to do

The repair release passed the full workspace build and type checks, a 114-page SEO source check, and 21 targeted server tests. A production-style local check covered 2,983 public URLs. We tested mobile navigation, retry behavior, and the change from one photo's structured information to another.

That gives us evidence about the implementation. It does not tell us what Google has indexed since the changes, because that needs a live release and independent indexing evidence.

Our next actions are concrete:

• Publish the verified repair set. Recheck the actual public pages, redirects, sitemap entries, and image bytes afterward.
• Use Search Console evidence. Inspect representative live URLs and review indexing reports instead of treating a sitemap count as an indexed-page count.
• Finish the audit evidence. Obtain the complete affected-URL and orphan-page exports, so we can close specific findings rather than just interpreting screenshots.
• Make the remaining route decisions. Identify genuinely retired pages and verified replacements without inventing connections.
• Improve the remaining repeated or lengthy metadata. Keep descriptions factual and titles useful, not mechanically padded or numbered.
• Measure performance properly. Review the 181 image-size items and compare consistent mobile tests. We added reserved image geometry and loading priorities, but have not proved a before-and-after speed-score improvement.
• Continue useful editorial work. Improve existing answers, add genuinely distinct ones, and connect them to the right public pages.

There are also structured-data checks and tracking-ownership questions still to finish. Structured data must describe the visible content accurately; it is not a promise of a special search appearance. We corrected venue vocabulary and factual inconsistencies without claiming that Google has approved every possible rich result.

We have not called all 51 audit categories closed. That is a more credible position than declaring the work finished because a build passed or a report score changed.

Could someone do this on Wix or WordPress?

Many of the principles are available to anyone. Wix and WordPress sites can have useful content, sound titles, internal links, and sitemaps. WordPress can be extended extensively, and a capable team can build sophisticated systems on it.

So the honest comparison is not “those platforms cannot do SEO.” It is that a standard template or an SEO plugin does not automatically reproduce the custom behavior we tested: an approved-photo inventory tied to publication, meaningful gallery discovery, consistent server and browser metadata, precise error handling, and checks that follow a visitor through navigation.

A site owner can copy the checklist. Reproducing the system means owning the content model, the implementation, the review rules, the testing, and the maintenance. That is the work that makes the checklist useful.

Sharing the work is not giving away the business

We do not think explaining this process gives away our secret sauce. We are sharing what broke, why it mattered, which public best practices informed our decisions, and what we can honestly verify.

We are not publishing private access details, internal credentials, or a copy-and-paste version of the entire system. More importantly, no article can hand someone our real photographs, our firsthand operating experience, or the discipline of keeping the site accurate as the business changes.

The progress from 21 indexed pages to over 200 matters to us. What matters next is whether the right people find useful answers, understand what Scarborough House offers, and take the next appropriate step. Better indexing is part of that job, not the entire job.

If you operate a venue and are wondering what your own website is leaving undiscovered, visit Tech Talk and use the free SEO audit request. Start with evidence about your actual pages, not a promise that one setting or one plugin will solve everything.

Research behind our decisions

We consulted these official Google Search Central resources for this article. They explain discovery and quality practices, not a guarantee that any specific page will rank or be indexed.

• Learn about sitemaps: when sitemaps help search engines discover complex or media-rich sites.
• Image sitemaps: image discovery, JavaScript-loaded media, and the equally valid separate or combined approaches.
• Google image SEO best practices: image elements, landing-page context, descriptive text, quality, and speed.
• Creating helpful, reliable, people-first content: original experience and usefulness rather than content produced simply to inflate search traffic.