What Happened When I Let GPT's Work Mode Audit an Entire Website — Part 2

A few weeks ago, I wrote about why I had started preferring ChatGPT Work Mode for larger projects.

At that point, I had already used it to research and produce several articles simultaneously, work across complete project files, create downloadable replacements, validate code, and inspect live websites.

Since then, I’ve taken the live-site auditing considerably further.

Instead of asking Work to inspect a few pages and tell me what looked wrong, I gave it something much closer to a complete website assignment.

The objective was not simply to improve the design or rewrite a few articles.

I wanted it to help determine what the website was actually supposed to accomplish, inspect how visitors moved through it, examine the traffic and tracking, repair technical problems, organize the content, review the affiliate structure, and create a realistic direction for the site going forward.

That turned into one of the most involved projects I’ve completed with AI so far.

As before, I won’t name the website. We’ll call it Project C.

The Audit Started With a Much Bigger Question

The first question wasn’t, “How can we improve this page?”

It was:

What is this website actually supposed to do for someone?

That sounds obvious, but websites have a way of accumulating things.

You publish articles. You add categories. You test affiliate programs. You install plugins. You change the homepage. You create a few tools. You add links because they seemed relevant at the time.

Eventually, you can have a website containing a lot of useful material without having a particularly clear journey through it.

That was the problem with Project C.

It had content, traffic history, affiliate relationships, destination pages, booking options, and years of accumulated work. What it didn’t have was one clear route showing a visitor what to do next.

Work helped me look at the website from the visitor’s side instead of only from the owner’s side.

Someone arriving at a website does not care how many hours I spent building it. They want to know whether it can help them make a decision.

That shifted the entire audit.

Traffic Had to Be Separated Before It Could Be Trusted

One of the most important discoveries was that some of the website’s analytics had been mixed with another property.

That meant the historical numbers couldn’t simply be accepted as a clean baseline.

Work helped trace which Google tag was loading, compare that against the available analytics properties, separate the website into its own measurement setup, and establish a new baseline going forward.

That alone changed how I thought about the audit.

There is no point celebrating traffic if you aren’t sure whose traffic you’re looking at.

The same principle applied to search performance and affiliate clicks.

We inspected Search Console history, indexed URLs, impressions, clicks, sitemap behaviour, redirect history, and the pages that had earned enough search visibility to deserve protection.

That prevented another common mistake: removing or redirecting an older article just because its title no longer matched the direction I wanted.

Some pages that looked expendable had search history. Others had comments or links worth preserving. A few needed to be rebuilt instead of deleted.

The audit became less about cleaning up the past and more about deciding which parts of the past were still useful.

The Homepage Became a Decision Tool

The homepage had several reasonable choices, but it still expected visitors to decide what they needed before the website had helped them understand their trip.

We changed that by creating a simple trip-preview experience.

It asks a small number of questions about the destination, timing, group, trip length, preferred pace, priorities, budget pressure, and what has already been booked.

It does not pretend to produce a complete itinerary.

Instead, it helps the visitor recognize the likely shape of the trip and choose between three practical routes:

• Plan and book it themselves
• Compare organized tours
• Ask a real person for planning help

That may sound like a small change, but it gave the entire website a purpose.

The articles could now educate and inspire. The booking tools could support do-it-yourself travelers. Organized tours had their own place. Complicated trips could move toward human help.

Everything no longer had to perform the same job.

The Human Handoff Needed More Work Than the AI Tool

One of the existing planning routes relied on opening the visitor’s email program.

That wasn’t dependable.

There was no reliable lead record, consent record, confirmation process, or clear way to know whether the inquiry had actually gone anywhere.

We replaced it with a proper form, private submission storage, required consent, a confirmation message, and a clear explanation of who would handle the request.

This part reinforced something I mentioned in the first article.

AI can help build the system, but I still have to supply the business truth.

Work did not automatically know who should receive the lead, what relationship existed between us, whether I earned a commission, or what promise I was comfortable making to the customer.

I had to provide those answers.

In this case, the person receiving the lead is someone I know and trust, but I do not receive a commission when she takes over the planning.

That needed to be stated honestly.

No amount of polished design replaces an accurate explanation of what happens after someone clicks Submit.

Internal Linking Became a Controlled Publishing Project

The website also had many articles that were useful individually but poorly connected.

Instead of dumping automated links across the site, we built several tightly focused content clusters.

Each cluster had:

• One established hub
• Four closely related articles
• A distinct purpose for each article
• Contextual sibling links
• A logical commercial route
• Safety or qualification language where appropriate
• A reciprocal section added to the hub last

This was slower than activating an automatic internal-linking system, but it produced better results.

The interesting part was how Work handled the publishing process.

Each page was inspected before editing. The exact insertion location was identified. A unique marker was included so we could detect duplication. Every save was verified from a refreshed source before moving forward.

Then WordPress began returning 502 errors.

Repeatedly.

This is where the project stopped looking like a smooth AI demonstration and started looking like actual website work.

Some saves went through despite the browser error. Others did not. A few Update attempts redirected to the WordPress Profile screen instead of saving the article.

We had to stop, reopen the authoritative source, check whether the marker existed, and determine whether the server had accepted the change.

Sometimes I had to click Update manually.

Work did not magically overpower a broken gateway. What it did well was preserve our exact position so we didn’t submit the same content twice or lose track of which pages had actually saved.

The Roadmap Became as Important as the Changes

The project now has a retained audit roadmap with dozens of saved versions.

That roadmap contains:

• Baseline measurements
• Completed work
• Post IDs and URLs
• Search evidence
• Affiliate findings
• Publication batches
• Recovery checkpoints
• Failed attempts
• Verified saves
• Cache-clearing records
• Public regression results
• Parked decisions
• Future phases

This has probably been the biggest improvement in how I assign long projects.

In my first article, I wrote about telling Work what I wanted and what must not be changed.

I would add something else now:

Tell it how to preserve continuity when something goes wrong.

A long website project should not depend on one browser tab remembering everything.

If a connection drops, a website times out, usage resets, or the work continues another day, there needs to be a reliable record of what was completed and what comes next.

The roadmap became the project’s memory.

Affiliate Auditing Wasn’t About Adding More Links

Another part of the audit involved affiliate platforms.

The website already had many programs and links. The obvious temptation would have been to add even more.

The data suggested the opposite.

One network showed hundreds of clicks across numerous travel programs during the reporting period, but no bookings and no earnings.

Other direct platforms showed very little traffic and no conversions yet.

That doesn’t automatically mean the programs are bad. It means there isn’t enough evidence to justify spreading visitors across dozens of choices.

The audit shifted toward:

• Fewer partners with clearer roles
• Destination-specific links
• Better campaign naming
• Consistent disclosures
• Reliable click tracking
• Verified payout information
• Matching each platform to the visitor’s intent
• Separating direct-to-partner traffic from visits that actually reach the website

Again, this required human judgment.

A dashboard can show an active program. That does not mean it belongs on a particular website.

We Eventually Stopped Instead of “Finishing”

After all the development, publishing, tracking work, content clusters, affiliate reviews, and testing, we reached an interesting decision.

We paused.

The website is now substantially better than where it started, but completing every remaining cleanup item immediately would have removed our chance to see whether the larger changes affected real visitor behaviour.

So we saved a baseline and created a short observation window.

When we return, we’ll compare traffic, landing pages, affiliate clicks, search impressions, leads, and bookings against the saved numbers.

Three days won’t prove an SEO trend or suddenly establish domain authority. Those take much longer.

It can, however, show whether the tracking is working, whether visitors are reaching the new pathways, and whether something obvious changed after the rebuild.

Sometimes the next productive action is to stop changing things long enough to measure them.

Now I’m About to Repeat the Process

The next step is to perform separate audits on three more websites.

They are very different projects.

One is based on honest second-income and affiliate-marketing education.

One is meant to drive qualified fishing travelers toward a small lodge.

One is intended to become a practical information and troubleshooting authority for RV owners.

I don’t want them to look alike.

I don’t want them to follow identical visitor journeys.

I don’t even want them to make money in exactly the same way.

What I do want is the same audit discipline:

• Understand the website’s real purpose
• Establish trustworthy measurements
• Protect existing search value
• Repair technical problems
• Build a useful visitor journey
• Verify affiliate relationships
• Improve content architecture
• Create a legitimate authority strategy
• Record every important decision
• Test the public result
• Preserve a recovery point
• Measure before deciding what comes next

That is where Work has become most valuable to me.

It is not making the business decisions.

It is helping me investigate enough of the business that I can make better decisions.

My Opinion Has Changed Again

In my first article, I described the difference this way:

Chat helps me figure out where I’m going. Work helps me get there.

I still believe that.

After this latest project, I would add one more line:

Work also helps me prove whether I actually arrived.

Building something is only one part of the job.

The finished website still needs to load, track correctly, guide visitors, preserve search value, disclose commercial relationships, work on mobile, and survive the occasional WordPress meltdown.

AI did not remove me from that process.

I reviewed the decisions. I supplied the firsthand information. I chose the direction. I approved the public changes. I clicked Update when automation couldn’t. I watched the failures happen and decided when we had pushed far enough.

What changed was the scale of the work I could organize and complete without trying to hold every moving part in my own head.

That is probably the biggest difference between my early AI use and what I am doing now.

I’m no longer testing whether AI can write something for me.

I’m testing whether we can manage a real project together—and whether the finished result is actually better than where we started.