WordPress SEO & Website Technical Optimisation
Most Hong Kong SME sites run on WordPress. The problem is rarely “not enough content” — it's plugins and themes slowing pages down, taxonomies generating duplicate pages, and inconsistent templates leaving every page with its own idea of titles and structured data. These get fixed by a developer directly, without a third party relaying instructions.
The SEO bottlenecks we keep finding on WordPress
Plugin conflicts and heavy themes slow pages down
Multipurpose themes load large amounts of CSS and JavaScript the site never uses, while SEO, caching, and page-builder plugins each inject their own overlapping assets. The result is several seconds on mobile — where most searches happen.
Taxonomies run loose, creating duplicates and crawl waste
Tag, category, author, and date archives are indexable by default, so near-identical pages multiply. Crawl budget goes to those instead of the service pages that matter, which then update more slowly.
No content model, so every page does its own thing
Without consistent templates, heading hierarchy, meta, and structured data get added by different people at different times in different ways. Neither search engines nor AI can tell what the site is about.
Redesigns and migrations lose rankings
Change the theme, the URL structure, or the host without a full URL map and 301 plan, and years of accumulated ranking can disappear within weeks — and it isn't easily recovered.
The WordPress technical audit checklist
Every WordPress engagement starts from the same checklist. These are the actual checks, not a summary of them.
- Full crawl: URL structure, status codes, redirect chains, orphan pages
- Indexation: robots.txt, meta robots, canonicals, pages indexed versus pages that should be
- Taxonomy review: indexing strategy for tag, category, author, and date archives
- Duplicate content: pagination, filter parameters, attachment pages, near-identical templates
- Headings: one H1 per page, and whether H2/H3 reflect the actual structure
- Structured data: whether existing schema matches visible content, and any duplicate or stale markup
- Plugin inventory: the asset cost of each, functional overlap, and whether it's still maintained
- Theme weight: unused CSS/JS, font loading, image formats and dimensions
- Core Web Vitals: field data (real users) assessed separately from lab data
- Multilingual setup: whether hreflang reciprocates and canonicals are self-referencing
- Internal link graph: how many links reach your important pages, and how deep they sit
- Server and caching: TTFB, cache layers, database size and autoloaded data
- CDN / WAF rules: confirming protection isn't blocking search-engine crawlers along with everything else
How the speed work is actually done
Speed work isn't installing a caching plugin. The order is usually: measure real-user data (Core Web Vitals field data) first, identify whether the problem is loading, interactivity, or layout shift, then treat that specifically — because the three have entirely different causes.
In practice that means removing or replacing overlapping plugins, stripping unused theme assets, converting images to modern formats with correct dimensions and lazy loading, self-hosting and preloading fonts, extracting critical CSS, deferring non-essential JavaScript, setting appropriate cache layers, and cleaning years of accumulated database rows and autoloaded data.
Every change goes into a change log, with before-and-after data. If an optimisation produced no measurable improvement, we say so rather than counting it as a completed item.
Keep WordPress, go headless, or rebuild?
We don't recommend a platform; we recommend the one your team can maintain. Here are the criteria we actually use — and in most cases the answer is to stay on WordPress and fix it.
| Criterion | Stay on WordPress | Consider a rebuild |
|---|---|---|
| Who maintains it | Non-technical colleagues edit content themselves → stay on WordPress | You have dev resource, or we maintain it → a rebuild is viable |
| Update frequency | Content changes several times a week → the WordPress admin is more direct | Content is stable and rarely changes → a rebuild costs less to run |
| State of the current site | Structure is sound; only speed and schema are wrong → optimise | The data model is tangled and years of plugins can't be unpicked → rebuilding may cost less overall |
| Functionality | You need forms, memberships, e-commerce — a mature ecosystem → WordPress wins | You need custom interfaces or unusual performance → rebuild |
| Budget and time | Limited budget, improve gradually → optimisation can be staged | One-off budget, reset the foundation → rebuild in one move |
Our own site runs on Next.js because the same team builds and maintains it, and no non-technical colleague needs to edit content. That's our situation, not necessarily yours — the platform should be chosen by whoever maintains it, not by a vendor's preference.
If a rebuild is the right call: a build starts at HKD 8,800 one-off, and costs nothing for clients on a 6-month SEO plan. Optimising an existing site is covered within the monthly plan's scope.
The lossless migration checklist
The most expensive mistake in a migration is having no redirect plan. These are the steps we run every time.
- 1Crawl the old site fully before moving, recording every URL, title, status code, and internal link
- 2Export Search Console query and page data as the comparison baseline
- 3Build the URL map: every old URL mapped to a new one, with no gaps
- 4Set single-hop 301s, avoiding redirect chains
- 5Verify content parity: no new page should have less content or fewer internal links than the old one
- 6Set staging to noindex so the test site never gets indexed
- 7Re-crawl immediately after launch and compare status codes and canonicals
- 8Check server logs to confirm search engines are actually fetching the new structure
- 9Submit the new sitemap and watch indexation in Search Console
- 10Keep a rollback plan until the data settles
What happens when this checklist is skipped
A medical aesthetic clinic in Toronto had its site redesigned by a previous provider. The redesign shipped, but three things weren't handled: old URLs were never mapped or redirected, producing a mass of 404s; no 301s meant years of accumulated ranking signals couldn't pass to the new pages; and when the language structure moved from mixed to subdirectories, hreflang wasn't set correctly, so the two language versions interfered with each other.
Traffic fell noticeably from late 2025, and this kind of damage doesn't repair itself — it keeps bleeding. We took over in May 2026: 404s and redirects first, then broken internal links, then keyword overlap between pages, and only after that competitor and content-gap analysis. Traffic is recovering; the recovery is still in progress.
Worth saying plainly: none of these are exotic mistakes. They're the three most commonly skipped steps in a migration. The checklist exists because when they're missed, the client carries the cost — and it takes months to win back.
Traffic lost after a redesign: old URLs unmapped, hreflang wrong. We took it over and repaired it.
Read the caseThe other failure mode: the remedy doing the damage
A Toronto aesthetics clinic was hit by a DDoS attack: bots flooding the site with requests, the server overloading, pages 404ing or simply unreachable. Upgrading the server doesn't fix that at the root — the attack traffic scales with you.
To stop the bleeding, the site was put behind strict blanket blocking at the CDN. It stopped the attack, and it also stopped Google's crawlers — the site could no longer be crawled or indexed, and organic traffic fell with it. What damaged the SEO wasn't the attack; it was the remedy.
We took over, analysed the attack sources and which pages were being targeted, and replaced the blanket rule with precise ones: block the malicious sources and the paths under attack, reopen legitimate traffic and search-engine crawlers, then crawl the whole site to confirm it was crawlable and indexable and watch indexing recover.
This is exactly why a technical audit checks CDN and WAF rules. The trade-off between security and crawlability needs someone who understands both sides — a content-led SEO provider usually never looks at this layer.
Anti-DDoS rules blocked Google's crawler along with the attack, and the site vanished from search.
Read the caseWhat you get
- A technical audit report following the checklist above, with priorities and expected impact
- A change log: what changed, when, and the before-and-after data
- Speed work implemented — we make the changes, not just recommend them
- Schema deployment, marked up only against visible content
- Migration or rebuild where relevant, with a full URL map and rollback plan
- Monthly reporting on Search Console and Core Web Vitals against the baseline
Who this is and isn't for
A good fit
- The site runs on WordPress and is slow, or rankings have been flat for a long time
- Traffic dropped after a redesign or migration and you want to know why
- You have content, but the technical base is holding it back
- You want someone to change the site, not hand you a report
Not a fit
- You want guaranteed rankings or traffic — we don't offer that
- You want a large number of near-duplicate pages covering keyword variations
- The site is still being planned with no content yet — content and structure come first
Frequently Asked Questions
My site is on WordPress — do you work on it?
Do we have to change theme or rebuild first?
Will the work affect our current rankings?
Will the site go down during a migration?
Your own site is Next.js — why recommend WordPress to me?
Isn't an SEO plugin like Yoast or Rank Math enough?
Want to know what's holding your WordPress site back?
The free search-visibility review includes an initial technical and content diagnosis. It's an initial review rather than a full audit — but enough to tell you which layer the problem sits in.