Website Development Services: WordPress, Magento, Shopify and Custom Builds That Rank

There is a specific kind of project that lands on my desk two or three times a year. A business spends fifty or a hundred thousand on a redesign, launches it, and watches organic traffic fall off a cliff within six weeks. The site looks better than the old one. It is also slower, the URLs changed without redirects, the category pages lost their copy, and the whole thing renders client-side so there is nothing in the HTML for a crawler to read.

That happens because design, development and search were three separate conversations. The developer optimised for what was quick to build, the designer optimised for what looked good in a mockup, and nobody in the room was going to be held responsible for rankings twelve months later.

We build the other way round. Keyword and entity research comes before the sitemap. The sitemap decides the templates. The templates decide what the site needs to be able to do, and only then do we recommend WordPress, Magento, Shopify or a fully custom build — because the honest answer is that each of them is excellent at something and an expensive mistake at something else.

The result is a site that launches without a traffic dip, that your team can publish to without a developer, and that answer engines can parse cleanly. If you want to see what a search-first build would fix on your current site, run it through the free SEO audit tool first — that report is usually the fastest way to work out whether you need a rebuild or a repair.

WordPress still powers something close to two in five websites, and the reason is not inertia. Nothing else gives a marketing team that much publishing freedom while keeping the underlying HTML under a developer’s control. If your growth plan depends on publishing — service pages, location pages, comparison pages, a real blog — WordPress is usually the shortest path between an idea and a live, indexable page.

Who WordPress website development is the right call for

Professional services firms, multi-location businesses, SaaS marketing sites, publishers, and any company whose organic strategy lives or dies on content volume. It is also the right call for small and mid-size ecommerce through WooCommerce, up to roughly a few thousand SKUs and a straightforward checkout. Past that point the platform starts fighting you, and that is where Magento or Shopify earns its keep.

How we build WordPress sites

Custom themes, not marketplace themes. A purchased theme brings thirty features you will never use, every one of them loading CSS and JavaScript on every page, and you inherit a codebase you cannot safely update. We build a bespoke theme or a tightly controlled block theme against your actual sitemap, with reusable blocks for the patterns your team will need again: comparison tables, FAQ accordions that emit valid schema, pricing grids, testimonial rows.

Custom post types and taxonomies carry the structure. If you have services, locations, case studies and team members, those are four content types with their own fields and their own templates, not four hundred pages of freehand page-builder layouts that drift apart within a year. That structure is what later lets us generate clean internal linking, accurate breadcrumbs and consistent structured data without touching a single page by hand.

Performance is a build constraint rather than a phase at the end. That means server-rendered HTML, critical CSS inlined, JavaScript deferred, images in AVIF or WebP at correct dimensions, fonts self-hosted and subset, and object caching in front of the database. We target a green Core Web Vitals profile on a throttled mobile connection, because that is the measurement Google actually uses.

Security and maintenance get designed in too: a minimal plugin surface, hardened login, automated offsite backups, a staging environment that mirrors production, and a documented update routine. Most hacked WordPress sites are not hacked through WordPress. They are hacked through an abandoned plugin nobody was tracking.

The WordPress trade-offs worth knowing before you commit

WordPress gives you freedom and hands you the responsibility that comes with it. There is no vendor keeping your stack patched, so somebody has to own updates. Plugin sprawl is a genuine risk and the single most common cause of slow WordPress sites. And once you push WooCommerce past a few thousand products, heavy faceted filtering or real B2B pricing rules, you are paying for infrastructure and engineering to do what a dedicated commerce platform does natively. We will tell you when you have reached that line rather than quietly billing to work around it. If your site is already on WordPress and the problem is visibility rather than architecture, our WordPress SEO services are usually the cheaper answer.

Magento Open Source and its licensed sibling Adobe Commerce are what you reach for when the catalogue itself is the hard problem. Hundreds of thousands of SKUs. Configurable products with real option matrices. Customer groups sitting on different price lists. Several storefronts in several currencies running off one admin. Shopify and WooCommerce can be pushed towards some of that with apps. Magento was designed for it.

Who Magento development is the right call for

Wholesalers and distributors with negotiated pricing per account. Manufacturers running B2B and direct-to-consumer from one inventory pool. Retailers with deep, attribute-heavy catalogues where customers filter by six dimensions before they ever see a product. Brands operating several regional storefronts that share stock but differ in language, tax treatment and payment methods. If two or more of those describe you, the extra cost of Magento is usually cheaper than the pile of apps and custom logic required to fake it elsewhere.

How we build on Magento

Everything starts with the attribute model, because in Magento the catalogue structure is the architecture. Attribute sets, attribute groups, configurable and bundled product types, and the layered navigation they drive all get mapped before a line of code is written. Get this right and the site scales for a decade. Get it wrong and every category page becomes a performance problem and an indexation problem at the same time.

We build custom themes on Hyvä rather than shipping stock Luma, and Hyvä in particular has changed the performance conversation on Magento. Stripping out the legacy Knockout and RequireJS weight is often the difference between a four-second and a one-second render. Where the front end needs to move faster than Magento’s templating allows, we go headless against the GraphQL API with a Next.js or Nuxt front end, server-rendered so crawlers still receive complete HTML.

Technical SEO on Magento is a discipline of its own and it is where most builds quietly fail. Layered navigation generates near-infinite parameter combinations, so we set canonical rules, decide which facets deserve to be indexable landing pages and which get blocked, control pagination, and keep the XML sitemap accurate and segmented. Category and product templates get a proper heading hierarchy, real editorial copy that is not buried below the fold, and Product, Offer, AggregateRating and BreadcrumbList schema generated from live data rather than hardcoded once and forgotten.

Integration is usually half the project. ERP, PIM, WMS, accounting, tax engines, 3PL, CRM — Magento sits in the middle of an operational stack, and we scope those data flows as first-class work with their own testing, not as a line item discovered in week ten.

The Magento trade-offs worth knowing

Magento is expensive to build and expensive to keep. It needs real infrastructure: Elasticsearch or OpenSearch, Redis, Varnish, a proper CDN, and a cron-driven indexer somebody has to monitor. It needs a retained developer, because security patches are not optional and version upgrades are projects rather than clicks. Adobe Commerce adds a licence fee that scales with your revenue. None of that is a reason to avoid it, but it is a reason to be honest about total cost of ownership before you sign. If your catalogue is modest and your pricing rules are simple, Magento will feel like renting a warehouse to store a filing cabinet.

Shopify removed an entire category of problems from ecommerce. Hosting, PCI compliance, checkout security, uptime during a traffic spike, platform upgrades — all of it becomes somebody else’s job. What you are buying is not really a website. It is the freedom to stop thinking about infrastructure and spend that attention on product, merchandising and acquisition instead.

Who Shopify website development is the right call for

Direct-to-consumer brands, retailers with a few thousand SKUs or fewer, subscription and replenishment businesses, and anyone who needs to be trading in weeks rather than quarters. It is also increasingly the right answer for mid-market brands that would once have defaulted to Magento, because Shopify Plus now handles multi-storefront setups, B2B price lists and scripted checkout logic that genuinely were not possible a few years ago.

How we build custom Shopify sites

Custom Online Store 2.0 themes built from a clean base, not a marketplace theme with your logo dropped in. The point of a 2.0 theme is sections and blocks: your merchandising team rearranges a landing page, adds a comparison block, swaps a hero, without opening a ticket. We design that block library around your actual campaigns so the flexibility gets used instead of feared.

Liquid does the heavy lifting where it should, and we reach for the Storefront API and Hydrogen only when a genuinely custom experience justifies it: a product configurator, a quiz-driven merchandiser, a bespoke bundling flow. Headless Shopify is a real capability and a real cost. We recommend it when the commercial case is there and talk clients out of it when it is not.

Custom apps and Shopify Functions handle the logic that used to mean bolting on four separate apps — discount rules, bundle pricing, shipping logic, checkout validation. Fewer third-party apps means fewer scripts in the page, a faster site and a smaller monthly bill. App stacking is the number one reason a Shopify store scores badly on Core Web Vitals.

On the search side, Shopify has known constraints and they are workable if you plan for them. The forced /collections/ and /products/ URL structure, duplicate product URLs when a product sits in several collections, and limited control over robots.txt all need deliberate canonical and internal-linking decisions. We build collection pages that can carry real content above and below the grid, metafield-driven structured data, and a blog structure that actually supports topical authority instead of being an afterthought. If you have an existing store with a visibility problem rather than a build problem, start with our Shopify SEO services.

The Shopify trade-offs worth knowing

You are renting, and the landlord sets the rules. Transaction fees apply unless you use Shopify Payments, the checkout is only properly editable at the Plus tier, and any feature Shopify chooses to change, you absorb. Costs creep quietly through apps, and a stack of ten at thirty dollars a month is a real line in the P&L. For deeply complex B2B pricing or catalogues in the hundreds of thousands, you will hit walls no app removes. What you get in exchange is that you will never spend a weekend patching a server, and for most brands that trade is worth making.

A custom website is built on a development framework rather than on top of a platform somebody else designed. There is no WordPress admin you inherit, no Shopify checkout you are locked into, no Magento indexer to babysit. Every page, every data model and every interaction exists because your business needed it. That is the whole appeal, and it is also the whole cost: nothing comes for free, so everything has to be decided.

Who custom website development is the right call for

The honest signal is when your website is really an application wearing a website’s clothes. Customer portals where clients log in to see their projects, invoices or results. Booking and scheduling engines with rules no plugin models properly. Marketplaces with a buyer side and a seller side. SaaS marketing sites that share components and authentication with the product itself. Calculators, quoting tools and configurators that are the reason people visit in the first place. It is also the right call when compliance or security requirements make a plugin ecosystem a liability rather than a convenience, or when page speed is a competitive weapon and you want to own every byte that reaches the browser.

It is usually not the right call for a brochure site or a standard online store. If your requirements fit comfortably inside WordPress or Shopify, a custom build means paying to rebuild features those platforms already hand you, and we will say so in the first meeting rather than the fifth invoice.

How we build custom websites

We pick the framework to fit the job rather than the one we happen to enjoy. Content-heavy marketing sites usually go on Next.js or Astro with static generation and server rendering, so every page arrives as complete HTML. Application back ends go on Laravel or Node with a proper relational database and an API the front end consumes. Where a site needs both — a marketing site with a logged-in area behind it — the two share one design system so they look and behave like a single product.

The most common failure of custom websites is that the marketing team cannot change anything without a developer. We solve that on day one with a headless CMS such as Sanity, Strapi or Contentful, chosen for the editing experience your team actually needs and wired to the same content model that drives the templates. Your team gets drafts, previews, scheduled publishing and revision history. The developers get clean structured content instead of blobs of HTML.

Search is where custom builds most often go wrong, and it is the part we are most careful about. A JavaScript single-page app that renders in the browser can look perfect to a visitor and nearly empty to a crawler. Every custom site we ship server-renders or pre-renders its HTML, generates its XML sitemap from the content model, manages redirects in the CMS rather than in a config file nobody can find, and outputs structured data from real data. The SEO controls a platform gives you by default — titles, descriptions, canonicals, Open Graph tags, noindex switches — are built into the CMS as first-class fields, so nobody has to file a ticket to fix a meta description.

Around all of that sits the engineering discipline that keeps a codebase alive after launch: version control, automated tests on the parts that matter, a deployment pipeline that spins up a preview of every change before it goes live, error monitoring, and documentation written for the next developer rather than the current one.

The custom build trade-offs worth knowing

You own everything, including every problem. No vendor is shipping security patches or new features on your behalf, so the codebase needs someone who understands it — either a retained developer or an in-house team we hand over to properly. Features you would take for granted on a platform, like a media library, a redirect manager or user roles, have to be chosen or built. Upfront cost is higher than WordPress for an equivalent marketing site, and timelines run longer. In exchange there are no licence fees, no plugin vulnerabilities, no transaction fees, no ceiling on what the site can do, and the fastest pages you can have, because nothing ships that you did not ask for. For the businesses that genuinely need one, nothing else comes close.

Platform comparisons usually get written by people selling one of the options. Here is the version we use internally when we are scoping a project, including the parts that are inconvenient for us to say. Read it down the left column: the row that matters most to your business is usually the row that decides how you should build, and it is rarely the price row.

The question that settles most of these decisions is not “which platform is best” but “what is the hardest thing this website has to do?” Answer that honestly and the shortlist usually collapses to one.

If the hardest thing is producing and organising a lot of content, WordPress wins and it is not particularly close. If the hardest thing is modelling a complicated catalogue, or serving different prices to different customers, or running several storefronts off one inventory, Magento wins and the cost is the price of admission. If the hardest thing is getting to market fast and staying out of infrastructure, Shopify wins. And if the hardest thing is that the website is really software — a portal, a booking engine, a marketplace, a quoting tool — a custom build wins, because every platform would have to be bent into a shape it was never designed for.

Two traps are worth naming. The first is choosing for the business you imagine rather than the one you have. Companies buy Magento for a catalogue they intend to build in three years, or commission a custom build for requirements a WordPress site would have met, then carry the running costs of ambitions they have not reached. Build for where you will be in eighteen months, not five years, because you can replatform later with far less pain than you think, and the money you save in the meantime is real.

The second trap is assuming the platform determines your rankings. It does not. Google and the answer engines do not care what generated your HTML. They care about what the HTML says, how fast it arrives and whether it earns trust. A well-built Shopify store will outrank a badly built WordPress site every single time, and a custom site that renders in the browser will lose to both. The platform sets your ceiling and your running costs; the build quality decides whether you get anywhere near that ceiling.

If you are still undecided after reading the table above, that is usually a sign the decision needs your real data rather than a general comparison. We do that as a paid discovery: your traffic, your catalogue, your integrations, your team’s actual capabilities, and a written recommendation you are free to take to any developer.

Every agency has a process diagram. What matters is which decisions get made in which order, because the order is what prevents the launch-day traffic collapse. Ours puts search research before information architecture and puts the migration plan before the design, which is the opposite of how most projects run.

Step seven is the one people skip and the one that costs them. A migration is not finished when the site goes live. It is finished when Search Console shows the old URLs resolving, the new URLs indexed, and impressions back at or above the previous baseline — which typically takes two to six weeks and needs somebody watching it.

A meaningful share of searches now end without a click. The user reads an AI Overview, asks ChatGPT, or gets a summarised answer in Gemini or Perplexity, and never visits a website at all. That does not make search less valuable. It changes what winning looks like: instead of only ranking a page, you are trying to be the source the model quotes and names.

Most websites are badly built for that, and the reasons are structural rather than editorial. Answers are buried under four hundred words of preamble. Facts live in images the model cannot read. There is no structured data tying a claim to an entity. Nothing on the page states plainly who wrote it or why they would know. We build those things in at the template level, so every page you publish afterwards inherits them. If the terminology is new, our explainer on GEO and AIO covers how the two differ.

Answer Engine Optimization (AEO)

Pages are structured so the answer comes first. Headings are written as the questions people actually ask, the paragraph immediately beneath each one answers it in two or three sentences that stand on their own when lifted out of context, and the supporting detail follows for readers who want it. FAQ sections emit valid FAQPage markup, comparison content sits in real HTML tables rather than images, and definitions are phrased as complete statements. It is a discipline that happens to make the page better for humans too, which is usually how you can tell it is not a trick.

Generative Engine Optimization (GEO)

Large language models cite sources that look like sources. That means clear authorship and credentials, dates that are visible and honest, specific numbers instead of vague claims, and consistent entity signals — your organisation, your people and your services described the same way across your site, your structured data and the places that mention you elsewhere on the web. We build the entity graph into the site during development, so the model has an unambiguous picture of who you are and what you do rather than assembling one from fragments.

AI Optimization (AIO)

The practical layer underneath both. Server-rendered HTML so crawlers and AI agents receive complete content without executing JavaScript. Clean semantic markup where headings, lists and tables mean what they say. A machine-readable content inventory, including an llms.txt file where it makes sense. Fast responses, since crawl budget and agent patience are both finite. Speakable markup on the passages most likely to be read aloud. None of it is exotic — it is mostly the same engineering discipline that makes a site fast and accessible, applied with the knowledge that a machine is now a primary reader.

If you want to see how your current site performs on these signals before committing to a build, the MRK SEO audit tool scores AI visibility alongside conventional technical SEO, and it is free to run.

Most of the development work we do is not a first website. It is a business moving from one platform to another, usually because they have outgrown something or inherited a build nobody can maintain. WooCommerce to Shopify when the store outgrows the plugin stack. Magento 1 to Magento 2, or off Magento entirely when the running costs stopped making sense. Shopify to Magento when B2B requirements arrive. A hand-coded site or an ageing Drupal install to WordPress so the marketing team can finally publish without a ticket. And, more and more often, a platform site to a custom build, when the website has quietly turned into a product the platform was never meant to run.

The technical work is well understood. The risk is entirely in the detail. A migration goes wrong when URLs change without a complete redirect map, when category and product descriptions get dropped because they were not in the export, when structured data does not survive the move, or when the new site launches slower than the old one and Core Web Vitals quietly degrade across every template at once.

So we start every migration from a full crawl of the existing site and an export of Search Console data, build the old-to-new URL map as a deliverable in its own right, and test every redirect on staging before DNS changes. Content, images, reviews, customer accounts and order history all get mapped explicitly rather than assumed. After launch we monitor indexation, crawl errors, rankings and conversion for thirty days, because the first fortnight is when a missed redirect is cheap to fix and the second month is when it is not.

Nobody can quote a website honestly from a one-line brief, and anyone who does is either guessing or pricing a template. What we can do is be clear about what drives the number, because the drivers are consistent across all four ways of building.

Cost tracks four things: how many distinct templates the site needs, how much of the content has to be written or restructured rather than migrated, how many external systems have to talk to it, and how much custom logic sits between a visitor and a completed order. A fifteen-page WordPress marketing site with a design system and no integrations is a different universe from a Magento build wired into an ERP, a PIM and a tax engine, and both are a different universe again from a custom customer portal with its own logins, permissions and billing — even though all three are “a website”.

On timing, a WordPress marketing site on a custom theme typically runs four to ten weeks. A custom Shopify theme build runs three to ten weeks, sometimes faster if the catalogue is already clean. A Magento or Adobe Commerce project runs three to seven months, and the schedule is almost always set by integrations and data migration rather than by design or front-end work. A fully custom-coded website or web application runs eight to twenty-four weeks, and where it lands in that range depends almost entirely on how much of it is application logic rather than content. Add two to six weeks after launch before organic performance stabilises on a migrated site.

We scope from a discovery phase rather than a package, and the discovery output — sitemap, template inventory, integration list, platform recommendation and a fixed-price build quote — is yours to keep whether or not you continue with us. That is deliberate. If the recommendation is that you should not rebuild at all, we would rather tell you that in week one than bill you for six months of finding out.

A new site is a foundation rather than a finished job. If you already have a site that works and the problem is that nobody can find it, these are usually the better place to start.