Book a fit call
Sample Modernization Assessment

Rebuild for speed. Carry the search set-up across.

The search foundations are in better shape than the platform. A rebuild is justified by speed and maintainability, not by search problems.

Assessed 11 October 2026Checked 80 addressesMethod crawl and manual review

78 of 80addresses return a page
0broken addresses
78 of 78correct canonical tags
4.2 smedian server response

This is a sample. It is based on a real assessment of a live website, carried out with the site owner's permission. The site's name, address, language, page titles and URL wording have been removed or generalized. Figures are measured, not illustrative, except where a section says it was not assessed.

01

Summary for decision-makers

The site is a business website with a service catalogue, published in a single non-English language written in a non-Latin script, and built on a widely used open-source content management system extended with plugins.

healthy

The search foundations are in better shape than the platform

Every page checked declares a correct canonical address, carries structured data, and is listed in a working sitemap. These are worth protecting in any rebuild.

main problem

Speed

The server took a median of 4.2 seconds to return a page's HTML, and 25 of 78 pages took more than 10 seconds. This is before images, scripts and styles load.

heavy

The pages are heavy

A typical page loads around 70 script tags and 27 stylesheets.

rebuild risk

The URL structure is where a rebuild would do damage if handled carelessly

Most addresses are written in the site's own non-Latin script, article addresses include the publication date, and several template and utility pages are publicly reachable.

Recommendation

Rebuild on a lighter front end while keeping the existing content, addresses and structured data, in the phased order set out in section 7. A rebuild is justified by speed and maintainability, not by search problems; the search set-up should be carried across, not redesigned.

02

Scope and method

What was assessed
The public website, as an anonymous visitor and crawler see it
Pages checked
80 addresses: the home page, all 57 addresses in the sitemap, and 22 more found by following links
Site size
Larger than the sample. About 1,400 further internal links were queued and not visited; these include many tag and filter pages and have not been de-duplicated
How
An automated crawl at one request per second, reading each page's response code, timing, headers and HTML, followed by manual review
When and from where
One session on 11 October 2026, from a single location
Not assessed
Search traffic, ranking keywords and inbound links (these need the site's search console data); page speed in a real browser; the admin area, hosting configuration, security and code quality
03

Current state

Platform
Plugin-based open-source CMS with shop and SEO plugins; commercial theme
Language
One language; language and text direction declared correctly on every page checked (78 of 78). No alternate-language tags, which is correct for a single-language site
Content types
Service and product pages, categories and tags, dated articles, testimonials, an interactive tool, and standard shop pages
Server
Responds over HTTPS; plain HTTP redirects to HTTPS; the www form redirects to the bare domain
Sitemap
A sitemap index with nine child sitemaps, 57 addresses in total, referenced from robots.txt
Machine-readable extras
Structured data on every page; no llms.txt file
04

Search inventory (technical)

All figures are for the 80 addresses checked.

7healthy5minor2to decide or fix

  • Returns a page (HTTP 200)78healthy
  • Permanent redirects (301)2Both are internal links pointing at an old address; they resolve, at the cost of an extra hopminor
  • Broken addresses (4xx or 5xx)0healthy
  • Sitemap addresses that fail0 of 57healthy
  • Canonical tag present and pointing to itself78 of 78Preserve exactlyhealthy
  • Structured data present78 of 78Preservehealthy
  • Exactly one main heading (H1)74Four pages have noneminor
  • Meta description present5127 missing, mostly on tag and category pagesfix
  • Social sharing tags present52 of 78minor
  • Marked "do not index"3Intentional on utility pages; none of them is in the sitemaphealthy
  • Reachable pages not in the sitemap21Mostly tag and utility pages; decide per type whether they should be indexed at alldecide
  • Duplicate page titles2Two pages share one titleminor
  • Images without an alt attribute0 of 1,054The quality of the alt text was not reviewedhealthy
  • Very thin pages (under 150 words)2minor
outside this sample

Which pages carry the traffic and the links. This is the most important input to a migration and it cannot be seen from outside. In a paid assessment it comes from the client's search console export: the pages with clicks and impressions over twelve months, the queries behind them, and the externally linked pages. Those pages get individual treatment in the redirect plan.

05

Performance

4.2 smedian time for the server to return a page's HTML
37 s+slowest tenth of pages
53 sslowest single response
170 KBmedian size of the HTML alone (home page 295 KB)
~70script tags on a typical page
27stylesheets on a typical page
how far to trust this

These are server response times measured from one location during a sequential crawl, not real-user loading times. A crawl can itself slow a small server, so the worst figures may overstate normal conditions. The median is the safer number, and at over four seconds it is already slow enough to matter. A proper assessment would confirm it with browser-based measurements at different times of day.

06

Risk register for a rebuild

  1. 1

    Addresses in a non-Latin script change or are re-encoded on the new platform, breaking every existing link

    likely if unplannedhigh impact

    Control: keep addresses byte-for-byte; test encoded and unencoded forms before launch

  2. 2

    Dated article addresses are dropped for a cleaner pattern without redirects

    mediumhigh impact

    Control: decide once: keep the dated pattern, or redirect every article individually

  3. 3

    Structured data and canonical tags, which work today, are lost because the new build does not reproduce what the SEO plugin generates

    mediumhigh impact

    Control: export the current output per page type and treat it as the specification

  4. 4

    Tag and category pages are removed in the name of simplification, taking their indexed addresses with them

    mediummedium impact

    Control: review each taxonomy against traffic data before removing anything

  5. 5

    The new front end renders content in the browser only, so crawlers see empty pages

    mediumhigh impact

    Control: server-side rendering for all indexable pages; verify with a crawler before launch

  6. 6

    Shop, account and interactive-tool functions are rebuilt without their current addresses or behaviour

    mediummedium impact

    Control: inventory every functional page and its address first

  7. 7

    Utility and template pages that are public today are carried over and indexed

    lowlow impact

    Control: exclude or mark "do not index" deliberately

  8. 8

    The rebuild fixes speed in testing but not on the live host

    mediummedium impact

    Control: measure on the production host before the switch

Likelihood and impact are the assessor's judgement, not measurements.

07

Options and recommended approach

A · start here

Tune the current platform

Caching, fewer plugins, lighter theme, image and script clean-up

For
Cheapest; no address changes; no migration risk
Against
The page weight comes from the theme and plugin stack itself, so gains are likely limited
B · then

Rebuild the theme on the same CMS

New lightweight front end, same content, same addresses

For
Removes most of the weight; content, addresses and SEO plugin output stay as they are
Against
Still tied to the plugin stack for shop functions
C · only if B falls short

Rebuild on a server-rendered framework with the CMS as the content source

New front end reading content from the existing CMS

For
Largest speed and maintainability gain; editors keep the tool they know
Against
Most work; every address, redirect and structured-data block has to be reproduced deliberately
Recommended

A first, then B, with C only if B does not meet the speed target. Option A is cheap and tells you how much of the slowness is configuration. Option B captures most of the benefit at the lowest search risk because nothing about the addresses or the SEO output changes. Option C is the right answer only when the shop and tool functions need more than the plugin stack can give.

This recommendation is a judgement from a technical review without traffic data. Traffic data could change the priority of individual sections but is unlikely to change the order of the options.

08

URL and redirect plan (outline)

  1. Freeze the inventory. Export every address from the sitemap, the crawl and the search console. This is the list the new site is tested against.
  2. Keep, redirect or retire, decided per content type.
    • Service and product pagesKeep addresses unchangedkeep
    • CategoriesKeep unchangedkeep
    • TagsReview against traffic; keep those that earn visits, redirect the rest to the nearest categoryreview
    • Dated articlesKeep the dated pattern unless there is a strong reason to change; if changed, one redirect per articlekeep
    • TestimonialsReview; candidates to fold into a single page with redirectsreview
    • Utility and template pagesRemove from public reach or mark "do not index"retire
    • The two internal links that currently redirectPoint them at the final address301
  3. Write the redirect map before building, as a table of old address, new address and reason.
  4. Test before launch: every old address requested against the new site, in both encoded and unencoded forms, expecting either the page or a single redirect to it.
  5. Carry over canonical tags, structured data, meta descriptions and the sitemap structure, and resubmit the sitemap at launch.
09

Phased roadmap

  1. 0

    Baseline: browser-based speed measurements, search console export, full address inventoryDepends on access to search console

  2. 1

    Option A: configuration and clean-up on the current platform; re-measureDepends on phase 0

  3. 2

    Decide between stopping, B and C using the phase 1 numbersDepends on phase 1

  4. 3

    Build, with the redirect map and SEO output as written specificationsDepends on phase 2

  5. 4

    Pre-launch crawl of the new site against the frozen inventoryDepends on phase 3

  6. 5

    Launch, sitemap resubmission, monitoring of indexed pages and crawl errorsDepends on phase 4

  7. 6

    Compare against the baseline at two, four and eight weeks; fix what movedDepends on phase 5

10

What to measure

Taken before the rebuild and compared after:

  • Number of indexed pages
  • Crawl errors
  • Clicks and impressions for the pages that carried traffic
  • Median server response time
  • A browser-based loading measure on the home page and two typical inner pages

Want this for your own site?

Book a Modernization Fit Call