If we rebuild your website, what should get better?

“We need a better website” is a reasonable place to start a conversation. It is not enough to scope the project, because a rebuild can finish with a set of attractive screenshots and no way to tell whether the customer journey improved.

I want to know what better means for the business. More appropriate inquiries? Fewer calls asking whether a service is available? A faster way to update pages? A mobile form that actually reaches the sales team?

Those answers change what I would build.

Visual quality matters. So do speed and search visibility. But the rebuild needs a purpose we can check afterward, so my approach at CodeAspen would start with the inquiry the business wants to receive, then work backward through the website and the systems behind it.

A qualified inquiry needs a definition before we change the site

A form submission is easy to count. A qualified opportunity takes a little more thought.

For a commercial service business, qualification might depend on service type, location, project fit, and usable contact information. I would agree on that definition with the people who handle sales before changing the site.

Otherwise, a larger pile of irrelevant submissions can look like success while creating more work.

Keep stages separate. A submission can be received, reviewed, qualified, booked, accepted, and eventually paid. The website influences some of that journey, but sales handling and delivery capacity matter too.

Where practical, give the submission an identifier that follows it into the CRM. Preserve source information when available, but acknowledge attribution gaps. Phone calls, device changes, consent choices, and untracked interactions mean the report will never describe every touch perfectly.

An honest partial view is useful. False precision is not.

The old website is worth studying

Before replacing pages, I want an inventory of what is already working.

Which URLs receive relevant search traffic? Which pages have useful inbound links? What do salespeople send prospects? Where do visitors misunderstand the offer?

I would review the current forms, phone links, booking tools, and CRM handoff alongside page content. Then I would try the main tasks on a phone and with a keyboard, including validation errors and a failed submission.

A website can look old and still contain valuable structure. Throwing it away without checking can turn a design project into a migration problem.

A website can look old and still contain valuable structure.

Record a baseline before launch: search visibility, landing-page activity, qualified inquiries, and performance. Note unusual circumstances such as a promotion or seasonal spike. We will need that context when someone asks whether the rebuild worked.

A page has to answer the questions a customer arrives with

A customer arriving on a service page usually needs a few concrete answers: do you handle this problem, do you serve my situation, what does the work include, and what happens if I contact you?

That is where I would spend the writing effort.

For a software studio, “AI development” says less than a clear explanation of the workflow being improved, the systems involved, and the limits of the engagement. Technical depth can come after the reader understands why it matters.

For a business with several locations, location pages should contain meaningful differences. Coverage, available services, actual local details, and genuine project evidence are useful. Repeating the same text with a different city name does little for the person trying to choose.

Case studies should be clear about what was shipped and what was measured. A demonstration can be valuable, too, provided it is identified as a demonstration.

SEO belongs in the implementation plan

I do not view technical SEO as something to sprinkle over a finished site.

The build needs sensible page structure, crawlable internal links, deliberate indexing controls, appropriate canonical URLs, descriptive titles, and important content that is actually available to search engines and users.

If URLs change, map old pages to relevant replacements. Test redirects and update internal links. Check sitemap coverage and monitor both the old and new URLs after launch. Google’s site-move guidance explains that process and the visibility fluctuations that can accompany a migration.

Sending every retired page to the homepage is a poor substitute for deciding where its content belongs.

I would also explicitly check that staging restrictions are removed from production. An unintended indexing block is easy to miss in a design review and expensive to discover late.

Speed needs to help the person using the page

I want performance work to improve the task, not just the presentation of a test score.

A huge image, a shifting layout, or a slow booking widget can make a page frustrating on the devices customers use. Third-party scripts deserve scrutiny because their cost is still paid by the visitor.

Core Web Vitals measure loading, responsiveness, and visual stability through LCP, INP, and CLS. Field data reflects actual visits, while laboratory tools are useful for diagnosis. They answer related but different questions. Source: web.dev, Web Vitals.

The practical work might involve resizing images, simplifying a page, reserving space for media, or removing a script that nobody needs. Test again on the target devices.

A performance improvement is worth documenting on its own terms. Whether it increases qualified inquiries is a separate question that requires business data.

A successful form needs to produce a usable record

The form should ask for enough information to let someone act. I would challenge fields that exist only because a department might want them someday.

Use visible labels, understandable errors, and a confirmation message that explains the next step. Preserve the request before handing it to downstream systems. Detect delivery failures and decide how duplicates are handled.

Then test the complete path. Does the record reach the right person? Does it contain what they need? Does it remain accessible when the CRM is unavailable?

For phone inquiries, a tap on the number measures intent. It does not establish that a conversation occurred. The business needs a way to record what happened after the call.

This is why I like reviewing the website and lead handling together. The customer experiences them as one process.

I would be careful with AI-search promises

Being cited by AI-generated search results is a reasonable thing to want. It does not justify a new set of unsupported guarantees.

Google says established SEO practices remain relevant to AI Overviews and AI Mode, with no additional technical requirements or special optimization needed for inclusion. Being eligible does not guarantee an appearance. Source: Google Search Central.

For CodeAspen, I would invest in material that earns attention on its own: a documented technical decision, a useful comparison, an actual implementation, or an experiment with inspectable results.

A page should be accurate and useful when someone reads it directly. That is a better editorial standard than guessing which phrase might be repeated by a search feature.

Report what changed without taking credit for everything

The reporting should connect search visits to inquiries and then to qualification and sales, as far as the available records allow.

Compare appropriate periods. Note changes in advertising, pricing, staffing, and demand. Segment by service or channel when there is enough data to make the comparison meaningful.

If the business receives only a handful of inquiries, I would not declare a dramatic conversion improvement after a short observation period. Direct usability feedback and lead-quality review may be more informative while more data accumulates.

A controlled test can strengthen attribution when traffic supports it. Otherwise, describe the observed change and its limitations.

A case study can prove the implementation without proving the revenue

Show the old journey, explain the problem, document the changes, and define the measurement window. Include relevant sample sizes and the other factors that may have influenced the result.

Screenshots can demonstrate interface work. A request traced into the CRM can demonstrate a functioning integration. Neither proves a revenue increase by itself.

If business outcomes are still being measured, publish the implementation story first. There is plenty to explain without inventing a result.

Before discussing colors or frameworks, I would ask the sales team to show us five recent inquiries and the pages those customers used. That gives the rebuild a purpose we can design around and a starting point we can compare against later.