DEV Community: Mecanik1337

Runtime encrypted strings: Part 1

Mecanik1337 — Tue, 06 Oct 2026 06:00:00 +0000

Runtime Encrypted Strings

Today we will go through the basics of runtime encrypted strings, why do we need to encrypt our strings and learn how to create our own.

In this article you will understand and learn:

What is runtime encryption and decryption
Why do you need to encrypt your strings
See how anybody can see your sensitive data
Create your own custom encryption

What is runtime encryption and decryption

This refers to data encrypted and/or decrypted during the runtime of a program (software, application). The data can be of any type from memory blocks, network traffic, strings, etc.

One of the most common methods used for this purpose is obfuscation (basic). The other (advanced) mechanisms involve mutation/virtualization of compiled code.

Today we will focus on a mechanism using XOR obfuscation.

Why encrypt strings?

The moment you run your software everything is visible in memory. This applies to your end users as well which means they can see everything.

One of the first things an attacker will do is look for strings inside your software. This will allow him to understand everything about your software with minimal effort.

If you are storing sensitive data (like passwords or licenses) it is crucial to not keep them in plain text. Keeping them in plain text will make the life of an attacker easy.

There is a number of ways people can use to analyze your software. The most known and common methods are static and runtime analysis.

Let’s have a look at a simple example using a console app:

We compile this in Release mode (to avoid any debug information left inside). Let’s proceed and test the static and runtime analysis.

Static Analysis Test

In static analysis the software does not need to execute. With that said, let’s open the sample in Ghidra.

From the screenshot below you can see that the sample is compiled without any debug information:

If we search for strings you can see that all our sensitive information is visible:

Once you highlighted the string you can open the decompiler view and see all the relevant code:

Pretty sad eh? 😕 Imagine you worked on your amazing software for months, and you are ready to sell it.

I think the rest is self-explanatory, but I’m sure you get the point.

What’s even sadder is the fact that this is so simple that even a 12-year old can do it. (and some actually do it)

Runtime Analysis Test

In runtime analysis the software needs to run (execute). This means we need to use a software to open the process and read it (normally a debugger).

However, a debugger is not really needed for this purpose. We can simply download a free tool like Process Hacker and open the process:

That was rather simple right? And keep in mind that we haven’t even attached a debugger. A skilled and determined individual will use a debugger.

When you attach a debugger you see much more, but that discussion is for another day.

Creating Runtime Encrypted Strings

There are numerous ways you achieve this:

Using a third party software like VMProtect, Themida.
Compile time string encryption like xorstr.
Using custom methods

The first 2 options might not suit your needs. There are many ups and downs for each of them, which we will not discuss at this point.

One thing you need to understand is that popularity means risk. When you use stuff found randomly on Google, someone already knows about it.

Most people developed a tool against your tool. It’s just the way things are. They do it for a challenge, or to steal your work, but they do it.

With this in mind, you must go custom. You can create your own string encryption from basic to advanced level.

The Plan

Create an easy to use solution
Keep strings encrypted at all times
Decryption only when you need it
Place the strings in random location (optional – not covered)
Destroy the strings after using them (optional – not covered)

The Solution

Start by defining our strings one by one as an array:

The array can hold an unlimited number of strings with a 256 length limit.

I know this is a daunting task, especially if your strings are long. This is just for demonstration and later on we will create a more practical solution.

The idea is to encrypt each character from the string. I will use a simple XOR encryption for this.

Below you can see an example of how this would work:

The above has nothing complicated going on, it’s plain and simple yet quite powerful. You can use this inside a console application.

After you compile and run, the result is unreadable bytes to the human eye:

There you have it, your own little software to create runtime encrypted strings. 😏

The Result

I’s time to put our solution into practice. Let’s create another sample for this purpose and add our code:

Notice 2 important things:

I’ve left some strings in plain text so you can see the difference
The decryption functions needs the length (more on this later)

We compile the above in Release mode and run it. The new Sample is working normally:

If we open the new Sample software in IDA (or Ghidra) the strings we encrypted are not visible:

I’ve mentioned that there are some string intentionally left plain in this sample. The reason why is, so we can follow them to see the code:

I had to scroll down to reach the text in the above image. You can see how different the compiled code is.

We solved the static analysis problem, let’s move on to runtime.

Open it in Process Hacker:

Voila! We solved the runtime analysis problem as well 😎

Download

To download the ready to use solution, please consider supporting this blog 😘

src="https://mecanik.dev/cdn-cgi/imagedelivery/xqiSCiPBXNEeBkfBRiRspQ/e7b91857-3fd7-474f-3b11-020258f32b00/350x197" class="img-fluid mx-auto" alt="Become a Patron" >

DeepSeek R1 vs. OpenAI o3-mini: Which API is Best?

Mecanik1337 — Mon, 05 Oct 2026 18:00:00 +0000

Choosing between DeepSeek R1 vs OpenAI o3-mini is a critical decision for developers integrating reasoning APIs into software applications in 2026. When it comes to reasoning APIs, these are the two strongest candidates most teams end up weighing. Both models excel at complex tasks, code generation, mathematical analysis, and structured logic. However, they operate on different pricing structures, reasoning token methods, latency patterns, and structured data validation limits. This guide compares the two in detail to help you choose the best API for your developer workflows.

TL;DR

Understand reasoning models; reasoning models utilise "thinking tokens" to solve problems before returning a response, improving accuracy on logical tasks.
DeepSeek R1 is highly cost-effective; R1 offers open-source weights and extremely low API costs, making it ideal for high-volume execution.
OpenAI o3-mini delivers lower latency; o3-mini excels at rapid, real-time responses and features robust structured JSON-schema support.
Evaluate data portability; R1 can be hosted on your own cloud infrastructure, preventing vendor lock-in, while o3-mini is hosted exclusively on OpenAI.
Select based on task requirements; use o3-mini for interactive, real-time web applications, and R1 for bulk analytical workflows and offline data processing.

The Core Concept of Reasoning Models

Unlike standard chat completion models, reasoning models are trained to think step by step before outputting answers.

This reasoning process utilises specialised "thinking tokens." The model generates internal steps to cross-examine its assumptions, debug code, and analyse syntax. While this process improves the quality of responses on complex logical tasks, it increases response latency and token costs. Understanding how to manage these context sizes is essential for budgeting. To see how standard APIs differ from reasoning ones, read our guide on building an OpenAI API chatbot.

Latency vs. Reasoning Depth

In production, latency is a critical consideration. If your application requires real-time user interaction, slow API responses will harm the user experience.

OpenAI's o3-mini is optimised for speed. It returns complex reasoning answers in a fraction of the time required by larger models, making it ideal for interactive coding tools. In a head-to-head speed test, o3-mini comes out faster, while DeepSeek R1 prioritises reasoning depth. It writes longer internal reasoning steps, which can result in longer response times. To inspect how to handle edge compute limits and latency, read our comparison of Cloudflare Workers vs AWS Lambda.

Structured Outputs and JSON Parsing

When integrating AI into software workflows, receiving unstructured text is problematic. You must ensure the model returns structured data, such as JSON schemas, to integrate with your database.

OpenAI o3-mini supports structured outputs with strict JSON schemas. This feature guarantees that the API response matches your specified JSON schema exactly, eliminating parsing errors. DeepSeek R1 also supports JSON formats, but developers must write clear system instructions and handle validation checks manually. If you are building database integrations, we suggest linking these APIs to edge databases; see Cloudflare D1 serverless database setup for details.

Pricing and Cost Optimisation

API usage costs are a primary consideration when scaling AI applications. The table below highlights the key pricing differences between the two APIs.

Model API	Input Cost (per 1M tokens)	Output Cost (per 1M tokens)	Hosting Flexibility
OpenAI o3-mini	Higher	Moderate	Hosted only (proprietary)
DeepSeek R1	Extremely Low	Extremely Low	Portable (open weights)

DeepSeek R1 is highly cost-effective, providing reasoning capabilities at a fraction of the cost of proprietary alternatives. Furthermore, since R1 weights are open, you can host the model on your own hardware or deploy it to edge runtimes; see our Cloudflare Workers AI tutorial to learn how to deploy models serverless.

How the Two Reasoning APIs Compare at a Glance

The headline choice comes down to a handful of dimensions that actually affect an integration: how much context each model accepts, how it handles structured data, where it can run, and what a request costs. The table below summarises the practical differences. Treat the specific figures as illustrative snapshots. Published limits and rates for both APIs change frequently, so confirm the current numbers in each provider's documentation before you commit.

Dimension	OpenAI o3-mini	DeepSeek R1
Context window (typical)	~200K tokens	~64K tokens
Max output per request	~100K tokens	~8K–32K tokens
Structured outputs	Native strict JSON schema	JSON via prompting + manual validation
Reasoning-effort control	Adjustable (low/medium/high)	Fixed reasoning behaviour
Hosting	OpenAI cloud only	Hosted API or self-hosted (open weights)
Relative latency	Lower	Higher (longer reasoning traces)
Relative token price	Higher	Substantially lower
Best-fit workload	Interactive, real-time tools	High-volume, batch analysis

Two rows deserve extra attention. o3-mini exposes a reasoning-effort setting, so you can dial thinking down for simple calls and up for hard ones, a direct lever on both latency and cost. R1's open weights, by contrast, mean the same model can run inside your own network, which matters for data-residency and compliance requirements that a hosted-only API cannot satisfy.

Working Out the Cost per 1,000 Calls

Per-million-token rates are hard to reason about in isolation, so it helps to work a realistic scenario end to end. Imagine a classification service that enriches each support ticket: roughly 800 input tokens of prompt and context, and 1,200 output tokens per reply, of which perhaps 900 are internal thinking tokens and 300 the visible answer. Reasoning models bill those thinking tokens at the standard output rate, so they count in full.

Using illustrative published rates (o3-mini around $1.10 input and $4.40 output per million tokens; R1 around $0.55 input and $2.19 output per million), the arithmetic works out as follows:

Step	OpenAI o3-mini	DeepSeek R1
Input: 800 tokens	$0.00088	$0.00044
Output: 1,200 tokens	$0.00528	$0.00263
Cost per call	~$0.0062	~$0.0031
Cost per 1,000 calls	~$6.16	~$3.07
Cost at 1M calls/month	~$6,160	~$3,070

At this shape of workload the hosted R1 API lands at roughly half the running cost of o3-mini. The gap widens as output tokens grow, because reasoning-heavy prompts spend most of their budget on the more expensive output side. The lesson is to estimate output tokens, thinking included, rather than input, since that is where reasoning-model bills are won or lost. Capping maximum output tokens and lowering reasoning effort on easy calls are the two most effective controls.

Self-hosting R1 changes the equation again: you swap per-token fees for GPU rental. A high-memory GPU instance capable of serving the full model tends to run into the low thousands of pounds per month, so self-hosting only beats the API once sustained throughput is high enough to keep that hardware busy. Below that break-even point, the managed API is cheaper and far less operational work.

Choosing by Workload, Not by Winner

Neither model is universally "better"; the right pick follows the shape of the job.

Choose OpenAI o3-mini when the interaction is user-facing and latency is visible: coding assistants, chat features, autocomplete, or anything where a person waits for the response. Its native strict JSON schema also makes it the safer choice when a malformed response would break a downstream system, such as a function-calling agent or a database write. The adjustable reasoning effort lets one integration serve both quick and hard queries without swapping models.

Choose DeepSeek R1 when volume is high and latency is hidden: overnight batch jobs, document enrichment, bulk classification, dataset labelling, or offline analysis where throughput and unit cost matter more than a second or two of delay. It is also the pragmatic choice under strict data-governance rules, because the open weights let you keep every token inside infrastructure you control.

Many production stacks end up using both: a fast hosted model on the interactive path and a cheaper, self-hostable model on the batch path, with a routing layer that sends each request to the model that fits. That hybrid pattern captures most of the cost saving without sacrificing the responsiveness users notice.

Total Cost of Ownership and Switching Costs

Sticker price is only part of the total cost of ownership. Because both APIs speak a broadly OpenAI-compatible request format, moving a prompt from one to the other is usually a matter of changing the endpoint, key, and model name rather than rewriting application logic. That keeps switching costs low and is a strong argument for not hard-coding a single provider. The larger migration effort sits elsewhere: strict-schema features and reasoning-effort parameters are provider-specific, so any code that depends on them needs a fallback path when you move to a model that lacks them.

Factor in the softer costs too. A hosted API adds no operational burden but exposes you to rate limits, pricing changes, and regional availability. Self-hosting removes those risks but adds GPU provisioning, scaling, patching, and monitoring, all real engineering time that belongs in the budget. Abstracting the model call behind a thin internal interface from day one is the cheapest insurance: it lets you test the two APIs against each other on your own traffic and switch whenever price or performance shifts, which for fast-moving reasoning models it inevitably will.

Key Takeaways

Reasoning models use internal thinking tokens to solve logical problems, outperforming standard chat models.
OpenAI o3-mini is optimised for low-latency, real-time web applications requiring structured JSON formats.
DeepSeek R1 is highly cost-effective and portable, allowing self-hosting to prevent vendor lock-in.
Choose o3-mini for interactive development assistants; choose R1 for high-volume offline data analysis.
Manage reasoning token sizes carefully to prevent unexpected API costs in production.

Integrate Reasoning Models into Your Stack

Integrating advanced reasoning APIs requires careful prompt engineering, error handling, and hosting configurations. Mecanik provides professional AI integration services and custom setups through our OpenAI API integration service. We construct fast, secure AI pipelines tailored to your business. Contact us today to discuss your next project.

Frequently Asked Questions (FAQ)

What is the difference between a reasoning model and a standard model?
Reasoning models use internal thinking tokens to analyse problems and debug logical steps before outputting a response, whereas standard models predict the next token immediately.

Can I host DeepSeek R1 on my own servers?
Yes. DeepSeek R1 is an open-source model with public weights, allowing you to self-host it on your own GPU infrastructure or deploy it on serverless runtimes.

Does OpenAI o3-mini support strict JSON schemas?
Yes. OpenAI's API supports structured outputs, guaranteeing that the model's output conforms exactly to the JSON schema you define in the API call.

How does thinking token usage impact API costs?
Thinking tokens are billed as input and output tokens. Because the model must write out its internal reasoning steps, a single query uses more tokens than a standard API query.

Which model is better for code generation?
Both are excellent. OpenAI o3-mini is faster and more interactive, while DeepSeek R1 often provides deeper logic analysis on complex, multi-file software tasks.

Deploying Llama 3 on the Edge with Cloudflare Workers AI

Mecanik1337 — Mon, 05 Oct 2026 06:00:00 +0000

This Cloudflare Workers AI tutorial shows you how to deploy and run machine learning models directly on Cloudflare's global edge network. With Cloudflare Workers AI, you can execute Large Language Models (LLMs), text translation, image generation, and audio transcription close to your users without managing complex GPU servers. The steps below cover how to configure Wrangler, write a fetch handler, run a Llama model, and optimise API costs at the edge.

TL;DR

Run AI models serverless; Cloudflare Workers AI manages the underlying GPU infrastructure, billing you only for active compute.
Configure bindings in wrangler.toml; link your worker directly to the AI binding without managing API keys.
Write a fetch handler to receive user requests, execute the model, and stream JSON responses.
Select optimised models from Cloudflare's catalogue (such as Llama 3, Whisper, or Stable Diffusion) to balance speed and accuracy.
Silo billing and rate limits to protect your endpoint from high-token cost abuse in production.

Why Run AI Models on the Edge?

Traditionally, integrating AI features required calling external APIs (like OpenAI) or hosting open-source models on expensive cloud servers.

Calling external APIs presents latency and data privacy concerns. Running your own GPU servers introduces maintenance challenges and scales poorly. Cloudflare Workers AI resolves this dilemma. The platform hosts open-source models on GPUs deployed across Cloudflare's global network. Your code runs as a lightweight Worker, executing models close to your users with near-zero latency. For an introduction to building basic edge structures, check our guide on building a serverless API with Cloudflare Workers.

Prerequisites

Before you begin, make sure you have the following in place:

A Cloudflare account with Workers enabled. The free plan includes a daily inference allocation, which is more than enough to follow this guide.
Node.js 18 or newer installed locally, so you can run the tooling and the local development server.
Wrangler, the Workers CLI, installed and authenticated. Install it with npm install -g wrangler, then run wrangler login to link it to your account.
Basic familiarity with JavaScript and the fetch request/response model that every Worker is built around.

If you are starting from a blank slate, scaffold a project with the create-cloudflare (C3) tool. It generates a ready-to-deploy Worker, a wrangler.toml, and a sensible compatibility_date:

npm create cloudflare@latest my-edge-ai
cd my-edge-ai

Choose the "Hello World" Worker template when prompted. That gives you a clean starting point to which you can add the AI binding in the next step.

Step 1: Configuring wrangler.toml

To access AI models, you first need to define the AI binding in your project's configuration file.

Open your wrangler.toml (or wrangler.json) and add the following block:

[ai]
binding = "AI"

This binding makes the AI service available on the environment argument (env.AI) in your worker code. You do not need to manage API keys, configure endpoints, or deal with connection strings. Wrangler handles the authentication automatically when you deploy.

A complete wrangler.toml for this project looks like this:

name = "my-edge-ai"
main = "src/index.js"
compatibility_date = "2025-01-01"

[ai]
binding = "AI"

The compatibility_date matters: it pins runtime behaviour so future platform changes cannot silently alter how your Worker runs. Omit it and deployment fails with a configuration error, which is one of the most common first-run stumbles.

Step 2: Writing the Worker Code

Once the binding is configured, you can call the AI service from your fetch handler. The example below shows how to receive a JSON payload containing a user prompt and generate a text completion using Llama 3.

export default {
  async fetch(request, env) {
    if (request.method !== "POST") {
      return new Response("Method not allowed", { status: 405 });
    }

    try {
      const { prompt } = await request.json();
      if (!prompt) {
        return Response.json({ error: "Missing prompt" }, { status: 400 });
      }

      // Call the model using the AI binding
      const response = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
        prompt: prompt,
        max_tokens: 256
      });

      return Response.json(response);
    } catch (err) {
      return Response.json({ error: err.message }, { status: 500 });
    }
  }
};

This simple structure allows you to build text summarisers, sentiment analysis tools, or content generators. If you want to connect these features to your database, you can bind to a serverless SQL database; see Cloudflare D1 database setup for details.

Using the chat message format

The prompt field is convenient for one-shot completions, but conversational models behave best with a structured messages array. This lets you set a system instruction that shapes the model's tone and keep it separate from the user's input:

const messages = [
  { role: "system", content: "You are a concise technical assistant." },
  { role: "user", content: prompt }
];

const response = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
  messages,
  max_tokens: 512
});

// Text models return the generated text on the `response` property
return Response.json({ answer: response.response });

Note that text-generation models wrap their output in a response field, so the completed text lives at response.response rather than at the top level. This catches out many first-time users, who log the raw object and see an unexpected shape.

Choosing the Right Model

Cloudflare's catalogue includes dozens of models, and choosing well is a trade-off between speed, quality, and cost. Smaller models reply faster and consume fewer resources; larger models reason better but cost more per request. The table below compares a few popular text-generation options.

Model	Best for	Relative speed	Relative cost
`@cf/meta/llama-3-8b-instruct`	General chat, summarisation	Fast	Low
`@cf/meta/llama-3.1-70b-instruct`	Complex reasoning, longer answers	Slower	Higher
`@cf/mistral/mistral-7b-instruct-v0.2`	Lightweight instructions, drafts	Fast	Low
`@cf/meta/llama-guard-3-8b`	Moderating and classifying content	Fast	Low

As a rule of thumb, start with an 8B model such as Llama 3 8B Instruct. It handles the majority of summarisation, classification, and chat workloads at a fraction of the latency and cost of a 70B model. Only move up to a larger model once your own evaluations show the smaller one genuinely falling short.

Step 3: Streaming Responses for Better User Experience

For chat applications, waiting for the full response to generate can result in poor user experience.

You can configure the AI binding to stream the response token by token as it generates. To achieve this, pass stream: true in your request options. The worker will return a ReadableStream that you can forward directly to the browser client, creating a fast, interactive chat interface. To compare this edge runtime approach with traditional cloud hosting, read our comparison of Cloudflare Workers vs AWS Lambda.

Here is a complete streaming handler. Rather than returning parsed JSON, you forward the stream to the client with the correct content-type so the browser can consume it as Server-Sent Events:

export default {
  async fetch(request, env) {
    const { prompt } = await request.json();

    const stream = await env.AI.run("@cf/meta/llama-3-8b-instruct", {
      prompt,
      max_tokens: 512,
      stream: true
    });

    return new Response(stream, {
      headers: { "content-type": "text/event-stream" }
    });
  }
};

The key difference from the non-streaming version is the response itself: you pass the stream straight into new Response() and set content-type to text/event-stream. Wrap a stream in Response.json() instead and it will not serialise correctly, so the client receives an empty body.

Testing and Deploying Your Worker

With the binding and handler in place, run the Worker locally before you ship it:

npx wrangler dev

Because inference runs on Cloudflare's GPUs rather than on your machine, the AI binding reaches out to the network even during local development. Wrangler manages this for you, but it does mean local testing needs connectivity and a valid login to work.

Send a test request with curl while wrangler dev is running:

curl -X POST http://localhost:8787 \
  -H "Content-Type: application/json" \
  -d '{"prompt": "Summarise the benefits of edge computing in one sentence."}'

Once you are happy with the output, deploy to the global network:

npx wrangler deploy

Wrangler uploads your Worker and returns a *.workers.dev URL. Your endpoint is now live in every Cloudflare data centre, and each request is routed to the location closest to the user automatically.

Common Pitfalls and Troubleshooting

A handful of issues recur when teams first deploy inference at the edge. Knowing the fix in advance saves hours of debugging.

Cannot read properties of undefined (reading 'run') — the env.AI binding is undefined. This almost always means the [ai] block is missing from wrangler.toml, or you edited the file but did not restart wrangler dev (or redeploy). Confirm the binding name matches exactly.
No such model or a 400 error on run — the model identifier is wrong. Model names are case-sensitive and must include the full path, for example @cf/meta/llama-3-8b-instruct. Copy them from the model catalogue rather than typing from memory.
Empty or malformed streamed responses — you returned the stream through Response.json() instead of new Response(stream, ...). Streams must be forwarded, not serialised.
Capacity or 429 errors under load — the model is temporarily saturated or you have hit an account limit. Add a short retry with back-off, and consider a smaller model for bursts of traffic.
Truncated answers — the reply stops mid-sentence because max_tokens is too low. Raise the limit, but remember that larger values increase both latency and cost.

If a request fails silently, watch the live logs with npx wrangler tail while you send a test request. It streams runtime errors and console.log output from the deployed Worker, which is the quickest way to see what the model actually returned.

Optimising Production Costs and Security

While Workers AI is highly cost-effective, running model inference in production requires careful controls.

Implement Rate Limiting: Limit how often a client can call your endpoint. GPU compute costs scale with usage.
Sanitise Prompts: Validate inputs to prevent injection attacks and ensure the model outputs stay on brand.
Silo Context Size: Keep prompt histories short. Sending massive context buffers on each call increases token processing costs.

For a detailed look at context management, check our guide on building an OpenAI API chatbot.

Key Takeaways

Cloudflare Workers AI provides serverless access to open-source models without GPU maintenance.
Configure access by adding the [ai] binding block to your wrangler.toml.
Write fetch handlers to execute text generation, translation, or image tasks directly at the edge.
Enable token streaming with stream: true to optimise mobile and chat experiences.
Implement rate limits and prompt sanitisation to protect your edge endpoints in production.

Build Your AI Applications on the Edge

Building reliable AI integrations requires expert knowledge of serverless architecture. Mecanik specialises in AI integration services and custom API setups through our OpenAI API integration service. We build edge-native tools that scale seamlessly, optimising costs and user experiences. Contact us today to discuss your project requirements.

Frequently Asked Questions (FAQ)

What is Cloudflare Workers AI?
It is a serverless platform that allows you to run machine learning models (text generation, translation, speech-to-text, image generation) on Cloudflare's global GPU network.

Do I need an API key to use Workers AI?
No. Once you declare the AI binding in your wrangler.toml file, Cloudflare handles credentials internally, making the service accessible via env.AI as shown in this cloudflare workers ai tutorial.

What models are available on Cloudflare Workers AI?
The platform hosts popular open-source models, including Meta Llama, Mistral, OpenAI Whisper, and Stable Diffusion, which are updated regularly in their model catalogue.

Can I stream text responses from Workers AI?
Yes. By setting stream: true in the parameters of your env.AI.run call, the worker returns a standard ReadableStream to stream text to the browser.

How does billing work for Workers AI?
Billing is based on the number of tokens processed (for text models) or the duration of compute time (for other models), offering a cost-effective utility model.

Drupal Migration in 2026: Costs, Options and Deadlines

Mecanik1337 — Sun, 04 Oct 2026 18:00:00 +0000

Drupal migration is one of those projects that stays comfortably in next quarter's plan until a date makes it urgent. Two dates are doing that right now, and only one of them is in the future.

Drupal 7 lost official support on 5 January 2025. Any site still running it has been going without security coverage for well over a year. Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released, after which it receives no further releases of any kind. If you are on either version, the question is no longer whether to move but which path to take and what it will cost.

Where you stand: From Drupal 10 to Drupal 11 is a genuine upgrade — the same site, updated in place, typically two to six weeks. From Drupal 7 to Drupal 11 is not an upgrade at all; it is a rebuild with a content migration attached, and it typically runs three to six months. Confusing the two is the single most expensive mistake in this space, because Drupal 7 sites get quoted as upgrades and then overrun by a factor of four.

The Two Very Different Migrations

The word migration covers two jobs that share almost nothing beyond the name.

Drupal 10 to 11 is an upgrade. The architecture is the same. Your entities, fields, views and configuration carry across. The work is mostly dependency management: making sure every contributed module has a Drupal 11 compatible release, clearing deprecated API calls out of your custom code, and moving to a supported PHP version. It is methodical rather than difficult, and a well-maintained site can be done in a fortnight.

Drupal 7 to Drupal 11 is a rebuild. Drupal 8 rewrote the platform on Symfony components, replacing the module API, the theming layer and the configuration system. Nothing carries over automatically except content, and even that arrives through a purpose-built migration process rather than an upgrade script. Your modules do not exist any more, your theme has to be rewritten in Twig, and your custom code has to be reimplemented against a different architecture.

That second case is why Drupal 7 sites have lingered so long. The honest framing is that you are not upgrading a site, you are building a new one and bringing the content with you.

What Each Drupal Migration Path Costs

Figures below assume UK agency rates and a site of moderate complexity. Complexity here means the number of content types, contributed modules and custom modules, not the number of pages.

Drupal 10 to 11, well-maintained site. Two to four weeks, roughly £6,000 to £15,000. This is the happy case: modules are current, custom code is small, and the main work is testing.

Drupal 10 to 11, neglected site. Four to eight weeks, roughly £15,000 to £35,000. Here the blockers are contributed modules with no Drupal 11 release, custom code written against APIs that have since been removed, and a PHP version that also has to move. Every abandoned module becomes a decision: find a replacement, take over maintenance, or reimplement its behaviour.

Drupal 7 to Drupal 11. Three to six months, commonly £40,000 to £120,000 and higher for large or heavily customised sites. That range is wide because it is really a rebuild budget. The content migration itself is often the smaller half; the theme, the custom functionality and the integrations are the larger half.

Drupal 7 to a different platform. Sometimes the right answer. If the original reason for choosing Drupal no longer applies — the site has become a straightforward marketing site with a blog — then moving to something simpler can cost less than migrating within Drupal, and reduce running costs afterwards. Our comparison of WordPress and custom web development covers where that line sits, and the Drupal web development guide is honest about when Drupal is not the answer.

Why Contributed Modules Decide Your Timeline

Almost every Drupal upgrade estimate lives or dies on the contrib audit, and it is the first thing worth doing.

List every contributed module the site uses, then check each one for a stable release compatible with your target version. What you will find falls into four groups. Some have a compatible release and need nothing. Some have a release candidate or a patch in the issue queue that you can apply through Composer. Some have been abandoned, and you must find a replacement, adopt the module yourself, or replace its function with custom code. And some have been absorbed into Drupal core, which is the pleasant surprise of the exercise.

That audit converts a vague project into a countable one. Until it is done, any quote is a guess, and a supplier who gives you a fixed price without it is either padding heavily or about to raise change requests.

The same logic applies to custom modules, with a different tool. Drupal's deprecation tooling will scan custom code and report calls to APIs that have been removed or are due for removal, which turns "we have some custom code" into a specific list of files and line numbers.

What Actually Goes Wrong

Certain failure modes recur across almost every Drupal migration.

Configuration drift between environments. If changes have been made directly in the production admin interface rather than exported to configuration files, your staging environment is not a faithful copy and your testing is worth less than you think. Discovering this mid-migration is common and it always costs time.

Content that was never as structured as everyone believed. Drupal 7 sites frequently accumulated content in ways nobody documented: fields repurposed for other things, a taxonomy vocabulary doing the job of a workflow state, HTML pasted into body fields carrying inline styles. A migration surfaces all of it at once, and each case needs a decision from someone who knows what the content is for.

Media and file handling. Drupal's media handling changed substantially after Drupal 7. Files, image styles and embedded media rarely map one to one, and sites with large media libraries should budget for this specifically rather than assuming it comes free with the content migration.

URL and SEO continuity. This is the one that damages the business rather than the schedule. If URL aliases change without redirects, you lose the rankings the old site earned. Every migration needs a full URL inventory, a redirect map, and verification after launch. Our guide to migrating a website without losing traffic covers that process in detail, and it applies to platform changes just as much as domain changes.

Multilingual content. If the site runs in several languages, expect the migration to take substantially longer. Language handling was rebuilt after Drupal 7, and translated content, translated configuration and language-specific URL patterns each need their own attention.

How to Sequence the Work

The order matters more than most teams expect, and getting it wrong causes rework.

Start with the contrib and custom code audit, before any estimating. Then get the site onto a supported PHP version and the latest release of its current major version, because that removes a whole category of noise from the actual upgrade. Only then attempt the major version step.

Build the new environment alongside the old one rather than upgrading in place. That gives you somewhere to test the content migration repeatedly, which you will need, because migrations are run many times before they are run once for real.

Treat the content migration as code. Drupal's migration framework lets you define migrations in configuration and re-run them, which means you can reset, adjust the mapping and go again. Teams that hand-fix content in the new site rather than fixing the migration definition end up unable to re-run it, and then a single content change in the old site becomes a manual reconciliation.

Finally, plan a content freeze near the end, and keep it short. Long freezes cause editors to work around you, which produces exactly the drift you were trying to avoid.

Should You Move Off Drupal Entirely?

It is a fair question and it deserves an honest answer rather than a defensive one.

Stay on Drupal when the reasons you chose it still hold: complex content modelling, granular permissions, multilingual requirements, heavy editorial workflow, or accessibility and public sector obligations. Drupal remains genuinely strong at all of these and the upgrade path from here is now stable, with a predictable two-year major release cycle.

Consider moving when the site has drifted away from those needs. Plenty of Drupal 7 sites are now, in practice, a marketing site with news and a contact form. Migrating that within Drupal means paying rebuild prices for capability you no longer use.

The decision should turn on the content model and the editorial workload, not on which platform your developer prefers. If nobody can articulate what Drupal is doing for you that a simpler platform could not, that is informative.

Get the Audit Before You Get a Quote

Mecanik handles Drupal upgrades and migrations as part of our website development services. We start with the contrib and custom code audit, because that is what turns an open-ended project into a fixed scope, and it is worth having even if you then take the work elsewhere.

For Drupal 10 sites the sensible move is to plan the Drupal 11 step now rather than in November, when everyone else is doing it. For Drupal 7 sites the security position is already the argument. If your constraint is capacity rather than expertise, our guide to hiring a Drupal developer covers what to look for.

Tell us which version you are on and roughly how many contributed and custom modules the site uses, and we will tell you which of the paths above you are actually facing.

Frequently Asked Questions

When does Drupal 10 stop being supported?
Drupal 10 reaches end of life on 9 December 2026, the same week Drupal 12 is released. After that date it receives no further releases, including security fixes, so any site remaining on it is running unsupported.

How much does a Drupal migration cost?
A Drupal 10 to 11 upgrade on a well-maintained site typically costs £6,000 to £15,000, rising to £15,000 to £35,000 where modules and custom code are neglected. Drupal 7 to Drupal 11 is a rebuild with content migration and commonly runs £40,000 to £120,000 or more.

Why is Drupal 7 to Drupal 11 so much more expensive?
Because it is not an upgrade. Drupal 8 rebuilt the platform on Symfony components, replacing the module API, theming layer and configuration system. Modules must be replaced, themes rewritten in Twig and custom code reimplemented, with content brought across through a purpose-built migration.

How long does a Drupal 10 to 11 upgrade take?
Two to four weeks for a site whose contributed modules are current and custom code is small, and four to eight weeks where abandoned modules or removed APIs have to be worked around. A contributed module audit up front is what makes the estimate reliable.

Can I migrate from Drupal to WordPress instead?
Sometimes that is the right call, particularly where a Drupal 7 site has become a straightforward marketing site with no complex content modelling, permissions or multilingual needs. Base the decision on your content model and editorial workload rather than on platform preference.

COBOL Migration Cost, Timeline and Risk - A UK Guide 2026

Mecanik1337 — Sun, 04 Oct 2026 06:00:00 +0000

"How much will it cost to move off COBOL?" is the first question every board asks, and the honest answer is that it depends on more than the size of the codebase. This guide breaks down what actually drives the cost of a COBOL migration in the UK, realistic budget and timeline ranges, and the risks that turn a well-planned project into an overrun.

TL;DR

A mid-size UK COBOL migration typically costs £200,000 to £800,000 and takes one to two years; full mainframe decommissions run into the millions and multiple years
Cost is driven far more by codebase complexity, undocumented business logic, and data access redesign than by raw line count
The choice of target language and migration approach materially changes the budget
The most common reason projects overrun is underestimating scope, especially undocumented business rules and the data access layer

What Actually Drives COBOL Migration Cost

Line count is the headline number, but it is a weak predictor on its own. The real cost drivers are:

Complexity, not just size. A 100,000-line system of clean batch programs is cheaper to migrate than a 50,000-line system dense with EXEC CICS, dynamic CALLs, and intricate REDEFINES. Transaction processing systems cost more than batch systems of the same size.

Undocumented business logic. COBOL systems often carry 30 to 40 years of business rules embedded in code with no external documentation. Rediscovering and validating those rules is frequently the single largest and least predictable line item.

The data access layer. EXEC SQL against DB2 and VSAM file handling rarely convert automatically. They must be redesigned onto the target platform's data access technology, and this is often the biggest work item after business-logic discovery.

Data format conversion. Packed decimal (COMP-3), EBCDIC encoding, and fixed-width layouts all need explicit mapping and testing with real data.

Target language and approach. These shift the budget in predictable ways (covered below).

Testing and cut-over. Building a regression test suite that proves output parity, and executing a safe cut-over with rollback, is real, non-trivial effort that inexperienced estimates omit.

Indicative Cost and Timeline Ranges (UK)

These ranges cover analysis, migration, testing, and go-live support. They exclude ongoing operational costs, training, and downstream integration work that often surfaces mid-project.

System Size	Approach	Estimated Cost	Typical Timeline
Small (< 50,000 lines)	Parallel rewrite	£80,000 to £200,000	3 to 9 months
Medium (50,000 to 500,000 lines)	Strangler fig	£200,000 to £800,000	12 to 24 months
Large (500,000+ lines)	Automated + incremental refactor	£500,000 to £2,000,000+	2 to 4 years
Legacy mainframe decommission	Full programme	£1,000,000 to £10,000,000+	3 to 5 years+

Treat these as planning ranges, not quotes. A proper estimate requires a code assessment; the spread within each band is driven by the complexity factors above.

How the Target Language Affects Cost

The destination language changes both the effort profile and the long-term cost of ownership. In broad terms:

Python maps naturally to COBOL's procedural style and has the largest developer pool, which tends to lower conversion and long-term maintenance cost.
C# is efficient for organisations already on the .NET and Azure stack, and its native decimal type reduces the effort of getting financial precision right.
Java suits JVM-based enterprises; BigDecimal handles precision correctly but adds some verbosity.
Go is efficient to build and deploy, but the lack of a native decimal type adds review effort for financial fields.
Rust tends toward the upper end of any size band because its ownership model adds up-front design effort.

The COBOL migration overview compares all six target languages side by side to help you choose.

How the Migration Approach Affects Cost

Automated conversion reduces the mechanical translation effort but never produces a finished system; budget for the manual work the tooling flags (embedded SQL, CICS, dynamic calls, decimal precision).
Parallel rewrite roughly doubles operational cost during the transition because two systems run at once, but it minimises continuity risk. It suits smaller, mission-critical systems.
Incremental (strangler fig) spreads cost over time and reduces big-bang risk, at the price of a longer hybrid period. It is the most common approach for large UK enterprise systems.

Most real projects blend automated conversion with an incremental rollout.

The Risks That Cause Overruns

Migrations overrun for predictable reasons. The big five:

Underestimated business-logic discovery. The rules are in the code, not in a document. Budget explicit discovery time.
Data access redesign. DB2 and VSAM access does not port automatically. Treat it as its own workstream.
Inadequate regression testing. Without output-parity testing on real data, you cannot prove the migration is correct. Build the test suite before migration starts.
Decimal precision errors. Financial fields mapped to floating-point types silently corrupt money. Map to the correct decimal type for the target language.
Cut-over failure. The switch to production is the highest-risk moment. A detailed cut-over plan with rollback and reconciliation is mandatory.

How to Get an Accurate Estimate

A reliable number comes from a code assessment, not a line count. A good assessment inventories programs and copybooks, identifies EXEC SQL / EXEC CICS / dynamic-call hotspots, gauges business-logic density, and maps the data access surface. The Mecanik COBOL migration service provides UK enterprise assessments and full-service migration; for mainframe estates on IBM z/OS, the legacy mainframe migration service covers the infrastructure decommission alongside the code.

Key Takeaways

A mid-size UK COBOL migration typically costs £200,000 to £800,000 over one to two years; mainframe decommissions run into the millions.
Complexity, undocumented business logic, and data access redesign drive cost far more than line count.
Target language and migration approach both move the budget in predictable ways.
Overruns come from underestimating discovery, testing, and cut-over; a proper code assessment is the only reliable basis for a quote.

Frequently Asked Questions (FAQ)

How much does a COBOL migration cost in the UK?
A small system typically costs £80,000 to £200,000, a mid-size system £200,000 to £800,000, and large systems £500,000 upward. Full mainframe decommission programmes run from £1,000,000 into the tens of millions. Complexity, not line count, sets where you land in the range.

How long does a COBOL migration take?
Small, well-documented systems take three to nine months. Mid-size enterprise systems run twelve to twenty-four months. Large mainframe programmes take three to five years or more for full decommission.

Why do COBOL migration costs vary so much?
Because complexity varies enormously. Undocumented business logic, embedded SQL and CICS, data format conversion, the target language, and the migration approach all move the cost. Two systems of the same line count can differ by an order of magnitude.

Does automated conversion reduce the cost?
It reduces mechanical translation effort, but no tool produces a finished system. You still budget for the data access layer, decimal-precision decisions, testing, and cut-over that the tooling flags for manual work.

What is the biggest cause of COBOL migration overruns?
Underestimating scope, especially undocumented business logic and the data access redesign. Building a regression test suite for output parity before migration begins is the single most effective way to control that risk.

WordPress Hacked: Malware Removal and Recovery Guide

Mecanik1337 — Sat, 03 Oct 2026 18:00:00 +0000

If your WordPress site was hacked and is now showing pharmaceutical spam, redirecting visitors to somewhere unpleasant, or has been flagged by Google as deceptive, start here rather than with a plugin. The instinct is to install a security scanner and click clean. That removes the visible symptom and leaves the way in, which is why so many sites get reinfected within days and their owners conclude that WordPress is simply insecure.

It is not. Almost every compromise arrives through an out-of-date plugin, and almost every failed cleanup happens because someone removed the malware without removing the access.

First hour: Take the site offline or into maintenance mode. Change the hosting control panel password, the database password, all administrator passwords and the FTP or SSH credentials. Do not restore a backup yet, and do not delete anything yet. You need the current state to work out how they got in, and a restore destroys that evidence while very likely reinstating the same vulnerability.

What to Do in the First Hour

Order matters here, and the common mistakes are all impatience.

Take the site down. A maintenance page or a temporary block at the hosting or CDN level protects visitors and stops the site distributing malware while you work. If the site is serving malicious redirects, every hour it stays up compounds the reputational damage.

Rotate every credential, not just the WordPress admin password. That means hosting panel, database user, FTP and SSH keys, and any API keys stored in the site's configuration. Attackers routinely create a second administrator account or leave a key behind, so changing one password achieves nothing.

Preserve the evidence before changing anything. Take a full copy of the files and database as they are now, and download the server access logs covering at least the last thirty days. Those logs are how you find the entry point, and many hosts rotate them within days.

Then, and only then, work out what happened.

How Your WordPress Site Got Hacked: Finding the Entry Point

Cleaning without diagnosis is why reinfection is so common. Four checks find the cause in most cases.

Check plugin and theme versions against known vulnerabilities. Out-of-date plugins are far and away the leading cause. Note every plugin, its version, and whether a security release exists that you have not applied. Pay particular attention to anything with an expired licence, because premium plugins stop receiving updates when the licence lapses while continuing to appear installed and active.

Read the access logs around the first sign of trouble. You are looking for POST requests to unusual paths, requests to files that should not exist, and a burst of activity from one address shortly before the defacement. This is usually where the answer is.

Look for files that do not belong. Recently modified PHP files in the uploads directory are a strong signal, because nothing should ever execute there. So are files with names designed to look plausible, and modifications to wp-config.php or .htaccess.

Check for added administrator accounts and scheduled tasks. Attackers commonly create a user to return through, and register a scheduled task that reinstalls the payload after you clean it. A site that keeps reinfecting on a regular cycle almost always has a scheduled task nobody looked for.

Why "Just Restore a Backup" Usually Fails

It is the first suggestion everyone receives and it is right about a third of the time.

Restoring works when you know the compromise date, have a backup from before it, and have identified and fixed the vulnerability. Without all three it fails predictably. Restore a backup from last week and you may be restoring a site that was already compromised two weeks ago and merely quiet. Restore without patching the vulnerable plugin and you have rebuilt the door you were locked out of.

There is also the problem of what a restore costs you. On a store or a membership site, rolling back means losing every order, registration and comment since the backup. That is often unacceptable, which pushes you towards cleaning the live site rather than replacing it.

The reliable approach is a rebuild rather than a restore. Install WordPress core fresh, install clean copies of every plugin and theme from their official sources rather than from the compromised site, and carry across only the uploads directory and the database — both inspected first. That guarantees the executable code is clean, which file-by-file cleaning never quite does.

Cleaning the Database

The database is where incomplete cleanups leave things behind, because scanners concentrate on files.

Injected content usually appears in post content as hidden links or iframes, in the options table where redirect scripts get stored, and in user metadata. Search for script tags, base64-encoded blocks and unfamiliar domains across the content and options tables.

Check the users table by hand. Look at every account with administrator privileges and confirm you recognise each one, then check registration dates against your own records.

Look at scheduled tasks, which in WordPress live in the options table. An entry pointing at a function you do not recognise is how a site reinfects itself on schedule long after the files were cleaned.

Take particular care with anything encoded. Attackers obfuscate payloads specifically so a search for obvious strings misses them, so decode anything suspicious rather than assuming it is a legitimate plugin doing something clever.

Getting Unflagged and Recovering Rankings

Cleaning the site is not the end, because the warnings persist until you ask for them to be reviewed.

If Google has flagged the site, the security issues report in Search Console tells you what was detected and lets you request a review once you have fixed it. Only request the review after the site is genuinely clean, because a failed review lengthens the process.

Check whether the domain has landed on blocklists used by browsers and email providers. Being clean is not enough on its own; each maintains its own list and its own removal process.

Then look at the damage. Search visibility usually recovers once warnings are lifted, but a site that spent weeks serving spam pages may have had those pages indexed. Check for indexed URLs that were never yours, remove them, and confirm the clean versions are being crawled. Our website security audit guide covers the verification steps in more detail.

What Professional Recovery Costs

Prices reflect typical UK rates and vary with how long the compromise went unnoticed.

A straightforward cleanup on a small site caught quickly, with a known cause, generally runs £400 to £1,200 and takes a day or two. This is the common case when someone notices within a week.

A full incident response — log analysis to establish entry point and timeline, clean rebuild, database inspection, credential rotation, hardening and blocklist removal — typically runs £1,500 to £5,000. This is what a store or a site holding customer data should expect, because you also need to establish whether data was accessed.

Sites compromised for months, or hosting several sites on the same account, cost more, because cross-contamination between sites on shared hosting is common and each one must be checked.

If personal data may have been accessed, there are obligations beyond the technical cleanup. UK GDPR requires notifying the ICO within 72 hours of becoming aware of a qualifying breach, and that clock starts at awareness, not at cleanup. Take advice early rather than after you have finished tidying. Our guide to GDPR technical compliance covers the engineering side of that.

Making Sure It Does Not Happen Again

Recovery without hardening just resets the clock.

Update discipline is the whole game. The overwhelming majority of compromises exploit a vulnerability with a patch already available, so the fix is a routine that applies security releases promptly and a policy of removing anything unmaintained. Premium plugins with lapsed licences should be renewed or replaced, never left in place.

Reduce what can execute. Nothing in the uploads directory should ever run as PHP, file editing from the admin interface should be disabled, and administrator accounts should be few and individually named.

Add multi-factor authentication on every administrator account and rate-limit the login endpoint. Most credential attacks are automated and stop being viable the moment a second factor exists.

Finally, back up properly and test it. A backup you have never restored is a hypothesis. Keep several generations, because the newest one may already contain the compromise. Our WordPress security hardening checklist sets out the full configuration, and our WordPress performance audit guide covers the plugin discipline that reduces the attack surface as a side effect.

Get It Cleaned Properly

Mecanik provides WordPress security audit and incident recovery work: establishing how the compromise happened, rebuilding cleanly rather than patching over it, inspecting the database, and hardening the site so the same route closes behind you.

We work from the server logs rather than from a scanner's output, because a scanner tells you what it recognises and the logs tell you what actually happened. Where the site handles customer data we will also tell you plainly whether you appear to have a notifiable breach, rather than leaving you to discover that later. Ongoing maintenance is available through our WordPress development service, which is generally cheaper than a second incident.

If your site is compromised right now, take it offline, rotate the credentials, keep the logs, and get in touch.

Frequently Asked Questions

What should I do first if my WordPress site is hacked?
Take the site offline, rotate every credential including hosting, database, FTP and all administrator accounts, and preserve a copy of the current files, database and server logs. Do not restore a backup or delete files yet, because that destroys the evidence needed to find the entry point.

Why does my WordPress site keep getting reinfected?
Almost always because the cleanup removed the malware but not the access. Look for administrator accounts you do not recognise, backdoors in the uploads directory, and scheduled tasks in the options table that reinstall the payload. Reinfection on a regular cycle usually indicates a scheduled task.

Can I just restore a backup to fix a hacked site?
Only if you know when the compromise happened, have a backup from before it, and have fixed the underlying vulnerability. Without all three you risk restoring an already-compromised site or reopening the same hole. A clean rebuild with fresh core, plugins and themes is more reliable.

How much does WordPress malware removal cost?
A straightforward cleanup on a small site caught early typically costs £400 to £1,200. A full incident response with log analysis, clean rebuild, database inspection and hardening generally runs £1,500 to £5,000, and long-running or multi-site compromises cost more.

How do I get my site unflagged by Google?
Clean the site fully, then request a review through the security issues report in Search Console. Only request it once the site is genuinely clean, since a failed review lengthens the process, and check separately for browser and email blocklists which each have their own removal procedure.

WooCommerce Performance: Why Your Store Is Slow

Mecanik1337 — Sat, 03 Oct 2026 06:00:00 +0000

Almost every WooCommerce performance investigation starts the same way. The store owner has already moved to a faster host, installed a caching plugin, and bought an image optimiser, and the site is still slow. They conclude that WooCommerce is simply heavy and give up.

WooCommerce is heavier than a brochure site, which is unavoidable when every page can carry a cart. But a store that takes six seconds to load is not suffering from that overhead. It is suffering from something specific, and in my experience it is nearly always one of four things.

The short version: Shops are slow because cart and checkout pages cannot be page-cached, because the options table has grown enormous with autoloaded junk, because product queries scan an unindexed metadata table, and because thirty plugins each add their own scripts to every page. Hosting is the last thing to change, not the first.

Why a Store Is Different From a Blog

Understanding one distinction explains most WooCommerce performance behaviour.

A blog post is the same for every visitor, so it can be generated once and served from cache to everyone. That is why brochure sites are fast almost regardless of how they are built. A store cannot do that on every page, because the cart is personal. The moment a visitor adds an item, the page has to reflect their state rather than a shared copy.

The consequence is that cart, checkout and account pages bypass page caching entirely and execute PHP and database queries on every request. Those are also the pages where slowness costs you money directly. A slow category page loses browsers; a slow checkout loses buyers.

So the useful question is never "is my site fast?" It is "how fast is my site for a logged-in visitor with something in their cart?" Test that state specifically, because it is the one your revenue depends on and the one every synthetic speed test misses.

The Four Things That Are Actually Wrong

An overloaded options table. WordPress loads a set of options on every single request, and plugins add to it freely. Uninstalled plugins routinely leave their rows behind. On older stores this table grows to tens of megabytes of autoloaded data being read on every page view including the checkout. It is invisible, it is cumulative, and it is one of the highest-return fixes available. Check the total size of autoloaded options first; if it is measured in megabytes rather than kilobytes, you have found real time.

Product queries against unindexed metadata. WooCommerce historically stored product attributes, prices and stock in a generic metadata table shared with everything else. Filtering or sorting a large catalogue means joining that table repeatedly. With a few hundred products nobody notices. With tens of thousands, category and filter pages slow to a crawl. Newer WooCommerce versions moved order data to dedicated tables specifically to relieve this pressure, and enabling that storage on a store with a long order history is usually worth doing on its own.

Plugins and External Calls

Plugin sprawl on the critical path. The problem is rarely the count itself; it is that most plugins enqueue their CSS and JavaScript on every page rather than only where needed. A booking plugin used on one page loads its assets on your checkout. The fix is unglamorous: audit what each plugin loads, dequeue assets outside their own pages, and remove anything whose function you cannot name.

Uncached third-party calls. Live shipping rates, tax lookups, currency conversion and stock checks against an external system all place a network request inside the page load. When that provider is slow, your checkout is slow, and when it fails your checkout fails. Every external call in a request path needs a timeout, a cache and a fallback. Our guide to third-party API integration covers how that should be built.

What Actually Helps, In Order

Work through these in sequence, because each one changes what the next measurement tells you.

Object caching, not just page caching. Page caching serves whole HTML pages and cannot help cart or checkout. A persistent object cache stores the results of database queries in memory and speeds up exactly the pages page caching cannot touch. For a store this is usually the single largest improvement available, and it is the step most often skipped because the caching plugin already installed gave the impression the job was done.

Database maintenance. Clear expired transients, remove orphaned metadata from deleted products and orders, and trim post revisions. On a store that has been trading for years this routinely removes a large fraction of the database. Schedule it rather than doing it once.

Then hosting. Once caching and the database are in order, hosting genuinely matters: PHP version, available memory, whether the database is on the same machine, and whether you are on shared hosting competing with other tenants. But moving host before fixing the above just relocates the problem to a more expensive address.

Assets last. Image formats, lazy loading and script deferral are worth doing and they are what most guides lead with. They improve the loading experience of pages that were already being served reasonably quickly. They do very little for a checkout that spends four seconds in PHP before sending a byte.

Measuring WooCommerce Performance Properly

Synthetic scores mislead store owners more than any other group, so measure deliberately.

Test the logged-in, cart-populated state. Most tools test an anonymous visitor hitting the homepage, which is the fastest possible path through your site and tells you almost nothing about checkout.

Separate server time from front-end time. If the server takes three seconds to produce the HTML, no amount of image optimisation will save the page. Time to first byte tells you which half of the problem you have, and therefore which of the fixes above applies.

Use field data rather than lab data where you can. Real visitors on real connections and real phones produce a different picture from a test run in a data centre, and Core Web Vitals are assessed on the former. Our WordPress performance audit guide covers how to read those metrics properly, and Core Web Vitals in 2026 explains what the thresholds actually require.

Finally, watch the database directly during a slow request. A query log showing the same query executed two hundred times on one page load identifies the culprit immediately, and that pattern is extremely common in stores running several plugins that each ask for product data independently.

What This Work Costs

Prices below reflect typical UK agency rates for a store of moderate size.

A performance audit that identifies the specific causes, with a prioritised fix list and before-and-after measurements, generally runs £900 to £2,500. That is a diagnostic engagement and it is worth buying separately, because it tells you whether the remaining work is a week or a month.

Implementing the common fixes — object caching, database cleanup, plugin asset auditing, external call caching — usually runs £2,000 to £6,000 depending on how much has accumulated.

Deeper work costs more because it is genuinely development. Migrating a large catalogue to indexed storage, rebuilding a filter system that scans metadata, or replacing a slow plugin with a targeted custom implementation typically falls between £6,000 and £20,000.

The figure that matters more than any of these is what slowness costs you. Checkout abandonment rises measurably with load time, so a store turning over meaningful revenue can usually justify the audit on the checkout page alone.

Fix the Store, Not the Score

Mecanik does WooCommerce performance work as part of our WordPress development service, and we start by measuring the logged-in checkout path rather than the homepage, because that is where stores actually lose money.

We look at autoloaded options, order storage, query patterns and external calls before recommending a host change, and we give you the measurements both before and after so the improvement is verifiable rather than asserted. If your store is slow because it has outgrown the platform rather than because it is misconfigured, we will tell you that too — our comparison of Shopify and custom ecommerce covers where that line sits.

Send us the URL and roughly how many products and orders the store holds, and we will tell you which of the four causes above you are most likely facing.

Frequently Asked Questions

Why is my WooCommerce site slow even with a caching plugin?
Page caching cannot be applied to cart, checkout and account pages, because those must reflect each visitor's own state. Those pages execute PHP and database queries on every request, so speeding them up requires object caching and database work rather than page caching.

Does moving to better hosting fix WooCommerce performance?
Only partly, and it should not be the first step. If the options table is bloated, queries are unindexed and plugins load assets everywhere, better hosting makes the same problems slightly faster at higher cost. Fix caching and the database first, then reassess hosting.

How many plugins are too many for WooCommerce?
The count matters less than what each one loads. Twenty well-behaved plugins that only enqueue assets on their own pages cause less harm than eight that load scripts site-wide. Audit what each adds to the checkout, and remove anything whose purpose nobody can state.

What does WooCommerce speed optimisation cost?
A diagnostic audit with a prioritised fix list typically costs £900 to £2,500. Implementing common fixes such as object caching, database cleanup and asset auditing usually runs £2,000 to £6,000, while catalogue or filter rework can reach £6,000 to £20,000.

How should I test WooCommerce performance properly?
Test as a logged-in visitor with items in the cart, not an anonymous homepage visit. Separate server response time from front-end rendering to see which half is slow, and use field data from real visitors rather than relying only on lab scores.

Penetration Testing Cost: 2026 Enterprise Budgeting Guide

Mecanik1337 — Fri, 02 Oct 2026 18:00:00 +0000

Calculating the cost of penetration testing in the UK is a vital compliance task for enterprises planning cyber security audits in 2026. With business transactions shifting online, maintaining strict application security is critical to protect sensitive client databases and avoid expensive regulatory penalties. Commissioning an annual penetration test has shifted from a general recommendation to a standard requirement under local frameworks. This guide breaks down the pricing models, scope definitions, and compliance standards used to calculate penetration testing budgets.

Compliance Risk Warning: Relying purely on automated vulnerability scanners does not constitute a penetration test. Under standard industry frameworks, automated tools fail to identify complex logic bugs, leaving your systems vulnerable to manual breaches.

Key Takeaways:

Costs vary based on IP count, active user roles, and network complexity.

Small-scale web application pen tests range from £3,500 to £6,500, while complex enterprise networks start at £8,000.

Working with CREST-accredited agencies is essential to pass compliance frameworks like ISO 27001 or PCI-DSS.

Retaining a detailed vulnerability report simplifies structural remediation, saving engineering hours post-audit.

Variables That Dictate Penetration Testing Cost

A professional security audit requires manual validation by experienced ethical hackers. According to guidelines from the National Cyber Security Centre (NCSC), scoping security tests accurately is the first step to prevent budget overruns. Several parameters directly impact the scope of work and the final quote. Therefore, you must define the target surfaces cleanly to avoid budget creep.

1. Scope and Target Count

The number of servers, external IP addresses, internal domains, and active APIs dictates the test duration. Additionally, a web application with multiple user access levels requires testing each authorisation path to identify privilege escalation risks.

2. Testing Methodology: Black vs. White Box

The amount of information provided to the security engineers determines the testing path and, ultimately, the testing style.

Black-Box Testing: Engineers receive only the target URL or IP. This method simulates an external attack, requiring more hours to gather intelligence and map endpoints.
White-Box Testing: Developers provide source code access, network diagrams, and database configurations. This allows for deep review but requires close collaboration.

3. Compliance and Industry Requirements

UK businesses bidding for public sector contracts or working in fintech must meet specific security baselines (such as Cyber Essentials Plus or PCI-DSS). To satisfy these audit criteria, the testing agency must run specialised tests, and this additional compliance layer increases testing hours and the final fee.

Average Penetration Testing Costs in the UK for 2026

To help your compliance team budget, the following table details the average cost metrics for security audits in the UK:

Testing Target	Average Cost Range (GBP)	Recommended Testing Frequency	Compliance Standards Met
Simple Web App / API	£3,500 - £6,500	Annual / Post-Update	GDPR / OWASP Top 10
Enterprise Network (Internal & External)	£8,000 - £15,000+	Annual	ISO 27001 / PCI-DSS
Active Mobile Application (iOS & Android)	£5,000 - £10,000	Annual	OWASP MASVS
Cloud Infrastructure (AWS/Cloudflare)	£6,000 - £12,000	Annual / Major Change	CIS Benchmarks

These estimates assume hiring a certified agency that provides comprehensive liability insurance and senior, accredited testers.

How a Pen-Test Quote Is Built: A Worked Example

Most reputable UK consultancies price on a day-rate basis. The quote is simply the estimated number of testing days multiplied by the consultant day rate, plus reporting and a retest. This makes the arithmetic easy to interrogate once you know the inputs. For CREST-registered testers, day rates typically sit between £1,000 and £1,500 per day (illustrative for 2026); highly specialised work — bespoke thick-client, embedded, or hardware testing — commands more.

Consider a realistic scenario: a mid-sized SaaS business commissioning its annual assessment. The in-scope assets are a customer-facing web application with three user roles, the REST API behind it, and a small external network perimeter. A blended senior rate of £1,200 per day applies across the engagement.

Component	Scope detail	Estimated effort (days)	Subtotal at £1,200/day
Web application (authenticated)	3 user roles, ~25 dynamic pages	5.0	£6,000
REST API	~40 endpoints	2.5	£3,000
External network	12 live IP addresses	1.5	£1,800
Reporting & QA	Findings write-up, executive summary, peer review	1.5	£1,800
Remediation retest	Verify critical and high-severity fixes	1.0	£1,200
Total	—	11.5 days	£13,800

The headline figure of roughly £13,800 is therefore not a mysterious lump sum. It is 11.5 days of effort at a £1,200 blended rate. The day counts themselves come from a scoping questionnaire: the tester estimates hours per authorisation path, per endpoint cluster, and per network segment, then rounds to sensible half-days. Change any input and the price moves predictably. Add a native mobile application and you add roughly 4 to 6 days (£4,800–£7,200). Insist on a fully black-box engagement and reconnaissance alone can add a day or two, because the team must map from scratch what a white-box brief would have handed over.

Most agencies present this as a fixed-price quote rather than an open day rate, having converted their day estimate into a single figure. The practical difference matters at contract time: a fixed price protects you if the work runs long, but only against the scope you agreed, so anything discovered outside the original boundary becomes a change request. Always confirm what the quote assumes — the number of days baked in, whether one retest is included, and how out-of-scope findings are handled — before you sign. A supplier who cannot break their fixed price back down into days and rates is a supplier worth questioning.

What Makes Up the Headline Price: A Line-Item Breakdown

Even within a single engagement, the fee covers far more than hands-on-keyboard exploitation. Understanding how the effort divides helps you compare quotes like for like and spot a supplier who has under-scoped the unglamorous stages.

Stage	What it covers	Typical share of effort
Scoping & pre-engagement	Questionnaire, rules of engagement, written authorisation	5–10%
Reconnaissance & mapping	Enumerating the attack surface, cataloguing endpoints	10–15%
Active testing & exploitation	Manual testing, chaining findings, privilege escalation	45–55%
Reporting & QA review	Write-up, severity ratings, senior peer review	20–25%
Remediation retest	Re-testing issues your team has patched	5–10%

The reporting stage surprises many first-time buyers. A test that finds serious problems but documents them poorly is close to worthless: your engineers cannot reproduce or prioritise what they cannot understand. When you analyse two quotes and one is conspicuously cheaper, check whether it has quietly compressed reporting and retesting — that is usually where corners get cut.

Ongoing and Hidden Costs to Budget For

The invoice from the testing agency is rarely the whole story. A realistic annual security budget should account for these recurring or easily overlooked items:

Remediation engineering time. Fixing what the test finds is frequently the single largest cost, and it lands on your own team rather than the supplier's invoice. A report with a dozen medium and high findings can absorb several developer-weeks.
Annual re-testing. Frameworks such as ISO 27001 and PCI-DSS expect a fresh assessment at least yearly, plus targeted testing after any major change.
Retest and validation fees. Most engagements include one retest window; verifying fixes after that window has closed is usually billed separately.
Interim scanning and tooling. Many organisations run authenticated vulnerability scanning between annual tests, which carries its own licence cost.
Internal staff time. Scoping calls, environment preparation, and provisioning test accounts all consume hours that rarely appear in any quote.

As an annual rule of thumb, plan for total security-testing spend of roughly 1.5 to 2 times the headline test fee once remediation labour, retests, and interim scanning are included (illustrative). In our worked example, the £13,800 engagement realistically implies a £20,000–£28,000 all-in annual figure for that programme of work.

What Moves the Price Up or Down

Because the model is days multiplied by a rate, every price lever ultimately changes the day count. The factors below push a quote in one direction or the other:

Pushes it up: a fully black-box brief, many user roles or authorisation boundaries, compliance overlays such as PCI-DSS or CBEST that mandate specific methodologies and evidence, out-of-hours testing to protect production, and any physical or social-engineering component.
Pulls it down: a tightly defined and well-documented scope, white-box or grey-box access, consolidating several assets into one booking, a stable code freeze during the test window, and a standing retainer relationship that removes repeated scoping overhead.

Best Practices to Control Testing Expenses

Protecting your budget from inflation requires preparing your systems before the audit begins. To keep costs under control, follow these optimisation guidelines:

Clean up Active Codebases: Resolve obvious OWASP vulnerability points using automated scanners before the engineers start testing.
Establish Clear Scopes: Exclude non-critical staging subdomains or legacy static servers from the target list to limit testing hours.
Verify Third-Party Approvals: If your systems are hosted on managed servers, ensure you secure authorisation from the host to prevent testing blocks.
Link remediations to SLAs: Ensure your engineering team is scheduled to patch identified vulnerabilities immediately upon receiving the draft report.

Partner with a Vetted UK Security Consultancy

Understanding the elements that shape your budget ensures your compliance audits stay on schedule. Mecanik provides professional penetration testing services and comprehensive security testing through the website security audit page. We specialise in web application security, server hardening, and API compliance audits. Contact us today to schedule your scoping session.

Frequently Asked Questions

What is the average penetration testing cost uk?
The average cost of a penetration test in the UK starts at £3,500 for a simple web application or API and can exceed £15,000 for complex enterprise networks. The final pricing depends on the number of IP addresses, active endpoints, user roles, and compliance requirements.

Why do I need a manual penetration test instead of a scanner?
Automated scanners only identify known signature patterns. Conversely, a manual penetration test uses ethical hackers to identify complex logic flaws, chain minor issues into critical breaches, and verify access escalation bugs that scanners cannot spot.

How often should a UK business conduct a pen test?
UK businesses should conduct a penetration test at least once a year to maintain compliance standards like ISO 27001. Additionally, you should commission a pen test after launching major feature updates, changing database structures, or shifting cloud hosts.

What is the role of CREST accreditation in pen testing?
CREST accreditation verifies that the security agency and its engineers follow strict technical, ethical, and legal guidelines. Hiring a CREST-approved firm is often a requirement to satisfy compliance audits and validate your security posture to enterprise clients.

What happens if the pen test identifies critical vulnerabilities?
A professional test report categorises vulnerabilities by severity (Critical, High, Medium, Low). Your development team should patch critical and high risks immediately, and the testing agency should run a validation test to confirm the patches are secure.

Core Web Vitals in 2026: How to Actually Pass

Mecanik1337 — Fri, 02 Oct 2026 06:00:00 +0000

Core Web Vitals are Google's measurable signals for real-world page experience, and they feed into ranking. Passing them is not about chasing a green score for its own sake; it is about a site that loads fast, responds instantly, and does not jump around while people use it. This guide explains the three metrics as they stand in 2026 and, more importantly, the fixes that actually move each one.

TL;DR

The three Core Web Vitals are LCP (loading), INP (responsiveness), and CLS (visual stability). INP replaced FID as a Core Web Vital in 2024
"Good" thresholds: LCP under 2.5s, INP under 200ms, CLS under 0.1, measured at the 75th percentile of real visits
The highest-impact fixes are optimising the largest image or text block, reducing and breaking up JavaScript, and reserving space for images, ads, and embeds
Use field data (real users), not just lab tests, because Google ranks on real-world performance

The Three Core Web Vitals (2026)

Largest Contentful Paint (LCP): Loading

LCP measures how long it takes for the largest visible element (usually a hero image, banner, or large text block) to render. Good: under 2.5 seconds.

Interaction to Next Paint (INP): Responsiveness

INP measures how quickly the page responds to user interactions across the whole visit, replacing the older First Input Delay (FID) metric in 2024. It captures the delay between a tap or click and the next visual update. Good: under 200 milliseconds.

Cumulative Layout Shift (CLS): Visual Stability

CLS measures how much the page unexpectedly shifts while loading (the frustrating jump when a late image or ad pushes content down). Good: under 0.1.

Google evaluates these at the 75th percentile of real visits, so you need most of your users, not just the fastest, to have a good experience.

Fixing LCP

Optimise the LCP element. Identify it (most tools name it) and make it load fast: compress and correctly size the image, serve modern formats (WebP/AVIF), and avoid lazy-loading the hero image.
Serve responsive images with a proper srcset so devices download an appropriately sized file rather than a huge one. (See the guide to dealing with responsive images.)
Speed up the server response (TTFB) with caching and a CDN so the document arrives quickly.
Preload critical resources (the LCP image, key fonts) and eliminate render-blocking CSS and JavaScript where possible.
Use a fast image pipeline. Serving images through an optimised service like Cloudflare image transformations resizes and compresses on the fly.

Fixing INP

Reduce JavaScript execution. Heavy scripts block the main thread and delay responses. Ship less JavaScript and remove unused code.
Break up long tasks. Split long-running work so the browser can respond to input between chunks.
Defer non-critical work until after interaction, and avoid large, synchronous handlers.
Audit third-party scripts. Tag managers, chat widgets, and analytics are common INP culprits; load them efficiently or remove what you do not need.

Fixing CLS

Always set width and height (or CSS aspect-ratio) on images and video so the browser reserves space.
Reserve space for ads, embeds, and iframes so they do not push content when they load.
Avoid inserting content above existing content after load.
Preload fonts and use font-display sensibly to reduce layout shift from late-loading fonts.

Measure the Right Way

Field data over lab data. Google ranks on real-user (field) data such as the Chrome User Experience Report, not just a single lab run. A perfect lab score with poor field data will not pass.
Watch the 75th percentile. Improving your median is not enough; the slower quarter of visits is what fails you.
Test on real devices and connections, especially mid-range mobile, not just a fast desktop.

Key Takeaways

The three Core Web Vitals in 2026 are LCP, INP (which replaced FID), and CLS.
Aim for LCP under 2.5s, INP under 200ms, and CLS under 0.1 at the 75th percentile of real visits.
The biggest wins: optimise the LCP element and images, cut and split JavaScript for INP, and reserve space to stop layout shift for CLS.
Judge success on field data, not just a lab score.

Get a Professional Assessment

Core Web Vitals are one part of technical SEO. A technical SEO audit covers Core Web Vitals alongside crawl budget, indexation, site architecture, JavaScript rendering, and structured data, with a prioritised action plan based on real ranking impact. If speed is your main concern, the guide to speeding up your website with Cloudflare goes deeper on performance.

Frequently Asked Questions (FAQ)

What are the three Core Web Vitals in 2026?
Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. INP replaced First Input Delay (FID) as a Core Web Vital in 2024.

What are good Core Web Vitals scores?
LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1, measured at the 75th percentile of real user visits. You need most visitors, not just the fastest, to hit these.

Do Core Web Vitals affect Google rankings?
Yes. They are part of Google's page experience signals. They are not the only or the strongest ranking factor, but for competitive queries a good page experience is a meaningful advantage, and a bad one holds you back.

Why does my site pass in the lab but fail in Search Console?
Because Google uses field data from real users, not a single lab test. Real devices, connections, and the 75th percentile expose problems a fast test machine hides. Optimise for real-world conditions.

What is the fastest way to improve Core Web Vitals?
Usually optimising the LCP element (compress and size the largest image, avoid lazy-loading it) and reducing JavaScript. For CLS, set dimensions on images and reserve space for ads and embeds.

Structured Data and Schema Markup for SEO in 2026

Mecanik1337 — Thu, 01 Oct 2026 18:00:00 +0000

Structured data is how you describe your page to search engines in a language they parse precisely. Instead of hoping Google infers that a page is a recipe, a product, or an FAQ, you tell it explicitly. Done right, this can earn rich results (star ratings, FAQs, prices, and more) that make your listing stand out and win clicks. This guide explains what structured data is, how to implement it in 2026, and where it actually helps.

TL;DR

Structured data is standardised markup (from schema.org) that describes your content to search engines
Google's recommended format is JSON-LD, a script block you add to the page
It does not directly boost rankings, but the rich results it can earn improve visibility and click-through rate
The markup must accurately reflect visible page content, or it breaks Google's guidelines and can be ignored or penalised

What Structured Data Is

Structured data uses a shared vocabulary, schema.org, to label the meaning of content: this is an Article, that is its author, this is a Product with a price and a review. Search engines read these labels to understand the page more confidently and to decide whether it is eligible for enhanced search features.

JSON-LD Is the Format to Use

There are a few ways to add structured data, but JSON-LD is Google's recommended format. It is a `

Technical SEO Audit Checklist for 2026

Mecanik1337 — Thu, 01 Oct 2026 06:00:00 +0000

Content and links get the attention, but if search engines cannot crawl, render, and index your pages efficiently, none of it ranks. A technical SEO audit checks the foundation. This checklist walks through what to review in 2026, grouped by the questions that matter: can Google find your pages, index them, understand them, and does the experience hold up?

TL;DR

A technical SEO audit covers crawlability, indexation, site architecture and internal linking, Core Web Vitals, JavaScript rendering, structured data, and international configuration
The biggest wins usually come from fixing indexation problems and crawl waste, not from micro-optimisations
Prioritise findings by ranking impact, not by how many the tool reports
Re-audit periodically; technical health drifts as the site changes

1. Crawlability: Can Google Reach Your Pages?

robots.txt: Confirm it is not accidentally blocking important pages or resources (CSS/JS Google needs to render).
Crawl budget: For large sites, make sure crawlers spend time on valuable pages, not on infinite filters, duplicates, or parameter URLs.
XML sitemap: Present, submitted in Search Console, and listing canonical, indexable URLs only.
Broken links and redirects: Fix 404s on linked pages and clean up long redirect chains.
HTTP status codes: Ensure pages return the correct codes (200 for live, 301 for permanent moves, 410 for gone).

2. Indexation: Are the Right Pages Indexed?

Index coverage: Review Google Search Console for pages that should be indexed but are not, and pages that are indexed but should not be.
Canonical tags: Each piece of content has one clear canonical URL, and canonicals are consistent and self-referencing where appropriate.
noindex usage: Applied deliberately to thin or duplicate pages, and not accidentally on pages you want to rank.
Duplicate content: Consolidate duplicates (HTTP/HTTPS, www/non-www, trailing slashes, parameters) so authority is not split.

3. Site Architecture and Internal Linking

Depth: Important pages are reachable within a few clicks of the homepage.
Internal linking: Link related pages so authority flows to what matters and crawlers can discover everything.
URL structure: Clean, logical, and stable; avoid unnecessary parameters and deep, messy paths.
Orphan pages: Find pages with no internal links pointing to them; they are hard to discover and rank.

4. Performance: Core Web Vitals

Assess LCP, INP, and CLS on real-user (field) data, not just a lab run.
Confirm mobile performance specifically, since indexing is mobile-first.
For the detailed fixes, see the guide to passing Core Web Vitals in 2026 and speeding up your website with Cloudflare.

5. Rendering: Can Google See Your Content?

JavaScript rendering: If content is injected by JavaScript, confirm Google can render and index it. Client-side-only content is a common hidden cause of missing pages.
Mobile-first: Ensure the mobile version contains the same important content and structured data as desktop.
Rendered vs raw HTML: Check what Google actually sees after rendering, not just the initial HTML.

6. Structured Data

Validate structured data (schema markup) for eligible rich results and fix errors and warnings.
Ensure markup reflects the visible page content. See the guide to structured data and schema markup for SEO.

7. International and Multilingual Configuration

hreflang: If you serve multiple languages or regions, confirm hreflang tags are correct and reciprocal so the right version ranks in the right market.
Geotargeting: Check regional targeting settings are consistent.

8. Security and Fundamentals

HTTPS everywhere, with HTTP redirecting to HTTPS and no mixed content.
Mobile usability: No blocked resources, readable text, tappable targets.

Prioritise by Impact

A tool will happily report hundreds of "issues." The skill is separating the handful that actually affect rankings (indexation problems, blocked resources, crawl waste, slow real-world performance) from cosmetic noise. Fix the high-impact items first.

Key Takeaways

Audit crawlability, indexation, architecture, Core Web Vitals, rendering, structured data, and internationalisation.
Indexation and crawl-waste fixes usually deliver more than micro-optimisations.
Judge performance on field data and mobile.
Prioritise findings by ranking impact, not by raw issue count, and re-audit as the site evolves.

Get a Professional Technical SEO Audit

A checklist gets you oriented; an expert audit tells you what is actually costing you rankings and in what order to fix it. The technical SEO audit service covers crawl budget, indexation, architecture, rendering, Core Web Vitals, and structured data with a prioritised action plan, and the broader SEO audit service adds on-page, content, and backlink review. For what to expect from SEO support generally, see the guide to SEO services in the UK.

Frequently Asked Questions (FAQ)

What is a technical SEO audit?
A review of the technical foundations that let search engines crawl, render, and index a site: crawlability, indexation, architecture, performance, rendering, structured data, and internationalisation. It finds the infrastructure issues that stop good content from ranking.

How is a technical SEO audit different from an SEO audit?
A technical SEO audit focuses on infrastructure and how search engines access the site. A full SEO audit also covers on-page optimisation, content quality, and backlinks. Technical is the foundation the rest builds on.

How often should I run a technical SEO audit?
At least once or twice a year for an active site, and after any major change such as a redesign, migration, or platform switch. Technical health drifts as content and code change, so periodic checks catch regressions early.

What technical SEO issues hurt rankings the most?
Indexation problems (important pages not indexed, or duplicates splitting authority), blocked resources that stop rendering, crawl waste on low-value URLs, and poor real-world performance. These outweigh most cosmetic issues a tool flags.

Can I do a technical SEO audit myself?
You can cover the basics with Search Console and a crawler, and this checklist helps. Deeper issues like JavaScript rendering, crawl-budget waste, and prioritising by real ranking impact benefit from experience, which is where a professional audit adds value.

Website Migration Without Losing Traffic: 2026 Guide

Mecanik1337 — Tue, 22 Sep 2026 18:00:00 +0000

A website migration is the only routine project that can wipe out years of search visibility in a single afternoon. Rebuilds, replatforms, domain changes and even a tidy-up of URL structure all carry the same risk, and the damage rarely announces itself on launch day. It shows up two weeks later as a quiet, steady decline that nobody connects to the release.

The good news is that the causes are well understood and almost entirely preventable. In practice, nearly all migration traffic loss traces back to one thing: an incomplete redirect map. Everything else in this guide is secondary to getting that right.

The one rule: Every URL that currently exists and has any value — traffic, backlinks, or indexed status — must resolve to a single permanent redirect pointing at its closest equivalent on the new site. Not the homepage. Not a chain of three hops. One redirect, to the genuinely equivalent page.

Build the Inventory Before You Build Anything

You cannot redirect URLs you do not know about, and no single source lists them all. Pull from four and merge.

A full crawl of the existing site. This gives you everything reachable by following links, which is the majority but never the whole picture.

Search Console data. Export every URL that has received impressions or clicks. This catches pages that earn traffic but nothing links to internally, which is more common than people expect.

Server access logs. These show what is actually being requested, including old URLs that no longer appear anywhere on the site but still receive traffic from bookmarks, emails and external links.

Your backlink data. Any URL that other sites link to carries value you will lose if it stops resolving. These are the highest-priority redirects in the whole exercise, because the link equity is not recoverable by other means.

Merge those four into one list, deduplicate, and you have the real surface area of your site. On a mature site it will be considerably larger than anyone estimated, and that number alone often changes the project plan.

Mapping Old to New

With the inventory in hand, the mapping is where judgement enters.

Map every URL to its closest equivalent. Where a page has a direct replacement, that is easy. Where content has been consolidated, point to the page that now covers the topic. Where content has genuinely gone and has no successor, allow it to return a 404 or 410 rather than redirecting it somewhere irrelevant.

Resist the temptation to redirect everything to the homepage. Search engines treat a redirect to an unrelated page as a soft 404, so it passes nothing on and produces a poor experience for anyone following an old link. A deliberate 404 on genuinely removed content is a better outcome than a misleading redirect.

Use permanent redirects, and make sure they are single hops. Redirect chains, where the old URL points to a second URL which points to a third, are common after a site has been migrated more than once. Each hop adds latency and dilutes the signal, so always map to the final destination, not to whatever the previous migration left behind.

Watch the details that are easy to miss: trailing slashes, uppercase characters, query-string parameters that produce distinct indexed URLs, and the protocol and subdomain. A migration that fixes the pages but leaves http and www variants unhandled has doubled its problems.

What Else Moves With the Site

Redirects are the biggest risk, but four other things are worth protecting.

Canonical tags and hreflang. After migration, canonicals must point at the new URLs. Stale canonicals pointing to the old domain are a genuinely effective way to prevent the new site being indexed at all. If you run multiple languages, every hreflang cluster has to be updated in step, since a mismatch invalidates the whole set.

Structured data. Any schema on the old pages should carry across, including URLs inside it. It is easy to migrate the visible content and lose the markup, which quietly removes eligibility for rich results.

Metadata. Titles and descriptions should transfer deliberately rather than being regenerated by the new platform's defaults. A rebuild that replaces well-tuned titles with a template pattern will lose clicks even if rankings hold.

Page speed. A new site is often heavier than the one it replaced. Since Core Web Vitals are assessed on field data collected over a rolling period, a slower site takes weeks to show its full effect, by which time the cause is easy to misattribute. Our guide to Core Web Vitals covers what the thresholds actually require.

Launch and the First 48 Hours

The launch itself is short; the verification is what matters.

Before going live, test the redirect map against the full inventory on a staging environment. Automate it: request every old URL, assert a single 301 and the expected destination. Doing this by hand on a sample will miss the pattern that breaks a thousand URLs.

Confirm the new site is actually crawlable. The most common launch-day disaster is shipping the staging environment's robots directives or a leftover noindex tag. Check both before anything else.

Submit the new sitemap, and keep the old URLs in a temporary sitemap for a while so crawlers rediscover them and follow the redirects. If the domain changed, use the change of address tool in Search Console.

Then watch the logs rather than the rankings. Crawler activity on the new URLs tells you within hours whether the migration is being picked up. Rankings tell you nothing useful for at least a week.

What Recovery Actually Looks Like

Set expectations before launch, because the shape of the recovery curve causes more panic than the migration itself.

Some fluctuation is normal even when everything is done correctly. Search engines have to recrawl, reprocess and reassociate every URL, and that takes time proportional to the size of the site. A dip of a couple of weeks on a mid-sized site is not evidence of failure.

A well-executed migration typically returns to previous levels within four to eight weeks, sometimes faster on smaller sites. A poorly executed one does not recover on its own, because the cause persists.

The distinction is visible in the data. If Search Console shows a rise in crawl errors and pages dropping out of the index, you have a technical problem to fix. If crawling looks healthy and impressions are simply lagging, you are watching normal reprocessing.

Keep the old site's analytics and Search Console data exported before launch. Comparing against a baseline you can no longer access is a miserable position, and it happens surprisingly often.

What Website Migration Work Costs

Prices reflect typical UK agency rates and scale with URL count rather than page design.

Redirect mapping and migration QA for a small site of a few hundred URLs generally runs £900 to £2,500. This covers the inventory, the mapping, the automated verification and post-launch checks.

A mid-sized site of a few thousand URLs typically runs £2,500 to £8,000, mostly because the mapping requires more judgement and the verification more tooling.

Large or ecommerce sites with faceted navigation, parameter URLs and international variants start around £8,000 and rise with complexity. Faceted navigation in particular can generate enormous numbers of indexed URLs that need decisions rather than mechanical mapping.

Set against that, the cost of getting it wrong is the revenue from your organic traffic for however long recovery takes, plus the cost of the emergency work to fix it. It is one of the clearer cases for spending money in advance. Our technical SEO audit cost guide covers the related diagnostic work.

Migrate Once, Properly

Mecanik handles migration planning and verification as part of our technical SEO audit and website development services. We build the inventory from all four sources, produce the redirect map, automate verification against it, and monitor crawl behaviour through the first weeks after launch.

We also do this for platform changes specifically, where the URL structure often changes as a side effect of the new system's conventions rather than by anyone's decision. Our Drupal migration guide covers one common version of that, and the same discipline applies to any replatform.

If a migration has already happened and traffic has dropped, get in touch with the launch date and we will tell you whether it is a redirect problem, an indexing problem, or normal reprocessing.

Frequently Asked Questions

Why did my traffic drop after a website migration?
Most commonly an incomplete redirect map: URLs that had traffic or backlinks now return errors or point somewhere irrelevant. Other frequent causes are a leftover noindex tag from staging, canonicals still pointing at the old domain, and redirect chains that dilute the signal.

Should I redirect old URLs to the homepage?
No. Search engines treat a redirect to an unrelated page as a soft 404, so it passes nothing on and frustrates anyone following an old link. Map each URL to its closest genuine equivalent, and let content with no successor return a 404 or 410 instead.

How long does it take to recover rankings after a migration?
A well-executed migration typically returns to previous levels within four to eight weeks, faster on smaller sites. Some fluctuation during recrawling is normal. If crawl errors are rising and pages are dropping out of the index, that is a technical fault rather than normal reprocessing.

What should I inventory before migrating a website?
Merge four sources: a full crawl of the existing site, every URL with impressions or clicks in Search Console, server access logs showing what is genuinely requested, and your backlink data. Each catches URLs the others miss, and backlinked URLs are the highest priority to preserve.

How much does website migration SEO work cost?
Redirect mapping and verification for a small site of a few hundred URLs typically costs £900 to £2,500. Mid-sized sites of a few thousand URLs run £2,500 to £8,000, while large or ecommerce sites with faceted navigation and international variants start around £8,000.

DEV Community: Mecanik1337

Runtime encrypted strings: Part 1

Runtime Encrypted Strings

What is runtime encryption and decryption

Why encrypt strings?

Static Analysis Test

Runtime Analysis Test

Creating Runtime Encrypted Strings

The Plan

The Solution

The Result

More on encrypted strings

Download

DeepSeek R1 vs. OpenAI o3-mini: Which API is Best?

The Core Concept of Reasoning Models

Latency vs. Reasoning Depth

Structured Outputs and JSON Parsing

Pricing and Cost Optimisation

How the Two Reasoning APIs Compare at a Glance

Working Out the Cost per 1,000 Calls

Choosing by Workload, Not by Winner

Total Cost of Ownership and Switching Costs

Key Takeaways

Integrate Reasoning Models into Your Stack

Frequently Asked Questions (FAQ)

Deploying Llama 3 on the Edge with Cloudflare Workers AI

Why Run AI Models on the Edge?

Prerequisites

Step 1: Configuring wrangler.toml

Step 2: Writing the Worker Code

Using the chat message format

Choosing the Right Model

Step 3: Streaming Responses for Better User Experience

Testing and Deploying Your Worker

Common Pitfalls and Troubleshooting

Optimising Production Costs and Security

Key Takeaways

Build Your AI Applications on the Edge

Frequently Asked Questions (FAQ)

Drupal Migration in 2026: Costs, Options and Deadlines

The Two Very Different Migrations

What Each Drupal Migration Path Costs

Why Contributed Modules Decide Your Timeline

What Actually Goes Wrong

How to Sequence the Work

Should You Move Off Drupal Entirely?

Get the Audit Before You Get a Quote

Frequently Asked Questions

COBOL Migration Cost, Timeline and Risk - A UK Guide 2026

What Actually Drives COBOL Migration Cost

Indicative Cost and Timeline Ranges (UK)

How the Target Language Affects Cost

How the Migration Approach Affects Cost

The Risks That Cause Overruns

How to Get an Accurate Estimate

Key Takeaways

Frequently Asked Questions (FAQ)

WordPress Hacked: Malware Removal and Recovery Guide

What to Do in the First Hour

How Your WordPress Site Got Hacked: Finding the Entry Point

Why "Just Restore a Backup" Usually Fails

Cleaning the Database

Getting Unflagged and Recovering Rankings

What Professional Recovery Costs

Making Sure It Does Not Happen Again

Get It Cleaned Properly

Frequently Asked Questions

WooCommerce Performance: Why Your Store Is Slow

Why a Store Is Different From a Blog

The Four Things That Are Actually Wrong

Plugins and External Calls

What Actually Helps, In Order

Measuring WooCommerce Performance Properly

What This Work Costs

Fix the Store, Not the Score

Frequently Asked Questions

Penetration Testing Cost: 2026 Enterprise Budgeting Guide

Variables That Dictate Penetration Testing Cost

1. Scope and Target Count

2. Testing Methodology: Black vs. White Box