# Yorkshire Design — full corpus Generated 2026-09-05 UTC ============================================================ # AI App Development Source: https://yorkshiredesign.co.uk/ai-app-development/ Published: 2026-08-21 > I ensure fluid communications so you get the results you deserve. Your website will be made to exacting standards so it ranks in Google and all the major search engines. With my technical design service, your business will not get lost online. ------------------------------------------------------------ # Sitemap Source: https://yorkshiredesign.co.uk/sitemap/ Published: 2026-07-31 ------------------------------------------------------------ # Privacy Policy Source: https://yorkshiredesign.co.uk/privacy-policy/ Published: 2026-07-07 > Learn how Yorkshire Design handles your personal data. Read our privacy terms, cookie policy and your data rights. Contact us with questions about your information. ------------------------------------------------------------ # AI & Automation Source: https://yorkshiredesign.co.uk/ai-automation/ Published: 2026-07-06 > Practical AI and automation guides tested on real workflows. Learn what actually saves time and money, without the hype. Explore our resources today. ------------------------------------------------------------ # Home Source: https://yorkshiredesign.co.uk/ Published: 2024-01-16 > Practical WordPress, SEO and web design guides from 20+ years building sites. Real client work, tested steps, no filler. Explore guides on page speed, hosting and rankings. ------------------------------------------------------------ # Web Hosting Source: https://yorkshiredesign.co.uk/web-hosting/ Published: 2024-01-07 > Explore my authoritative and engaging Web Hosting Blog. ------------------------------------------------------------ # Web Design Source: https://yorkshiredesign.co.uk/web-design/ Published: 2024-01-07 > Expert web design guidance from Yorkshire Design. Learn what makes websites convert visitors into enquiries. Discover real design decisions that work. ------------------------------------------------------------ # Core Web Vitals Source: https://yorkshiredesign.co.uk/core-web-vitals/ Published: 2024-01-07 > Page speed guide covering pagespeed and core web vitals. Learn how to optimise your WordPress website performance. Explore our expert tips today. ------------------------------------------------------------ # Blog Source: https://yorkshiredesign.co.uk/blog/ Published: 2024-01-07 > Read Yorkshire Design's complete archive of web design, SEO, WordPress and hosting guides. Twenty years of real client work explained in plain English. ------------------------------------------------------------ # WordPress Source: https://yorkshiredesign.co.uk/wordpress/ Published: 2024-01-07 > Explore my authoritative and engaging Web Hosting Blog. ------------------------------------------------------------ # Content Source: https://yorkshiredesign.co.uk/content/ Published: 2024-01-07 > Expert tips and strategies to enhance your writing skills and captivate your audience. ------------------------------------------------------------ # SEO Source: https://yorkshiredesign.co.uk/seo/ Published: 2024-01-07 > Everything to do with SEO and climbing up the Google rankings. ------------------------------------------------------------ # Terms and Conditions Source: https://yorkshiredesign.co.uk/terms-and-conditions/ Published: 2023-02-18 ------------------------------------------------------------ # About Us Source: https://yorkshiredesign.co.uk/about-us/ Published: 2020-09-02 > I ensure fluid communications so you get the results you deserve. Your website will be made to exacting standards so it ranks in Google and all the major search engines. With my technical design service, your business will not get lost online. ------------------------------------------------------------ # Contact Us Source: https://yorkshiredesign.co.uk/contact-us/ Published: 2017-10-31 > My personal service allows me to really transfer your personality onto your website. Your customers will experience a bespoke web presence that will portray your online business perfectly. ------------------------------------------------------------ # AI Writing: When It Saves Time and When It Sabotages You Source: https://yorkshiredesign.co.uk/ai-writing-when-it-saves-time-and-when-it-sabotages-you/ Published: 2026-08-17 > Roughly half the business owners who contact me about slow rankings have one thing in common, a site full of AI-generated copy that reads fine on the surface but does nothing for Google. That's not an argument against AI writing. It's an argument for knowing exactly where it earns its keep and where it quietly does damage. The line between the two is narrower than most people assume, and it shifts depending on the type of content, the page's purpose, and how much human judgement goes into the final edit. Where AI Writing Pulls Its Weight There are tasks where AI earns its place, and the key is knowing which ones before you start. First-draft structure is the clearest win. Give an AI a solid brief and it will return a serviceable skeleton in seconds, headings, rough paragraph order, the logical flow of an argument. That scaffolding alone can cut the staring-at-a-blank-screen time from an hour to five minutes. The same holds for meta descriptions. They follow a tight formula, need to land within a character count, and the subject matter is already defined by the page. An AI can produce four or five workable options faster than most people can write one. FAQs behave similarly. If you have a clear topic and a list of genuine questions your customers ask, AI will produce clean, readable answers that need a light edit rather than a full rewrite. Product descriptions with a complete brief, dimensions, materials, key features, target use case, follow the same pattern. The more constrained and repeatable the format, the better AI performs. Where people often stumble is treating these outputs as finished copy rather than a starting point. A page that earns its ranking needs specific detail, an actual point of view, and language that fits the brand. AI gets you to the starting line faster. It does not run the race for you. The Pages Where AI Copy Works Against You Service pages are where AI-generated text tends to cause the most damage. When a model writes a service page, it pulls from the same pool of general knowledge every other model draws on, which means your roofing page, your accountancy page, or your legal services page ends up reading almost identically to a competitor's. Google's quality evaluators look hard at these pages precisely because they're the ones most likely to be thin or manufactured. A service page needs to answer the questions a real buyer has at the point they're considering spending money. That requires specifics, your process, your pricing logic, the problems you've actually solved, the things that go wrong and how you handle them. An AI that has never quoted a job, never dealt with a difficult client situation, and never had to explain why something took longer than expected cannot write that page with any conviction. Case studies and 'how we work' sections face the same problem, only worse. These formats exist to demonstrate a genuine point of view, and what makes a page worth ranking in those contexts is precisely the kind of first-hand detail no AI has access to. Anywhere Google is actively weighing depth and authenticity is the wrong place to paste in generated copy and move on. What 'Sounds Fine' Costs You in Search Rankings The E-E-A-T problem Grammatically clean copy that answers a query on the surface is not the same as copy that demonstrates real knowledge. Google's quality guidance is explicit on this: E-E-A-T (Experience, Expertise, Authoritativeness, Trustworthiness) puts experience at the front for a reason. A paragraph that reads fluently but could have been written by anyone who skimmed a Wikipedia article carries no experience signal at all. Picture a plumber's website where every service page explains what a boiler is rather than what goes wrong with that specific model in a hard-water area. Correct. Plausible. Useless as a trust signal, and increasingly easy for a classifier to spot. Topical authority Thin content spread across twenty loosely related pages tells a search engine you cover a lot and understand little. The fix is not rewriting AI output to sound more human, though that helps. The real fix is knowing what to add: the specific failure mode a practitioner has seen twice this month, the caveat that only applies to one edge case, the recommendation that runs against the obvious advice. That texture is what separates copy that earns rankings from copy that fills space. AI can draft a structure and give you something to react to. The parts that hold up are the ones you've rewritten with something only you know. How to Spot the AI Tells Before Google Does Phrases that signal nothing A second read through AI-generated content reveals patterns a first pass misses. Watch for hedged openers that add no information: "It's worth noting that...", "In today's world...", "When it comes to..." These phrases exist because the model needed a sentence to begin, not because the thought required one. Hollow transitions are the same problem mid-paragraph. "Furthermore" and "Additionally" chained together mean the model couldn't find a real logical connection between two points, so it reached for a connector and kept moving. Rhythm and vagueness Uniform sentence length across a whole paragraph, five sentences all landing at roughly the same weight, is a structure almost no human writer falls into naturally. Read it aloud and it sounds like a list dressed up as prose. Claims without specificity are the most damaging tell, and the one Google's quality assessors focus on. "Many businesses have seen significant improvements" asserts nothing. A technical editor would circle it and ask, which businesses, what improvement, over what period? If the answer isn't in the next sentence, the claim should not be in the piece. You can see the same failure in AI-generated SEO content across almost every industry vertical. Fix the rhythm first. Then replace every vague confidence claim with a number or a named example. What's left after that edit is usually publishable. The Edit That Turns Generated Text Into Something Publishable Raw AI output is a first draft. Full stop. Treating it as a finished piece is where most people go wrong. The editing layer is where the actual work happens. A typical AI draft hedges on everything, offers no real verdict, and pads the middle with restatements dressed up as new points. A useful edit does four specific things, it strips filler paragraphs (usually the third and fourth in any section, where the AI circles back to what it already said); replaces vague summary sentences with a concrete position; injects a real example where the AI wrote something like "for instance, a business might consider..."; and cuts anything a reader could skip without losing ground. Take a generated section on AI content writing for SEO and you will almost always find two or three sentences that restate the opening point in different words. Delete them. The paragraph that remains is tighter and reads more authoritative, not less. The skill being tested here is editorial judgement, not typing speed. Anyone can paste a prompt and copy the result. Knowing which paragraph to cut, where the argument needs a sharper claim, and when the AI has buried the actual point three sentences too late takes a trained eye. The writing is almost incidental. The edit is the craft. A Practical Decision Checklist for Each Content Type Four questions to ask before you start Before using AI on any page, four questions will cover most of the ground. Does this page need to demonstrate real experience? A product review, a case study, or a service page that quotes your own process should have a human at the wheel, because AI has no access to what you actually did or saw. Does the topic change often enough that a confident but outdated answer would actively mislead someone? If yes, AI output needs careful verification before it goes anywhere near a live page. Is the page targeting a competitive keyword where thin, generic content is already the norm? Publishing something that reads like everything else on the first page is not a neutral choice; it is a disadvantage. Does the page carry any conversion weight, a pricing page, a contact form intro, an about section? Those words do a specific job, and AI tends to smooth away the friction and specificity that actually persuade people. Where to draw the line If all four answers point away from AI, write it yourself or commission someone who knows the subject. Where AI earns its place is on structured, factual, low-stakes content where the frame is already clear: FAQ answers, metadata drafts, or category descriptions that a human then tightens. The checklist is not about avoiding AI. It's about not reaching for it by default before asking whether this particular page actually benefits from it. Most of the time, that one question changes the answer. ------------------------------------------------------------ # Fast Hosting Won’t Save a Bloated Website Source: https://yorkshiredesign.co.uk/fast-hosting-wont-save-a-bloated-website/ Published: 2026-08-16 > Plenty of site owners switch to a premium host, see the spec sheet full of NVMe drives and global CDN nodes, and expect their pages to snap into life. Then nothing changes. The load time barely shifts. The frustration is real, and the instinct to blame the host is understandable. But the server is rarely the bottleneck. What slows most WordPress sites down is already sitting inside the site itself, waiting to be found. What Fast Hosting Actually Fixes Fast hosting solves one thing well, the gap between a browser sending a request and your server sending back the first byte of a response. That is it. Everything else is down to you. That metric, Time to First Byte, is influenced by your server's hardware, its geographic location relative to your visitor, and how efficiently your hosting environment handles concurrent connections. A well-provisioned server on a reputable platform can shave meaningful time off that initial handshake. Where things get muddier is everything that happens after. Once the server has delivered the raw HTML, the browser still has to download every stylesheet, parse every script, request every image, and render the whole thing into what the visitor sees. Hosting has no say in any of that. It cannot shrink an unoptimised 4MB hero image, untangle a render-blocking plugin stack, or reduce the 60 JavaScript requests a theme has accumulated over time. Those problems travel with the site, regardless of which server it sits on. We've worked on sites that moved from sluggish shared environments to faster infrastructure and saw their Core Web Vitals scores barely shift. The server was no longer the bottleneck. The page itself was. A cleaner, leaner build will outperform a bloated one on premium hosting almost every time, and understanding that distinction is what stops you spending money in the wrong place. Where the Real Weight Lives Hosting gives your site a faster road to travel on, but it cannot change what's in the vehicle. Uncompressed images are the most common culprit by far. A hero image saved straight from a camera or a design tool at 4MB will load slowly on even the quickest server. Render-blocking scripts are the next problem. JavaScript and CSS loaded in the document head force the browser to pause and parse files before it can show the user anything. Then there are plugins. Each one can add its own stylesheet and script file to every page load, regardless of whether that page uses the plugin's feature at all. A contact form plugin loading its assets on your homepage, a slider library firing on a product page, a page-builder injecting four separate scripts into a simple blog post. It adds up fast, and the host has no mechanism to stop any of it. This is the kind of thing that takes careful attention to untangle, and it rarely shows up in a basic hosting comparison. Themes built for demo sites are a particular problem. They look impressive in screenshots because they ship with every feature switched on, which means dozens of asset files loaded whether you use those features or not. A theme optimised for a plugin-heavy demo environment is rarely the same thing as a theme built to perform in the real world. Fix these on-site culprits first, and a hosting upgrade means something. The Plugin Pile-Up Problem WordPress plugins are easy to install and easy to forget about. A contact form here, a social share button there, a cookie notice added six months ago that nobody uses any more. Over time, a typical WordPress site accumulates a long tail of these additions, each one feeling minor on its own. The problem is that they rarely stay minor. Every active plugin is a potential source of extra database queries, additional HTTP requests, and JavaScript that loads whether the visitor needs it or not. A slider plugin fetching its scripts on a contact page. A WooCommerce extension querying stock levels on a blog post. The code runs regardless, and the browser waits. That compounding effect is what catches people out. Ten plugins each adding a single database query sounds harmless, but under real traffic, with multiple requests firing at once, that load gets multiplied across every page view. What lingers after you deactivate Deactivating a plugin does not always clean up after itself. Legacy scripts, orphaned database rows, and stylesheet references can linger long after the plugin is switched off, adding weight to every page load with nothing to show for it. If you have ever wondered why your site drags despite sitting on decent hardware, the plugin overhead that accumulates between audits is usually the first place to look. A fast server can only do so much when the application layer is fighting it at every step. Images Are Usually the Biggest Offender A hero image shot on a DSLR and dropped straight into a media library will often land at 4MB or more. The hosting might respond in 180ms, but that single file still has to travel across the wire before anything above the fold renders. On a mobile connection, a 4MB image can add three to four seconds to perceived load time on its own, which swamps any advantage a fast server brings. The browser cannot paint what it has not received, and no amount of premium infrastructure changes that basic equation. Format matters too. A JPEG that could have been a WebP at one-fifth the file size, or a PNG used where a compressed WebP would have done the job, represents a decision made once and paid for on every single page load, by every visitor, indefinitely. You can see this play out in any Largest Contentful Paint audit. The LCP element is almost always an unoptimised hero image, and fixing the host does nothing to shift it. Resize to display dimensions, convert to WebP, and apply lazy loading to anything below the fold. Those three steps alone typically cut image payload by 60 to 80 percent, and that saving shows up immediately in render time where it matters. How to Diagnose Which Layer Is Slow Start with PageSpeed Insights. It separates server response from front-end rendering, which is exactly what you need to know before touching anything. Reading the numbers correctly The metric to look at first is Time to First Byte, usually shown as TTFB. This measures how long your server takes to respond before the browser has received a single character of HTML. A TTFB above 600 milliseconds points at the server layer, so hosting, caching, or a database creaking under load. If TTFB is fine, say under 200 milliseconds, but your Largest Contentful Paint is still sitting at four or five seconds, the server is doing its job. The problem lives further down the stack, in the browser. That typically means render-blocking scripts, uncompressed images, too much CSS loading before the page paints, or a theme pulling in resources it never uses. PageSpeed Insights will flag these directly in the Opportunities and Diagnostics sections, and each flag tells you the specific file or request causing the delay, not just a vague score to worry about. Run the test on mobile, not just desktop. Mobile scores are harder to achieve and closer to what most of your visitors experience. If the gap between the two is large, JavaScript weight is almost always the culprit. Fixing the Site Itself, Not the Shelf It Sits On The right move before spending more on hosting is to audit what the site is doing. That means looking at which plugins are loading scripts on every page regardless of whether they're needed there, whether images are being served at the right size and format, how many external requests fire on a single page load, and whether the theme is pulling in half a dozen font files before a visitor sees anything useful. A bloated plugin stack is one of the most common culprits, and it rarely announces itself. You won't see it in your hosting dashboard. You'll only find it when you dig into the waterfall of a page speed test and start tracing what's loading, in what order, and why. That kind of audit takes time to do properly. Every site has a slightly different tangle, and pulling on one thread sometimes means checking three others before you can be confident the change is safe. The result, when the work is done carefully, is a leaner site that performs well on mid-range hosting rather than one that still struggles on expensive infrastructure. Upgrading the server without fixing the code is a bit like fitting wider tyres to a car with a bent axle. ------------------------------------------------------------ # WP Rocket Settings: Get More From What You Already Paid For Source: https://yorkshiredesign.co.uk/wp-rocket-settings-get-more-from-what-you-already-paid-for/ Published: 2026-08-15 > WP Rocket is the most popular premium caching plugin on WordPress. Most people install it, tick a few boxes, and assume the job is done. It isn't. The default configuration leaves a significant amount of performance on the table. This guide covers the specific settings that actually reduce load times, improve Core Web Vitals scores, and do the work most installs quietly skip. Why the Default Install Is Not Enough WP Rocket ships in a deliberately cautious state. The moment you activate it, a handful of foundational features switch on automatically, basic page caching, cache preloading, and browser caching being the main ones. That sounds like a lot, but the settings that move the needle most on Core Web Vitals and PageSpeed scores stay completely off until you enable them yourself. The developers made this choice intentionally, because aggressive optimisations applied blindly can break poorly coded themes or conflict with certain plugins. The real performance gains come from the features buried inside the dashboard that nobody prompts you to turn on. LazyLoad for images and iframes is off by default. JavaScript deferral is off. CSS and JS file minification is off. Database optimisation runs on no schedule until you set one. If you install WP Rocket, get a modest score bump from the automatic settings, and leave it there, you are genuinely using about a third of what the plugin can do. Understanding which WP Rocket settings to enable, and in what order, is where the actual work begins. File Optimisation Settings Worth Switching On WP Rocket settings under File Optimisation give you some of the biggest performance gains on the page, but not every option is safe to enable without testing. CSS and JS minification strip out whitespace and comments from your files, reducing their size without changing what they do. Combining CSS delivery merges multiple stylesheets into a single request, which cuts round trips to the server. Both are generally safe starting points, though a complex theme with lots of third-party styles can occasionally produce layout shifts, so check your front end after enabling them. Remove Unused CSS and Defer JS Loading are the two options that need the most care. Remove Unused CSS tells WP Rocket to load only the stylesheet rules a given page actually uses, which can dramatically shrink render-blocking CSS, but it sometimes strips rules your site needs, especially on dynamic elements like sliders or popups. Defer JS Loading delays non-critical scripts until after the page renders, which improves time to first interaction noticeably, but poorly coded plugins can break when their scripts load out of sequence. Test both on staging before pushing to production. Media Settings That Cut Load Time Without Quality Loss Lazy loading is one of the highest-impact WP Rocket settings you can enable, and it costs nothing in visual quality. When lazy loading is active, images and iframes below the fold only load as a visitor scrolls toward them, which means the browser spends its initial resources on what's actually visible. On image-heavy pages, this directly improves Largest Contentful Paint scores because the critical above-the-fold content gets full bandwidth rather than competing with a dozen off-screen images loading simultaneously. Disable it, and Google's Core Web Vitals report will tell you about it. WebP compatibility works alongside lazy loading rather than replacing it. WP Rocket doesn't convert images to WebP itself, but it serves WebP versions automatically when your image plugin, such as Imagify or ShortPixel, has already generated them. A product page carrying thirty JPEG thumbnails can shed a significant portion of its image payload simply by switching to WebP delivery, with no visible difference to the user. If you're already investing time in reducing server response time, skipping WebP and lazy loading leaves a sizeable performance gain on the table that no amount of server optimisation can recover. Preloading and Prefetching: What Each One Does Cache preloading tells WP Rocket to visit your pages and build their cached versions before a real visitor arrives, so nobody ever loads an uncached page cold. Sitemap-based preloading extends that idea by pulling your XML sitemap and walking every URL in it, which is genuinely useful on large sites where you publish frequently and can't afford the first visitor to a new post eating a slow uncached response. These two WP Rocket settings work together, preloading keeps the cache warm, and the sitemap ensures that warmth covers the full site, not just pages that have already had traffic. Without both active, a new post published at 9am could sit uncached until someone stumbles across it. DNS prefetch and preconnect are different beasts entirely. They don't touch your cache. Instead, they tell the browser to resolve and open connections to external domains, such as Google Fonts or a third-party analytics server, before your page actually needs them. DNS prefetch handles the name lookup, while preconnect goes further and completes the full handshake, cutting the time a browser spends waiting on outside resources. If you're curious how early-connection work fits into the broader server response and TTFB picture, the two topics overlap more than most people expect. Add preconnect only for domains your page loads on every request, otherwise you're opening connections that go unused. The Database Optimisation Tab Most Users Never Open Most WordPress sites accumulate thousands of post revisions, expired transients, and orphaned metadata within a few months of going live. WP Rocket settings include a dedicated Database tab that handles all of this, yet it sits unopened on the majority of installs. Post revisions are the worst offender. A site with 500 posts and WordPress's default unlimited revisions can easily carry 5,000 to 8,000 redundant rows in the wp_posts table, slowing every query that touches it. Clearing those out once makes a measurable difference. Clearing them on a recurring schedule keeps that difference permanent. The smarter move is to enable the scheduled cleanup and set it to run weekly rather than treating it as a one-off task. Transients in particular regenerate constantly, so a single clean gives you a day or two of breathing room before the table bloats again. Set the schedule, choose your cleanup targets, and let automation handle the maintenance window you would otherwise forget. If you want to understand how other recurring technical tasks affect crawl efficiency, the piece on crawl budget and why big sites lose rankings over it covers the knock-on effects that a sluggish database can trigger upstream. CDN and Cloudflare Integration Done Right WP Rocket's CDN tab is where you tell the plugin to rewrite your static asset URLs, pointing images, scripts, and stylesheets toward your CDN hostname instead of your origin server. That rewriting alone cuts load time for visitors who are geographically distant from your host, because assets are served from a node closer to them. If you are running Cloudflare, the setup goes a step further. WP Rocket ships a dedicated Cloudflare add-on, found under Settings, that connects directly to the Cloudflare API using your account email, API key, and zone ID. Once connected, WP Rocket can push cache-purge requests to Cloudflare automatically whenever you clear your local cache. The problem most sites run into is a mismatch between the two cache layers. A user publishes an updated page, WP Rocket clears its own cache, but Cloudflare still serves the old version from its edge nodes because the purge request was never sent, or the API credentials had quietly expired. Visitors see stale content and nobody traces it back to the CDN because the page looks fine in the browser. The fix is straightforward, verify your Cloudflare credentials inside the add-on, set the cache level to "Standard", and enable "Auto Purge Content" so both layers clear together. If you want to go deeper on how poor server response time and TTFB compound these caching issues, that is worth reading alongside your CDN configuration. Testing and Validating Your Configuration Once your WP Rocket settings are in place, you need to confirm they are actually doing what you expect, not just assume the configuration worked. Run a PageSpeed Insights test on a key page and look specifically at the Diagnostics section for "Eliminate render-blocking resources" and "Serve static assets with an efficient cache policy." If WP Rocket is configured correctly, those warnings should shrink or disappear entirely. GTmetrix gives you a waterfall view, which lets you see whether your CSS and JS files are loading in a combined, minified form rather than as a long list of individual requests. A before-and-after comparison here is far more telling than a single score. For a deeper look at how server response time affects those results, it is worth checking what your TTFB reading looks like in both tools. Browser DevTools fills in the gaps that online tools miss. Open the Network tab in Chrome, reload your page with the cache cleared, and filter by "Img" to check lazy loading is triggering correctly. Images below the fold should not appear in the initial request waterfall. Then filter by "JS" and confirm your deferred scripts are loading after the main document, not blocking it. The Response Headers panel on any static asset should show a "Cache-Control, max-age" value in the thousands of seconds if browser caching is set. If you see "no-cache" or a very short max-age, WP Rocket's browser caching rule is not taking effect and needs investigating. Related: WP Rocket: A Beginner's Guide to What It Actually Does ------------------------------------------------------------ # SEM Firms’ July 2026 Rankings: What a ‘Top Agency’ List Actually Tells You Source: https://yorkshiredesign.co.uk/sem-firms-july-2026-rankings-what-a-top-agency-list-actually-tells-you/ Published: 2026-08-15 > SEM Firms has published its latest roundup of top digital marketing agencies for July 2026. Before you take it as gospel, it's worth understanding exactly what these lists measure and what they quietly leave out. By Simon Parker Rankings lists are everywhere in digital marketing. The semfirms announcement for July is one of the more prominent doing the rounds, and my honest take is this, treat it as a starting point, not a verdict. These lists do useful filtering work, but they carry structural limitations that matter when real money is on the table. What SEM Firms Actually Measures Semfirms publishes periodic rankings of digital marketing agencies across search engine marketing, SEO, paid media and related disciplines. The methodology typically combines client reviews, case study depth, portfolio quality and editorial assessment. That is a reasonable framework as far as it goes. It surfaces agencies that are at least organised enough to submit credentials, maintain a public profile and collect client testimonials. The problem is what that framework misses. An agency can tick every box on a review-aggregation platform and still deliver mediocre technical SEO work. Client satisfaction scores and what SEO actually takes under the bonnet are two entirely different things. A client who felt well looked-after does not necessarily know whether their Core Web Vitals improved, whether their crawl budget was properly managed, or whether the links built for them were worth having. So the list tells you which agencies are visible, credible-looking and reasonably well-reviewed. It does not tell you which ones do the hard, unglamorous technical work that compounds over time. The Digital Marketing Agency Scene Right Now Context matters here. Digital marketing today is not the same industry it was three years ago. AI tooling has changed the economics of content production considerably. Agencies that once charged a premium for volume content now compete with automation. That shifts the real differentiator toward technical depth, strategic judgement and site-level work that AI cannot yet replace reliably. The agencies worth hiring are the ones that understand server-level performance, how hosting choices affect page speed, structured data, crawlability and the intersection of Core Web Vitals with user experience signals. Those capabilities do not show up cleanly in a semfirms ranking built around reviews and portfolio submissions. What These Lists Get Right That said, I would not dismiss the semfirms list entirely. It does two things well. First, it narrows the field. The digital marketing agency space is vast and opaque. A curated list of agencies assessed against some criteria is more useful than a cold Google search, where the top results are often the agencies best at ranking themselves rather than the ones best at ranking their clients. Second, it creates accountability pressure. Agencies appearing on visible rankings have a reputational stake in maintaining standards. That is not nothing. A firm with a public profile on a respected aggregator is somewhat more likely to respond properly when something goes wrong. The Solo Operator Blind Spot This is where I have a genuine gripe. Rankings like semfirms are almost entirely oriented toward agencies, meaning teams with account managers, sales processes and the overhead that comes with them. The solo specialist or very small operation rarely appears, regardless of technical quality. That is a real structural gap. Some of the sharpest SEO and web performance work around comes from individuals who are heads-down on the actual problem rather than building the institutional presence that rankings platforms reward. A solo operator who has built well over 200 WordPress sites, who understands PHP at the code level and works through Core Web Vitals issues methodically, is not well served by a methodology that weights client volume and company profile. If you are choosing an agency or specialist based partly on a list like this, factor that gap in. Ask specifically about technical depth, not just case study results. Ask who actually does the work. In a larger agency, the answer is often several people removed from whoever pitched you. How to Use the Rankings Sensibly Use the semfirms list as a shortlist generator, not a final answer. Once you have a handful of names, do your own due diligence. Specifically Ask for technical audit samples, not just traffic graphs. Find out who on the team will actually handle your account day to day. Ask directly about Core Web Vitals, site architecture and crawl management. If they pivot straight to paid traffic or content volume, that tells you something. Check whether their own site performs well. A slow, bloated agency website is not a good sign. That last point is more useful than it sounds. Running a quick PageSpeed Insights check on an agency's own domain takes about thirty seconds and reveals a great deal. If they cannot keep their own house in order, they are unlikely to prioritise yours. Local vs. National: What Rankings Flatten Out One more thing to consider. National rankings naturally favour agencies in major cities with the client volume to generate reviews at scale. If you are a regional business looking for a partner who understands your market, a national top-ten list may not be pointing you in the right direction. Aggregate rankings tend to compress the geographic dimension of web design and digital marketing almost completely. A smaller specialist who works consistently in your sector and location, and who knows the search behaviour of your actual customers, is often worth more than a ranked national agency that slots you into a standard process. The Bottom Line The semfirms rankings are a credible signal, not a definitive guide. They help you avoid the completely unknown and the obviously poor. Beyond that, the work of choosing the right digital marketing partner is still on you. Ask harder questions than any rankings list does. The agencies and specialists who can answer those questions with real specifics, rather than slides and case study headlines, are the ones worth your time. Good results in SEO and web performance do not happen overnight, and the best operators are the first to tell you that. Anyone promising fast wins via a polished pitch deserves more scrutiny, not less. Reference Source: SEM Firms Announces Top Digital Marketing Agencies for July 2026 - ... ------------------------------------------------------------ # WordPress Log In: What To Do When You Can’t Get In Source: https://yorkshiredesign.co.uk/wordpress-log-in-what-to-do-when-you-cant-get-in/ Published: 2026-08-15 > Being locked out of your WordPress log in is one of those things that feels urgent the moment it happens. The site is right there, you can see it, but the admin dashboard is completely out of reach. Before you do anything drastic, most lock-out situations come down to a handful of causes, and most of them have a straightforward fix. This guide walks through each one in plain English, in roughly the order you should try them. Wrong Credentials Are the Most Common Cause It catches more people out than you'd expect. WordPress usernames are case-sensitive. If your username is Simon with a capital S, typing simon in lowercase will fail every time. Passwords follow the same rule. Before going any further, check that caps lock is off and that you're typing into the correct field. Also check that you're pointing at the right login URL. The standard WordPress login page sits at yoursite.com/wp-admin or yoursite.com/wp-login.php. Some security plugins move the login page to a custom address. If that applies to your site, the standard URL will return a 404 with no explanation. Try the Password Reset First If you can't remember your password, the reset link on the login page is the cleanest starting point. Click "Lost your password?", enter your username or account email address, and WordPress sends a reset link. Check both your inbox and your spam folder, because it often ends up there. If that email never arrives, the problem is usually your server's mail configuration rather than WordPress itself. Many hosting setups don't have outgoing mail configured properly from the start. When that's the case, you need to go a level deeper. Reset Your Password Through phpMyAdmin When the email route fails, you can reset your password directly in the database. Log in to your hosting control panel (cPanel or equivalent), open phpMyAdmin, and select your WordPress database. Open the wp_users table (the prefix may differ if it was changed during setup), find your username, and click Edit. In the user_pass field, select MD5 from the function dropdown and type your new password into the value field. Save the row. That password is now active. Head back to /wp-admin and log in with it. This feels technical the first time, but it's a standard procedure and you're not breaking anything. Think of the database as a very structured spreadsheet and it becomes far less daunting. Create a New Admin User via FTP If phpMyAdmin isn't available, you can create a fresh admin account by editing a theme file directly over FTP. Connect to your server using an FTP client, navigate to your active theme folder inside wp-content/themes/your-theme/, and open functions.php. Add the following snippet to the top of the file, just below the opening <?php tag: add_action('init', function() { if (!username_exists('tempuser')) { $id = wp_create_user('tempuser', 'ChangeMe123!', 'temp@yourdomain.com'); wp_update_user(['ID' => $id, 'role' => 'administrator']); } }); Save the file, visit any page on your site to trigger the code, then log in with those credentials. Once you're in, go straight to Users, update your original account or create a permanent one, and remove that snippet from functions.php. Do not leave it there. If you want a clearer picture of how WordPress site structure affects security and stability, the technical work happening beneath a WordPress site is often what separates a solid setup from a fragile one. A Security Plugin May Have Locked You Out Several security plugins, including Wordfence and Limit Login Attempts, block an IP address after a set number of failed login attempts. If you've been trying repeatedly and can no longer see the login form at all, this is a likely cause. To fix it, temporarily disable the plugin via FTP. Go to wp-content/plugins/ and rename the plugin's folder, for example from wordfence to wordfence-disabled. WordPress deactivates it automatically. Log in, rename the folder back, and reactivate it from the Plugins screen. Your IP should be cleared once you're back inside. When a White Screen Appears Instead of the Login Page A white screen on the login page usually points to a PHP error rather than a credentials problem. This often happens after a plugin update or a PHP version change at the server level. Enable WordPress debug mode by editing wp-config.php over FTP. Find the line that reads define('WP_DEBUG', false); and change false to true. Reload the page and you'll see an actual error message rather than a blank screen, which tells you exactly what needs fixing. Slow or broken admin pages can be a separate matter entirely, and knowing what makes a WordPress site drag helps you rule out performance-related causes quickly. Before You Start Trying Everything at Once Some of these fixes need server access that most people don't have close to hand. If your host doesn't offer phpMyAdmin or FTP access, or if you're on a managed platform with restricted file access, the steps above may not be straightforward. In that case, your host's support team is the fastest path forward. They can reset credentials at the server level far more quickly than any plugin or workaround. If you can't login to WordPress, getting back in is almost always possible. Work through each option methodically rather than trying several things at once. Otherwise it becomes very hard to tell what actually fixed it. ------------------------------------------------------------ # What Bing AI Search Actually Means for Your Organic Traffic Source: https://yorkshiredesign.co.uk/what-bing-ai-search-actually-means-for-your-organic-traffic/ Published: 2026-08-15 > Most site owners are watching Google closely right now, which means Bing's AI overhaul is quietly reshaping traffic patterns nobody has noticed yet. Bing AI search now surfaces synthesised answers above the traditional blue links, and the click behaviour that follows looks nothing like what we've been optimising for. Some sites are benefiting. Plenty aren't. The difference usually comes down to a handful of technical and content choices made months or years ago. How Bing AI Search Actually Works When you type a query into Bing and an AI-generated answer appears at the top of the page, that answer has a source. Bing's AI layer reads across its indexed pages, pulls out the most relevant points, shapes them into a direct response, and lists the source pages as citations alongside. Think of it as a summariser sitting on top of the standard index. The underlying pages still need to exist, still need to be crawled, and still need to rank well enough for the AI to consider them worth drawing from. This is structurally different from a normal search results page. On a standard SERP, a user sees ten links and picks one to click. With an AI answer at the top, many users read the synthesised response and stop there, never scrolling to the organic results below. The citations Bing includes do attract clicks, but the pool of sites earning those slots is far smaller than the list of sites that once ranked on page one. A page sitting at position four may now be invisible to most visitors, even though nothing about it has changed. That structural shift is exactly why it pays to monitor Bing organic performance properly, rather than assuming your rankings tell the full story. What Happens to Your Click-Through Rate It depends almost entirely on what someone was searching for. Informational queries, the "how does X work" and "what is Y" questions, are the most exposed. Bing's AI answer often resolves the question right there on the page, and if the user gets what they came for without clicking, your organic listing simply does not get the visit. Take a query like "what is a canonical tag." A well-structured AI summary answers that in four sentences, and the links below it go largely untouched. That kind of traffic was always low-converting, but it still represents a measurable drop in volume that catches many site owners off guard. High-intent and commercial queries tell a different story. When someone searches "best WordPress hosting for WooCommerce" or "hire an SEO consultant," the AI response cites sources rather than replacing them, and those citation placements attract clicks from users already close to a decision. It is a smaller pool of visits, but they tend to convert better than broad informational traffic ever did. If you are already paying attention to what genuinely moves the needle in organic search, the shift is not catastrophic. It does mean rethinking which content you invest time building out. What Bing's AI Looks for in Sources Bing's AI does not pick citations at random. The pages it draws from tend to be clearly structured, answer a specific question directly, and carry genuine factual depth rather than padded generalisations. A post that states a claim and backs it with a concrete example, a real figure, or a named process will almost always outperform one that restates the question three ways and calls it content. Clear authorship signals matter too. Pages where real expertise shows through, via specific detail, direct opinion, or hands-on observation, read very differently from pages that could have been written by anyone about anything. What most optimisation guides still miss is that Bing's AI search weighs page experience alongside content quality. A slow-loading page, or one that shifts layout as it loads, sends a negative signal even if the words on it are good. Speed matters here, but not in the superficial sense of chasing a PageSpeed score, which is a diagnostic tool rather than a direct ranking input. What counts is whether the page loads cleanly for a real user on a real connection, serves content without layout instability, and does not rely on deferred rendering that leaves the AI crawler with an incomplete picture. These are unglamorous details, but they are exactly the ones that separate a page worth citing from one that gets passed over. Technical Checks Your Site Needs First Before worrying about content strategy or AI-optimised copy, the fundamental question is whether Bing's crawler can actually read your pages at all. Check your robots.txt file first. A single misconfigured disallow rule can silently block Bingbot from entire sections of your site without you noticing. After that, look at your XML sitemap and confirm every URL it lists returns a 200 status, not a redirect chain or a 404. Bing's AI summarisation pulls from pages it can confidently parse, so if your canonical tags point in conflicting directions or your indexing signals are muddled, you will not appear in those summaries regardless of how strong the underlying content is. Schema markup is where most sites fall short, and it matters more than many people expect. Structured data gives Bing's AI a clean, unambiguous description of what a page covers, whether that is an article, a product, a FAQ, or a local business. Without it, the model has to infer from raw HTML, and it often gets it wrong. Core Web Vitals are worth auditing too, not because page speed is a direct AI ranking signal, but because pages that load slowly or shift during load are harder to crawl reliably at scale. Each of these fixes depends on correctly diagnosing the one before it. That is why the work takes longer than most people expect, and why being thorough from the outset pays off. Structuring Content That Gets Cited Bing's AI does not read a page the way a human does, skimming down to find the good bit. It pulls the most directly useful answer from the content closest to a section's opening, which means burying your point three paragraphs deep is a practical problem, not just a stylistic one. Pages that earn citations tend to answer the implied question in the first two sentences of a section, then build on it. A heading that reads "How long does SEO take?" followed immediately by "Most sites see measurable movement in three to six months" is far more extractable than one that opens with background context and saves the actual answer for later. Structure your H2s and H3s to reflect the specific question, then answer it straight away. Thin copy gets passed over because the AI has nothing concrete to cite. Vague phrases like "there are many factors involved" or "results vary" give a language model nowhere to land, and it moves on to a page that commits to an actual answer. This is where solid on-page SEO and AI visibility overlap more than people realise. Clean heading hierarchy, specific claims, and copy that genuinely explains something rather than gesturing at it all make a page easier for both humans and AI systems to extract value from. The discipline is the same. The stakes have simply gone up. Where Not to Spend Your Energy Bing's share of the search market is real, but it is not Google. Depending on your sector and audience, Bing typically accounts for somewhere between 5 and 15 per cent of organic search traffic for most UK websites. That matters, but it also means pouring significant time into Bing-specific optimisation is rarely the best use of a limited content budget. If your Google presence is still patchy, fixing that first will move the needle far more than fine-tuning for an AI feature that the majority of your visitors will never encounter. Most of what sound SEO already asks of you serves Bing AI search just as well as it serves Google. Clear structure, authoritative content, well-formed markup. There is no separate Bing playbook worth maintaining in parallel. Where the effort becomes worthwhile is if your audience skews older, works in enterprise, or uses Microsoft 365 products daily, because those groups over-index on Bing considerably. In those cases, taking the time to monitor Bing organic traffic and understand how its AI surfaces answers pays off in measurable ways. For everyone else, treat Bing as a useful secondary channel and keep your energy pointed where the bulk of your traffic actually comes from. ------------------------------------------------------------ # 5 WordPress Plugins Quietly Killing Your Core Web Vitals Source: https://yorkshiredesign.co.uk/5-wordpress-plugins-quietly-killing-your-core-web-vitals/ Published: 2026-08-14 > Pick up any WordPress site that has sat untouched for a year and you will almost always find the same thing. The theme looks fine, the content is solid, but the Core Web Vitals scores are in the red. Most of the time, it is not the theme causing it. It is the plugins. Specifically, a handful of well-intentioned tools that add far more weight to the front end than anyone realised when they were first installed. Page Builder Plugins With Unloaded CSS Everywhere Elementor is the clearest example of this pattern. Install it, build five pages with it, and it will load its full stylesheet on every single page of your site, including your contact form, your blog archive, and any page built entirely in the native editor. Open Chrome DevTools, run the Coverage tab while the page loads, and you will often see 60 to 80 percent of Elementor's CSS flagged as unused. That unused payload sits between the browser and your content, pushing up the render-blocking time and dragging LCP with it. The browser has to parse the whole file before it can paint anything meaningful to the screen. Trimming that dead CSS makes a measurable difference to LCP because the browser gets to the content sooner. The practical fix is to use Elementor's built-in "Improved Asset Loading" option, which attempts to load only the widgets present on each page, though it does not always catch everything. A more thorough approach is to test each template in the Coverage panel after enabling it, check what remains flagged as unused, then decide whether a lighter page builder or a hand-coded plugin audit makes more sense for that site. There is no shortcut here. It takes time to do it properly. What Slider and Carousel Plugins Actually Load Slider plugins look tidy inside the WordPress dashboard. Pick a layout, drop in some images, publish. What you don't see is the payload being sent to every visitor, a full JavaScript library, often multiple CSS files, and in some cases lazy-load scripts that fire before the page has even painted its first meaningful content. Plugins like Slider Revolution and Smart Slider 3 are common offenders, not because they're poorly built, but because the feature set they carry is enormous relative to what most sites use. That weight lands directly on your Largest Contentful Paint score, pushing the metric out by hundreds of milliseconds before a single product image or headline has rendered. The practical problem is that sliders almost always sit above the fold, right where Google measures LCP. The browser ends up waiting for JavaScript to initialise before it can even work out what the largest visible element is. You end up serving a complex animation framework to every visitor, including those on a 4G connection in a rural area, just to display three images cycling on a five-second timer. Most clients who remove a slider and replace it with a single static image see a measurable LCP improvement without touching anything else on the page. The trade-off rarely makes sense once you see it clearly laid out in PageSpeed Insights. Do Chat and Pop-Up Widgets Hurt INP Scores? Chat widgets and pop-up builders are among the worst offenders for Interaction to Next Paint, and the reason sits in how they load. Most of these tools inject third-party scripts that register dozens of event listeners the moment the page initialises, long before a visitor has clicked anything. Every tap or keypress then has to work through that stack before the browser can respond, and INP measures exactly that delay. A live chat plugin from a well-known provider can add 80 to 120 milliseconds to an INP reading on its own, which is enough to push a borderline site from "Needs Improvement" into the failing band. When scripts load matters as much as what they load Scripts loaded synchronously in the <head> block the main thread during the most sensitive part of page startup. Any interaction shortly after load hits a thread that is already busy. Lazy-loading the widget until after the first user interaction cuts that cost dramatically, but most pop-up plugins don't do this by default. If you open Chrome DevTools and run a trace while clicking a button on a page with a chat widget active, you'll often see long tasks of 200ms or more attributed directly to the third-party script. The fix is rarely about the widget itself. It's about controlling when and how those scripts reach the main thread. Font and Icon Plugins That Block the First Render Most font and icon plugins drop their stylesheet into the document <head> as a standard blocking resource. The browser has to fetch that external file before it can paint anything on screen, which pushes your Largest Contentful Paint further out than it needs to be. A site running a Google Fonts plugin alongside a Font Awesome icon library can easily add 300 to 600 milliseconds of render delay on a slow connection, simply because both stylesheets sit in the critical path. That might sound marginal, but it shows up plainly in LCP and the other Core Web Vitals metrics that Google uses as ranking signals. Self-hosting is the cleaner fix Load these resources asynchronously or, better still, self-host the fonts and inline only the subset you need. Most out-of-the-box font plugins ship with synchronous loading because it's the safe default, not because it's the right one. Swapping a Google Fonts plugin for a self-hosted font with a font-display, swap declaration removes the third-party round-trip entirely. With icon libraries, the better approach is to load only the specific icons a page uses rather than the entire library, which is what most plugins fetch by default. None of this is complicated once you know where to look, but it does take a methodical eye across what your plugin stack is requesting on each page load. WooCommerce Add-Ons That Load on Non-Shop Pages WooCommerce itself is reasonably well-behaved about where it loads its scripts, but the ecosystem around it is far less careful. Extensions for wishlists, product reviews, currency switchers and dynamic pricing almost all enqueue their JavaScript and CSS globally by default. That means a visitor reading a blog post or landing on your homepage still downloads the full payload for features they cannot possibly use there. A currency switcher script that belongs on a product page has no business adding weight to your contact form. That extra load hits your Largest Contentful Paint and Interaction to Next Paint scores before the visitor has even seen a product. Conditional loading is usually the biggest single win A short block of PHP in your functions file checks whether the current page is a shop, product, cart or checkout page, and only registers the extension's assets there. For most WooCommerce sites carrying four or five add-ons, stripping those scripts from non-shop pages can shave several hundred milliseconds off Time to First Byte and LCP on the pages that actually drive traffic. It takes careful testing to confirm nothing breaks on edge cases, but the payoff is real. This is the kind of methodical, under-the-hood work that rarely shows up in a plugin's changelog, yet it changes what real visitors experience the moment they land on your site. Finding Which Plugin Is Actually Responsible The most reliable starting point is Chrome DevTools, specifically the Coverage tab. Open it via the three-dot menu, go to More Tools, then Coverage, and hit the record button while your page loads. What you get is a breakdown of every JavaScript and CSS file loaded on the page, with a column showing how much of each file ran. A plugin serving 400KB of JavaScript where 80 percent goes unused is a clear signal that something is adding far more than the page needs. That unused code still has to be downloaded, parsed and evaluated by the browser, and it shows up in your Largest Contentful Paint and Interaction to Next Paint scores before a single user clicks anything. Once you have suspects, WordPress plugins that load scripts on every page are the ones to isolate first using staged deactivation. Disable plugins in small batches, clear your cache, and re-run PageSpeed Insights after each round. It takes time, but it is the only way to be certain. Two plugins can each look fine individually while causing problems in combination. Query Monitor is worth installing alongside this process because it surfaces database queries, HTTP requests and script enqueues tied to specific plugins, giving you a second layer of evidence beyond raw file sizes. Between Coverage, Query Monitor and a methodical deactivation sequence, you can usually pin down the exact offender within an hour or two. ------------------------------------------------------------ # Why Bing’s Growing Market Share Belongs in Your SEO Plan Source: https://yorkshiredesign.co.uk/why-bings-growing-market-share-belongs-in-your-seo-plan/ Published: 2026-08-14 > Bing now handles roughly a third of all desktop searches in the UK, and with AI-powered answers baked into its results pages, that number is moving in one direction. Most site owners still treat it as an afterthought. That's a gap worth closing, because the technical signals Bing rewards are not exotic or expensive. In many cases, a site already optimised for Google is most of the way there. The Numbers Behind the Shift Bing holds roughly 27% of desktop search share in the United States, and in the UK it sits consistently above 7%. Those figures are not dramatic, but they are not trivial either. What is pushing them upward is the Copilot integration. Microsoft has embedded its AI assistant directly into Windows, Edge, and the Bing search results page itself. That means anyone using a Windows PC and running a default browser is already one keystroke away from a Bing-powered AI answer. Older professionals and corporate workers, groups that rarely change default browser settings, are now generating significant search volume without consciously choosing to use Bing at all. StatCounter and SimilarWeb both track this shift, and the desktop numbers in particular have been climbing steadily. Desktop matters because that is where higher-value commercial searches still happen, business software, financial services, B2B research, anything that involves a longer decision process before someone commits. If your audience skews toward 35 and above, or if you are targeting decision-makers in a professional context, the case for ignoring Bing starts to look thin. None of this repositions Bing as a Google rival overnight. What it does mean is that a meaningful slice of your potential audience is already there, and the AI-driven results they see are shaped by signals that reward the same fundamentals that good SEO has always rested on. Where Bing Reads a Page Differently to Google JavaScript and HTML structure Bing puts noticeably more weight on clean, well-structured HTML than Google does. Google has spent years building crawlers that can piece together a page even when the markup is messy or the content is buried inside JavaScript components. Bing is far less forgiving. If your key headings, body copy and navigation only exist after a client-side render fires, Bing's crawler often misses them entirely. A site that ranks well on Google while leaning heavily on a JavaScript framework can sit pages back on Bing for the same terms, not because the content is poor, but because Bing never quite saw it. Server-side rendering or a clean static HTML output removes that ambiguity for both engines, but it matters more urgently for Bing. Meta keywords still do something here Google stopped reading meta keywords years ago and is open about that. Bing still indexes them. They carry modest weight, but ignoring them means leaving a small, free signal on the table. A tightly written set of meta keywords that mirrors your actual page topic costs nothing to add and gives Bing one more clear signal about what the page covers. If you want to understand how Bing weighs on-page signals compared to off-page ones, the technical differences between Bing and Google's ranking approach are worth understanding before you adjust your template defaults. Heading hierarchy Bing responds well to a logical H1, H2, H3 hierarchy that reflects the page's actual topic. Skipping levels or using heading tags purely for visual styling tends to cost more on Bing than it does on Google. It is a small thing to fix and one of the faster wins available. What AI Answers in Bing Actually Do to Click-Through Bing's AI-generated summaries sit at the top of the results page and answer a reasonable number of queries before the user ever reaches a blue link. For simple factual questions, the click often does not happen. If your content is written to answer a straightforward "what is" or "how many" question, there is a real chance Bing surfaces a tidy summary and the reader moves on. Content built around thin definitions or quick lookups is doing less work than it used to. The formats that still pull traffic are the ones AI cannot compress neatly into a box. Step-by-step processes, opinionated comparisons, detailed worked examples. A user scanning a summary quickly realises the answer needs more than two sentences, and that is when they click. Pieces that combine a direct answer near the top with genuine depth further down tend to get the best of both outcomes, a shot at appearing in the AI summary, and a reason for the reader to click through for the full picture. If you want to understand how Bing's AI search reshapes organic traffic in more detail, the patterns are consistent enough that adjusting your content structure now makes sense rather than leaving it for later. The Bing Webmaster Tools Audit Most Sites Skip Most site owners connect Google Search Console and consider the job done. Bing Webmaster Tools sits there unclaimed, which is a shame because it surfaces diagnostic data from a completely separate crawl pipeline. Log in, verify your site, and the first thing to check is the crawl information report. Bing will show you pages it tried to reach but couldn't, pages it found but decided not to index, and the specific HTTP status codes it received along the way. Where Google Search Console sometimes groups issues vaguely, Bing tends to be more granular about why a URL was skipped. That level of detail is genuinely useful when you're chasing down a stubborn indexing problem that Google's tooling hasn't pinpointed. The backlink section is the other area most people miss. Bing pulls its own link graph independently, so you'll occasionally find referring domains there that don't appear in Google's data at all. Cross-referencing the two gives you a fuller picture of your site's authority profile than either tool provides alone. If you want to go deeper on the wider traffic cost of ignoring Bing's index, that's covered separately. Set up keyword tracking while you're there. It takes ten minutes and shows you exactly where Bing is ranking your pages, which rarely mirrors your Google positions. How Yorkshire Design Approaches a Dual-Engine SEO Build Good technical SEO has no allegiance to a particular search engine. Do it properly and both Google and Bing benefit from the same work. The practical workflow here takes real attention. Clean, well-structured HTML gives Bing's crawler something it can read without guessing. Structured data markup, applied to the right page types, feeds both engines the context they need to categorise content correctly. Canonical tags stop duplicate URLs from fragmenting a page's signals across two indexes at once. Page speed matters on Bing just as it does with Core Web Vitals on Google, and a slow-loading page loses ground regardless of which engine is assessing it. None of these are Google-specific fixes bolted onto an existing build. They are the standard a site should meet anyway, and meeting it properly covers both engines in one pass. The content side follows the same logic. Chasing volume rarely works, and it tends to cannibalise your own rankings rather than extend them. A smaller number of carefully chosen pages, each built around something your business genuinely does well, carries more weight with both engines than dozens of thin articles written to tick a keyword box. That is the approach taken here, and it is what keeps a site clean and readable rather than cluttered with pages that compete against each other. The One Audience Segment Bing Owns Outright Edge ships as the default browser on every Windows machine, and most people who use it never change the search engine. That single default setting puts Bing in front of a huge slice of the professional workforce, particularly anyone sitting at a company-issued laptop running Microsoft 365. Office workers opening a new tab between spreadsheets and emails are not actively choosing Bing, but they are searching on it. Add to that the older demographic who set up their PC years ago and stuck with whatever came installed, and you have a concentrated group of users that skews older, more senior, and often more purchase-ready than the average Google searcher chasing a quick answer on a phone. For B2B businesses, that overlap is hard to ignore. Decision-makers researching software, procurement teams comparing suppliers, senior professionals looking for services they'll actually pay for, these people are disproportionately represented in Bing's user base. If your target customer sits behind a desk rather than a smartphone screen, the cost of overlooking Bing's share of that traffic is a real one, not a theoretical risk. The audience is identifiable and reachable. That is reason enough to account for it. ------------------------------------------------------------ # 9 AI Automation Tasks Small Businesses Should Start With Source: https://yorkshiredesign.co.uk/9-ai-automation-tasks-small-businesses-should-start-with/ Published: 2026-08-14 > Most small businesses have the same problem when they look at AI automation, too many options, not enough clarity on where to actually begin. The tools are real. The time savings are real. But picking the wrong starting point means weeks of setup for something that barely touches your day. These nine tasks are the ones that tend to pay off fastest, not because they sound impressive, but because they handle the repetitive, low-creativity work that quietly eats hours every week. Answering the Same Customer Questions, Over and Over Most small businesses are already sitting on everything they need to automate a significant chunk of their inbound enquiries. They just haven't connected the dots yet. Think about the questions your inbox sees every week. Opening hours, pricing, turnaround times, whether you cover a certain area, what happens after someone places an order. The same handful of questions, arriving from different people, typed slightly differently each time. A well-configured AI response layer reads the intent behind each message and returns an accurate, friendly answer without anyone on your side lifting a finger. Businesses that set this up properly find it handles somewhere between 70% and 80% of routine inbound questions outright, leaving the more complex conversations for a human to pick up. The setup takes time to get right, particularly matching your existing FAQ content to the right triggers, but once it's running it works around the clock without a salary attached to it. The businesses that benefit most are those who already have the answers written down somewhere, even loosely. A FAQ page, a pinned post, an old email template. That existing content becomes the foundation, and the AI layer puts it to work at scale. Following Up on Enquiries You Never Got Round To Most small businesses lose work not because the lead was bad, but because life got in the way before the follow-up happened. Someone fills in your contact form on a Tuesday afternoon. You mean to reply that evening, then a client calls, an order comes in, and by Thursday that enquiry is buried under three other things. The person has already moved on and contacted someone else. An automated follow-up sequence in your ai automation workflow small business setup removes that gap entirely. The moment an enquiry lands, it triggers a timed response, then a second message two days later if there's no reply, then perhaps a short closing note after five days. The timing is consistent whether you're flat out or on a day off. The sequence doesn't need to feel robotic. A short, warm first reply that acknowledges what the person asked about, written once and reused, does the job far better than a late, rushed manual response ever would. That consistency is what converts more enquiries. Not chasing harder, just not dropping the thread in the first place. Turning One Piece of Content Into Several A recorded client call, a blog post, or even a rough script for a short video already holds far more usable material than most small businesses realise. An AI repurposing workflow takes that single source and pulls from it in several directions at once, a summary for your email newsletter, three or four social captions with different angles, a bullet-point FAQ for your website, and a short quote graphic for Instagram. The source content does the heavy lifting once, and the workflow distributes it rather than leaving it buried in a folder somewhere. That shift alone cuts the time spent staring at a blank page for every new platform. The practical setup is straightforward. You feed the transcript or draft into an AI tool with a clear prompt for each output type, and the tool returns rough versions you edit and publish. If you want to understand where this kind of content automation saves hours, the gains tend to stack up fastest when repurposing runs on a schedule rather than as a one-off task. Booking Calls and Appointments Without the Back-and-Forth Scheduling is one of those tasks that looks trivial until you add up how much time it takes. A single meeting can generate four or five emails before anyone's even on the call, proposing a time, waiting for a reply, finding it doesn't work, suggesting another slot, confirming, then sending a reminder. Connect a tool like Calendly or TidyCal to a simple AI-driven booking layer and that whole sequence disappears. The prospect picks a slot from your live availability, receives an automatic confirmation, gets a reminder the day before, and the event lands in both calendars without a single message from you. The real gain isn't the convenience. It's the mental load you stop carrying every time someone asks "what does your week look like?" Setup takes a few hours, not a few days. Once it's running, it runs without you. Pulling Weekly Reports Together Without Manual Effort Manual reporting eats an hour before you've noticed it's gone. You open your analytics platform, copy a few numbers into a spreadsheet, switch over to your sales tool, pull last week's figures, check your email stats, and then try to make sense of it all in a single document. An automated reporting workflow replaces that entire chain by connecting your tools directly, pulling the data on a set schedule, and producing a formatted summary without you touching anything. Set it up once, and every Monday morning the report simply exists. The key is picking four or five metrics that tell you how the week went, then building the workflow around those. Broad data pulls create noise. Focused ones create something you'll read. Writing First Drafts of Routine Business Documents Quotes, proposals, onboarding emails and service summaries all follow a predictable shape every single time. The opening sets context, the middle lists what is included and at what cost, and the close tells the client what happens next. Once you feed an AI tool that structure, along with your pricing, your service scope and a few bullet points about the client, it can produce a solid working draft in under a minute. That is useful for a small business owner who writes the same kind of proposal a dozen times a month, because the blank-page problem disappears. You go straight to editing rather than composing from scratch, which is where most of the time goes. If you want to see how this fits into a broader repeatable AI workflow for small businesses, the pattern is the same across most document types. Where AI still needs watching is anything that requires real judgement about a specific client relationship. Tone, sensitivity around price objections, knowing when a client needs reassurance rather than bullet points , that part stays human. Sorting and Routing Inbound Messages Most solo operators underestimate how much time disappears into reading messages and deciding what to do with them. An AI triage workflow reads each incoming email or contact form submission, classifies it by intent, and routes it to the right place before you've even opened your inbox. A refund request goes straight to the relevant folder. A new business enquiry gets flagged as high priority. A generic support question triggers an auto-reply with your FAQ link. The classification happens in seconds, on every message, without you touching it. The real gain compounds over weeks. Once you can trust that nothing urgent is sitting unread in a pile of noise, you stop checking your inbox compulsively. If you're curious where this kind of inbox triage sits alongside other small business time savings, it's consistently one of the first places the hours add up. The setup takes some thought at the start, but once the routing rules are dialled in, the system handles the sorting in the background every single day. Where to Start if You Have Under Two Hours If you are starting from scratch, the temptation is to map out every process you could possibly automate and then do nothing because it feels overwhelming. Pick one task instead. The best place to start is wherever you answer the same question repeatedly, because that pattern is exactly what AI handles well. A contact form that always triggers a follow-up email, a new enquiry that needs logging to a spreadsheet, a customer question that gets the same reply nine times out of ten. Any one of those is a real starting point, and two hours is enough to connect a tool like Make or Zapier to your inbox and have something working before the end of the day. Start with a single trigger and a single action. One thing fires, one thing happens. That is all you need to prove the concept to yourself. Once that first automation runs without you touching it, you will have a much clearer sense of where the real time is going. If you want a structured way to think about building your first AI workflow from the ground up, that broader framework is worth reading before you add a second layer. ------------------------------------------------------------ # Local Business Schema Markup: What to Add and What to Skip Source: https://yorkshiredesign.co.uk/local-business-schema-markup-what-to-add-and-what-to-skip/ Published: 2026-08-14 > Schema markup gets treated like a magic switch. Add it, rank better. That is not how it works. Google uses structured data to understand your site more clearly, and for local businesses, the right schema can earn you richer search results. But half the properties people add do nothing, and the wrong setup can quietly confuse rather than help. Here is what is actually worth your time. What Schema Markup Actually Does for a Local BusinessStructured data gives search engines a machine-readable version of information already on your page. For a local business, that means your address, phone number, opening hours, and business category. Google does not need schema to find this information. It reads your page either way.What schema does is remove ambiguity. Instead of Google inferring that a string of digits is probably a phone number, you tell it directly. That confidence powers features like the business panel in local search results and rich snippets showing your hours inside Google Maps.The Schema.org LocalBusiness type is the starting point. Everything branches from there.Which Properties to IncludeKeep the core tight. These are the fields Google consistently reads and uses for local results. @type , be specific. Use Plumber, Restaurant or LegalService rather than the generic LocalBusiness where a more precise type exists.name , your business name exactly as it appears across every other platform online. Consistency matters here.address , use PostalAddress with street, town, postcode and country. Match it to your Google Business Profile precisely.telephone , the number customers actually call. One number is enough.openingHoursSpecification , structured hours rather than a plain text string. This is what drives the open or closed display in search results.url , your canonical homepage URL.geo , latitude and longitude if you want to reinforce your precise location. If you host genuine customer reviews directly on your own site, aggregateRating is worth including. Google is strict on this. You can only mark up ratings you host yourself. Do not pull your Google or Trustpilot score and present it as your own data.What to Leave OutThis is where most implementations go wrong. Properties get added because they exist, not because they serve a purpose.Avoid marking up description with a keyword-heavy paragraph. Google does not use it for rich results, and it reads as an attempt to game something that schema simply cannot game.Skip sameAs unless your social profiles are well-maintained and consistent. Pointing Google at an abandoned Facebook page does not help. It creates a conflicting signal.Leave hasMap out entirely. Once your address and geo coordinates are in place, it adds nothing useful.Do not add schema for anything that is not on the page. If your contact details only appear in the footer, adding full service-area markup to a page that says nothing about those services is technically invalid. Google's own guidance is clear on this. Structured data should describe content the user can actually see.Why Content Has to Come FirstWhen you add local business schema to your website, it sits on top of your content, not beneath it. It cannot rescue a weak page. We have seen this play out on a local company site where an outside SEO firm produced hundreds of poorly targeted pages chasing fast rankings. The schema on those pages was fine. The content was not. Rankings dropped, and the site picked up a quality signal problem that took months to clear.Bad content is bad content. Marking it up with structured data only gives Google a clearer map to something it would rather not rank.Adding It Without Breaking ThingsJSON-LD is the format Google recommends, and it is the most straightforward to work with. Drop it into the <head> of the relevant page, or use a plugin that handles the output cleanly. On WordPress, choose a lightweight plugin that generates valid JSON-LD without bloating the page. Avoid plugins that inject dozens of schema types you never asked for.Validate everything with Google's Rich Results Test before you publish. Errors are not always fatal, but warnings about missing recommended fields are worth addressing if the field genuinely applies to your business.Check your Google Search Console for schema errors a few weeks after implementing. The Enhancements section shows whether Google has processed your markup and whether anything has been flagged. That feedback loop tells you far more than a one-time validation check ever will.What to ExpectDone properly, choosing to add local business schema to your website takes a few careful hours for a single location. That is a modest investment for a meaningful return. It is not a ranking shortcut, and it will not rescue a slow site or thin content. Think of it as tidying up the information Google already holds about your business. A clean signal beats a muddled one, and combined with solid fundamentals, it closes a gap that repays the effort. ------------------------------------------------------------ # Article Schema vs BlogPosting Schema: Does It Matter for SEO? Source: https://yorkshiredesign.co.uk/article-schema-vs-blogposting-schema-does-it-matter-for-seo/ Published: 2026-08-13 > BlogPosting is not a rival to Article schema. It is a child type of it, sitting one level down in the Schema.org hierarchy. That single fact changes how you should think about the choice. Most of the debate about which one to use misses the point entirely, because Google does not treat them as competing formats. What Google cares about is whether your structured data is accurate, complete, and matches what is actually on the page. What the Two Schema Types Are Both Article and BlogPosting come from Schema.org, the shared vocabulary that search engines use to read structured data. Article is the parent type. BlogPosting inherits everything from it and adds semantic precision for one specific kind of content, a post published in reverse-chronological order, typically on a blog, with a named author. Because BlogPosting extends Article rather than replacing it, every property you can attach to an Article, headline, author, datePublished, image, publisher, is equally valid on a BlogPosting. There is no field you lose by choosing one over the other. The decision is about semantic fit, not capability. How Google Reads Each One Google's structured data documentation groups Article and its subtypes together for rich result eligibility. A BlogPosting does not get treated differently from an Article when Google decides whether to show an author byline, a date, or an image in search results. The crawler is looking at the fields you have populated, not at which branch of the Schema.org tree you picked. Where the distinction does matter is in how accurately the type label describes the content. Google's systems are built to understand page context, and a mismatch between schema type and actual content is a signal that the markup was applied lazily. It is unlikely to cause a penalty, but it adds noise where there should be clarity. When BlogPosting Is the Cleaner Choice If you are writing a dated post on a blog, attributed to a named author, and it will appear in a feed ordered by date, BlogPosting is the semantically correct pick. The type tells Google's parsers exactly what they are looking at before they read a single field value. Practical signals that point to BlogPosting: The page is part of a blog or news feed with a visible published date A single, named human author is clearly attributed The content is time-specific or written in a first-person or editorial voice The post would look out of place if the date were removed For most business blogs and content marketing posts, BlogPosting is the right call and requires no further justification. When Article or a Tighter Subtype Fits Better Evergreen guides, long-form technical references, and formally structured how-to content often suit the broader Article type because they are not tied to a publication date in the way a blog post is. A comprehensive reference on, say, server configuration does not really belong in a chronological feed, and labelling it BlogPosting would be a stretch. Tighter subtypes to consider Schema.org also provides more specific options. NewsArticle fits content published by a journalistic outlet with a clear news hook. TechArticle works well for documentation and technical tutorials. If your content matches one of these precisely, using the specific type is better than defaulting to the generic Article. The logic throughout is the same, match the schema to what the content is, rather than reaching for the nearest familiar label. The Fields That Move the Needle The type declaration is table stakes. The fields you complete are where the real SEO work happens. Google uses a specific set of properties to generate rich result features, and leaving them empty means leaving that display real estate on the table. Fields Google uses for Article rich results, and what each one affects: Field What Google Does With It Priority headline Displays in the rich result title High author Powers author byline in search features High datePublished Shows freshness signals in results High image Required for Top Stories carousel eligibility High publisher Associates content with a known entity Medium A thinly populated BlogPosting with only a headline set will underperform a well-populated Article every time. Fill the fields properly, and the type label becomes secondary. Implementing This in WordPress Checking your current output Most WordPress SEO plugins, Yoast, Rank Math, and similar tools, auto-assign a schema type at the site level and let you override it on a per-post basis. Yoast defaults to Article for posts unless you manually switch it. Rank Math gives you a dropdown in the post sidebar where you can select BlogPosting without touching any code. To check what your site is currently outputting, paste a post URL into Google's Rich Results Test and look at the JSON-LD block for the @type value. If it says Article but you are running a blog with dated posts and named authors, switching to BlogPosting is a five-second change in your plugin settings that makes the markup more honest. Beyond the plugin defaults For sites that need a more considered approach across multiple content types, the decisions around what schema properties to include and what to leave out are worth working through carefully rather than just accepting whatever the plugin outputs. We'd argue that pumping out schema-decorated content at volume rarely helps. A handful of well-marked-up pages on topics you genuinely own will do more than a hundred thinly populated posts where the structured data is just another checkbox ticked on the way to publish. So does the Article vs BlogPosting choice matter? Less than most people think. Does getting the fields right matter? Considerably more than most people bother with. Which of those two things is your site currently neglecting? ------------------------------------------------------------ # Content Refresh SEO: How to Decide What to Update First Source: https://yorkshiredesign.co.uk/content-refresh-seo-how-to-decide-what-to-update-first/ Published: 2026-08-13 > Every site hits the same fork in the road. You have limited time, and you have to choose between updating a post that used to rank and writing something entirely new. Both can drive traffic. Both can waste your time. The difference is knowing which option the data actually supports. This checklist gives you a clear process for making that call, based on signals you can read from Search Console today, not gut feeling. Why Google Rewards Refreshed Content Google's Quality Rater Guidelines place real weight on accuracy and trustworthiness. A page that was thorough a year ago can slip once its information falls out of date. Freshness signals tell Google a page is still being maintained, and that matters for updating content for SEO performance over the long term. An existing page already carries backlinks, crawl history, and topical authority built up over time. A brand-new page starts with none of that. When you refresh a post sitting at position six or seven, you are working with a real asset. Writing from scratch means competing against pages that have years of authority behind them. The compounding effect is real. A refreshed page moving from position eight to position three on a mid-volume keyword can double or triple organic clicks without a single new link being built. How to Spot a Page That Needs Refreshing Open Search Console and filter by page. Look for these patterns, individually or together, as clear signals that a refresh is overdue. Declining impressions, stable position. The page still ranks where it did, but fewer people are searching the terms it targets. That usually means the subtopics on the page no longer match what searchers want. Stuck on page two with no movement. A page sitting between positions eleven and twenty for several months is not climbing because something on it is weaker than the pages above it. That gap is almost always fixable through updating content rather than publishing something new. Outdated examples or subtopics. If the page references tools, prices, or processes that have since changed, Google's quality signals will flag it. A reader who bounces immediately because the information looks stale sends a clear engagement signal back to the algorithm. Any one of these signals is enough to prioritise a refresh over creating something new. When New Content Actually Wins Some situations call for a new page entirely. New content wins when you are targeting genuinely unclaimed keyword territory, where no page on your site has ever touched the topic. Launching a new service is another clear case. You cannot retrofit a post about web design to rank for AI automation. The intent is different, the content structure is different, and Google reads them as separate topics. No amount of refreshing bridges that gap. New content also wins when competitors are filling a topical gap and your site has nothing targeting those queries. If a cluster of related searches exists and you have zero pages covering them, writing fresh content is the only option. See our breakdown of long-form versus short posts to decide what format that new content should take. Auditing Your Existing Posts Before Writing Anything New Before you open a blank document, run this four-step check on every post you are considering. Search Console impressions. Pull the last three months. Any page with over 200 impressions and under a 3% click-through rate has a title or meta description problem worth fixing first. Current ranking position. Pages between positions four and fifteen are your highest-priority refresh candidates. They are close enough to the top to move with relatively little effort. Word count versus top-ranking competitors. Open the top three results for your target keyword and count their words. If your page is shorter and thinner on subtopics, a content refresh is the fastest route to parity. People Also Ask coverage. Search the keyword and note which PAA questions your page does not answer. Each unanswered question is a missed intent signal. For a closer look at how technical gaps compound these issues, our technical SEO audit checklist covers the structural fixes that support any content work. What a Proper Content Refresh Actually Involves Changing the published date is not a refresh. Google is not fooled by a timestamp update on otherwise unchanged content. A proper refresh rewrites the introduction to match current search intent, updates examples that have aged badly, and adds sections covering PAA questions the original post missed. It also means reviewing internal links and adding anchors to newer posts published since the original went live. Our post on content writing for SEO explains why matching intent at the brief stage prevents most of these problems from accumulating in the first place. Image compression matters too. If the post was written a few years ago and images were never optimised, oversized files drag Core Web Vitals scores down and hurt the page's ability to rank. That kind of unseen work takes real time, but it pays off in the rankings. Building a Refresh Schedule That Compounds Over Time A quarterly review system beats ad hoc decisions every time. Divide your posts into three tiers based on Search Console performance over the previous ninety days. Tier one posts hold positions one to five with stable or growing impressions. Leave them alone unless a PAA gap appears. Tier two posts sit between positions six and twenty with declining click-through rates. These are your primary targets for updating content for SEO gains each quarter. Tier three posts have under fifty impressions and no movement. Assess whether they should be merged into a stronger page or set aside as low-priority work. Review the tiers every quarter, move posts between them as the data shifts, and always refresh a tier-two page before commissioning new content on a related topic. That discipline stops content debt from building and keeps your strongest pages climbing rather than drifting. ------------------------------------------------------------ # Kinsta WordPress Hosting: What You Get and Who It Suits Source: https://yorkshiredesign.co.uk/kinsta-wordpress-hosting-what-you-get-and-who-it-suits/ Published: 2026-08-12 > Kinsta sits at the pricier end of the managed WordPress hosting market, and the pitch is compelling , Google Cloud infrastructure, fast load times, a clean dashboard. But compelling marketing and a genuinely good product are not always the same thing. Before you commit to a monthly bill that starts well above shared hosting, it's worth understanding exactly what Kinsta gives you, where it earns that price, and which types of site are probably better off elsewhere. What Kinsta Is Under the Hood Kinsta runs on Google Cloud Platform, and that distinction matters more than the marketing makes it sound. Most shared hosting stacks dozens or hundreds of sites onto a single physical server. One site has a traffic spike, runs a badly coded plugin, or gets hit by a bot crawl, and every other site on that box feels it. Kinsta does the opposite. Each site lives inside its own LXD container, a lightweight isolated environment with its own allocated CPU, memory and file system. Nothing leaks between containers. If the site next to yours starts chewing through resources, your site carries on as normal. That isolation is the real reason Kinsta's stability tends to hold up under load, not just because the underlying infrastructure is Google Cloud, but because the architecture prevents the neighbour problem from ever becoming yours. In practical terms, your WordPress site's raw server response time starts from a cleaner baseline than it would on a conventional shared stack. Container isolation also makes it easier to diagnose performance issues when they do appear, because you know the problem is your code and your traffic, not an invisible neighbour. Anyone who has spent time chasing an intermittent server slowdown that turned out to be someone else's runaway process will recognise exactly why that matters. The Performance Numbers What the infrastructure delivers Kinsta's infrastructure does move the needle on raw server speed. Time to First Byte on a well-configured Kinsta site typically sits well under 200ms, and the built-in full-page cache handles that cleanly without needing a separate caching plugin muddying the stack. The CDN, powered by Cloudflare, serves static assets from edge nodes close to the visitor, which cuts latency on images, scripts and fonts without you touching a config file. For a straightforward brochure site or a lean blog, those gains show up clearly in Core Web Vitals scores after the first few weeks of real traffic data settling in. That's where Kinsta earns its price tag. The server is doing what it promises. What the hosting cannot fix Where people come unstuck is expecting the hosting to compensate for problems the hosting cannot fix. A theme loading 4MB of unoptimised CSS, a page builder stacking render-blocking scripts, images shipped at three times the dimensions they're displayed at. None of that disappears because the server is fast. TTFB can be excellent and Largest Contentful Paint still fails. Good hosting removes one set of variables. The rest still needs attention. What the Dashboard Gives You Day-to-Day MyKinsta is clean and quick to navigate. The staging environment is one click away from your live site, which sounds like a small thing until you're testing a plugin update on a client build at 11pm and you need to push changes without touching production. PHP version control sits right inside the site settings, so switching from 8.1 to 8.2 takes seconds rather than a support ticket. One-click restores pull from automated backups that run daily, and you can trigger a manual backup before any significant change. That combination of staging plus quick restores removes a lot of the anxiety that comes with maintaining a live site over time. The analytics tab is where MyKinsta earns its keep for anyone who cares about performance. You get CDN usage, top requests, cache hit rates, and a breakdown of PHP memory. It's not Google Analytics, but it tells you the things a hosting dashboard should tell you. For anyone managing multiple WordPress sites, the real convenience is having all of them visible in a single account view without the usual juggling between cPanel logins. You can see at a glance which sites have recent backups, which PHP versions are running, and whether your managed WordPress hosting is doing what you're paying for. Nothing is buried three menus deep. The interface is built around the tasks you do regularly, not the tasks that make a features page look impressive. Who Gets Real Value From Kinsta Kinsta suits sites where performance costs money when it slips. An established business taking enquiries through its website cannot afford the kind of response-time spikes that shared hosting produces under load. A WooCommerce store processing orders during a busy period needs consistent server capacity, not a host that throttles resources when traffic jumps. These are the scenarios where Kinsta's container-based infrastructure earns its price. Each site runs in isolation, so a traffic surge on one account does not bleed into yours. That separation matters far more than it sounds when your checkout page is involved. The same logic applies to any site with a predictable content-publishing schedule or a membership area where logged-in users hit the server directly, bypassing cached pages entirely. Agencies managing client sites also find the account structure useful. Having multiple sites under one dashboard, each with its own staging environment and granular user permissions, removes the administrative overhead that separate hosting accounts create. Where Kinsta makes less sense is for a simple brochure site with modest traffic and no ecommerce. The infrastructure is built for sites that need it, and if yours does not, you are paying for headroom you will never use. Understanding what managed WordPress hosting costs cover makes that call much easier. Where Kinsta Is Overkill Kinsta is a serious hosting platform with a price tag to match. For plenty of WordPress sites, that seriousness is unnecessary. A five-page brochure site for a local trade business, a new blog finding its feet with a few hundred visitors a month, a portfolio site that has not changed in six months. None of these need Google Cloud's premium tier infrastructure or a staging environment with push-to-live controls. They need a clean, reliable server and someone who has kept WordPress and PHP properly updated. A well-configured managed host like SiteGround or even a quality VPS running Cloudflare in front of it will handle that load without breaking a sweat, at a fraction of Kinsta's entry price. The real cost difference matters. Kinsta's starter plan sits around the £30 per month mark, where a decent alternative comes in at under £10. Over a year, that gap is hard to justify when your traffic analytics would fit on a Post-it note. If a site is already performing well on managed WordPress hosting that costs less, moving to Kinsta for the badge of it makes no financial sense. Spend the difference on content or SEO work that moves the needle. The Price and What You Are Paying For How the billing works in practice Kinsta's entry plan starts at around $35 per month, and that number needs unpacking before you commit. The plan includes a single WordPress install with a monthly visit limit, typically set at 25,000 visits. Go over that ceiling and overage charges kick in automatically, which catches small businesses out more often than you would expect, particularly around seasonal traffic spikes. Add-ons like premium staging environments, extra PHP workers, or additional site migrations stack on top, so the headline price rarely reflects what you end up paying by month three. The renewal cost stays consistent at least, which is more than can be said for some hosts where the introductory rate is half what you pay from year two onwards. We've moved clients off providers that worked that way. GoDaddy being one that combined slow server performance with a tangle of unnecessary add-ons and renewal prices that crept up quietly. Whether it stacks up For a small business running steady, modest traffic, Kinsta's pricing is defensible. The question is whether the infrastructure justifies the gap over budget shared hosting, and the honest answer is that it often does if you factor in what you're not paying for separately, CDN, automated backups, and a usable staging environment. If you want a full breakdown of what each tier covers, our managed WordPress hosting pricing breakdown runs through the tiers in plain terms. Where Kinsta earns its cost is in consistency. The price is the price. ------------------------------------------------------------ # How Small Businesses Can Build an AI Workflow Without a Tech Team Source: https://yorkshiredesign.co.uk/how-small-businesses-can-build-an-ai-workflow-without-a-tech-team/ Published: 2026-08-12 > Most small business owners looking at AI automation hit the same wall. The tools look promising, the demos are polished, but the moment you try to wire something together yourself it falls apart. Nobody's got a tech team to hand. Nobody wants to spend three weeks reading documentation. The good news is that a working AI workflow doesn't need either. What it needs is the right starting point and a clear sense of what you're actually trying to fix. Start With the Problem, Not the Tool Picking a tool first is the single most common mistake. People sign up for something impressive, then spend weeks trying to justify it. The better approach is almost embarrassingly straightforward. Write down every task you did last week that felt like a copy-paste job. Answering the same enquiry with a slightly different name. Pulling numbers from a spreadsheet into a report. Chasing the same invoice at the same point in every project. Moving a confirmed booking from one system into another. These tasks share a common shape, a fixed trigger, a predictable set of steps, and an outcome that rarely changes. That shape is exactly what automation handles well. Once you spot it, the right tool becomes obvious, because you are matching a solution to a defined problem rather than guessing at use cases for software you have already paid for. Start with one task only. Not three, not a whole department. A single repetitive process you can describe in two sentences is far more useful than a grand automation strategy that never gets off the ground. Customer enquiry routing, appointment reminders, and follow-up emails are good starting points because the trigger and the outcome are clear from the beginning. Once that first process runs without you touching it, you will have a much clearer sense of where automation earns its keep and where it does not. What a Basic AI Workflow Looks Like Strip the buzzwords away and any AI workflow comes down to three things. Something happens, the AI does something useful with it, and the result goes where it needs to go. That structure holds whether you are running a plumbing firm or a small e-commerce shop. A trigger fires the process, an AI action processes the information, and an output lands somewhere actionable. The trigger might be a customer filling in a contact form at 11pm. The AI reads the message, pulls out the key details, and drafts a short summary. That summary then gets routed to the right inbox, labelled by urgency, and a holding reply goes back to the customer automatically. Nobody touched it. Nobody had to read a rambling paragraph at midnight and decide whether it was a sales lead or a complaint. That is not a hypothetical setup reserved for businesses with a developer on staff. Tools like Zapier and Make can wire those steps together without a single line of code, using an AI layer such as OpenAI's API to handle the language processing in the middle. What most small business owners miss is that a well-chosen starting point for AI workflow automation does not need to be ambitious. Pick the one task that eats the most repetitive time each week, map those three steps around it, and prove the concept before adding anything else. A single working workflow that saves an hour a day is more useful than a complicated system that never quite gets finished. Picking the Right Tools Without Getting Lost Check what you already have There are dozens of no-code automation platforms out there, and most of them will tell you they can do everything. Some can. The question is whether you need everything, or whether you need one thing done reliably. Before you sign up for anything new, check what your existing tools already do. Gmail, HubSpot, Mailchimp, Typeform, and most CRMs have native automation baked in now, and connecting them to a lightweight tool like Make or Zapier is far lower friction than rebuilding your stack from scratch. That is usually the right starting point, not a shiny new platform with a free trial and a steep learning curve hiding underneath it. Cheap is not always cheap The cheapest option nearly always costs more in hours lost. A platform that saves £20 a month but breaks every time a form field changes, or needs a developer to adjust a single trigger, is not a saving. When evaluating options, think about the practical steps for building a small business AI workflow before committing to a monthly subscription. Look for a platform that connects to the tools you already use without custom code, has clear error logging so you know when something breaks, and is honest about what you get at the entry tier. Avoid anything that buries its core features behind an enterprise plan or charges per automation run in a way that punishes volume. A focused setup that handles two or three tasks well is far more useful than a sprawling one nobody on your team understands. How to Test Before You Commit Run a quiet pilot first Before rolling out any AI workflow, pick one small, self-contained task and run it alongside your existing process for two to four weeks. Not instead of it. Alongside it. That way, if the AI gets it wrong, nothing breaks and no customer notices. A good candidate is something repetitive, low-stakes and easy to measure, routing support emails into categories, drafting first-pass social copy, or summarising inbound enquiries before they reach you. Run both the manual and the automated version, then compare the outputs side by side at the end of the pilot. A good result means the AI version is saving you real time, producing output you would use with minor edits, and not introducing errors you have to chase down. A bad result is subtler. The output looks fine at a glance but consistently needs heavy rewriting, or it creates a new admin task you had not anticipated. Fix the process before you automate it The mistake that catches most small businesses out is automating a process that was already broken. If your enquiry handling is inconsistent when done manually, an AI layer just produces inconsistent output faster. Fix the underlying process first, even if that means writing a short checklist or template before you touch any tool. If you are not sure where a low-risk pilot fits within a broader plan, building a structured starting point for AI automation is a good thing to map out before you run any test. When to Bring in Outside Help DIY automation tools are useful up to a point. Past that point, they start eating time you do not have. The signal to watch for is not a single breaking moment. It is a slow accumulation. You have connected three or four tools, something breaks every other week, and fixing it takes half a day you had not budgeted. Or you have hit a task that matters, syncing order data between your CRM and your fulfilment system, for instance, and the no-code platforms you have tried either cannot quite do it or require a workaround so fragile it fails the first time an edge case appears. At that stage, the hours spent troubleshooting, reading forum threads, and rebuilding broken flows are costing more than bringing in someone who has already solved the same problem. That calculation shifts faster than most people expect, particularly for small businesses trying to stretch an automation budget without wasting it on trial and error. When you do look for outside help, ask whether they build automation or just configure someone else's platform. There is a real difference between a partner who understands the logic underneath a workflow and one who drags connectors around a visual editor and hands you the bill. Yorkshire Design works at the technical layer, not the surface one. No account managers, no overhead passed on in the day rate, just someone who knows where things tend to go wrong and how to build around that from the start. ------------------------------------------------------------ # How Content Teams Can Use AI Automation to Publish Faster Source: https://yorkshiredesign.co.uk/how-content-teams-can-use-ai-automation-to-publish-faster/ Published: 2026-08-12 > Most content teams don't have a writing problem. They have a pipeline problem. The article gets written, then it sits waiting for someone to format it, resize the images, add the meta description, schedule it, and cross-post it somewhere else. That gap between 'done' and 'published' is where AI automation does its best work, and it's also where most teams have never thought to look. The Myth That AI Just Writes Things for You Walk into most conversations about AI and content, and within five minutes someone will describe a chatbot producing a finished article. That image has taken hold, and it's also the least interesting thing AI does for a content team. The real time drain in content production isn't the writing. It's everything wrapped around it. Pulling a brief together from a scattered Slack thread. Checking which keywords a piece should target. Resizing images, writing alt text, filling in meta descriptions, scheduling the post, then copying a summary across to three different channels. A competent writer might spend forty minutes on a draft and another two hours on all of that surrounding admin. Nobody budgets for those two hours because nobody sees them as a single problem. AI handles that layer far better than it handles creative prose, because those tasks are repetitive and rule-based, following the same pattern every single time, which is exactly what automation is built for. Reframing what AI actually does changes which tools you reach for and how you measure success. Go in expecting it to write your best work and you'll be disappointed, probably rightly. Go in expecting it to handle the mechanical steps that pad out every content workflow and you'll find meaningful time savings fast. The writing stays yours. The scaffolding around it doesn't have to. Where the Pipeline Actually Breaks Down Most content teams don't have a writing problem. The draft gets done. What kills the schedule is everything that comes after. Someone has to resize and compress the hero image, write the alt text, and drop it into the post. Someone else has to fill in the meta title and description, check the slug, set the canonical, and pick the right category. Then there's internal linking, which almost always gets done in a hurry or skipped entirely because nobody has time to cross-reference fifty other posts. By the time a piece of content is ready to schedule, four or five people have touched it, each one waiting on the person before them. That handoff chain is where time disappears. The frustrating part is that none of those individual tasks are difficult. They're just slow and repetitive when you do them manually for every single post. Scheduling is its own trap. A post sits at 'ready to publish' for three days because the person who owns the calendar is in meetings, or the publishing slot hasn't been agreed, or it's waiting on a social caption that hasn't been written yet. If any of this sounds familiar, the bottleneck isn't your writers. It's the content publishing workflow itself, and that's exactly where AI automation does its most useful work. What Automation Handles Well The repetitive work nobody wants to own Writing a post takes an hour. Then come the tags, the category selection, the excerpt, the alt text on every image, and the three slightly different social captions for LinkedIn, Facebook and X, before finally scheduling across time zones. None of that requires editorial judgement, but it eats time all the same. This is where structured AI automation workflows earn their place, handling the repetitive, rules-based work so the writer can move straight on to the next piece. Categorisation, tagging, and metadata Categorisation and tagging are a good example. A well-prompted model reads the finished article, maps its themes against your taxonomy, and assigns tags consistently. That's something a busy team rarely manages manually at scale. Excerpt generation, alt text drafts, and caption variants sit in the same bracket. These are not tasks where creativity is the deciding factor. They are tasks where accuracy, tone-matching, and simply getting them done at all are what matter. AI handles those conditions well. The output still needs a human eye before it goes live, but the difference is that you're reviewing a first draft rather than writing from nothing, and that shift alone saves a meaningful chunk of time across a week of publishing. Where Human Judgement Has to Stay Tone drift The problems with unsupervised automation are specific and repeatable. Tone drift is the one most teams notice last, because it creeps in gradually. An AI writing tool trained on a general corpus will, over dozens of outputs, sand down the edges that make a brand's voice distinctive, replacing specific opinions with cautious generalities. Factual errors and link placement Factual errors in summaries are a sharper risk. Ask an AI to condense a technical article and it will confidently paraphrase a statistic, attribute a claim to the wrong source, or invert a comparison. The output reads fluently and passes a quick skim, which is precisely why it slips through. Internal links placed without context are a related problem. A tool that slots links in automatically often anchors them to vague phrases that tell neither the reader nor a search engine what sits on the other side. If you have read much about the difference between AI content that ranks and content that just exists, these patterns will be familiar. None of this is a reason to pull back from automation. It is a reason to wire a human check into the workflow at the right point, after generation but before publication. A short editorial pass covering tone, facts and link context takes ten minutes per piece. That time is negligible against the output volume automation makes possible, and it is the step that keeps the whole system trustworthy. Building a Workflow That Holds Under Pressure Why most pipelines fail Most automated content pipelines fail for the same reason. They were built around a tool, not a process. The three layers that matter A pipeline that holds up under real publishing pressure has three layers working together. The first is a trigger, something that fires the chain reliably, whether that's a scheduled time, a form submission, a CMS status change, or an external event like a product going live. The second is a set of conditions that route the content correctly, checking word count thresholds, flagging missing metadata, or pausing when a human review is required. The third is a fallback, a defined behaviour for when something upstream breaks. Without that fallback layer, one bad API response or an empty field from a content source can take down the whole run without anyone noticing until a publish slot is missed. Teams that automate content publishing without breaking their workflow spend most of their setup time on these edge cases, not on the happy path. Treating AI automation for content teams as an engineering problem rather than a software subscription changes what questions you ask at the start. You stop asking "which tool does this?" and start asking "what breaks first, and what happens when it does?" That shift in thinking is where durable pipelines begin. Is AI Content Automation Worth the Setup Time? The honest answer is that it depends entirely on how much you publish. Setting up a proper AI-assisted content workflow takes real time, sometimes several days of testing prompts, connecting tools, and ironing out the edge cases where automation produces something unusable. If a workflow saves two hours per post but you only publish twice a month, you'll be waiting months before the setup time pays for itself. At four posts a month, that same investment starts to look sensible within six to eight weeks. At ten or more, it becomes one of the better decisions a content team can make. The other variable is consistency. Automation rewards teams who publish on a predictable schedule because the time saving compounds across every post, every week. A team that publishes sporadically gets patchy returns from the same setup. So before committing the hours, be honest about your actual output, not your intended output. If the volume is genuinely there, the case for investing in automation is strong. If it isn't, a lighter approach, perhaps templating and prompt libraries rather than full pipeline automation, will serve you better without the overhead. ------------------------------------------------------------ # Writing Your Own Website Content: Where Most Go Wrong Source: https://yorkshiredesign.co.uk/writing-your-own-website-content-where-most-go-wrong/ Published: 2026-08-11 > Most business owners sit down to write their website content with good intentions and end up with a page that reads like a CV. It talks about them, their history, their passion. The person visiting the site just wants to know if you can fix their problem. That gap, between what you want to say and what your visitor needs to read, is where most self-written websites quietly fall apart. You Are Not the Audience Most business owners sit down to write their website and naturally start with themselves. Their story, their qualifications, how long they've been trading. It's understandable, but it's the wrong starting point. The person landing on your page isn't there to read your biography. They arrived with a problem, a question, or a job they need done, and they're scanning quickly to find out whether you can help them. If the first thing they read is three paragraphs about how you founded the business in 2009 and have a diploma on the wall, they've already started looking elsewhere. The fix is straightforward once you see it. Write the page as though you're answering the reader's question out loud. What are they worried about? What outcome do they want? Lead with that, and your credentials become supporting evidence rather than the main event. A plumber's homepage that opens with "Burst pipe? We're usually on-site within the hour" converts far better than one that opens with "Family-run business serving the area for 30 years." Flipping that lens changes how almost every sentence reads. It changes the headline, the first paragraph, even the call to action. At Yorkshire Design, this is one of the most consistent gaps we see when businesses write their own copy. Not a lack of information, but a mismatch in whose perspective is driving the page. What Does 'Writing for SEO' Mean? Most business owners hear "SEO" and picture something technical happening in a dashboard somewhere, not the words on the page. But a big part of how Google decides what a page is about comes down to plain language. The phrases you use, the questions you answer, whether the structure makes the logic easy to follow. Search engines are, at their core, reading comprehension tools. They scan a page the way a careful reader would, looking for the main topic, the supporting points, and whether the content addresses what someone typed into the search bar. So what makes a page rank is usually simpler than people assume. It answers a real question, clearly, in the words a real person would use to ask it. The mistake most owners make is lurching to one extreme or the other. They either write as if Google doesn't exist at all, producing copy that reads beautifully but never quite addresses what anyone searches for, or they repeat a phrase so many times the page starts to read like a chant. Neither works. The practical middle ground is thinking about how your customers describe their problem, then writing a sentence that answers it naturally. If someone searches "how much does a kitchen fitter cost in Leeds," a page that contains that sentence, in plain English, already has a head start. Structure matters just as much as the words themselves. Break a long topic into sections with clear headings and Google can follow the logic. One idea per section, headings that say what the section is about, paragraphs that stay on topic. That's the whole game. The Structure That Most Service Pages Get Backwards The pattern is so common it barely registers. A service page opens with the business name, a founding year, maybe a line about being family-run or locally trusted, then a loose paragraph explaining what the company broadly does. By the time the page gets to anything useful, a good chunk of visitors have already left. The problem is not the content itself. It's the order. Visitors arrive with a specific question in their head, and if the first thing they read does not answer it, they hit the back button. That question is almost always the same one, can this person help me with my specific problem? Write for a scanning eye, not a reading one A visitor's attention moves down the page in quick passes before they commit to reading anything carefully. If your opening paragraph leads with your name and your story, you are asking them to care about you before you have given them any reason to. The order that holds attention is blunt. What you do. Who it is for. What happens next if they want it. Open with the outcome you provide, name the type of person you provide it for, and close the section with a clear next step. That structure maps onto how attention moves in practice, from "is this relevant?" to "is this for me?" to "what do I do now?" That progression, in that order, is what content written for service businesses tends to get right when it converts. Proofreading Is Not Editing Most business owners run a spell-check, scan for obvious typos, and consider the job done. That is proofreading. Editing is a different question entirely, and it is the one most people skip. A real editorial pass asks whether each sentence is earning its place. Does it tell the reader something they need to know, or is it just occupying space? A paragraph that opens with "We are a family-run business with over 20 years of experience" might be grammatically fine, but if it says nothing about what the reader gets from working with you, it is filler dressed up as content. That is the kind of thing a proper edit catches, and a spell-check never will. The question to ask of every paragraph is blunt. If you removed it entirely, would the reader miss anything that helps them decide? If the answer is no, cut it. Good content writing for service businesses is almost always shorter after editing, not longer. The words that survive that process are the ones that do some work. When to Write It Yourself Nobody knows your business like you do. That is both your biggest advantage and, for website copy, your biggest blind spot. If you run a niche trade or a specialist service, you carry knowledge that a professional copywriter would spend days trying to absorb before writing a single sentence. That depth shows in the copy when you use it well. An independent surveyor explaining what to look for in a Victorian terrace, or a nutritionist writing about the specific conditions they treat, brings a credibility that generic hired-in text rarely matches. Where DIY content earns its keep The cases where writing your own copy makes sense are usually the ones where the subject matter is technical, specific, or tied to personal experience. A short bio, an FAQ built from the questions clients actually ask, a breakdown of your own process. These are all areas where you are the most qualified person in the room, and a professional writer working on copy for service businesses will often tell you the same thing. The trouble starts when familiarity breeds assumption. Business owners tend to write for people who already understand their industry, skipping the context a first-time visitor needs. They bury the most important point three paragraphs down. They write how they talk in person rather than how copy needs to read on screen. Hiring a writer does not compensate for that gap in every case, but where your pages need to convert strangers rather than reassure existing clients, the investment in professional content usually pays back faster than people expect. A Practical Starting Point for Your Next Page Before you write a single word, answer this question honestly. What does the person reading this page actually want to know? Not what you want to tell them, not what makes your business sound impressive, but what they typed into Google and what they are hoping to find. That one question changes everything. Once you have a clear answer, the page almost structures itself. A service page needs four things to do its job. A plain statement of what you offer and who it suits. A short explanation of how you work. Some evidence that you can be trusted, a result, a client note, a specific example. And a clear next step. Those four elements, in roughly that order, give a reader enough to make a decision. Skip one and the page feels incomplete in a way most visitors cannot name but definitely feel. A draft is ready when you can read it aloud without stumbling and a stranger could tell you, in one sentence, what the page is about. If that sounds straightforward but you keep staring at a blank screen, our content writing for service businesses takes the whole job off your plate, written by someone who understands both search engines and plain English. ------------------------------------------------------------ # WordPress Child Themes Explained: Why Skipping One Breaks Your Site Source: https://yorkshiredesign.co.uk/wordpress-child-themes-explained-why-skipping-one-breaks-your-site/ Published: 2026-08-10 > Make one customisation directly inside a WordPress theme and update that theme a week later. Everything you changed is gone. No warning, no backup prompt, just a blank slate where your tweaks used to be. A WordPress child theme stops that from happening. It is a thin wrapper that sits on top of your main theme, holding your changes safely while the parent theme updates underneath. Simple idea, but skipping it causes more avoidable damage than almost anything else in WordPress development. What a Parent Theme Actually Does A parent theme is the complete foundation of your WordPress site. Every file that controls how your pages look and behave, from the header layout to the font choices to the way posts are structured, lives inside it. Think of it as the engine beneath the bonnet. You can see the bodywork just fine from the outside, but the parent theme is doing the real work underneath. It holds the PHP templates that decide how different page types are rendered, the CSS that handles your visual styling, and the functions.php file that registers menus, widget areas, and all the other structural pieces WordPress needs to run properly. When a theme developer releases an update, usually to patch a security flaw or fix a compatibility issue with a newer version of PHP, those files get rewritten. Any edits you made directly inside the parent theme get wiped out in the process, cleanly and completely, with no recovery option. This is the core problem that trips people up. Editing a parent theme directly feels perfectly fine on day one. The changes show up, everything looks right, and there is no warning anywhere telling you what you have just put at risk. The danger only becomes obvious the moment an update runs. That is exactly the situation a child theme exists to prevent. How a Child Theme Works WordPress loads a child theme in a specific order. It checks the child theme folder first, and if it finds the file it needs, that is the version it uses. If it does not find one, it falls back to the parent theme automatically. That single mechanism is what makes the whole thing useful. You can copy one template file into your child theme, edit it, and WordPress picks up your version without touching anything else in the parent. The parent theme keeps its full file structure intact, so when the theme developer releases an update, your modified files sit safely in a separate folder and are never overwritten. Everything you have not touched continues to pull straight from the parent. Styles work slightly differently. WordPress loads the parent stylesheet first, then layers the child theme's stylesheet on top, so your CSS rules take precedence. You only write what you want to change, not a full stylesheet from scratch. For anyone who has ever spent an afternoon rebuilding customisations after a theme update wiped them out, this is the part that makes a child theme non-negotiable. The plugins that load extra CSS can also compound here if the load order is wrong, but with a properly set-up child theme the cascade stays predictable. Put simply, the child theme borrows everything and owns nothing it has not deliberately claimed. Your changes live in one clean, separate place. What Happens When You Skip the Child Theme The pattern plays out the same way every time. Someone installs a theme, spots something they want to change, and edits the parent theme's files directly. Maybe it's a tweak to the header, a font size buried in the stylesheet, or a layout adjustment in a template file. The changes look fine. The site looks fine. Then the theme developer releases an update, and WordPress applies it overnight. Every file that was touched gets overwritten, because that is exactly what an update does, it replaces the theme's files with clean copies from the developer's package. The customisations are gone, with no warning and no recovery option unless there's a recent backup specifically capturing those edits. That's the real cost. Not just lost code, but lost time rebuilding something from memory, or explaining to a client why the site looks different this morning. The rebuild is rarely quick. If the changes were well-documented or version-controlled, a developer might recover them in an hour. More often they weren't, and what felt like a modest customisation turns out to be spread across four or five files with no clear record of what changed or why. A properly structured child theme keeps all of that work separate from the parent entirely, so updates run clean and nothing you've built gets touched. The Files That Actually Matter Inside a Child Theme A child theme only needs two files to exist: style.css and functions.php. The style.css file is not really a stylesheet in the traditional sense, at least not at first. Its job is to carry the header comment block that tells WordPress which parent theme to inherit from. That block includes a Template: line pointing to the parent's folder name, and if you get that name wrong by even a single character, WordPress treats the child theme as broken. Once that header is in place, any actual CSS rules you add below it will override the parent's styles cleanly, with no risk of your changes being wiped out on the next theme update. The functions.php file in a child theme loads in addition to the parent's version, not instead of it. That makes it the right place to add custom functions, register scripts, or disable Google Fonts loading from the parent theme without editing files you do not own. Template files are a different matter. If you need to change how a specific page or post type is structured, copy that template file from the parent into the child theme's folder, keeping the exact same path. WordPress picks up the child's version first, so your changes stick while the parent updates around them. When You Might Not Need One Not every WordPress site needs a child theme. That's an honest answer, and it depends almost entirely on how the site is built. If you're working with a block-based, full-site-editing theme, customisation happens inside the editor itself, stored in the database as block templates and theme.json overrides rather than as modified PHP files. Editing the parent theme's code directly isn't part of the workflow, so there's nothing to protect. The same logic applies to sites built with page builders like Elementor, where layouts, fonts and colours live in the builder's own settings, not in the theme files. Update the theme, and your work is untouched either way. In those setups, adding a child theme is an extra layer that doesn't really do anything useful. Where it still matters is when you're writing custom PHP, registering hooks in functions.php, or modifying template files directly. Any of that work, done in a parent theme, disappears the moment the theme updates. A child theme is the only thing standing between months of careful code and a routine update wiping it out. The more custom the build, the more that protection is worth having. Setting One Up Without Breaking Anything The manual route takes about five minutes. Create a new folder in wp-content/themes/, name it something obvious like yourtheme-child, then add two files inside it. The first is style.css, which needs a comment block at the top declaring the template name and pointing to the parent theme. The second is functions.php, where you enqueue the parent stylesheet so styles load in the right order. That's the whole skeleton. If you'd rather not touch a file manager, plugins like Child Theme Configurator do the same job through the WordPress dashboard and handle the stylesheet enqueue automatically, which removes one common source of broken layouts. Once you activate the child theme, check four things straight away. Load the homepage and a single post in a browser, then open the developer tools and look at the console for any stylesheet or script errors. Click through your navigation menus, because menu locations occasionally need reassigning after a theme switch. Finally, if your site has a caching plugin running, clear the cache before you judge anything, because stale files will make a perfectly working setup look broken. Nothing on the live site should change visually at this point. If something does, the enqueue order in functions.php is almost always the culprit. ------------------------------------------------------------ # AI Chatbots on Small Business Websites: What They Can and Cannot Do Source: https://yorkshiredesign.co.uk/ai-chatbots-on-small-business-websites-what-they-can-and-cannot-do/ Published: 2026-08-10 > Roughly half of all small business owners who add a chatbot to their site are disappointed within three months. Not because chatbots are useless, but because the version they installed was never going to handle what they needed. There is a real gap between what the marketing says and what a chatbot actually does on a five-page trade website. This post goes through the honest options, what each one is genuinely good at, and where the wheels tend to come off. What a chatbot does on a small business site Strip back the vendor promises and most chatbots on small business sites are doing one thing, answering the same five questions so you don't have to. That's not a criticism. It's just worth being clear-eyed about before you commit to building one. Think about how many times a week a plumber, a florist, or a letting agent fields the same enquiries about opening hours, pricing bands, turnaround times, and service areas. A chatbot handles all of that at midnight on a Sunday without the owner lifting a finger. The customer gets an instant answer rather than a contact form and a two-day wait. Done well, that is a real improvement to the experience. The mistake is expecting the tool to do something more sophisticated than it was built for. Most off-the-shelf chatbots on small business sites have no real understanding of context, no memory between sessions, and no ability to handle anything outside a pre-written script. Push them past that boundary and they either loop awkwardly or fall back on a generic "contact us" message, which frustrates the very person you were trying to help. Think of it as a well-organised FAQ that talks back. Deployed with that scope clearly defined, it earns its place. Oversold to yourself as a virtual sales assistant, it will disappoint you and your visitors in equal measure. The three types you will encounter Rule-based bots Rule-based bots follow a script. You map out a set of questions and responses in advance, and the bot works through that decision tree every time. If someone asks something outside the prepared paths, the bot either loops back to a menu or admits it cannot help. They are cheap to set up, predictable, and useful for narrow tasks, collecting a name and phone number before routing someone to a contact form, or answering the same handful of questions your support inbox gets every week. The downside is brittleness. One question phrased slightly differently and the whole thing falls over. A visitor who types "how long does delivery take" instead of "delivery times" may get nothing back, which is more frustrating than no chatbot at all. LLM-powered chat These tools sit on top of a large language model, so they can read an unexpected question and attempt a sensible answer in plain English. The trade-off is accuracy. Without tight guardrails and a reliable knowledge source behind them, they can confidently say something wrong, which is a real risk for any business where pricing, availability, or policy needs to be precise. If you are thinking about how AI automation fits a small business budget, the running costs here are worth factoring in early. Hybrid tools Hybrid tools blend both approaches, using rule-based flows for the structured parts and an LLM to handle the gaps. For most small business websites, that middle ground is where the practical value sits. Where chatbots earn their keep The clearest wins are the questions that arrive on repeat. Opening hours, parking, whether you deliver to a particular postcode, how long a job takes, whether a specific product is in stock. A bot handles all of that without anyone touching their inbox. Out of hours is where this pays off most noticeably. A potential customer lands on your site at 10pm with a straightforward question and, instead of bouncing because nobody replied, they get an answer and book. That conversation would have sat in your inbox until morning and probably gone cold. Booking triage is another solid use case. The bot asks a few qualifying questions, confirms availability, and either sends the person to a calendar link or flags them for a callback. Nothing fancy required. The pattern that tends to surprise people is just how much inbox volume comes from repetitive queries. If you run a service business, you already know which five questions arrive every single week. A bot that handles that kind of repeatable task automatically is not replacing a conversation worth having. It is clearing the noise so you can focus on the enquiries that need your attention. That is where the time saving becomes real, and where even a modest bot earns its place on the page. Where they make things worse The failure mode nobody mentions in the sales pitch is a chatbot that confidently produces the wrong answer. A customer asks whether a product can be returned after 30 days because they bought it as a gift. The bot pulls from its training, finds something vague about your returns policy, and fires back a definitive "yes" or "no" that does not match your terms. The customer acts on it. Then they find out it was wrong. That moment, where a person has to unpick something a bot told them with total confidence, is harder to recover from than if they had simply waited for a human reply. Wrong information feels like a broken promise, and a broken promise from an automated system carries a particular kind of sting because the customer had no reason to doubt it. Complaints are the other pressure point. A frustrated customer typing out a nuanced grievance wants to feel heard. A scripted response that redirects them to an FAQ page or offers a discount code without engaging with their actual words almost always makes things worse. The underlying problem does not change; the person just gets angrier. If your website copy does the work of setting clear expectations upfront, you reduce the number of edge-case questions a bot will mishandle. That matters more than most people give it credit for. The setup work people underestimate Most chatbot installations go wrong before the first visitor ever types a question. The tool itself might take twenty minutes to embed. What takes real time is everything that sits behind it, the content it draws on, the conversation flows you map out, and the edge cases you test until the responses stop being embarrassing. A chatbot pointed at a thin FAQ page will confidently give wrong answers, loop visitors in circles, or simply fail to handle the question that 60% of your customers actually ask. Picture a trades business that installs a chatbot to handle enquiries but never feeds it accurate service areas, current lead times, or what happens when someone wants an emergency call-out. The bot becomes a liability rather than a help, and the frustrated visitor just leaves. There is also the ongoing side that people consistently overlook. Your prices change, your services shift, a product goes out of stock. Any chatbot pulling from stale content will give stale answers. For an AI chatbot for small business website use to stay useful, it needs someone checking it regularly, not treating it as a set-and-forget install. That maintenance is unglamorous work, but skipping it is exactly why so many chatbots end up doing more harm than good. Which route suits your situation Before installing any chatbot, ask whether your site generates enough repetitive queries to justify building and maintaining one. A busy e-commerce store or a service business fielding dozens of identical enquiries each week has a genuine case. The volume is there, the queries are predictable, and a well-trained bot can field them without anyone sitting at a desk. A brochure site with forty visitors a month is a different matter entirely. Bolting a chatbot onto five static pages adds weight, introduces a widget that needs feeding with accurate content, and creates a support obligation the business may not have time to honour. The chatbot sits there, half-answered and slightly embarrassing, doing more reputational damage than good. For businesses that want automation without the babysitting, the smarter route is usually backend process automation rather than a front-facing widget. If you are curious how that distinction plays out practically, our guide to getting started with AI automation for small business covers where the real gains tend to sit. High query volume justifies the effort. Low traffic rarely does. Match the tool to the actual workload, not the idea of looking modern. ------------------------------------------------------------ # Google Business Profile: What It Actually Does for Local Rankings Source: https://yorkshiredesign.co.uk/google-business-profile-what-it-actually-does-for-local-rankings/ Published: 2026-08-09 > Roughly half of all Google searches have local intent, yet most business owners set up their Google Business Profile once and never touch it again. That single listing quietly shapes whether you appear in the map pack, how far your visibility extends beyond your postcode, and whether a potential customer phones a competitor instead. Getting it right is not complicated, but there is a specific order to do it in, and most guides skip the parts that actually move the needle. What Your Business Profile Controls in Local Search Google sorts local results using three signals, relevance, distance, and prominence. Your Business Profile feeds directly into all three, which is why the details matter far more than most people expect when they first set one up. Relevance is about whether Google thinks your listing matches what someone searched for. Your business category is the single biggest lever here. Pick the wrong primary category and Google will deprioritise you, regardless of how close you are to the searcher. The services you list, the keywords that appear naturally in your description, and even the products you add all sharpen that match. Distance is more straightforward. Google weighs how far your verified address sits from the searcher's location, or from the location implied by the search query. A tighter, more accurate service area definition helps Google understand where you genuinely operate rather than making it guess. Prominence is where most businesses leave points on the table. It draws on your review count, your average rating, how consistently you respond to reviews, the number of photos on the profile, and how often the listing is updated. Google treats a stale, half-finished profile as a signal that the business may not be active or trustworthy. The profile is not just a digital business card. It is one of the primary inputs Google uses to decide whether you appear in the local pack at all, and then where you sit within it. Filling In the Details That Most People Skip Primary and secondary categories Primary category is the single most influential field on the entire profile, yet plenty of businesses pick something vague and move on. Your primary category should describe exactly what your business does, not a broad parent category that half-fits. A plumber is not a "contractor." A family dental practice is not a "health service." Google uses the primary category to determine which searches your profile is eligible to appear in, and a loose choice locks you out of searches you should be winning. Secondary categories carry less weight, so treat them as a way to cover adjacent services rather than padding out the list. If you offer gas work alongside general plumbing, a secondary category for "gas engineer" gives Google a clearer picture without diluting the primary signal. Your description and attributes The business description field allows up to 750 characters, and most profiles waste it with something that reads like a tagline. Use it to describe the services you offer, the areas you cover, and anything that distinguishes how you work. Google does read this field and it surfaces in local pack results, so writing with the signals Google looks for in service businesses in mind pays off more than a polished brand statement. Attributes often go untouched entirely. Things like "women-led," "wheelchair accessible," or "free Wi-Fi" sound minor, but they feed into filtered searches and can tip a result in your favour when a user narrows their query. Photos, Posts and the Activity Signals Google Watches Google can see when a profile was last touched. A profile that hasn't been updated in months reads as neglect. Adding photos regularly, whether interior shots, team pictures, or finished work, tells Google the listing belongs to an active operation. Posts work similarly. A Google Post that announces a seasonal offer or answers a common question shows the profile is being managed by someone who cares about it. Neither of these actions will catapult you from page three to position one on their own, but they contribute to the overall health signal Google uses when deciding which profiles deserve to appear prominently. Think of it as consistent maintenance rather than a quick fix. Q&A is the one area most businesses ignore entirely, which is a mistake. You can seed your own questions and answer them before anyone else does, keeping the answers accurate and on-brand rather than leaving them to chance. Photos, posts and Q&A are supporting signals, not ranking levers you can pull for instant movement. A business doing proper local search optimisation treats them as part of a steady routine. Post something useful once a week, refresh your photos every couple of months, keep Q&A tidy. That level of consistent attention compounds over time in a way that cramming a month's activity into a single afternoon simply won't. Reviews: How to Earn Them and How to Respond Google treats reviews as a prominence signal, which means the volume, recency, and content of your reviews all feed into how your profile ranks locally. The mechanics of asking compliantly are straightforward. Google permits you to ask customers for reviews but prohibits incentivising them or filtering so that only happy customers are prompted. The cleanest approach is a direct link, generated inside your Business Profile dashboard, sent to customers shortly after a transaction while the experience is still fresh. What matters beyond volume is the language customers use naturally. When a reviewer mentions your trade, your location, or a specific service, that text reinforces the topical signals Google is already reading from your profile. You cannot script that language without crossing into manipulation, but you can ask at the right moment. A customer who just had a good experience will often describe it in exactly the terms that help you. Response rate and speed matter too. Google's own guidance suggests that responding to reviews shows you value customer feedback, and profiles that engage consistently tend to perform better in local pack rankings for service businesses than those that go quiet after the first few replies. Keep responses specific rather than templated. A reply that references the actual service reinforces relevance without any manipulation, and it signals to prospective customers that a real person is paying attention. Connecting the Profile to Your Website NAP consistency and landing pages The profile and your website need to tell Google exactly the same story. Any gap between them dilutes the signal. NAP consistency is the obvious starting point. Your business name, address and phone number must match character-for-character across the profile, your site's contact page, and every directory that references you. A profile that says "St." where the website says "Street" is a small discrepancy, but Google weighs dozens of these signals together and inconsistencies chip away at the confidence the algorithm places in your location data. Beyond NAP, the landing page your profile links to matters more than most people realise. If your primary category on the profile is "Plumber" but the page it links to leads with boiler servicing and barely mentions general plumbing, that mismatch weakens the whole setup. The page needs to reflect the category claims directly, with the relevant service described clearly in the heading and body copy. For businesses that want the full picture of how local signals feed into search rankings, the relationship between on-page content and off-page profile data is where the real leverage sits. Schema markup Adding local business schema markup to that landing page is the layer most profiles skip. Structured data lets you encode your address, phone number and business type in a format Google can parse without inference, which reinforces rather than repeats what the profile already states. Reading the Insights to Know What to Fix Next The Insights tab inside your Google Business Profile is one of the most underused tools in local SEO. Most people glance at it once then ignore it. The numbers to pay attention to are the search queries that triggered your profile, direction requests, and call clicks. A profile with plenty of impressions but almost no calls or direction requests tells you something specific. People are finding you but not acting on what they see. That gap usually points to a thin description, weak photos, or a category mismatch that makes the profile feel off. Contrast that with a profile where searches are low but the call-click rate is high relative to views. That suggests your listing is well-optimised for the audience already finding it, but not yet visible enough for the broader search terms you want to own. For businesses working through the ranking factors that matter most for service businesses, these metrics help narrow down exactly where to focus time first. Photo views are also a real signal, not decoration. A sharp drop in photo engagement after a period of steady views often coincides with a competitor refreshing their own imagery and pulling attention away. Check the query list against what you want to rank for. If the phrases driving impressions are too generic or off-topic, your categories and description need tightening. ------------------------------------------------------------ # Website Speed Testing Tools Compared: Which Numbers Matter Source: https://yorkshiredesign.co.uk/website-speed-testing-tools-compared-which-numbers-matter/ Published: 2026-08-09 > Run the same URL through three different speed tools and you'll get three different scores. That alone tells you something important, the numbers are not gospel. Each tool measures different things at different moments under different conditions. Knowing which figures to trust, which to ignore, and what a bad result actually looks like in practice is where the real work begins. Why Every Tool Returns a Different Score Run the same URL through PageSpeed Insights, GTmetrix and WebPageTest within five minutes of each other and you will get three different numbers. Not a bug. It is what happens when each tool makes different assumptions before it even loads your page. The biggest variable is throttling. PageSpeed Insights simulates a mid-range Android device on a throttled mobile connection, which is why its mobile scores tend to look alarming even on a reasonably fast site. GTmetrix, by default, tests from a Canadian data centre on a desktop connection with no throttling applied unless you configure it otherwise. WebPageTest lets you pick your own server location and connection profile, so a test from London on a cable connection will return a materially different result than one from Sydney on 3G. Caching state adds another layer. A first-view test hits a cold server with no cached assets, while a repeat-view test loads resources the browser already has. A freshly deployed site tested cold will score worse than the same page after a warm-up crawl, even if nothing changed in the code. Real user data from the Chrome User Experience Report, which feeds into the Core Web Vitals section of PageSpeed Insights, introduces a different dimension altogether. Those figures come from actual visitors on their own devices and connections, not a controlled lab environment. The practical upshot is to stop hunting for the tool that gives the best score and start understanding what each one is measuring. The page speed metrics Google scores you on are rooted in real user experience data, not lab simulations, so a polished GTmetrix result with throttling switched off tells you very little about how Google sees the same page. PageSpeed Insights PageSpeed Insights pulls from two completely different sources, and mixing them up is where most people get confused. The lab data is generated by Lighthouse running in a controlled environment, a simulated mid-range device on a throttled connection. The field data, labelled as Core Web Vitals, comes from the Chrome User Experience Report (CrUX), which is real anonymous browsing data collected from actual Chrome users visiting your site. A well-cached site with a returning audience can show strong field data while the lab score sits in the forties. That gap is not a contradiction. It reflects the difference between a cold synthetic test and how people load your pages day to day. The lab score is still useful for spotting specific technical problems, but do not be alarmed if it looks worse than expected, particularly on sites where most visitors arrive with cached assets already in their browser. The section that deserves the most attention is the field data panel at the top of the report. If you have enough traffic for CrUX data to appear, those numbers are what Google's ranking systems see. For a detailed look at the page speed metrics Google scores you on, the distinction between LCP, INP and CLS matters far more than chasing a higher lab score. Thin-traffic sites often show no field data at all, which leaves only the lab results to work from. In that case, treat Lighthouse as a diagnostic checklist rather than a report card. GTmetrix The waterfall chart is the reason to use it GTmetrix earns its place in any serious diagnostic workflow because of the waterfall chart. Where Lighthouse gives you a score and a checklist, GTmetrix shows you exactly which request fired at what millisecond, how long it hung, and what came after it. That granularity matters when you are chasing a specific render-blocking resource or trying to work out why a third-party script is dragging your Time to First Byte up by 400ms. The waterfall is where a slow site stops being a mystery and becomes a solvable problem with a sequence you can follow. Test location matters more than people realise The default test location is Vancouver, Canada. If your site serves a British audience, those numbers will look worse than reality, and occasionally better, depending on where your CDN edge nodes sit. Always switch the test region to match your actual visitors before reading anything into the figures. GTmetrix is the right tool when you already know something is slow and you need to find what specifically is causing it. For a broad first pass on the page speed metrics Google scores you on, something closer to real Chrome User Experience data serves you better. But for dissecting a stubborn performance issue, request by request, GTmetrix is hard to beat. Use it as a surgical instrument rather than a health check, and it pays back the time you put into reading it. WebPageTest, the Tool Most Site Owners Never Touch WebPageTest sits in a different category from the tools most people reach for first. Where PageSpeed Insights hands you a score and a colour, WebPageTest hands you the raw test conditions and lets you decide what matters. The repeat view feature is a good example of why that matters in practice. The first view loads every asset cold, no cache. The second view runs the same request again immediately, with the browser cache populated. If your first view takes 4.2 seconds and your repeat view still takes 3.8, something is wrong with your caching configuration, and a single-run tool would never surface that gap. The filmstrip view goes further still. It renders a second-by-second screenshot strip of what the page looked like to a visitor as it loaded, which is far more telling than a single number when you are trying to understand why something feels slow even if the total load time looks acceptable. Connection throttling is where the diagnostic honesty gets serious. You can test over a simulated cable connection, a 4G mobile network, or a slow 3G signal, and the results shift considerably. Testing only on fast connections is one of the most common ways to miss a performance problem that is obvious to half your audience. For a grounded read on the specific page speed metrics Google uses to score your site, the filmstrip and waterfall views in WebPageTest give you the evidence to act on, not just a number to worry about. Which Metrics to Fix and Which to Ignore The three numbers that feed directly into rankings Not every number in a speed report carries the same weight. Some will tank your rankings. Others are noise dressed up as urgency. Google's Core Web Vitals are the three figures that feed directly into search ranking signals. Largest Contentful Paint (LCP) measures how quickly your main content appears. Interaction to Next Paint (INP) captures how fast the page responds to a click or tap. Cumulative Layout Shift (CLS) tracks whether elements jump around as the page loads. Fail any of those and you have a genuine problem. Most of the websites we have worked on came in failing at least one Core Web Vital on mobile, and getting them to a pass required real investigation rather than a surface-level fix. A poor LCP almost always points to unoptimised images, slow server response, or render-blocking resources. CLS problems tend to come from images without declared dimensions, or fonts that swap in late and push everything down the page. These are solvable, but they take time to diagnose properly. Scores that are useful diagnostics but nothing more Figures like Time to First Byte shown in isolation, or the raw performance number from Lighthouse, are useful diagnostics but carry no direct ranking weight on their own. A page can sit at 68 in Lighthouse and still pass every Core Web Vital that matters. Chasing a round number is a distraction. Fix LCP, INP and CLS first, then look at everything else. How to Test Fairly A single test run tells you almost nothing useful. Network conditions vary, server responses fluctuate, and a cold cache behaves completely differently from a warm one. Before you run any tool, clear the cache on both your server and your caching plugin, then run the same URL three times in a row and average the results. That averaged figure is far more honest than the outlier score you happened to screenshot. Test mobile and desktop as separate exercises too, not as a footnote, because the performance gap between them is often 20 or 30 points and the fixes for each can pull in opposite directions. Geography matters as well. If your customers are in the UK, test from a UK location rather than letting the tool default to a US data centre, because the extra round-trip latency will skew your numbers and mislead you about what needs fixing. PageSpeed Insights is the obvious starting point because it uses real-world Chrome User Experience Report data alongside the lab result. For a deeper look at the specific metrics Google scores you on, it pays to know which numbers feed into Core Web Vitals and which are diagnostic only. The score is a prompt, not a goal. Chase the underlying metric, not the badge. ------------------------------------------------------------ # Why Good Web Design Takes Longer Than People Expect Source: https://yorkshiredesign.co.uk/why-good-web-design-takes-longer-than-people-expect/ Published: 2026-08-09 > Most people assume a website takes a few days. Pick a theme, drop in some text, add a logo, done. The reality is that anything built that way tends to show it within six months. Slow load times, pages Google ignores, forms that break on mobile. The parts of a website that actually hold up over time are almost entirely invisible, and they're the parts that take the longest to get right. The visible stuff is the easy bit Choosing colours, arranging a layout, writing headlines. That part takes real time, but it's what most people picture when they think about web design. What they don't picture is everything underneath, how database queries are structured, whether the HTML is clean enough for a search engine to read, whether the server will hold up under real traffic. A site can look polished and still perform terribly. Google's Core Web Vitals measure real user experience, things like how fast the largest element loads on screen and how much the layout shifts as the page settles. A site that fails those checks loses rankings quietly, regardless of how good it looks. Hosting is a decision that affects everything Where a site lives matters more than most clients expect. GoDaddy hosting, in our experience, tends to run slow, bundles unnecessary add-ons, and creeps up sharply in renewal costs once the introductory period ends. That's not a casual criticism. It's the pattern we see repeatedly when a site that looked fine in the browser turns out to have a server response time that makes Google wince. Picking the right hosting environment, configuring it properly, and testing under realistic conditions all add hours to a project. Skip that stage, though, and you are polishing a car with a broken engine. Why clean code takes longer to write The faster a developer builds, the more shortcuts they tend to take. Those shortcuts compound. A plugin added to fix one problem introduces three new conflicts. A page builder that generates 400 lines of HTML for a two-column section. Render-blocking scripts that fire before the page can even begin drawing. Unpicking that kind of technical debt is what eats the most time on sites we inherit. It's also work nobody sees, which makes it hard to explain to a client expecting a quote by Thursday. Waiting times for website designers who work at this level can surprise people, because this unseen groundwork takes real hours to get right. If you want to understand where that effort goes, the breakdown of what web design work actually covers gives a clearer picture. SEO belongs in the build, not bolted on at the end A common trap is treating SEO as something you add once the site goes live. It doesn't work that way. URL structure, how internal links are organised, whether each page targets a clear topic, how images are labelled. These decisions are baked into the build from the start, not patched in afterwards. A site built without that thinking needs to be partially rebuilt before it ranks well. That means time spent correcting what should have been right from day one. Getting the structure solid before a single page goes live is slower upfront, but far cheaper over time. Here's a quick look at how time typically splits across a proper build: Where the hours actually go in a well-built site Technical setup and hosting config , longest phase SEO structure and page architecture , significant Design and layout , moderate Content input and copy , variable Testing and QA , often skipped, shouldn't be Relative effort breakdown, not fixed hours. Every project differs. Testing is where most budgets get cut first Cross-browser checks. Mobile layout at different screen widths. Form submissions, redirects, page speed scores before and after optimisation. This stage is invisible when done well and painful when skipped. Many cut-price builds skip it entirely. The result is a site that works on the developer's machine and breaks on someone's older Android phone. The stages of a proper design process show why testing isn't optional padding. It's where problems surface before they reach real users. Rushing a build costs more to fix later A site built in three days rarely stays cheap. The hidden cost arrives later, in slow page speeds that suppress rankings, in a rebuild when a theme causes conflicts, in the developer hours needed to untangle a codebase that was never clean to begin with. The sites that hold up are the ones where someone took the time to get the foundations right. That's not a slow builder. That's someone doing the job properly, and it's the main reason waiting times for website designers who work this way run longer than most people expect. ------------------------------------------------------------ # WordPress Multisite vs Single Site: Which Setup Suits Your Business Source: https://yorkshiredesign.co.uk/wordpress-multisite-vs-single-site-which-setup-suits-your-business/ Published: 2026-08-08 > Choosing between WordPress Multisite and a standalone install is one of those decisions that looks straightforward until you are three months into the wrong one. Most guides talk about features. This one is about fit. The two setups solve genuinely different problems, and picking the wrong one does not just cause inconvenience , it creates technical debt that costs real time to unpick later. Here is what each actually does, where each falls short, and who should be using which. What WordPress Multisite Actually Does Under the Bonnet Most people picture WordPress Multisite as several websites running side by side, independent installs sharing a server. The reality is stranger and more interesting than that. When you enable Multisite, you are not installing WordPress multiple times. You are telling a single WordPress installation to serve multiple sites from one codebase, one database, and one server footprint. Every sub-site in the network shares the same wp-config.php, the same core files, and the same database server, though each site gets its own set of tables within that database, prefixed to keep them separate. Think of it like a block of flats built on a single foundation. The structure, the utilities, the roof are all shared, but each flat has its own front door. Plugins and themes live in one place on the server, and a network administrator decides which ones each site can use. Updates happen once and ripple across every site in the network at the same time, which is where a lot of the appeal comes from if you are managing dozens of properties. That shared foundation is also where the constraints show up. A rogue plugin that breaks the core installation does not just affect one site, it affects all of them simultaneously. Database load is pooled, so a traffic spike on one sub-site puts pressure on resources that every other site in the network depends on. Understanding that shared layer is the starting point for deciding whether Multisite fits what you are trying to build. Where Single Sites Have the Edge The strongest case for separate installs is autonomy. Each site runs its own WordPress core, its own plugin stack, and its own hosting environment. That means one site can be updated, migrated, or taken offline without touching anything else. If a plugin conflict brings down Site A, Sites B and C keep running. That kind of isolation is hard to replicate inside a Multisite network, where a single bad update to a network-activated plugin can ripple across every sub-site at once. For businesses where each property needs to operate on its own terms, a shared infrastructure is a liability rather than a convenience. Separate installs also make hosting decisions simpler. You can put a high-traffic site on a beefier server and leave a quieter one on a cheaper plan, rather than sizing one network to cover every edge case. Plugin choice is another area where single sites win. On a Multisite network, network-activated plugins apply everywhere. Individual site admins can often add their own, but they cannot remove the network-level ones. With separate installs, each site gets exactly what it needs, nothing more. That matters once you have clients or internal teams with different requirements who need full control over their own hosting and plugin environments. When Multisite Earns Its Place Multisite fits a narrow set of situations. Franchise networks are the clearest example, one brand, dozens of locations, each needing its own content and contact details but sharing the same theme, plugins, and admin overhead. University platforms fit the same pattern, where each faculty or department gets its own subsite without IT having to spin up separate hosting accounts for all of them. Multilingual setups can work well too, particularly when you want a single codebase controlling language variants that share plugins and receive updates simultaneously. In all these cases, the architecture pays for its own complexity. Where people go wrong is reaching for Multisite because they run two or three related websites. That is not a network problem. A small business with a main site and a blog, or an agency managing a handful of client sites, gets very little from Multisite that it could not manage more cleanly with separate installs. A bad plugin update on one site cannot take down the others when they are separate. The SEO complications that surface early in a Multisite setup alone are enough to make most small operators question whether the shared infrastructure was a good idea. If you are not managing ten or more sites under one brand umbrella, a single site almost always keeps things simpler. Performance and Core Web Vitals Architecturally, both setups share the same WordPress codebase, so the raw performance ceiling is similar. The difference shows up in how you configure caching and how server load distributes across sites. Tuning a single site A single site is straightforward to tune. One caching layer, one set of database queries, one place to check when something slows down. If performance dips, the culprit is usually obvious. Tuning a Multisite network Multisite is trickier. All sub-sites share the same database and the same server resources, so a traffic spike on one sub-site puts pressure on every other site in the network simultaneously. That shared pool becomes a real problem at scale, particularly if you are running sub-sites with very different traffic patterns on a modest hosting plan. Plugin-level caching tools like WP Rocket or W3 Total Cache can handle Multisite, but the configuration is more involved, and getting unnecessary asset requests under control across multiple sub-sites takes considerably more attention than on a standalone install. For Core Web Vitals, the setup itself is not the deciding factor. Theme quality, image handling, and server response time matter far more. Single site wins on simplicity of performance tuning. Multisite can match it, but only with more deliberate configuration work. Plugin and Theme Management Across Both Setups Plugin management is where the two setups feel most different in day-to-day practice. How single sites handle plugins Single sites are straightforward. You install, activate, update, and if something breaks, you deactivate and trace the conflict. Simple cause and effect, nothing shared, nothing unexpected. How Multisite handles plugins Multisite adds a layer of network-level control that sounds appealing on paper but creates friction in practice. A network admin installs a plugin centrally, but individual site admins can only activate it if the network admin permits that. Some plugins refuse to work correctly in this environment at all, particularly anything that writes its own database tables or assumes it owns the whole WordPress installation. A membership plugin or a WooCommerce setup is a good example of something that regularly misbehaves across a Multisite network because it was never designed to share a database with twenty other stores. Debugging those conflicts takes real time, and the fix often is not obvious. Themes work on a similar principle. You enable them network-wide, but per-site customisation is restricted unless you handle it carefully through child themes or conditional logic. Anyone who has tried to give five subsites five distinct brand identities on a single Multisite install will know how quickly that becomes untidy. We have written more about those early friction points in our breakdown of common Multisite problems. Single sites win on flexibility. Every plugin decision is local, every theme change is contained, and nothing you do ripples unexpectedly into someone else's site. Which Setup Is Right for You If you run a single business with one audience and one brand, a standard single site is almost always the right call. It is simpler to maintain, easier to hand off to a developer, and far less likely to produce the kind of cascading problems that come with shared infrastructure. A network starts to make sense when you need to manage several sites from one dashboard and those sites share a common purpose. A university with faculty subsites, a franchise group, a publisher running regional editions. The moment those sites start diverging significantly in design, plugin needs, or user permissions, the shared environment that felt like an advantage becomes the constraint you are working around. If you have found yourself reading about the SEO complications that Multisite introduces and feeling uneasy, that instinct is usually correct. For most small businesses and independent operators, separate sites win. Each one stays contained, and a problem on one never bleeds into another. The cleaner question to ask yourself is whether your sites need to share users, themes, or a central admin. If the answer is no, skip Multisite entirely. The overhead rarely justifies itself, and the practical differences between Multisite and separate WordPress installations tend to favour separate sites for most real-world setups. ------------------------------------------------------------ # How to Use AI to Repurpose One Article Across Six Formats Source: https://yorkshiredesign.co.uk/how-to-use-ai-to-repurpose-one-article-across-six-formats/ Published: 2026-08-08 > Most articles get written once, published, and quietly forgotten. That is a waste of the time that went into researching and writing them. A single well-structured piece already holds the raw material for a newsletter section, a social post series, a short video script, an FAQ page and more. What AI changes is how long that extraction takes. This guide walks through the full workflow, step by step, so nothing useful gets left sitting in a draft folder. Start With Something Worth Repurposing Thin content multiplied is still thin content. Feed a weak article into an AI repurposing workflow and what comes out the other end is six weak things instead of one. The source piece needs to carry real weight before you do anything with it. That means a clear argument you could summarise in a single sentence, sub-points that build on each other rather than repeat the same idea in different clothes, and enough depth that a reader walks away knowing something they didn't before. Eight hundred words is a rough floor, but word count alone tells you nothing. A 1,200-word article built around one obvious observation padded out with transition sentences has nothing to extract. What you're looking for is structure you can pull apart, a strong opening claim, a middle section with at least two or three distinct positions or steps, and a close that lands somewhere concrete. If you can't identify those elements before you start repurposing, the AI tools you use to spin it into social posts, a script, or an email sequence will flatten what little is there into something even thinner. A practical test is to read the article and ask whether each section could stand alone as a useful idea. If you're scanning for content that earns its place on the page, rather than content that merely exists, the distinction becomes obvious quickly. Strong source material repurposes into six formats that each feel distinct. Weak source material just echoes itself. Map Your Output Formats Before You Prompt Most people open a chat window, paste their article in, and ask for "a LinkedIn post" or "a newsletter summary." That works once, but the moment you want six different outputs from the same source, prompting format by format produces inconsistent results. The tone shifts between pieces, the core message drifts, and you end up rewriting half of what the AI returns. Deciding the full output list upfront changes that dynamic completely. When you know you need a newsletter snippet, a LinkedIn post, a short-form video script, an FAQ section, social quote card copy, and an email sequence intro, you can build a single framing prompt that holds the through-line across the whole batch. Each individual prompt then references the same source material, the same key message, and the same audience, so the outputs feel like parts of one campaign rather than six unrelated pieces. That consistency is hard to achieve when you're prompting reactively. Think of it like a shot list before a photoshoot. A photographer who walks in without one leaves with usable images but misses half the angles. The list is not a constraint; it is what keeps the session focused. The six formats each serve a different reader and a different context, so they pull different elements from the source article. A structured approach to repurposing a blog post makes it easier to brief each format accurately, rather than discovering mid-batch that your video script needs a hook you never extracted. Map the list first, and the prompting becomes a process rather than a guessing game. How to Structure Your Prompts for Each Format One prompt does not fit all A prompt that works for a LinkedIn post will actively hurt you if you point it at a podcast script. The format changes everything, the reading level, the assumed context, the length, and which slice of the source article is relevant at all. A Twitter thread needs a single sharp hook from one concrete claim. An email newsletter wants a warmer opening, a quick summary of the idea, and a reason to care. A YouTube description wants searchable language front-loaded into the first two lines. Each of those is a different brief, and treating them as variations on one master prompt is where most AI content repurposing falls flat. Be specific about three things Before writing any prompt, pin down the format's constraints (character limit, spoken versus read, scrolled versus clicked), the platform's audience expectations, and the exact section of the source article you want the AI to draw from. That last point matters more than most people anticipate. Pointing the AI at your whole 1,500-word article and asking it to "make a LinkedIn post" produces a bland middle-of-everything summary. Feed it only the paragraph containing your strongest concrete example instead, and say: "Turn this specific example into a 150-word LinkedIn post written in first person, aimed at small business owners who are sceptical about AI tools, with no jargon and a question at the end." That level of instruction gives the model something to work with, and the output reflects it. Editing the AI Output Without Losing the Speed Gain Know what actually needs fixing The editing pass is where most people lose the time they just saved. They start rewriting sentences, smoothing tone, chasing perfect phrasing, and before long a ten-minute task has turned into an afternoon. AI output tends to fail in three specific places. It hedges where you'd be direct. It skips the concrete detail only you know. It fills space with generic observations that add nothing. Those are the only things that need correcting. Fact-check any claim the AI has stated with confidence, because it will occasionally assert something plausible that is simply wrong. Then scan each format for a line or two that could have come from anyone writing on this topic, and swap it for the specific opinion or example that makes your take different from the ten other articles on the same subject. That last step is the one people skip, and it's the one that matters most for content that earns attention rather than just occupying space. Everything else, sentence rhythm, word choice, paragraph order, you can largely leave alone. The goal is a light pass, not a rewrite. Set a timer Ten minutes per format is enough for fact-checking, one targeted reinjection of your point of view, and a final read-aloud. If you are still editing at twelve minutes, you have drifted into perfectionism, not quality control. Scheduling and Publishing the Six Pieces Don't post everything on the same day. It wastes the work you've done. Spacing six formats across two to three weeks keeps the original idea in front of people repeatedly, through different channels, without flooding any single platform. A LinkedIn post on Monday, a short-form video script shared Thursday, an email newsletter the following Tuesday. Each one lands as its own thing, picks up its own small audience, and points curious readers back to the long-form article. That's the whole point of a solid content publishing workflow. The stagger compounds reach rather than cannibalising it, because someone who scrolls past your Twitter thread on day three may have already saved your LinkedIn post on day one. They're warming to the idea across multiple touchpoints rather than seeing a single burst they'll forget by Friday. A simple content calendar, even a basic spreadsheet, is enough to map this out before you start publishing. Assign each format a platform and a date, and stick to it. The cadence matters far more than the tool you use to track it. Where Yorkshire Design Handles This for You Building an AI content repurposing workflow from scratch takes longer than most people expect. You need to pick the right tools, write the prompts, test the outputs, fix the formatting, work out where each format lives, and then do it all again for the next article. Most businesses get halfway through that process, hit a wall, and the whole thing gets abandoned. That is exactly the problem the ComPOS AI Automation system was built to solve. Rather than stitching together a handful of separate tools and hoping they play nicely, ComPOS handles the logic behind the scenes so the workflow runs consistently, without someone needing to babysit it every time a new piece of content goes live. The content writing side sits alongside it. Articles are written with repurposing in mind from the start, structured so the headings, pull quotes and key points all translate cleanly into other formats without needing to be reworked. If you would rather focus on running your business than building publishing infrastructure, get in touch and we can talk through what a realistic setup looks like for you. ------------------------------------------------------------ # How Service Businesses Should Write Website Copy to Win Clients Source: https://yorkshiredesign.co.uk/how-service-businesses-should-write-website-copy-to-win-clients/ Published: 2026-08-08 > Roughly half of all service websites lose a potential client in the first ten seconds. Not because the service is wrong, not because the price is off, but because the copy is written for the wrong person. It talks about the business when the visitor only wants to know one thing, can you fix my problem? Getting that answer in front of someone quickly is the whole job of a service page. Why Most Service Copy Fails Before the Second Paragraph Most service pages lose the visitor in the first three lines. Not because the business is bad at what it does, but because the page opens talking about itself. The pattern is near-universal. A visitor lands on a plumbing company's site and reads "We are a family-run plumbing business established in 1987, proud to serve our local community with professional and reliable service." That sentence tells the visitor nothing useful. They arrived because a pipe is leaking, or they need a boiler replaced before winter, and the page is already making them wade through the company's self-image before getting to any of that. By the time a second paragraph appears, a good portion of readers have already hit the back button. Attention online is not polite. People scan the top of a page in a fraction of a second, looking for confirmation that they are in the right place. They want to see their own situation reflected back at them, a problem named, a tension acknowledged. "We are..." gives them none of that. It is the written equivalent of a shop assistant who greets every customer with a five-minute company history before asking what they need. The fix is not complicated, but it does require a genuine shift in perspective. Start with the client's situation. Your credentials can earn their place later, once the reader already feels understood. Writing for the Client's Problem, Not the Business's History Put the client at the centre Most service pages open with some version of "we provide X, and we've been doing it since Y". That framing puts the business at the centre of the page, which is exactly the wrong place to start. A visitor landing on your site is not thinking about your history or your team structure. They're thinking about a problem they have right now, and whether you can fix it. The fastest way to lose them is to spend the first three paragraphs talking about yourself. Reframe every sentence around what the client is experiencing, and the copy starts to pull rather than push. Compare "we provide payroll management services" with "if you're spending Sunday evenings doing payroll instead of switching off, we sort that for you". Same service, completely different effect on the person reading it. A simple reframe that changes everything The pattern to follow is straightforward. Swap "we offer X" for "you get X when Y is happening". That second shape shows the reader you understand their situation before you've even named your price. This is the same thinking that separates average service page copy from the kind that generates enquiries. Name the problem plainly, then connect it to your solution. That order matters more than most people realise. What a Strong Service Page Contains The headline and opening sentence Most service pages fail at the first line. The headline describes the business rather than speaking to the person reading it. A strong headline names the outcome the client gets, not the service the business sells. "Accounting that keeps your tax bill legal and your paperwork sorted" lands differently than "Professional Accountancy Services". Below the headline, one clear sentence should confirm exactly who the page is for and what happens next. If a reader has to work out whether they're in the right place, the page has already lost them. Evidence that earns belief This is where most service pages fall flat. Claims like "we're passionate and experienced" cost nothing to write and mean nothing to read. Real evidence looks different, a specific result, a named process, a quote from an actual client that describes a before and an after. This is the section where the difference between good and weak copy becomes impossible to ignore. Concrete proof does the persuasion work that adjectives cannot. The call to action "Contact us" asks the reader to take a leap into the unknown. "Book a free 20-minute call to talk through your options" tells them exactly what they're agreeing to, how long it takes, and that there's no commitment attached. That small change removes hesitation at the moment it matters most. How Much Copy Does a Service Page Need? Length should follow the complexity of the decision a visitor has to make, not a word-count target someone read in an SEO guide. A page selling a straightforward 45-minute boiler service needs enough copy to confirm what's included, what it costs, and why you're a safe pair of hands. That might be 200 words. A page selling a bespoke kitchen refit at £15,000 needs to walk the reader through your process, address their fears about disruption and overspend, and give them enough reassurance to pick up the phone. That might be 600 words, possibly more. The gap between those two has nothing to do with Google and everything to do with how long a reasonable person takes to commit to spending that kind of money. Ask yourself one question before writing a single line, what does a cautious, sensible person need to know before saying yes to this? Write until you've answered that. Stop there. If you're unsure where the line is, look at your enquiry conversations. The questions people ask before they book are almost always the questions your service page copy should be answering before they even pick up the phone. If you're getting the same three questions on every call, those answers belong on the page. The Trust Signals That Make Copy Believable Specificity over adjectives A bold claim with nothing behind it is just noise. Visitors have seen too many "dedicated team of experts" promises to take them at face value. What builds credibility is specificity. Say you've completed over 200 websites and people have something to hold onto. Say you "create beautiful digital experiences" and they have nothing. Named outcomes work the same way: "reduced checkout drop-off by reorganising the product page" tells a reader far more than "improved user experience". If you have a real result from a real piece of work, put it in plain language and let it stand. Scope statements and honest framing Scope statements are often missed entirely. Telling a prospective client what you don't cover is a form of trust, not a weakness. It signals that you understand your own work well enough to draw a line around it, and it saves both sides from a conversation that was never going to go anywhere. The elements of a strong service page almost always include this kind of honest framing, even if it's just a short paragraph on who the service suits best. Social proof that actually means something Social proof, stripped of the marketing jargon, means showing that someone else trusted you and it worked out. A specific quote from a named client beats a five-star graphic with no context. Even a brief description of the type of business you worked with, and what they came to you needing, gives a reader enough to picture themselves in the same position. What to Do When You Are Not a Natural Writer Most people who struggle with website copy are not bad at explaining their work. They are bad at explaining it to a blank page. The moment you sit down to write, something shifts. You second-guess every word, reach for formal phrasing you would never use in conversation, and end up with something stiff and unconvincing. A far more reliable starting point is to forget the keyboard entirely. Talk through what you do, out loud, as if a friend had just asked you to explain your service over a cup of tea. Record it on your phone. Don't edit yourself, don't pause for the right word, just talk. When you transcribe that recording, you will almost certainly find clearer, warmer, more persuasive copy than anything you would have typed from scratch. The words "we basically help people who..." are worth ten bullet points that start with "We specialise in providing...". From there, tighten the transcript into short paragraphs and cut anything you would not say to a real person. That is most of the work done. If you want to see how that kind of plain-spoken copy differs from the alternative, the real copy examples comparing good and bad service page writing make the gap obvious fast. If you are also briefing a designer or copywriter to help, knowing what you want to say before that conversation saves a lot of back and forth. A clear website brief turns that recorded explanation into something a professional can actually work from. ------------------------------------------------------------ # How to Repurpose One Article Into a Month of Marketing Content Source: https://yorkshiredesign.co.uk/how-to-repurpose-one-article-into-a-month-of-marketing-content/ Published: 2026-08-08 > Most business owners write a solid article, publish it, share it once, and move on. That single post could realistically fuel four weeks of marketing content across every channel they use. The writing is already done. The research is already done. What follows is a step-by-step walkthrough of exactly how to pull that apart, reformat each piece for where it lands, and end the month with a full content calendar built from a single starting point. Start With an Article That Has Real Substance Not every post earns the repurposing treatment. Some are too thin, too vague, or too locked into one format to travel anywhere useful. So before you start pulling anything apart, it's worth being honest about what you're working with. The posts worth pulling apart are the ones that already do real work on their own. A strong candidate answers a specific question with genuine depth, holds a clear opinion rather than sitting on the fence, or walks through a process step by step in a way that naturally maps to other formats. A thorough how-to post, for instance, already contains the bones of a short video script, a checklist, a carousel, and a standalone social tip, all sitting inside the same piece of writing. An article that draws consistent search traffic is another reliable signal, because it tells you the topic resonates with real people who went looking for it. Depth matters more than length here. A 600-word post that takes a firm position on a misunderstood topic is far more repurposable than a 2,000-word piece that skims five ideas without committing to any of them. If you are unsure whether a post qualifies, read it back and ask whether a reader could act on it, argue with it, or share it as a recommendation. If the answer is no, it needs more work before it becomes the source of anything else. Map the Formats Before You Write Anything New A finished 1,000-word article already contains most of what you need for a solid month of content, if you know where to look. The introduction usually holds your strongest hook, which lifts straight into an email newsletter subject line and opening paragraph. The subheadings map to short-form social posts, one idea per platform, one heading per post. A dense middle section with a concrete argument or process gives you the backbone of a long-form LinkedIn piece without needing to draft from scratch. Pull a particularly clear sentence or a hard-won observation and you have a quote card. FAQ sections or any 'common mistake' passages convert directly into snippet-style content, short answers that work across search features, social captions, and chatbot responses. If you've structured the article with a clear beginning, middle, and end, a video script is already ghosted out for you. Doing this mapping before you commission or write anything new is where a solid content brief pays for itself. Knowing the formats in advance shapes the article structure, so every section is already pulling double duty. Six formats. One source article. No new research required. How to Pull Social Posts Straight From the Body Copy The raw material is already there. Read through the article and mark anything that would stop someone mid-scroll, a bold claim, a specific number, a single-sentence how-to, a strong opinion that contradicts what most people assume. Each one of those is a post waiting to happen. A sentence like "most businesses publish three times more content than they actually need" lifts straight into a LinkedIn post with one reframing sentence added above it. A three-step process buried in paragraph four becomes a numbered carousel for Instagram. You are not rewriting anything from scratch. You are changing the wrapper, not the content. The platform tone does most of the work. Twitter or X wants the sharpest version of the claim, no context. LinkedIn wants the same claim with one line of professional reasoning underneath it. That is the only adaptation required. Where AI tools earn their place is in this scanning and reframing step. Rather than reading the article four times looking for quotable moments, AI-assisted content workflows can surface candidate sentences in seconds and draft platform-specific variants from each one. The output still needs a human eye to check the tone lands correctly, but the mechanical slog of identifying what is usable and reshaping it per platform shrinks from an hour to a few minutes. Turning the Article Into an Email Your List Actually Opens Lead with one insight, not a summary The mistake most people make is summarising the article inside the email itself. Once you've given the reader the gist, there's no reason for them to click through. A better approach is to pull out the single sharpest insight from the piece, the one observation that changes how someone thinks about the problem, and build the whole email around that. Set it up, give it a line or two of context, then stop. Let the post do the rest. Subject lines and length Subject lines follow the same logic. Something specific and slightly incomplete beats a clever headline every time. "Why your summary email kills your click rate" will outperform "This week's content tip" by a distance, because the reader has a gap they want to close. Length-wise, an email that connects one idea to one link sits comfortably between 120 and 180 words. Longer than that and you're writing a newsletter, not a traffic driver. If your content strategy for your business is still finding its footing, this single-insight format is the easiest place to start. The test is simple. Read your draft email and ask whether someone who gets to the end still has a reason to click. If they don't, you've given too much away. Cut something. Send it. Watch the click rate. Building a Video or Audio Script From What You Already Wrote Most people stare at a blank document when they sit down to record. They already have everything they need sitting in the article. The structure maps across almost perfectly. Your subheadings become talking points in sequence, each one a natural beat to move through. The intro paragraph, the one you spent time tightening, already does the job of a hook because it frames the problem and promises a payoff. Drop it at the top of your script and it works for a camera or a microphone just as well as it does on a page. The conclusion you wrote, the part that nudges a reader toward a next step, becomes your call to action at the end of the recording. By the time you've lifted those three elements, the script is roughly 80% assembled. What remains is mostly bridging language, the short verbal transitions that make spoken content feel natural rather than read aloud. For a short-form content repurposing workflow this approach removes the blank-page problem entirely. It works whether you're recording a two-minute talking-head clip or a longer podcast-style audio piece. The ratio holds either way. Scheduling It So the Month Doesn't Feel Chaotic A four-week rhythm that holds together The simplest way to stop staring at a blank calendar is to treat the original article as a publishing plan, not just a piece of content. Week one is straightforward, the article goes live, you share it once on your main social channel, and you let it settle. Week two is where the bulk of distribution happens. Send the email, pulling two or three lines directly from the post as your hook, then drop two social posts on different days, each leading with a different angle from the same piece. One might quote a specific tip, the other might pose a question to the audience. Week three shifts format. A short talking-head video, a quote graphic pulled from a strong line in the post, or a screen-recorded walkthrough if the subject suits it. The idea is that the audience sees the same thinking in a different shape, which suits readers who skimmed past the original. Week four is where you close the loop and feed the next cycle, using any comments or replies from the previous three weeks to frame a follow-up question or a poll. If you are still building the bigger picture of a content plan for a small business, this four-week structure gives you something concrete to run before that strategy is fully formed. When to Bring in Help and When to Do It Yourself The planning side of content repurposing is manageable for most business owners. Mapping out which formats suit which piece, deciding what goes to LinkedIn versus a newsletter, building a rough four-week schedule on a spreadsheet, that part takes an afternoon, not a week. Most people can hold that together without outside help, and there is no real reason to pay someone else to do it once you understand the pattern. The rewriting is where the hours disappear. Taking one article and reshaping it into a punchy social caption, a scannable email, and a short video script are three separate writing jobs, not three copies of the same text with bits cut out. Each format has its own rhythm, its own reader expectation, its own structure. If you are running a business alongside this, that work compounds fast. A clear content plan for your business only pays off if the actual writing gets done to a standard that earns the reader's attention. That is the fork in the road. The strategy is yours to own, but the execution is where bringing in a content writer often makes more practical sense than grinding through it alone. ------------------------------------------------------------ # How to Write a Content Brief That Gets You the Article You Wanted Source: https://yorkshiredesign.co.uk/how-to-write-a-content-brief-that-gets-you-the-article-you-wanted/ Published: 2026-08-07 > Most content briefs are either a single vague sentence or a five-page document nobody reads past the first paragraph. Writers end up guessing, editors end up rewriting, and the article that lands is rarely the one the client pictured. Getting a brief right is not about writing more. It is about being specific in the right places and leaving room in the right ones. Here is how to do it properly. Start With the One Question the Brief Must Answer Every brief needs a single, clear question written at the top. Not a topic. A question. The difference matters more than most people realise when they sit down to write a brief. A topic like "content marketing for small businesses" could mean a hundred different things depending on who is searching for it. A question like "how do small businesses with no budget get started with content marketing?" tells the writer exactly who is sitting at the other end of that search, what they already know, and what gap they are trying to close. Everything else in the brief, the headings you suggest, the tone you want, the examples you ask for, only makes sense once that question is pinned down. Without it, a writer can produce something technically competent that still misses the mark completely, because they made a reasonable guess about intent and guessed differently than you did. Before you write a single bullet point, go and read the pages that currently rank for your target phrase. Ask yourself what job those pages are doing for the reader. Are people looking for a quick definition, a step-by-step process, a comparison of options, or reassurance that they are making the right call? That single observation shapes the format, the depth, and the opening paragraph more than any word count or keyword instruction you could give. What a Working Brief Contains A working title comes first, and it needs to be specific enough that the writer knows exactly what territory they are covering. "SEO tips" is not a working title. "Five technical SEO fixes a small business can apply without a developer" is. Next comes the focus keyword, which tells the writer what phrase the article needs to rank for and shapes how they structure the opening paragraphs. After that, audience and tone, because a brief aimed at first-time business owners reads completely differently from one aimed at developers who already know their way around a codebase. Word count follows from those two things. It is not a random target but a signal of how deep the article needs to go to genuinely satisfy the reader's question. Finally, and the element most briefs forget, the intended outcome. What should the reader know, feel, or do by the final sentence? If you leave that out, the writer will pick an ending arbitrarily, and you will wonder why the piece trails off. Miss the focus keyword and the writer optimises for a phrase that was never yours to begin with. Miss the intended outcome and you get an article that informs without ever converting. A well-structured content brief for writers ties all of these elements together into a single document the writer can open and start from, without a back-and-forth email thread to fill the gaps. How to Write the Angle Without Writing the Article The most common reason a brief produces the wrong article is that the angle was never stated. The client knew what they meant, the writer guessed, and the two guesses did not match. Fixing this does not require you to draft the piece yourself. It requires one sentence that states a working position, not just the topic, but what the article claims about it. "A content brief should do one specific job, give the writer enough to make every structural decision without coming back to ask" is a position. "Content briefs" is a subject. These are not the same thing, and handing a writer the subject without the position is what produces a generic, perfectly competent article that says nothing you wanted said. Think of it as the difference between a map reference and a compass bearing. The topic tells a writer where they are. The angle tells them which direction to walk. A working hypothesis does not need to be polished or permanent. Write it as a rough claim, something you could argue with. "Most businesses over-explain the background and never state what they want the reader to believe by the end." That single line tells a writer what tone to take, what to cut, and where the piece should land. If you find yourself writing supporting points and sub-arguments to go with it, you have gone far enough. For a practical example of how this fits into a broader document structure, our guide on the elements a brief needs to perform in search covers where the angle sits alongside keyword and intent signals. Telling Writers What to Avoid Most briefs list what they want. The ones that save the most revision time also list what they don't want. A writer who doesn't know your red lines will cross them, not out of carelessness but because they're working from their own defaults. If you've been burned by a draft that opened with a competitor comparison you'd never make, or one that leaned on a claim your legal team has flagged, that problem almost always traces back to a brief that left those boundaries unspoken. Spell out the angles you're not taking, the structural habits you've seen go wrong, the phrases that are off-limits, and the tone traps that have appeared in previous work. One line in a brief prevents a full rewrite. A clear, concrete list of what to avoid in a well-constructed content brief is often what separates a first draft you can publish from one you have to rebuild from scratch. Common entries include topics that overlap with ongoing campaigns, claims that haven't been verified, emotional angles that feel off-brand, and any structural formula that's become stale on your site. It doesn't need to be long. Two or three specific callouts, drawn from actual experience with past drafts, will do far more than a vague instruction to "keep it professional." Where SEO Notes Belong in the Brief SEO context belongs in the brief. It does not belong in every paragraph of it. A writer needs to know the target keyword, the search intent (are people looking to buy, compare, or learn something?), and which existing pages to link toward. That is the full list. The keyword tells them what phrase the page is competing on so they can write naturally around it rather than stuffing it in at random. The search intent tells them whether to write a how-to walkthrough or a straight answer to a question. A short list of related posts to link saves them from either ignoring internal linking entirely or reaching for whatever vaguely fits. Three lines of SEO context, placed together near the top of the brief, does more than a full technical audit dropped at the bottom where nobody reads it. What you do not need to include is every competing URL, a keyword difficulty score, search volume figures, or a breakdown of what the top-ranking pages cover. That information shapes your strategy before you write the brief. By the time a writer opens the document, those decisions are already made. Hand them the output, not the workings. A Brief Is a Conversation Starter, Not a Contract The most common mistake I see is a brief written as though it has to contain every answer before the writer even begins. The thinking is understandable. You want the finished article to match the vision in your head, so you try to pre-empt every possible detour. But a brief that attempts to control every decision leaves the writer no room to bring anything of their own, and the result tends to read that way. A better brief hands over enough context for the writer to understand the job, then trusts them to think. If you are working with someone good, they will come back with questions, and those questions will almost always sharpen the brief in ways you did not anticipate. That back-and-forth is not a sign that something went wrong. It is the brief doing exactly what it should. Treat it as a first draft of a conversation. Mark the things you feel strongly about, and be honest about the things you are less certain on, so the writer knows where their judgement has room to move. A good working content brief names the audience, the angle, and the outcome you want the reader to walk away with. Everything else is negotiable. When writers know which parts of the brief are fixed and which are open, they stop second-guessing and start writing. ------------------------------------------------------------ # SEO for Tradespeople: Why Most Trade Websites Never Rank Source: https://yorkshiredesign.co.uk/seo-for-tradespeople-why-most-trade-websites-never-rank/ Published: 2026-08-07 > A plumber in Leeds builds a website, pays someone a few hundred pounds for it, and then waits. Six months pass. No calls from Google. He assumes SEO is a scam, or that the big players have locked up every search result. Neither is true. The real problem is usually sitting in the site itself, quiet and unfixed, and it has nothing to do with how competitive the market is. The Site Looks Fine, But Google Sees Something Different When a search engine crawls a typical trade website, it doesn't see the clean layout or the professional photos. It reads the underlying code, the heading structure, the page text, and the signals that tell it what each page is about. Most brochure-style trade sites fall apart at this point. The homepage tries to cover everything at once, plastering boiler installations, bathroom refits, and general plumbing enquiries onto a single page with a handful of sentences and a contact form. Google has no way to distinguish which service matters most, and no depth of content to work with. Headings are often missing entirely, or used to make text look bigger rather than to signal topic structure. Images almost never carry alt text, so a photo of a recently fitted kitchen extension tells a crawler precisely nothing. The result is a site that reads as thin. Not broken, not penalised, just not substantial enough to compete against pages that answer the questions people are searching for. Fixing this doesn't require a redesign. It usually means separating on-page structure from the technical foundations and working through both properly, which takes time but produces changes that stick. Why "We Cover All of " Is the Wrong Approach A page that says "we cover the whole of Yorkshire" and leaves it there gives Google almost nothing to work with. Search engines need concrete signals to match a page to a local query, and a vague regional claim is not one of them. Think about what happens when someone types "emergency plumber Harrogate" or "kitchen fitter Skipton" into Google. The results tend to be pages that mention those towns specifically, not a page that gestures at an entire county. If your site lists twelve areas in a single sentence but never builds a dedicated page for any of them, you are asking Google to guess at your relevance for each one. It rarely guesses in your favour. The towns get no individual content, no local context, and no reason to rank above a competitor who took the time to write specifically about that area. The fix is not complicated, but it does take patience. A separate page per town, with real detail about the work you do there, outperforms a catch-all service-area paragraph every time. If you want to understand how on-page signals like location-specific copy combine with the broader structure of your site, that distinction matters more than most trade websites realise. Name the towns. Build the pages. Do the work. Thin Pages That Can't Hold a Position The most common pattern on trade websites is a Services page with a short paragraph under each heading. Boiler installation gets four sentences. Bathroom fitting gets three. It looks tidy, but from a search engine's perspective there is almost nothing to work with. Someone searching "boiler installation cost" or "what's involved in a new boiler fitting" has a specific question in mind. A page that doesn't cover what's included in the job, how long it typically takes, what needs to happen beforehand, or roughly what to budget for cannot satisfy that question. Google can see the gap, and so can the person reading it. Thin content doesn't just fail to rank. It often can't hold a position even when it briefly gets one. What depth actually means for a service page Search intent for a trade service is rarely as simple as "find me a plumber." People researching a job want enough detail to feel prepared before they pick up the phone. A boiler installation page that explains the difference between a system and a combi boiler, mentions that the job typically runs a full day, and notes that you'll need the water turned off beforehand, is a page that earns time on site. That time signals relevance. Pages that match the depth of what a searcher is looking for are exactly what on-page SEO best practice points toward, and thin trade pages sit at the opposite end of that spectrum. Page Speed and Core Web Vitals on Trade Sites Most trade websites arrive pre-loaded with problems before a single word of content is written. The theme ships with a full-width slider on the homepage, a rotating gallery of stock scaffolding photos, and three or four page builder scripts all firing on load. That combination routinely pushes Largest Contentful Paint, the time it takes for the main visible element to fully render, well past four seconds on a mid-range Android phone on a 4G connection. Google measures LCP as one of its Core Web Vitals signals, and a score that poor sits in the red zone, feeding directly into how the page is ranked against competitors. Cumulative Layout Shift is the other common offender on these sites, caused by images loading without fixed dimensions so the whole page jumps around as a user tries to tap a phone number. Why mobile performance matters more than desktop The majority of people searching for a plumber or an electrician are doing it from a phone, often in the middle of a problem. A page that shifts and stutters while they're trying to find a contact number loses the job before the phone rings. That detail matters more than most builders realise. Stripping out unused scripts and replacing heavy sliders with a single optimised image makes a measurable difference. The fixes are unglamorous but the results are not. What a Trade Website Needs to Rank None of this is complicated. It is methodical, and most trade websites skip the method entirely. Start with the page structure. Every service you offer needs its own dedicated page, written specifically for that service, not bundled onto a single "what we do" catch-all. A plumber covering boiler installations, bathroom fitting and emergency call-outs should have three separate pages, each with its own content, its own headings, and its own area references. Those references matter. Mentioning the actual towns and areas you cover, by name, throughout the page copy tells search engines exactly where you operate. Pair that with a Google Business Profile that carries the same address, phone number and service details as the website, because any mismatch between the two creates a credibility problem Google tends to penalise. On the technical side, the site needs to load fast on a phone. Most trade enquiries come from mobile, and a slow, bloated build loses those visitors before they have read a single line. If you want a fuller picture of how the relationship between technical foundations and on-page content affects rankings, that distinction is worth understanding before you start making changes. Getting all of this right takes time. Don't expect a page published today to rank by next week. The groundwork builds gradually, and that is exactly how it is supposed to work. How Long This Takes and What to Expect A trade site that has been sitting untouched for years, with thin page content and no backlinks pointing to it, does not turn around quickly. The first few months of work are almost entirely invisible from the outside. Fixing crawl errors, tightening up page structure, rewriting service pages so they say something useful, sorting out slow load times, none of that shows up as a ranking jump the following week. It's foundation work, and foundations take time to settle before anything built on top of them becomes visible. Most clients won't see meaningful movement in search positions until around the four to six month mark, and for competitive trades in busy areas it can be longer. The temptation is to push out a lot of content fast and hope something sticks. That approach tends to backfire. Pages start competing with each other for the same search terms, diluting whatever authority the site had, and Google ends up confused about which page to rank. A handful of carefully written, well-targeted pages almost always outperforms a flood of thin ones. Patience here isn't just good advice. It's the reality of why search engine optimisation takes as long as it does. The work that moves the needle is mostly done before results appear. ------------------------------------------------------------ # CDN for WordPress: What It Does and Whether You Need One Source: https://yorkshiredesign.co.uk/cdn-for-wordpress-what-it-does-and-whether-you-need-one/ Published: 2026-08-07 > A CDN sounds like a quick win for any slow WordPress site. In some cases it absolutely is. But bolt one on without understanding what's causing the slowness and you'll still have a slow site, just with more moving parts to troubleshoot. Whether a CDN makes sense for your setup depends on a handful of fairly specific factors, and most advice glosses over the cases where it won't move the needle much at all. What a CDN does to your WordPress site Strip away the marketing language and a CDN does one thing, it puts copies of your files closer to the person trying to load them. Your WordPress site lives on an origin server, probably in one data centre somewhere in the UK or the US. Every time someone loads your homepage, their browser has to reach that server, wait for it to respond, and pull back the files it needs. Static assets, things like your CSS stylesheets, JavaScript files, fonts, and compressed images, don't change between visits. A CDN copies those files onto a network of servers spread across multiple countries and cities, and when a visitor requests your site, those files come from whichever server is geographically nearest to them. A visitor in Sydney gets your logo from a server in Australia, not one in a London data centre. That shorter physical distance translates directly into lower latency, and lower latency means a faster-feeling page. What the CDN does not serve is a separate matter. Your WordPress database, PHP processing, dynamic page generation, logged-in user sessions, and anything produced by server-side logic all still come from your origin server. A CDN offloads the weight of repeated, identical file requests, and that can meaningfully reduce the load on your hosting, but it doesn't replace the origin. It sits in front of it. The difference it makes to Core Web Vitals Two metrics feel the impact of server distance more than anything else: Time to First Byte (TTFB) and Largest Contentful Paint (LCP). TTFB measures how quickly the browser receives the first byte of a response, and a CDN shrinks that gap by serving cached assets from a node physically closer to the visitor. If your origin server sits in a US data centre and someone loads your site from Manchester, every uncached request travels across the Atlantic and back. A CDN node in London cuts that round trip to milliseconds. LCP then benefits because the browser can start painting the dominant image or text block sooner, once that initial connection overhead drops. Google's own Core Web Vitals guidance treats TTFB as a foundational signal precisely because delays compound through every subsequent load step. When a CDN improves LCP The clearest wins come on static assets. Hero images, fonts, and cached HTML pages served from edge nodes consistently pull LCP times down, particularly for visitors far from the origin. Sites with a global or wide national audience see the biggest shifts, sometimes shaving half a second or more off LCP on slower mobile connections, where network latency already hurts. If you have already done proper WordPress image optimisation, a CDN amplifies that work rather than replacing it. When it doesn't move the needle Dynamic pages that bypass the cache tell a different story. WooCommerce cart pages, logged-in dashboards, and personalised content usually can't be cached at the edge, so every request still hits the origin. A CDN won't rescue a slow PHP response time on those pages. Fix the server first. Who sees a real speed gain A local plumber, a village café, a regional accountancy firm. If your visitors are almost entirely based within 50 miles of a well-located UK server, a CDN gives you very little. The content is already close. The latency is already low. Where you tend to see a CDN make a measurable difference is on sites serving heavy image galleries or video thumbnails to users spread across multiple countries. A fashion retailer shipping to Australia and Canada from a London-based origin server, for instance, can cut delivery times noticeably once static assets are cached at edge nodes close to those users. Geography is the deciding factor, not the size of the site. The other variable to consider is asset weight. A text-heavy blog with modest traffic rarely strains a decent host, CDN or not. But a site pushing large product images to high volumes of concurrent visitors is exactly where image delivery settings and CDN caching start to work together in a way that shows up in your Core Web Vitals scores. If your audience is concentrated and your host is nearby, spend that time elsewhere. If your traffic is spread out or your pages are image-heavy, a CDN earns its place. How a CDN fits with managed WordPress hosting Most managed WordPress hosts have already done a fair amount of this work for you. Kinsta runs on Google's network and serves static assets from edge locations by default. WP Engine bundles its own CDN layer through Cloudflare. Pressable, Flywheel, and several others follow a similar pattern. That means before you sign up for a separate Cloudflare plan or a third-party CDN subscription, open your hosting dashboard and check exactly what is already running. If your host is already caching at the edge, adding another CDN layer on top does not double the speed gains. What it can do is create cache conflicts, where two systems disagree about which version of a file is current, or generate double origin requests when the outer CDN misses its cache and asks the inner one, which then has to call the server anyway. For sites on managed WordPress hosting plans that already include a global edge network, a separate CDN is often redundant overhead rather than a real improvement. Check the support docs for your specific plan, not just the marketing page. The headline feature and the default configuration for your tier are not always the same thing. The options most WordPress sites end up using Most sites land on one of three options: Cloudflare's free tier, Bunny CDN, or whatever the hosting provider bundles in. Cloudflare Cloudflare is the obvious starting point because it costs nothing and takes about twenty minutes to set up. You point your nameservers at Cloudflare and it proxies your traffic through its network automatically. The free tier covers most of what a small or medium site needs, static asset caching, basic DDoS protection, and a global edge presence. The thing to watch is that Cloudflare operates as a reverse proxy, so it sits between your visitor and your server for all traffic, not just static files. That changes how some plugins behave, particularly caching plugins. Make sure they're not fighting each other by caching the same thing twice, which is a common misconfiguration that quietly undoes the benefit. If you're on managed WordPress hosting with a built-in CDN layer, adding Cloudflare on top needs careful thought before you enable it. Bunny CDN and host-bundled options Bunny CDN suits sites where you want more control over what's cached and what isn't, at a low per-gigabyte price. It's popular with sites that serve a lot of images or video, and its configuration is more transparent than Cloudflare's. As for host-bundled CDNs, check what you already have before paying for anything separately. Some are limited to a specific region; others are solid enough that adding a third-party option would duplicate the effort for no real gain. What a CDN won't fix A CDN moves your files closer to the person requesting them. That's the whole job. What it cannot do is make those files smaller, leaner, or less demanding on the browser once they arrive. A 4MB hero image served from a server 20 miles away instead of 4,000 miles away is still a 4MB hero image. Render-blocking scripts that hold up the page while a browser waits to parse them will hold it up regardless of where they're hosted. Unoptimised images, bloated plugin assets, slow database queries pulling hundreds of rows to render a simple sidebar widget, none of these are delivery problems, and a CDN doesn't pretend to solve them. The mistake people make is running a speed test after setting up a CDN, seeing an improvement, and assuming the job is done. That improvement is real, but it only tells you delivery got faster, not that the page itself is well built. Core Web Vitals scores can still fail badly on a CDN-enabled site. Largest Contentful Paint, Cumulative Layout Shift, and Interaction to Next Paint are shaped by what's on the page, not just how quickly it crosses a network. Think of it as a faster road to a cluttered warehouse. The journey shortens, but the work waiting at the other end stays exactly the same. ------------------------------------------------------------ # AI Automation for Small Businesses: Where the Real Time Savings Are Source: https://yorkshiredesign.co.uk/ai-automation-for-small-businesses-where-the-real-time-savings-are/ Published: 2026-08-07 > Most small business owners who ask about AI automation are picturing one thing, getting hours back. That instinct is right, but the hours tend to hide in places people don't immediately think to look. It's rarely the big obvious jobs that AI handles best at first. It's the small, repetitive tasks that stack up across a week and quietly consume far more time than anyone realises. Knowing where to start makes the difference between a tool that earns its keep and one that gathers digital dust. What AI Automation Does in a Small Business Context Forget the enterprise IT version of this. For a small business, AI automation is much simpler and far more useful day-to-day. Think of it as setting up a system that handles the repetitive, low-thinking tasks that eat into your working hours. A customer fills in a contact form on your website, and instead of that sitting in an inbox until Monday morning, the details flow straight into your CRM, a confirmation email goes out automatically, and a follow-up reminder lands in your calendar. Nobody touched it. The same idea applies to invoice chasing, where a payment reminder goes out three days after the due date without you remembering to send it. Social media scheduling works the same way. A week's worth of posts is queued and published while you're focused on the job in front of you. Customer support too, a well-configured auto-reply handles the most common questions without someone sitting on live chat all afternoon. None of this replaces the thinking parts of running a business. What it does is clear the clutter around them. The realistic expectation is a few hours saved each week, less admin falling through the cracks, and fewer of those small tasks that pile up and eventually become a proper problem. For most small businesses, that's the scale that saves time in a meaningful way. The Tasks That Eat Your Week Without You Noticing The time doesn't disappear in one go. It goes in small, forgettable chunks. A reply to the same enquiry you answered last Tuesday. A copy-paste from your booking form into a spreadsheet. A reminder email to a client whose invoice has been sitting unpaid for two weeks. A post scheduled manually on one platform when it needed to go out on three. Each of those tasks might take ten minutes. Do five of them every working day and you've spent fifty minutes. Across a full month, that's roughly eight hours, a complete working day, gone on things that follow the exact same pattern every single time. That's the nature of repeatable business workflows: they feel trivial in the moment and significant only when you add them up. Data entry is probably the worst offender. A customer fills in a form, and someone has to move that information into a CRM, an invoice system, and a project tracker. Three tools, same data, done by hand, every time. None of this is skilled work. That's the point. Where the Real Time Savings Show Up First Email and enquiry handling This is where small operators tend to feel the relief fastest. A simple automation that reads a contact form submission, categorises it, sends an acknowledgement, and drops the lead into a spreadsheet or CRM can cut twenty minutes of admin per enquiry down to near-zero. Booking and appointment confirmations work the same way. A client fills in a form, a confirmation goes out automatically, a calendar entry gets created, and a reminder fires the day before. No back-and-forth, no forgotten replies, no double-bookings to untangle later. That kind of routine task automation is where most small businesses recover four to six hours a week without changing how they work at all. Content scheduling and data entry Scheduling is obvious once you see it laid out. A post drafted on Monday publishes to three channels on Thursday with no manual steps in between. Data entry is less glamorous but probably more valuable. Copying an invoice total from one system into another, or moving a customer record from a form into a database, takes seconds per row but adds up to hours across a month. Automating that connection between apps removes the error risk too, which is where the real cost of doing it manually usually hides. What Takes Longer Than People Expect The first automation you build properly will take longer than you think. Not because the tools are difficult, but because the thinking behind them is. Before a single trigger fires, you need to map out exactly what the process does today, where the data comes from, what happens when something goes wrong, and what "done correctly" looks like. Most small business owners have never had to articulate that in detail because a human was always there to fill the gaps with judgement. An automation can't do that, so every gap has to be found and filled before you switch it on. That groundwork, the scoping and the logic-mapping, is where most of the time goes, and it's invisible to anyone watching from the outside. Testing takes longer than setup in most cases. A workflow that handles routine business tasks needs to be run through edge cases, a contact with a missing field, a form submission that arrives at midnight, an order where the customer changed their mind halfway through. Each one surfaces something to fix. The payoff is real. But it rarely arrives in week one. Choosing Your First Automation Wisely Most failed automation attempts start the same way. Someone picks the flashiest tool first and figures out the workflow later. A better approach is to work backwards from the task itself. Look for something that happens more than three times a week, follows a predictable sequence every single time, and doesn't need a human to make a judgement call mid-way through. Invoice reminders, new enquiry acknowledgements, appointment confirmations, stock-level alerts, these are the kinds of tasks that fit. They're repeatable, low-risk to automate, and their output is easy to check. Before you open any tool, map the workflow on paper. Write down every step from trigger to outcome, note where data moves between systems, and flag any point where a person currently has to make a decision. That map tells you whether the task is automatable or whether it only looks simple on the surface. A good AI workflow planning approach will surface those hidden decision points before they become a problem inside a live automation. Start with one workflow, get it running cleanly, and resist the urge to bolt on a second before the first has been tested properly. The time savings compound once the foundation is solid, not before. How Far Can a Small Business Realistically Go? Further than most people assume A solo operator or a micro-team of two or three can automate a meaningful chunk of day-to-day admin using tools that cost less per month than a tank of petrol. Automated invoice reminders, appointment confirmations, social post scheduling, contact form follow-ups, basic customer onboarding sequences, none of that requires a developer or a bespoke system. Free tiers on tools like Zapier or Make will handle a surprising amount of it, and the setup time, once you've mapped out what repeats in your week, is often measured in hours rather than days. The real gain is not just the minutes saved on each task. It's the mental overhead that disappears when you stop carrying those small recurring jobs in your head. Where people still need to be involved Anything that needs judgement, nuance, or a human response still needs a person. Handling a complaint, writing a proposal for an unusual brief, deciding whether a long-standing client gets a discount, those are not tasks you hand to a workflow tool and walk away from. The sensible goal is freeing up thinking time, not eliminating every human touchpoint from your business processes. Get the repetitive, predictable tasks off your plate, and use the hours you recover on the work that needs you. ------------------------------------------------------------ # WordPress Robots.txt: What It Controls and What It Does Not Source: https://yorkshiredesign.co.uk/wordpress-robots-txt-what-it-controls-and-what-it-does-not/ Published: 2026-08-06 > A robots.txt file is one of those things that looks simple until you realise what it genuinely cannot do. It sits at the root of your WordPress site, a few lines of plain text, and most people either ignore it completely or throw in disallow rules they copied from a forum post years ago. Neither approach serves you well. Getting it right is quiet, unglamorous work , but it affects which parts of your site Google spends time crawling and which it skips. What robots.txt is in WordPress Most site owners never think about robots.txt until something breaks. At that point it becomes urgent, and the fix usually turns out to be simpler than the panic suggested. A robots.txt file is a plain text file sitting at the root of your domain, at yoursite.com/robots.txt, and it tells search engine crawlers which parts of the site they are allowed to fetch. It is not a security measure and it does not block human visitors. It is a set of directives written in a format that crawlers like Googlebot read before they decide what to crawl. The key word there is "decide". Robots.txt is a request, not an enforcement mechanism, and a badly configured one can cause real damage to how your pages get indexed. WordPress generates this file automatically. There is no physical robots.txt sitting in your server's file manager by default. Instead, WordPress creates it on the fly whenever a crawler requests it, pulling together a small set of default rules. You can see exactly what yours contains by visiting yoursite.com/robots.txt in a browser right now. If you want to override those defaults, you have two options. You can create a real physical robots.txt file and upload it to your root directory, which takes precedence over the virtual one, or you can use a plugin such as Yoast SEO or Rank Math to edit the virtual version from within the WordPress dashboard. Either route works. The physical file approach is more reliable because it does not depend on WordPress loading correctly to serve the rules. Crawl budget and why it matters Search engines don't have infinite patience. Googlebot allocates a crawl budget to each site, and once that quota is spent, it moves on. If your robots.txt isn't blocking the right paths, crawlers burn through that budget on pages that will never rank and should never be indexed. The usual culprits are WordPress's /wp-admin/ directory, internal search result pages generated by /?s= queries, tag archives that duplicate category content, and paginated author archives that thin out with every click. None of those pages serve a searcher. Every one of them wastes a crawl request that could have gone to a product page, a service page, or a piece of content you want to rank. Blocking them in robots.txt is the single fastest way to redirect that budget toward pages that matter, and it costs nothing to implement. What to block The paths to disallow follow a clear pattern. Block /wp-admin/ while keeping /wp-admin/admin-ajax.php open so front-end forms still fire. Add /wp-login.php, /?s= for search queries, and any tag or author archive you aren't actively curating. If you run WooCommerce, cart and checkout pages belong on that list too. For anyone already looking at their Core Web Vitals scores in Search Console, an overcrawled site adds noise to that data and makes it harder to spot the pages with real performance problems. Cleaning up crawl paths consistently frees up budget for the pages that deserve it. The one thing robots.txt cannot do Blocking a URL with a Disallow rule tells Google's crawler not to visit that page. It does not tell Google the page does not exist. That distinction trips people up constantly. If another site links to your blocked URL, Google can still discover it, index it, and show it in search results, all without ever crawling the content. You end up with a result in the SERPs that displays nothing more than the URL and perhaps a snippet scraped from an external link's anchor text. It looks broken, it gives users nothing, and you have no control over how it appears. Disallow is a crawl directive. Noindex is an indexing directive. They operate at completely different stages, and only one of them removes a page from Google's index. If you want a page kept out of search results, a properly configured WordPress site should deliver that via a noindex meta tag or an X-Robots-Tag header, not through robots.txt. The noindex directive is something Google reads on the page itself and acts on directly. There is also a secondary problem with combining the two approaches, if the crawler cannot reach the page, it cannot read the noindex tag, so the directive never gets processed. Block the crawl, lose the noindex. The two should never be applied to the same URL at the same time. Common WordPress robots.txt mistakes The most damaging error I see on real sites is blocking /wp-content/ entirely. It looks harmless at first glance, particularly if someone is trying to prevent direct access to uploaded files, but that directory is also where WordPress serves your theme stylesheets, JavaScript files, and plugin assets. Block it and Googlebot cannot render your pages properly. Google's crawler needs those CSS and JS files to understand your layout, assess your Core Web Vitals, and decide whether your content is visible to a user. A rendered page and a raw HTML document look very different to a search engine, and a misconfigured robots.txt is often the reason a site that looks fine in the browser is performing poorly in search. You can verify what Googlebot can and cannot access using the URL inspection tool inside Google Search Console alongside your Core Web Vitals data, which will flag render-blocking issues caused by disallowed resources. Two other traps worth watching Copying a generic robots.txt template from a blog post is a common mistake. Rules written for a WooCommerce store will conflict with a portfolio theme. Rules that assume a specific permalink structure break silently after a URL rebuild. Site migrations catch people out too. After moving from a staging domain or changing directory structure, old disallow rules frequently carry over unchanged, blocking paths that no longer match the live site's actual layout. Nobody notices until coverage drops. How to test what your rules are doing Writing a robots.txt rule and assuming it works are two different things. Test it before you assume anything. Google Search Console has two tools that together give you a clear picture. The robots.txt tester, found under the old Search Console interface but still accessible via its direct URL, lets you paste your file and check a specific URL path against it. It tells you which rule matched and whether the result is "allowed" or "disallowed". That alone catches a surprising number of mistakes, particularly overly broad wildcard patterns that block more than intended. A pattern like Disallow: /wp-content/ looks harmless until you realise it is blocking the stylesheet and script files that Googlebot needs to render the page. The tester surfaces this immediately. The URL Inspection tool in the main Search Console goes further. Enter a specific URL, hit "Test Live URL", and Google will show you what it can crawl and render right now. If the coverage report flags a page as "Blocked by robots.txt", the inspection result tells you exactly why, which rule is responsible, and whether the block is intentional. If you are also working through Core Web Vitals issues in WordPress, that live render view is useful for spotting blocked resources that degrade Largest Contentful Paint scores. Run both tools after any change to your robots.txt file. Not just when something looks broken. How Yorkshire Design approaches robots.txt Robots.txt is rarely broken in isolation. When a site has crawl problems, the file is almost always one piece of a larger puzzle alongside duplicate content, index bloat, slow server response times, and orphaned pages that have no business being crawled at all. The approach here is to look at the whole picture before touching a single directive. That means pulling a crawl report, checking Google Search Console for coverage errors, and cross-referencing what the file currently blocks against what the site actually needs indexed. A directive that looks harmless on its own can starve a whole section of the site if something else in the architecture is already limiting crawl budget. That kind of compounding problem is easy to miss if you only glance at the file in isolation rather than reading it against the rest of the site's Core Web Vitals and technical health signals. Robots.txt is one layer, not a strategy. Getting it right means understanding everything around it first, and that takes proper time to do thoroughly. If you want a clear-eyed review of how your WordPress site handles crawling, indexation and overall technical structure, the technical SEO service at Yorkshire Design covers exactly that. No guesswork, no template audits. ------------------------------------------------------------ # How to Report SEO Results to Clients Who Tune Out Data Source: https://yorkshiredesign.co.uk/how-to-report-seo-results-to-clients-who-tune-out-data/ Published: 2026-08-06 > Most clients are not staring at Google Search Console every morning. They have a business to run. So when you drop a spreadsheet full of impressions, CTR and average position in their inbox, the chances are it gets skimmed and forgotten. That does not mean the work is not landing. It means the report is not speaking their language. Here is how to change that, step by step, without dumbing it down or spending half your week writing essays. Start With What the Client Actually Cares About Most clients do not lie awake thinking about organic impressions. They think about whether the phone rang. Before you touch a single metric, ask one question, what does a good month look like to you? Nine times out of ten the answer involves enquiries, bookings, or a number on an invoice, not a position ranking or a click-through rate. That answer is your anchor. Every figure in your report should trace a clear line back to it. If you are showing a 40% rise in organic sessions but the client's inbox is quiet, that number means nothing to them, and honestly, it probably should not mean much to you either. SEO reporting for clients only earns its keep when the data connects to something the client already cares about measuring. A useful trick is to write the report's headline sentence before you pull a single screenshot. Something like: "Organic search sent 63 more visitors to your contact page this month compared with last." That forces you to find the metric that matters, rather than defaulting to the dashboard's default view. It also gives the client a sentence they can repeat to a business partner without needing to understand what a crawl budget is. Strip the Report Down to Five Numbers Most clients do not need seventeen tabs of data. What they need is a short list of numbers that tell them whether the work is paying off. Pick four signals and one trend line Organic sessions shows whether more people are finding the site through search. Top ranking keywords shows whether the right pages are climbing. Conversions from organic shows whether that traffic is doing anything useful once it lands. One trend line, usually sessions or conversions over the last three months, gives the picture movement rather than a frozen snapshot. Those four data points, with a single directional trend beneath them, tell most clients everything they came to the meeting to hear. The temptation is always to add more. Keyword difficulty scores, crawl coverage percentages, domain authority figures, bounce rate breakdowns. Every extra metric dilutes the ones that matter and gives a disengaged client somewhere to get lost. A good rule of thumb, if removing a metric would not change the conversation, it should not be in the report. Why fewer numbers spot problems faster The five-number approach makes it far easier to see a real problem when one appears. If SEO timelines stretch longer than a client expected, a stripped-back report keeps the focus on steady directional progress rather than a wall of flat figures that are hard to read without context. Translate Jargon Before It Reaches Them Most clients do not know what "impressions" means, and there is no reason they should. The terminology that search tools default to was written for people who already live inside the data. Before any report goes out, swap every technical label for plain language. "Impressions" becomes "how many times Google showed your site to someone searching." "Average position" becomes "where you typically appear in the results." "CTR" becomes "the share of people who clicked through to you." Keep these translations consistent from one month to the next, and something useful starts to happen. Clients begin reading their own numbers with confidence rather than skipping straight to whatever figure you have highlighted for them. A client who understands what they are looking at can have a proper conversation about what is working and what is not, rather than just nodding along. The plain-English habit also protects you. If a client has been nodding along for months without understanding the reports, the moment results dip they have no frame of reference and the figures feel alarming out of context. When you have been consistent with your translations, they already know that SEO timelines take time and that a single month's movement rarely tells the full story. That shared vocabulary means the data becomes something you both look at together, rather than something you present to a room full of crossed arms. Show Direction, Not Just a Snapshot A single month's numbers are almost impossible to read in isolation. Organic clicks up 12% sounds good until you realise the previous month was unusually low because of a bank holiday weekend, or a technical issue that got fixed mid-month. When you show a client one number with no surrounding context, you are asking them to form an opinion about a photograph when what they need is a short film. Why a rolling comparison works A rolling three-month comparison strips out that noise. It shows whether the site is moving in a consistent direction, and that consistency is far easier for a non-data person to trust than a single figure that could mean almost anything. The trend conversation is also where you manage expectations honestly. SEO compounds slowly. Early months often show modest movement, and the more meaningful gains tend to arrive three, four, sometimes six months into a proper programme. If you only ever show the latest snapshot, clients start to question whether anything is working. Show a line that is climbing across the quarter, and the patience tends to follow naturally. For anyone curious about common misconceptions around SEO timelines, the gap between effort and visible results is the one that catches most clients off guard. Showing direction bridges that gap better than any single metric can. Use a Visual That Takes Ten Seconds to Read Most clients do not read reports. They scan them for about thirty seconds, form a feeling, and move on. That is not a criticism. It is how people process information when they are running a business and have twelve other things competing for their attention. The fix is to stop building reports that reward close reading and start building ones that land on first glance. A single bar chart showing organic traffic over the last three months does more work than a five-tab spreadsheet full of impressions, CTR and crawl error counts. A two-column summary table, with "last period" on the left and "this period" on the right, tells the story in a format that requires no interpretation. The client sees a number go up or down and understands it immediately. That is the entire goal. Strip out every metric the client did not ask about and did not raise in conversation. Extra numbers do not add credibility. They add noise. If you are using automated tools to pull together SEO data, use that saved time to curate harder, not to include more. One focused visual, built around the two or three numbers that connect to the client's goal, beats a comprehensive report that nobody opens past page one. Tell Them What Happened and What Comes Next The clients who glaze over at a traffic graph will stay engaged if you close every report with two things in plain English. What changed this period, and what you are doing about it next. Keep it brief. Something like "your contact page picked up twelve more visits from search this month because we tightened the page title in early October, and next we are working on the service pages that are sitting just off page one" tells the whole story in two sentences. It names a cause, names a result, and gives the client something to look forward to. That forward-looking line matters more than most people expect. Without it, the report feels like a receipt rather than a plan, and non-data clients stop reading receipts very quickly. A clear next step keeps the work feeling purposeful even when the numbers are moving slowly, as they often do in the early months of SEO. Write this summary last, after you have pulled together the rest of the report, so you are not guessing at what to say. The common misunderstandings around SEO timelines tend to surface here, and having a specific next action ready is the simplest way to head them off. Two or three sentences is enough. If you need a paragraph to explain what happened, the explanation is too complicated. ------------------------------------------------------------ # What Actually Happens When We Rebuild a Website From Scratch Source: https://yorkshiredesign.co.uk/what-actually-happens-when-we-rebuild-a-website-from-scratch/ Published: 2026-08-06 > Most clients picture a rebuild as swapping one design for another, like repainting a room. The reality is closer to gutting the walls and rewiring the electrics while keeping the lights on. A full rebuild from scratch touches the database, the hosting stack, the URL structure, the performance architecture, and the content, all at once. Understanding what that actually involves changes how you plan for it, and how long you give it. The Audit That Comes Before Any Design Work Before a single colour is chosen or a wireframe sketched, the existing site gets taken apart. That is where a proper rebuild begins. The audit covers everything the casual observer would not think to check. Which pages are indexed and which have dropped out of Google's view. Whether the crawl is hitting redirect loops, thin content, or orphaned pages that stopped serving a purpose years ago. Page speed scores across mobile and desktop, broken internal links, duplicate title tags, missing canonical tags, and whether the current hosting setup is actively holding the site back. If there is an existing blog archive, that gets examined too, because thin or duplicate posts can drag the whole domain's authority down and nobody notices until a rebuild shakes things loose. The point is not to produce a long document for its own sake. It is to understand what the site is doing before any assumptions get baked into the new build. Skipping this step is where rebuilds go wrong. A new design sitting on top of unresolved structural problems just looks better while performing the same. The audit is what stops that happening, and it takes longer than most people expect, because the signals that matter rarely sit on the surface. Choosing the Right Foundation The stack decisions made in the first few hours of a rebuild shape everything that follows. Hosting environment, theme architecture, whether to use a page builder or write custom code, how the database is structured. These are not cosmetic choices. Pick the wrong hosting stack and you are fighting server response times before a single line of CSS is written. Choose a bloated page builder because it looks impressive in a demo and you will spend months working around the performance ceiling it imposes. The real danger is that none of this is obvious to the client during a project. It only surfaces six months later when pages are slow to load, the editor keeps crashing, or adding a new section breaks the layout on mobile. By that point, unpicking it is expensive. Getting these decisions right at the start is far cheaper than fixing them after the content is in. Theme Architecture Theme architecture matters more than most people assume. A lightweight, well-structured base theme, or a clean custom build, gives you somewhere solid to work from. Heavy multipurpose themes that bundle every feature imaginable are the exact opposite of that. They register scripts and styles across every page whether you need them or not, and that dead weight shows up directly in your Core Web Vitals scores. None of this is visible when the site launches. That is precisely why it matters. What Happens to Your Existing Content and URLs Every URL on your current site has a history. Some have earned links from other websites, citations in directories, or years of consistent traffic from search engines. When a rebuild ignores that, those signals do not transfer automatically. They stop working. The right approach is to audit every URL before a single line of new code gets written, map each old address to its equivalent on the new site, and put proper 301 redirects in place so that search engines follow the trail rather than hitting a dead end. It takes time to do this thoroughly, but the alternative is watching rankings you spent years building collapse within weeks of launch. A careless rebuild that drops even a handful of high-value URLs can do real damage. Search engines treat a missing page as a broken promise. Content Consolidation Content itself needs the same attention. It is tempting during a rebuild to add volume, but what an SEO audit almost always shows is that fewer, more focused pages outperform a sprawling site where similar content competes against itself. The redirect map and the content audit belong together. You look at what exists, what it ranks for, what can be consolidated, and what needs to survive intact. Only then do you start building the new structure around what matters. Performance Is Built In, Not Bolted On The single biggest mistake I see on rebuilt sites is treating performance as a final step. A caching plugin gets added, images get compressed in bulk, and a speed score gets checked once before launch. That approach almost always leaves measurable points on the table. When Core Web Vitals are considered from the first day of the build, the decisions look completely different. Images get sized and formatted at the point they are created in the pipeline, not retrospectively squeezed through a plugin. WebP conversion, correct srcset attributes, and explicit width and height declarations all go into the theme templates themselves. Scripts are ordered deliberately so nothing render-blocking sits between the browser and the first visible content. Fonts load with font-display:swap so the text appears immediately rather than waiting on an external file to return. None of that is complicated in isolation, but it takes time to wire together properly across every template, post type, and page layout. Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. Each one has a root cause that sits somewhere in the build decisions, not in a plugin settings panel. Getting good scores on a technical SEO audit after launch is far easier when the architecture was set up with those constraints in mind from the start. Retrofitting is slower, and it rarely gets you all the way there. Testing Before Anything Goes Live This phase takes far longer than most people expect. A day of testing is rarely enough. A proper pre-launch check covers a lot of ground that has nothing to do with how the site looks. Every internal link gets clicked. Every form gets submitted and the routing checked at the receiving end, not just assumed to be working. Redirects from the old URL structure get tested one by one to confirm the 301s are firing, because a missing redirect hands Google a 404 where a ranked page used to sit. Mobile layout gets checked across real screen sizes, not just a browser's responsive toggle, because the two can behave differently in ways that only show up on a physical device. Render paths matter too, particularly for pages built with JavaScript-heavy components where a crawler might see something quite different from what a visitor sees. If the full redesign process has shifted the page hierarchy significantly, the redirect map alone can run to dozens of entries that each need verifying. Clients sometimes wonder why this is not done in an afternoon. The honest answer is that each of these checks surfaces something small, and small things in the wrong combination can sink a launch. Getting them right before the site goes public is always faster than unpicking them afterwards. The Week After Launch DNS switching over is not the finish line. It feels like one, but the real monitoring work starts the moment the old site goes dark. The first thing to check is crawl coverage. Google's crawlers will revisit the site within hours of the change, and if any redirects are malformed or a noindex tag was left in place from the staging build, pages can vanish from the index before most people even notice the site is live. Search Console usually flags crawl errors within 24 to 48 hours, so that is where attention sits early on. Alongside that, indexing signals need watching carefully, particularly for any URLs that ranked well on the old site and need to confirm they are being picked up correctly under the new structure. Speed scores also want a second look at this stage. A rebuild that tested at 95 in a staging environment can regress once real assets, third-party scripts and live traffic load together on the production server. Font files, uncompressed images that slipped through QA, a cookie consent script loading synchronously. Any of these can drag Largest Contentful Paint back into amber territory, and that affects ranking. Checking all of this takes a few days of methodical work. There is no shortcut around it. ------------------------------------------------------------ # Technical SEO vs On-Page SEO: What Actually Separates Them Source: https://yorkshiredesign.co.uk/technical-seo-vs-on-page-seo-what-actually-separates-them/ Published: 2026-08-06 > Most SEO conversations lump these two together as though they're the same job. They're not. One lives in the code and server layer your visitors never see; the other sits in the words and structure they read every day. Getting clear on which is which stops you fixing the wrong thing first, and that distinction matters more than most guides let on. What On-Page SEO Covers On-page SEO is the layer a content editor can work through without opening a single file or writing a line of code. It covers everything a visitor can read or interact with directly on the page. The title tag and meta description tell search engines what the page is about before anyone clicks. The H1 sets the primary subject, with H2s and H3s organising the content beneath it in a logical structure. Body copy carries the actual meaning, the words, the context, the answers to the questions people are searching for. Image alt text describes what a graphic shows, both for screen readers and for crawlers that cannot see the image itself. Internal links connect one page to another, spreading relevance across the site and guiding readers toward related content they might need. None of that requires server access or a developer on call. A reasonably confident content editor can handle it all from inside the CMS. What on-page SEO cannot touch is the infrastructure underneath. Page speed, crawl paths, canonical tags, structured data, server response codes , all of that lives at a different layer entirely. On-page work shapes what the page says and how it is presented. Whether the page can be found, loaded and understood in the first place is a separate question. What Technical SEO Is Actually Doing Underneath The infrastructure layer Technical SEO has nothing to do with the words on a page or how a heading is phrased. What it covers is whether Googlebot can find your pages, crawl them without hitting dead ends, and render them correctly. That means server response times, canonical tags that prevent duplicate content from splitting your ranking signals, hreflang attributes that tell search engines which version of a page to serve in which country, structured data that gives Google a machine-readable summary of your content, and render-blocking resources that delay the browser from painting the page. Core Web Vitals fall squarely here too, measuring load speed, layout stability and interactivity in ways that feed directly into how Google scores the experience of landing on your site. None of this is visible to someone reading the page. A reader sees a headline and some text. Google sees HTTP status codes, crawl budgets, indexation signals, and whether your JavaScript is blocking the parser before a single word loads. Why it gets neglected That invisibility is exactly what makes it so easy to overlook. Sites can sit with broken canonical chains, misconfigured redirects, or pages accidentally blocked from indexation for months before anyone notices. By the time it shows up in rankings, the damage is already done. Where the Two Overlap Page speed is the clearest example of a genuine grey zone. A slow page frustrates visitors and pushes up bounce rates, which is an on-page concern about the experience someone has when they land. But that same slowness also burns crawl budget, because Googlebot spends time waiting for responses it could be spending crawling more of your site. One problem, two sets of consequences. The same logic applies to internal linking. The editor choosing which posts to link from a piece of content is making an editorial, on-page decision, but every one of those links is also a crawl path that tells search engines which pages are worth following and how authority flows between them. The overlap is real, but it does not make the two disciplines interchangeable. Structured data sits in a similar position. Writing clear, well-organised content is on-page work; adding schema markup that helps search engines parse that content is technical. Both serve the same goal, and you often have to touch both at once to get the result you are after. When you fix something in one camp, it is worth asking whether there is a matching job to do in the other. Page speed improvements often reveal crawling gaps. A content audit often surfaces broken internal link chains. Treating them as completely separate workstreams means you will occasionally miss that second half of the problem. Which One to Fix First Technical SEO is the floor Technical SEO forms the floor everything else stands on. A page with sharp copy, a well-researched title tag, and a clear heading structure will still underperform if the crawler cannot reach it cleanly, the canonical is pointing somewhere odd, or the LCP is sitting at four seconds on mobile. The on-page work has not been wasted, exactly, but it is working against resistance. Think of a site where the XML sitemap is submitting URLs that 301 redirect elsewhere, so Googlebot is spending crawl budget bouncing between versions of the same page rather than indexing new content. No amount of keyword refinement fixes that. The structural issues a proper audit surfaces often explain why a site with genuinely good content is not ranking anywhere near where it should be. The practical order Diagnosis first. Pull a crawl report, check your Core Web Vitals in Search Console, and confirm your canonical setup before you touch another meta description. Once the technical foundation is sound, on-page improvements compound properly. Better copy, tighter headings, and considered internal linking start to move the needle in a way they simply cannot when the infrastructure underneath is fighting you. How to Tell Which Your Site Is Missing Start with Google Search Console. It will point you toward whichever problem is louder. Open the Coverage report and look for crawl errors, pages marked as "Discovered but not indexed", or anything excluded by noindex. Then pull up the Core Web Vitals report and check whether Google is flagging poor LCP or CLS scores across a meaningful chunk of your URLs. If you want to go deeper, run the site through Screaming Frog or Sitebulb. Look at what gets crawled, what gets skipped, whether your internal links are pointing at redirect chains, and whether any pages are accidentally blocked in robots.txt. These are technical signals. They tell you whether Google can properly access and process the site in the first place. No amount of well-written content fixes a site that search engines cannot reliably crawl. As part of a structured technical SEO audit, these checks form the foundation before anything else gets touched. Once the technical layer looks clean, shift your attention to the content itself. Check that every page has a unique title tag describing what it covers. Look at your H1 tags and make sure none are duplicated across different pages. Scan for thin content, particularly pages with fewer than 300 words that are not earning their place in the index. Then check internal linking gaps. Pages that exist but receive no internal links are effectively invisible to crawlers, regardless of how good the copy is. When Both Need Work at the Same Time Most sites that come to me with ranking problems have both issues running at once. Content that is not doing enough, and an infrastructure that is quietly working against them. The temptation is to tackle everything together, or worse, to start polishing content while crawl issues are still buried in the background. That approach wastes time. If Google cannot reliably access your pages, it does not matter how well-written they are. Fix crawlability first. Sort out broken redirects, blocked resources, crawl errors and anything in your site's structure that prevents pages from being indexed cleanly. Those are the gates. Content improvements only count once the gates are open. Consider the difference, a page with a thin title tag and weak body copy is a missed opportunity. A page that is blocked in robots.txt or buried under a chain of redirects does not even get the chance to be an opportunity. The order matters because a proper technical SEO audit often surfaces issues that would have made every content improvement invisible to search engines regardless. Once access is clean, content work earns its keep. Not before. ------------------------------------------------------------ # 7 Reasons First-Party Data Is Your Content Edge Source: https://yorkshiredesign.co.uk/7-reasons-first-party-data-is-your-content-edge/ Published: 2026-08-06 > Third-party cookies are fading, ad platforms are getting noisier, and most content still gets written by looking at what competitors already rank for. That approach copies the past. First-party data, the behaviour, signals and patterns your own audience leaves behind, points somewhere more useful. It tells you what people actually do when they land on your site, not what a keyword tool thinks they might want. That gap is where real content advantage lives. What First-Party Data Means First-party data is the information your own site collects directly from the people who visit it. No middlemen, no third-party trackers, no inference. Most small site owners are already sitting on a decent pile of it without having labelled it that way. The search queries people type into your on-site search box, the pages where scroll depth drops off sharply, how often the same IP returns within a fortnight, which blog posts draw email sign-ups and which don't, what your contact form enquiries keep asking about. Taken individually, none of these feel like "data strategy". Taken together, they build a picture of what your visitors want that no bought-in audience report can replicate, because it reflects the specific people who found your specific site and decided to stay. The distinction that matters is consent and proximity. Someone browsing your site and triggering a heatmap or a scroll event has an implicit relationship with you. That signal is direct and clean. Third-party data, by contrast, has been aggregated, repackaged and sold at least once before it reaches you, and the people it describes never knowingly interacted with your brand at all. Less glamorous to talk about, but far harder for a competitor to copy. Your Search Console Data Is a Content Brief Google Search Console's queries report shows you exactly what real people typed before landing on your site, or clicking away from it. That raw list is something no third-party keyword tool can replicate, because it comes from your specific visitors, not a blended average across thousands of competitors. People searching for your services phrase things in ways that never surface in tools like Ahrefs or Semrush, particularly when they're asking questions rather than hunting for a product. You'll find half-formed queries that reveal genuine confusion, comparison questions that signal someone close to a decision, and long phrases that tell you precisely which part of a topic your readers care about most. A plumber's site might show "does a combi boiler need a hot water tank" rather than the clean, sanitised "combi boiler types" a keyword tool would suggest. That specific, conversational language is a ready-made article brief sitting there unread. Check the queries that service business content tends to generate separately from product queries. The intent is different, the language is messier, and that messiness is the signal to follow. On-Site Behaviour Tells You What to Write Next Page views give you a count. Heatmaps and scroll depth give you a story. When you can see that readers consistently drop off two-thirds down a long explainer, that is not an engagement problem, it is a structure problem. Either the section they are abandoning is too vague, or the piece has answered the question already and they have no reason to keep reading. Either way, you know exactly where to make the change. A monthly analytics dashboard would never surface that on its own. Exit pages are especially useful. A page that consistently sends people away, rather than deeper into your site, is a signal that the content did not earn the next click. That gap is your next brief. Treat Scroll Data as a Feedback Loop Scroll data, click maps, and session recordings work best when you check them after publishing something new, then again after any edit. Over time a clear pattern forms. Certain topics hold attention across the full page length; others lose readers at roughly the same point every time. Once you spot that, you know which subjects are the formats your readers take through to the end, and which ones need a rethink before you commission another piece like them. Email and Form Responses Are Underused Signal Every enquiry form submission and reply email that lands in your inbox is carrying something a keyword tool cannot give you. The exact phrasing a real person used when they had a real problem. That phrasing tells you how they think about the subject, what they already tried, and where the standard answers fell short. Someone asking "why does my site look broken on my phone but fine on my laptop" is not searching "responsive web design" in a spreadsheet. That gap between your assumed terminology and their words is where most content misses, and it shows up in bounce rates before anyone notices the cause. Read enough of those messages and patterns emerge fast. Objections that keep repeating, questions that reveal a genuine misunderstanding of how something works, phrasing that no competitor has bothered to address because they never looked. The fix is low-tech. Keep a running document. Copy in the phrases that surprise you. When the same concern appears three times in a fortnight, that is a content brief writing itself. If you want to see how structured content briefs handle this kind of raw input, there is a straightforward way to translate those real-world phrases into something a writer can use without losing what made them valuable in the first place. How First-Party Data Sharpens AI-Assisted Content AI writing tools are only as specific as what you feed them. Without real input, they default to the same well-worn angles every other site is already publishing. The shift happens when you bring actual material from your own visitors into the process. The exact phrases customers use in support tickets, the questions that repeat across sales calls, the topics your email list consistently clicks on but your site barely touches. Feed those specifics into a prompt and the output stops reading like a committee wrote it. A Real Signal Beats a Generic Prompt A roofing company that notices "how long does a flat roof last in heavy rain" appearing in three separate enquiry forms in one month has something most of their competitors lack. A real, timed signal about what their visitors want answered. An AI tool given that phrase, that context and that urgency will produce something sharper than any tool running on generic instructions. For more on getting that kind of mileage from a single piece of research, the approach covered in turning one blog post into multiple content formats using AI builds directly on this. The data does not have to be vast. A handful of honest, specific observations from your own visitors beats a spreadsheet of keyword volumes pulled from a tool everyone else is using too. Building a Simple First-Party Data Habit You don't need a data team or a dashboard that costs more per month than your hosting bill. The signals that matter most are already sitting in tools you likely have open every day. Google Search Console shows you which queries are sending people to your site and, just as usefully, which ones are landing them on pages that then lose them immediately. Your email platform tells you open rates and click patterns. A simple contact form tells you what people are asking in their own words. Spend thirty minutes a week reviewing these three sources together and patterns start to emerge far faster than most people expect. No complex setup, no consultant, no annual contract. Where This Shows Up in Content Planning If you notice a question appearing repeatedly in form submissions, or a search query driving traffic to a page that clearly doesn't answer it well, that's a gap worth filling. It's a signal no keyword tool gives you, because it came directly from your visitors. For anyone thinking about what gets read by real visitors, these signals are the most honest feedback you'll collect. Review them monthly at minimum, quarterly if your site moves slowly, and let them shape the next thing you publish. Why This Compounds Over Time First-party data doesn't behave like a single tactic you deploy and move on from. It accumulates. Every piece of content you publish on the back of real visitor signals teaches you something about what lands and what doesn't, and that understanding feeds the next piece, and the one after that. A site that has been doing this for two years has an understanding of its readership built from thousands of real interactions. A competitor starting fresh today cannot buy that. They can copy your format, your tone, even your topic list, but they cannot replicate what you know about your readers. That gap gets wider the longer you keep going. Most sites don't, which is the point. Pages built from real behavioural patterns, search queries, and on-site engagement data consistently outperform pages built from assumption, because they're answering questions that are genuinely being asked, in the way readers expect them answered. If you're thinking about where AI writing tools fall short, this is usually it. The tool has no access to your first-party signals, so it defaults to the generic middle. Your data is what keeps your content out of that pile. ------------------------------------------------------------ # What an Enterprise WordPress Agency Actually Does Differently Source: https://yorkshiredesign.co.uk/what-an-enterprise-wordpress-agency-actually-does-differently/ Published: 2026-08-05 > Most WordPress builds follow a familiar pattern. Pick a theme, install a page builder, add a contact form, go live. That works fine for a brochure site. Enterprise projects are a different problem entirely. The scale changes what breaks, what slows down, and what quietly costs money over time. The gap between a standard WordPress build and one designed to run at volume is not about price brackets. It is about what gets done underneath. Architecture First, Template Second Before a single page template is sketched out, there are decisions that will shape everything downstream, how the database is structured, whether the hosting topology can handle traffic spikes without choking, which caching layer sits where, and which plugins are load-bearing versus decorative. Get those decisions wrong at the start and no amount of front-end polish will save you later. A common failure pattern is a business that picks a multipurpose theme, installs a stack of plugins to patch the gaps, and then wonders why the site starts buckling once product catalogues grow past a few thousand entries or concurrent users hit double figures. The architecture was never designed to carry that weight. It was designed to look good in a demo. A considered architecture maps the data model before the design brief. That means knowing whether custom post types are the right structure for the content, how object caching will behave under a full page load, and whether the chosen hosting configuration separates database and application server traffic or lumps everything onto a single instance. Those choices interact. A plugin that runs six uncached database queries per page load is a minor annoyance on a ten-page brochure site and a serious problem on a high-traffic platform where technical debt compounds against rankings and load time simultaneously. Getting the foundation right takes time up front. It is also the only thing that scales. How Core Web Vitals Behave on Large Sites A homepage that scores 95 on PageSpeed Insights looks reassuring until you check what is happening three clicks deeper. Category pages with hundreds of product cards, faceted search results generating thousands of URL combinations, and user-generated content pages with variable image sizes and unpredictable markup all behave differently under the same infrastructure. The Largest Contentful Paint on a homepage is usually a single hero image you have full control over. On a category page, the LCP element might be the third product image in a lazy-loaded grid, and whether it loads fast enough depends on how the browser prioritises resources across a DOM that is twice the size. Cumulative Layout Shift is equally unpredictable at scale. A font that loads fine on a static editorial page can shift a price label or a button on a template that pulls dynamic content from three different sources. These are not edge cases. They are the default behaviour of large sites that have not been engineered with Core Web Vitals in mind from the beginning. Where server response time breaks down The pressure point most sites discover late is server response time across templated pages. A well-cached homepage tells you nothing about TTFB on a search results page that cannot be cached because every query string is unique. This is where technical SEO decisions at the infrastructure level start to affect real user experience scores, not just audit numbers. Getting this right means profiling page types individually, not averaging scores across a sample. Every template needs its own baseline. Plugin Strategy at Scale A poorly coded plugin on a small site is an annoyance. On an enterprise WordPress build with thousands of concurrent users, it can lock database tables and cascade failures across every page simultaneously. Plugins don't run in isolation. They share the same database connection pool, the same PHP process queue, and the same object cache. One plugin firing a slow, unindexed query on every page load doesn't just affect that page. It steals resources from every other request in the stack at that moment. Fewer, better-chosen plugins consistently outperform a bloated stack. That's not an opinion. It's the pattern you see repeatedly when you pull query logs on a site that's struggling under load. How to audit a plugin stack properly Auditing plugin dependencies at enterprise scale means going deeper than the WordPress admin screen. Start with Query Monitor to surface any plugin generating repeated or expensive database calls. Then cross-reference active plugins against their update frequency, codebase age, and whether they load assets globally rather than only on the pages that need them. The ones creating accumulated technical debt tend to share a common profile, no updates in over a year, hooks that fire on every request regardless of context, and no documentation for their database schema changes. Identifying and replacing those with leaner alternatives, or with custom-built functionality where nothing suitable exists, is the methodical work that underpins a stable enterprise site. Custom Development vs Off-the-Shelf Solutions Themes and plugins solve the common cases well. The trouble is that enterprise requirements are rarely common. A retailer needing real-time stock feeds from a warehouse management system, a publisher with a content approval workflow involving five internal teams, a membership platform where access rules shift based on external CRM data, none of these sit neatly inside a premium theme or a plugin bundle. Forcing them to fit means stacking workarounds, filters on top of hooks on top of conditional logic that nobody documented properly. That codebase becomes difficult to reason about, and every plugin update is a small gamble. Custom PHP, bespoke post types, and tailored REST API integrations exist precisely because the alternative, left long enough, degrades into something nobody wants to maintain. What maintenance looks like over time The maintenance picture is where the difference becomes most obvious. Third-party code carries someone else's roadmap, someone else's breaking changes, and someone else's security surface. Custom code carries only what the project needs. That does mean ongoing attention. Bespoke work needs a developer who understands it rather than a generic support ticket. But the hours spent maintaining clean, purposeful code tend to be far fewer than the hours spent chasing conflicts between six plugins that all need updating at once. Technical SEO Built Into the Build Crawl bloat is one of the most damaging ways a large WordPress site loses rankings, and it almost always starts in the architecture, not the content. Enterprise sites tend to generate enormous volumes of near-identical URLs without anyone deliberately choosing to do so. A faceted navigation on a product catalogue might let users filter by size, colour and price simultaneously, producing thousands of parameter-laden URLs that Google crawls instead of your actual pages. Taxonomy archives compound the problem. Auto-generated tag pages, author archives and date-based URLs can easily push a site past 50,000 indexable paths when the real content is a fraction of that. Baking SEO structure in from day one A technically sound build anticipates all of this before a single page goes live. That means designing the URL structure so that parameters are consolidated or excluded at the server level, canonicalisation is baked into templates rather than applied manually after launch, and crawl budget decisions for WordPress are made as part of the information architecture conversation, not bolted on six months later when rankings dip. Retrofitting noindex tags and redirect chains onto a site that was never planned with this in mind is slow, expensive and rarely complete. Getting the structure right from the start protects the crawl budget for pages that deserve it. What Yorkshire Design Does at This Level Most agencies handling enterprise WordPress work have a predictable shape to them. A senior architect scopes the project, writes a brief, hands it to a mid-weight developer, who hands anything tricky to a junior. By the time code touches the production codebase, the person who understood the original problem is three conversations away. Yorkshire Design works differently because there is no chain. The same person who asks the right questions at the start is the one writing the PHP, auditing the server-level technical fixes that affect crawl and speed, and reviewing the output before anything goes live. That continuity matters more than it sounds on paper. Fewer assumptions get made, fewer things get rebuilt twice, and the reasoning behind every decision stays intact throughout the project rather than being summarised in a ticket. For enterprise clients, direct access to someone who knows the codebase is harder to find than it should be. Its absence inflates both cost and timeline. The other difference is pace. A single senior engineer with no account management overhead moves through a problem faster than a team waiting on sign-off. You get answers the same day, not at the next scheduled standup. ------------------------------------------------------------ # Lazy Loading in WordPress: What It Does and When It Hurts Source: https://yorkshiredesign.co.uk/lazy-loading-in-wordpress-what-it-does-and-when-it-hurts/ Published: 2026-08-05 > WordPress has shipped lazy loading on images by default for a few years now. Most site owners have never touched the setting, which is fine, until it starts costing them. The browser defers images that are off-screen at load time, which sounds sensible on paper. The catch is that WordPress does not always know which images are truly off-screen, and when it gets that wrong, your Largest Contentful Paint score takes the hit before a single visitor has scrolled anywhere. What Lazy Loading Does in the Browser The loading="lazy" attribute is a single HTML instruction that tells the browser to hold off fetching an image until the user scrolls close to it. Without it, the browser downloads every image on the page the moment it starts parsing the HTML, regardless of whether those images are visible or buried three scrolls down. Add loading="lazy" to an <img> tag and the browser defers the request until the image enters, or nearly enters, the viewport. The exact trigger distance varies by browser, but Chromium-based browsers typically begin fetching once an image is within roughly 1,200 pixels of the visible area on a fast connection, pulling that threshold closer on a slower one. The practical effect is that a page with thirty product images may only request six or seven on initial load, with the rest following as the visitor scrolls. That reduces the volume of bytes the browser has to handle before it can paint the page and respond to interaction. The browser makes this decision independently for each image. It checks the loading attribute, considers the image's position relative to the viewport, and factors in current network conditions. It does not consult the CMS, the theme, or any plugin. Whatever WordPress or a page builder outputs in the HTML is what the browser acts on, which is why understanding what ends up in the markup matters far more than assuming a setting has been applied correctly. Why WordPress Gets It Wrong by Default WordPress added native lazy loading in version 5.5, and on paper it looked like a sensible move. Deferring off-screen images cuts unnecessary requests and reduces initial page weight. That logic holds for images buried halfway down a long page. The problem is that WordPress applies the loading="lazy" attribute broadly, without always accounting for which image is sitting at the very top. When your theme uses a full-width hero image or a featured image banner, that asset is almost certainly the Largest Contentful Paint element. Telling the browser to delay loading it is the same as telling your fastest runner to wait at the start line. Google measures LCP as one of the Core Web Vitals signals that directly influence search rankings, so a lazily loaded hero can drag scores down on an otherwise well-built site. Most themes compound the issue because the featured image is baked into the template at the top of every post and page, making it the first large element the browser encounters. Without a manual override, WordPress will flag it lazy regardless. The fix is not complicated, but it does require knowing where to look in the markup and being deliberate about which images get loading="eager" instead. Which Images Should Never Be Lazy Loaded Above-the-fold HTML images Hero images, above-the-fold banners, and your logo are the clearest cases. These elements are visible the moment a page loads, so telling the browser to defer them is counterproductive. The browser fetches lazy-loaded assets only after the initial render, which means a visitor stares at an empty space while the image catches up. On a hero section that takes up most of the viewport, that gap is exactly what Google's Largest Contentful Paint metric measures. Lazy loading those images does not save bandwidth; it just shifts the cost onto your LCP score. CSS background images CSS background images sit in a different category entirely, and they catch a lot of people out. When a page builder sets an image as a CSS background rather than a standard HTML img element, the browser's native lazy loading attribute has no effect on it at all. The image loads regardless, but without any of the priority signals that help it load fast. If that background is your main banner, you want it discovered and fetched as early as possible, which means preloading it explicitly, not deferring it. The same logic applies to any thumbnail used in an Open Graph tag or structured data block, since those assets feed previews that also depend on being present. Get the categorisation wrong and you either delay what should be instant or preload what nobody sees above the fold. How to Override Lazy Loading on Specific Images The most direct fix is adding loading="eager" to any image that needs to load immediately. In the block editor, select the image block, open the Advanced panel in the right-hand sidebar, and paste loading="eager" into the Additional CSS class field, then handle it in your theme's CSS or use a block attribute filter. A cleaner route in block themes is editing the HTML directly via the three-dot menu, switching to HTML view, and inserting the attribute by hand. In a theme template or a custom PHP loop, you write the attribute into your img tag directly: <img src="..." loading="eager" alt="...">. That tells the browser to treat the image exactly as it would without any lazy-loading instruction applied. Doing this post by post is manageable for a handful of images, but it breaks down fast on a larger site. A small filter inside your theme's functions.php can target images by class or context, removing the loading attribute programmatically wherever you need it, without touching every piece of content individually. As a rule, only hero images and anything sitting above the fold on your most-visited templates need this treatment. Overriding too many images defeats the purpose. Does Lazy Loading Help PageSpeed Scores? On pages heavy with images, it can make a real difference. On lean, well-optimised pages, the gains are often marginal at best. The metric lazy loading most directly affects is Largest Contentful Paint, because it controls when the browser fetches images. On a long blog post or a gallery page with thirty-plus images, deferring off-screen content means the browser stops competing with itself, and the images a visitor actually sees first load faster as a result. You'll often see a genuine drop in LCP on those pages, sometimes several hundred milliseconds, which moves the needle in PageSpeed Insights. The improvement is proportional to how much off-screen image weight you were loading unnecessarily before. Lean landing pages are a different story. If a page carries three or four compressed images and the above-the-fold content is mostly text, lazy loading does almost nothing measurable for your score. Worse, if the hero image gets tagged with loading="lazy" by accident or by a plugin applying it globally without discrimination, LCP can climb instead of fall. This is one of the more common causes of a puzzling LCP regression after installing a new WordPress speed optimisation tool. The fix is straightforward, but finding it takes time. What to Check in PageSpeed Insights and Search Console Reading the PageSpeed Insights diagnostics PageSpeed Insights will flag the problem directly if it exists. Look in the Diagnostics section for a warning labelled "Lazy loaded LCP image". That single line tells you WordPress has applied loading="lazy" to whichever image is being measured as the Largest Contentful Paint element on the page. The browser sees that attribute and waits before fetching the image, which pushes your LCP time up. On a product page where the hero shot is the first thing a visitor sees, this can add several hundred milliseconds to an otherwise reasonable score. Run the test on your homepage, your most important landing page, and a representative product or service page separately. Do not assume one page tells the whole story, because the LCP element changes depending on what is above the fold. Using Search Console field data Search Console's Core Web Vitals report gives you the field data picture. If you see a cluster of URLs moving from "Good" to "Needs Improvement" on LCP, and those pages share a similar layout with a large above-the-fold image, lazy loading is a strong candidate to investigate before anything else. Keep an eye on CLS too. If lazily loaded images below the fold do not have explicit width and height attributes set, they can shift the layout as they load in, and that movement registers as a CLS problem rather than an LCP one. The fix differs, but the root cause in both cases comes back to how the image is being handled at the HTML level. ------------------------------------------------------------ # Good Website Copy vs Bad: Real Examples That Show the Gap Source: https://yorkshiredesign.co.uk/good-website-copy-vs-bad-real-examples-that-show-the-gap/ Published: 2026-08-05 > Most website copy fails the same way. Not through bad grammar or obvious errors, but through saying nothing useful. It describes the business rather than the reader's problem, it reaches for vague warmth instead of a clear point, and it buries the thing the visitor actually came to find. The gap between copy that works and copy that sits there looking busy is not about talent. It comes down to a handful of specific choices, and once you can see them, you cannot unsee them. The Homepage Headline Test The headline is the first sentence anyone reads on your site. If it fails, nothing else on the page gets a chance. Take a plumber. A brand-first headline reads something like "Henderson Plumbing Services, Serving the Region Since 1987." That sentence tells you the company name and how long they've been around. Neither of those things answers the question sitting in a visitor's head, which is whether this person can fix my burst pipe today. A problem-first headline reads differently: "Burst pipe? Blocked drain? We're out to you within the hour." Same business, same service, completely different effect. The second version earns the next sentence because it speaks directly to the situation the visitor is already in. It doesn't ask them to care about the brand yet, because they don't, not until they believe you can help them. Trust gets built after the hook, not before it. What good headline copy looks like is surprisingly easy to test. Cover the logo and ask whether the text alone tells you what the site does and why you should stay. If the honest answer is no, the copy is doing brand work when it should be doing conversion work. Most visitors decide within a few seconds whether a page is for them. The headline is the only part of the page guaranteed to get those seconds. About Pages Nobody Reads The most common pattern on About pages goes something like this: "We are passionate about delivering exceptional service and building lasting relationships with our clients." That sentence says nothing. It could belong to a florist, a freight company, or a firm of accountants, and not one word would need to change. Visitors land on an About page because they want to know whether a business is right for them. Vague language about passion and commitment answers none of that. What earns trust is specificity, the kind that tells a reader exactly what the business does, for whom, and what makes the people behind it qualified to do it. A builder who writes "I've refurbished over 80 Victorian terraces across the north of England, mostly kitchens and rear extensions" is infinitely more convincing than one who writes "we are committed to quality craftsmanship." The first version gives a reader something to hold onto. Copy that names a real number, a real type of project, or a real type of customer does the job an About page is supposed to do. It filters. The right people lean in; the wrong ones move on. If you want to see how a well-structured service page handles this, the principle is the same. Specifics close the gap between a visitor who is curious and one who picks up the phone. Service Pages That Describe Themselves Into Silence Most service pages have the same structural problem. They list what the business offers rather than answering what the visitor came to find out. "We provide web design, SEO, and digital marketing services" tells a reader nothing useful. It doesn't say who it's for, what problem it fixes, or why this company is the right call. The page describes the seller's menu rather than the buyer's situation, and the moment a reader feels unaddressed, they leave. What a stronger opener looks like Compare that kind of opener to something like: "Your site looks fine but nobody's getting in touch. We find out why." That's a different conversation. A before-and-after makes the difference concrete. Before: "We offer responsive web design, on-page SEO, and content writing packages tailored to your needs." After: "If your site isn't bringing in enquiries, the layout, the copy, or the page speed is usually to blame. We check all three and fix what's broken." The second version names a recognisable situation. It earns attention because the reader feels seen. If you want to understand what separates copy that converts from copy that just fills space, the test is simple. Read it as a suspicious stranger and ask whether any of it could only have been written by this specific company, for this specific person. If the answer is no, it isn't working yet. How Calls to Action Kill Conversions The button at the bottom of a page looks like a minor detail. In practice, it is the moment everything either works or falls apart. Vague labels and the fear they leave unresolved "Get in touch" fails not because it is rude or confusing, but because it resolves nothing for the person reading it. They are sitting there wondering whether contacting you means a pushy sales call, a long wait, or a commitment they are not ready for. A vague label does not answer any of that. Something like "Book a free 20-minute call, no obligation" does, because it names the format, the length, and removes the fear of being cornered. That specificity is what turns a hesitant reader into someone who clicks. The phrase doesn't sell harder, it just removes the friction that was already there. The same logic applies to contact forms. "Submit" tells the reader nothing about what happens next. "Send my question" or "Request a callback" describes the action in the reader's own terms, which makes the whole thing feel less like leaping into the unknown. If you are unsure whether your calls to action are pulling their weight, look at the conversion problems a well-designed page can still carry without anyone noticing until the enquiries dry up. Which Version Would You Read? Reading copy side by side skips the theory entirely. Either a line pulls you forward or it doesn't. The table below puts weak and strong copy head to head across four page elements you'll find on almost any business site. Weak copy describes the business. Strong copy addresses the reader, names something specific, and moves on without ceremony. The weak versions aren't necessarily badly written in a grammatical sense. They're just pointing in the wrong direction, talking at the visitor rather than connecting with what that visitor needs to know. That gap is where most service page copy falls apart, long before anyone looks at layout or colour. Page element Weak version Stronger version Homepage headline Welcome to our website Get a quote in three minutes, no jargon About intro We are a passionate team of experts We've been fixing broken websites since 2005 Service description We offer a full range of solutions We optimise WordPress sites so pages load under two seconds Call to action Click here to get started Book a free 20-minute call The stronger versions aren't longer. They're just honest and specific, and that's enough. What to Fix First on Your Own Site Start with whichever page Google sends most of your visitors to. For most sites that is the homepage, but check your analytics before assuming. Two questions for every section Once you have the right page open, ask two questions about every section on it. What is this telling the reader, and what does it want them to do next? If you cannot answer both in under ten seconds, the copy has a problem. A common version of this is a homepage hero that leads with a tagline about values ("passionate about your success", "putting people first") and then sends visitors nowhere. There is no offer, no clear next step, and no reason to scroll. Rewriting that one section to name a specific outcome and pair it with a single obvious action will do more than tweaking a dozen secondary pages. After the landing page, move to your main service or product page. This is where most copy buries the thing people came to find out, usually the price range, the process, or what happens after they get in touch. If your service page structure puts testimonials before it explains what you do, flip the order. Work through the rest of the site in traffic order. Fix what the most people see first, and the smaller pages can wait. ------------------------------------------------------------ # Homepage Animations in WordPress: Do They Cost You Rankings? Source: https://yorkshiredesign.co.uk/homepage-animations-in-wordpress-do-they-cost-you-rankings/ Published: 2026-08-05 > An animated hero section can look sharp on launch day. Six months later, when your Largest Contentful Paint is sitting at 6.2 seconds and Google's Search Console is flagging poor page experience, the connection isn't always obvious. Animations are rarely the first thing anyone checks. That's exactly why they keep costing sites rankings without anyone realising it. This post walks through how to find out whether yours are part of the problem, and what to actually do about it. What animations do to your page before anything loads The damage starts before a visitor sees a single pixel move. Most animation libraries, including GSAP and similar JavaScript-driven tools, need to parse and execute before the browser can commit to painting the page. That execution sits on the main thread, which is the same thread responsible for rendering your hero image, your headline, and your Largest Contentful Paint element. Even a small, tasteful entrance animation can push your LCP measurement out by several hundred milliseconds if the script loading it isn't handled carefully. CSS keyframe animations are lighter by comparison, but they introduce a different problem, if the animated element is anywhere near the top of the viewport and its starting position shifts once the stylesheet loads, you hand Cumulative Layout Shift a number it doesn't forget. A hero section that fades in from a translated Y position, for instance, can register a CLS score the moment the browser recalculates that element's geometry. The pattern you see most often on a pre-audit WordPress site is a page that scores fine on a fast connection and looks broken on a slower one, because the render-blocking animation script holds up the paint entirely. The hero sits blank. That blank gap is exactly what LCP measures, the time until the largest visible element is fully rendered. Load the wrong library in the wrong place, and that timer keeps running long after your design team has declared the animation "subtle". The Three Animations That Cause the Most Damage Hero video autoplay is the single worst offender. A looping background video added purely for visual atmosphere forces the browser to download a large asset before it can paint anything meaningful on screen. That directly inflates Largest Contentful Paint, which Google uses as a core ranking signal. JavaScript-driven entrance animations on above-the-fold elements cause a different kind of harm, the browser has to parse and execute the script before it knows how to lay out the page, which means the user sits looking at nothing while the animation queues up. A common pattern is a theme that fades every hero element in on load, one after another, each delayed by a fraction of a second. It feels polished in a demo, but in practice it holds the entire above-the-fold render hostage. The visitor's first impression is a blank screen, not your content. Parallax scroll effects are subtler but persistently damaging. Every time the user scrolls, the browser recalculates the position of multiple elements and repaints sections of the screen. On a phone this gets expensive fast, and you can see it in the Interaction to Next Paint scores during a WordPress performance audit when scroll-triggered repaints stack up alongside other bottlenecks. All three animations share the same problem. They prioritise how the page feels in a screen-share demo over how fast it loads for a real visitor on a real connection. How to Test Whether Your Animations Are the Culprit Open Chrome DevTools, go to the Performance panel, and hit Record while the page loads from a hard refresh. Once the trace is captured, look at the Filmstrip view along the top of the timeline. You want to see when the page first shows meaningful content, and whether the frames stutter or delay during that window. If your hero animation kicks in before the main content paints, you'll see it clearly as a block of scripting or rendering activity sitting right where the browser should be drawing something useful. That gap between a blank screen and visible content is exactly what a structured performance audit is trying to find. The quicker test is PageSpeed Insights. Run it once on your live page, note the scores, then temporarily disable or remove the animation, and run it again. A gap of ten or more points in Total Blocking Time or Largest Contentful Paint is a strong signal the animation is doing real damage. If the scores barely shift between the two runs, the animation probably isn't your main problem, and you should look elsewhere. But if disabling it moves the needle, you have your answer. At that point it becomes a decision about whether the visual effect is worth the ranking cost, because search engines measure what users experience, not what looks good in a design mockup. Knowing the actual number makes that a straightforward call rather than a guess. When an Animation Is Worth Keeping Not every animation is a problem waiting to happen. A CSS-only fade on a card that sits three scrolls below the fold costs you almost nothing, because the browser has long finished painting the viewport before it reaches that element. The same logic applies to subtle hover effects on navigation links or buttons. These run entirely on the compositor thread, meaning the browser handles them independently of the main rendering work. They don't compete with font loading, hero image delivery, or anything else that feeds into your Largest Contentful Paint score. The test that actually matters is whether the animation touches an element that sits on the critical rendering path. If it does, you're adding weight to the very process Google measures. If it doesn't, the performance cost is negligible and the effect might genuinely improve how a page communicates. Where animations earn their place is on interactive states and below-the-fold content, things a user reaches after the page has already loaded and scored well. A smooth CSS transition on a call-to-action button adds polish without touching load time at all. The question to ask before removing anything is simple. Does this element appear above the fold, and does it animate on page load? If the answer to both is yes, that's where you look first. How to fix the problem without scrapping the design You don't have to choose between a flat, static page and one that tanks your Core Web Vitals. The fix is mostly about sequencing and substitution. Start by replacing JavaScript-driven entrance effects with CSS animations wherever the motion is simple, fades, slides, scale transitions. CSS animations run on the compositor thread and don't block the main thread the way a JS animation library does. For anything that genuinely needs JavaScript, defer the script until after the page has painted. The LCP element, usually your hero image or headline, should carry loading="eager" and fetchpriority="high" so the browser prioritises it immediately. If you want that element to animate in, apply the animation to a wrapper <div> around it rather than the element itself. That way the image loads at full priority while the container fades in behind it, and your technical SEO signals stay intact. Add a prefers-reduced-motion media query to your stylesheet as well. Setting animation, none inside it strips every transition for users who have requested less movement in their OS settings. That covers accessibility and cuts unnecessary rendering work for those visitors at the same time. What This Looks Like as an Audit When a homepage comes in for a Core Web Vitals review, animations are one of the first things I pull apart. The process starts in Chrome DevTools with a cold-load trace, looking at exactly what fires in the first five seconds and in what order. Anything that triggers layout recalculations or holds up the Largest Contentful Paint element gets flagged immediately. From there I check the network tab for oversized JavaScript bundles attached to scroll libraries, parallax scripts, or slider plugins, because those are reliably where the weight hides. CSS animations get a separate pass to see whether they're forcing the browser onto the main thread rather than running on the compositor. If a property like top or width is animating instead of transform or opacity, that's a straightforward fix, but one that gets missed surprisingly often. The technical SEO work that sits underneath page performance is exactly this kind of unglamorous, step-by-step checking. Priority is simple. Anything blocking the LCP element or causing a Cumulative Layout Shift score above 0.1 gets dealt with first. Visual enhancements that are just slow come second. After a cleanup, the most common result is a measurable drop in Total Blocking Time and a CLS score that finally passes the green threshold. Rankings tend to follow, though not overnight. ------------------------------------------------------------ # AI Content That Ranks vs AI Content That Just Exists Source: https://yorkshiredesign.co.uk/ai-content-that-ranks-vs-ai-content-that-just-exists/ Published: 2026-08-05 > Publish fifty AI-generated posts and you might get two that rank. That ratio is not bad luck. It comes down to a handful of decisions made before the first word is drafted. The gap between content that earns a position on page one and content that sits at impression zero is not about which tool wrote it. It is about whether anyone thought hard enough about what the reader actually needed to find. Intent, Not Output, Is the Real Split Most AI content fails before a single word is written. The decision that kills it happens at the brief stage. Writing a 1,500-word article about "the benefits of cloud accounting software" is aiming at a topic. Writing specifically for someone who has three spreadsheets open, hates reconciling VAT returns manually, and is weighing up whether the monthly cost is justified is aiming at a person with a real problem at a real moment. Those two briefs produce very different pages, and Google has spent years getting better at telling them apart. The first signals someone filling a content calendar. The second signals someone who understands what the searcher is trying to resolve. Search engines measure this gap through engagement signals, click-through rates, and how long someone stays on the page before bouncing back to the results. A page that matches why someone searched tends to hold attention. A page that matches only the surface keywords rarely does. Intent is not a writing style. You cannot fix a misaligned brief by making the prose warmer or the headings snappier. If the underlying purpose of the content was to cover a subject rather than answer a specific question, no amount of polish rescues it. That is the first fork in the road, and it has nothing to do with whether a human or a machine produced the text. What Google's Ranking Signals Reward Google does not score content on effort or word count. What it rewards is specificity and usefulness on a narrow question. A post that thoroughly answers one thing, with real context and logical follow-on reading built into its structure, consistently outperforms a survey post that skims twelve topics and goes deep on none. The pages that gain traction tend to treat one question with enough detail that a reader does not need to go elsewhere. They connect to related content through a coherent internal linking structure that signals topical authority across the site. And they carry clear authorship signals, a named person, a real point of view, something a machine on its own would not produce. That last point matters more than many people expect. Google's quality rater guidelines give significant weight to demonstrated expertise, and a piece that reads like it came from someone with a formed opinion behaves differently in the index than one that reads like a confident-sounding average of everything ever written on the topic. The generic survey post is the most common AI content failure mode. It covers the question, technically, but it does not commit to anything. No specific recommendation, no concrete scenario, no signal that a real person thought it through. Depth on a narrow question beats breadth across ten. That is what the data keeps showing, and it is what most AI-generated content gets backwards. Thin Content Is Still Thin, Whatever Wrote It AI can generate 1,500 words in thirty seconds. Volume and usefulness are not the same thing, and Google's quality systems have been trained on enough content to tell the difference. The pattern shows up constantly. A piece opens with a vague definition, moves into five or six generic tips anyone could have written from a ten-second think, and closes with a call to action. No real scenario. No specific failure mode. No position the writer could be challenged on. It reads like a summary of a summary, and that is more or less what it is. The thin-content tell is not the word count. It is the absence of anything a reader could not have guessed before they clicked. What the guidance actually says Google's helpful content guidance is explicit on this point. A page that offers nothing beyond what already exists in abundance provides no reason to rank. That applies whether a human spent three days writing it or an AI produced it in a minute. The fix is not to write longer. It is to write something specific. A worked example, a contrarian take backed by a reason, a failure mode with a name. If you strip the generic tips out of a piece and nothing of substance remains, the page has a problem that more words will not solve. This matters particularly for service businesses using AI content writing for SEO, where the temptation to publish at volume often outpaces any attention paid to depth. How Structure and Editing Change the Outcome Raw AI output tends to answer the question on the surface, then keep going. It restates the same point two or three times in slightly different clothing, hedges where it should commit, and skips the connective tissue that tells a reader why one idea follows the next. What a proper editing pass actually does A real editing pass cuts the repetition, sharpens the claim in the opening sentence, moves the most useful detail up from paragraph four, and adds one concrete example the AI left out because it was generalising. That shift in structure is what Google's quality reviewers, and real readers, respond to when they stay on a page or bounce straight off it. The difference is not the prose style. It is whether someone made a decision about what matters and arranged the content accordingly. A common failure is a 600-word piece where every paragraph is the same length and the same shape. Nothing signals thin content faster. An honest assessment of where AI-generated writing falls short usually points here first, not to the individual sentences. Edit for structure before you edit for words. Cut first, move things second, then polish. Publish without that pass and you have content that technically exists, answers nothing with any conviction, and earns nothing from search. Where AI Content Outperforms Hand-Written Copy AI earns its keep on structured, repeatable work. That is not a generalisation. It is where the evidence consistently points. Consider the content types that follow a fixed pattern. Product descriptions for a catalogue of fifty similar items. FAQ pages built around known search queries. Location or service pages that share the same template. Technical explainers covering a well-established process that has not changed in years. A human writer producing all fifty product descriptions will get tired around item thirty. The copy drifts, the structure slips, the tone wavers. An AI model holds the format precisely across all fifty, hits the same word count, and keeps the voice consistent from first to last. That reliability is useful, not a consolation prize. First drafts and workflow gains The same logic applies to first drafts. When a topic is well-defined and the brief is clear, AI can produce a clean working draft that a skilled editor can shape in a fraction of the time it would take to write from scratch. The editorial judgement still needs to come from a person, but the blank page stops being the problem. For businesses publishing at any real volume, that shift in workflow matters. If you want a clearer picture of how AI content writing intersects with SEO outcomes, the detail is there. Match the tool to the task, and it holds up well. The Publishing Decisions That Determine Performance Publishing ten posts in a week rarely outperforms publishing two good ones. The posts that rank tend to share qualities that have nothing to do with word count or how quickly they went live. Internal linking matters more than most people give it credit for, because a post that sits in isolation, with nothing pointing to it and nothing pointing out from it, gives Google very little reason to treat it as part of a coherent topic. Schema markup, clean heading structure, and a page that loads in under two seconds on mobile are the baseline, not optional extras. A crawler that hits a slow, poorly marked-up page may index it, but the threshold for ranking that page alongside well-built competition is considerably higher. When technical foundations undermine good content The content quality question becomes almost irrelevant if the technical foundations underneath it are weak. You can spend hours refining a piece of AI-assisted content for SEO and still find it buried on page four because the page loads slowly or carries bloated markup that buries the signal in noise. Frequency only helps when the quality floor stays consistent. One thoroughly optimised post, properly linked, with clean markup and a clear topic signal, will outperform a month of rushed output almost every time. ------------------------------------------------------------ # What Really Happens to Your SEO When You Change Domain Names Source: https://yorkshiredesign.co.uk/what-really-happens-to-your-seo-when-you-change-domain-names/ Published: 2026-08-05 > A small retail business rebrands, buys a shiny new domain, and points it at their existing site. Three months later, rankings that took years to build have largely vanished. The phones go quiet. Nobody warned them the old domain was carrying most of their SEO weight, and that moving without a proper migration plan is one of the few things in search that can genuinely set you back to zero. Why a Domain Name Carries More Than a Web Address Most site owners treat a domain as a label. Something you pick once and barely think about again. What lives inside that domain is a different matter. Over months and years, a domain accumulates something search engines care about, a history of backlinks pointing at it from other sites, a pattern of topical signals that tell Google what the site is consistently about, and a track record of trust built up through crawl after crawl. None of this appears on an invoice or shows up in your hosting dashboard. It accrues in the background, the way a good reputation does, and it feeds directly into where your pages rank. A site that has been earning relevant links from authoritative sources for three years carries far more weight than a technically identical site sitting on a brand-new domain, because the old one has done the time. That is not a vague notion. It is the mechanism. That accumulated value is what SEOs refer to as domain authority, though the real-world version of it is messier than any single score can capture. It spans the raw number of referring domains, the relevance of the sites linking in, the anchor text patterns across those links, and the age and consistency of the domain's topical focus. Change the domain and you put all of that at risk, whether you intend to or not. The Traffic Drop Is Normal How deep and how long is what matters Google's own guidance is clear that a domain migration will cause a temporary dip in rankings and organic traffic. That is not a sign something has gone wrong. When you change domain names, Google has to recrawl and reindex your content under a new address, reassess the signals attached to it, and gradually transfer authority across. That process takes time, and during it your visibility will soften. Most well-managed migrations see traffic return to its previous level within a few weeks to a couple of months. The redirect chain is clean, the new site is technically sound, and Google finds nothing to slow it down. The real concern is when that recovery window stretches past six months with no sign of improvement. At that point, the migration almost certainly had problems that were never fixed. Broken or missing 301 redirects, a disorganised site crawlability structure on the new domain, Search Console not updated, canonical tags pointing in the wrong direction. Each of those issues compounds the others, and Google's patience is not infinite. A short dip is the cost of doing this properly. A long one is almost always the cost of cutting corners. What a 301 Redirect Does (and What It Doesn't) A 301 tells search engines that a page has moved permanently, and for the most part they follow that instruction. Link equity, the accumulated authority from every backlink pointing at your old URL, does pass through to the new destination. But it does not pass through in full. Google has acknowledged over the years that some signal is lost in the transfer, and while the precise amount is not published, the effect is real. Think of it like forwarding post to a new address. Most letters arrive, but a few go missing along the way, and the ones that do arrive take slightly longer to be acted on. That loss becomes far worse when the redirect setup is sloppy. A redirect chain, where page A points to page B which points to page C, bleeds authority at every hop and slows crawling down noticeably. Redirect loops stop crawlers dead. Missing redirects are the worst of all. Any old URL left without one becomes a dead end, and every backlink pointing there is wasted. A site migration with even a handful of uncovered URLs can drop technical SEO signals that took years to build. Getting the redirect map right before you flip the switch is the one part of this process where there is no room to improvise. The Pages That Get Hit Hardest Not every page suffers equally when a domain changes. The pages that take the longest to recover are the ones that accumulated backlinks over months or years, because those links pointed to a particular URL on a particular domain. Even with a perfect 301 redirect in place, a portion of that link equity evaporates in transit. Pages with dozens of referring domains pointing to the old address can lose significant ranking positions in the weeks after migration, sometimes for queries where they previously held page one. The recovery timeline depends almost entirely on how quickly Googlebot recrawls the old URLs, follows the redirects, and reassigns the authority to the new destination. That can take weeks. For high-traffic commercial pages, that gap is costly. Pages that relied on technical SEO signals rather than strong content are especially exposed. If a page was ranking because of the old domain's age and reputation rather than anything it said, the migration strips that crutch away and leaves thin content with nowhere to hide. Pages targeted by exact-match anchor text pointing to the old URL face a different problem. Those anchors lose their precision signal the moment the URL changes, and the replacement page has to earn that association from scratch. It is a slow rebuild. Protecting Your Rankings During a Move Do the groundwork before you touch anything Most ranking drops after a domain change are not inevitable. They happen because the groundwork gets skipped. Start by crawling your entire site before you touch anything. Tools like Screaming Frog will pull every URL you have, including paginated pages, filtered product listings and old blog posts you had forgotten existed. Export that list and map each old URL to its exact new destination. A 301 redirect pointed at your new homepage instead of the equivalent new page tells Google nothing useful, and you will haemorrhage the link equity those pages spent years accumulating. Once you have the redirect map confirmed and tested in a staging environment, audit your existing backlink profile so you know which referring domains carry real weight. Those are the pages where broken redirects will hurt you most, and they are the first ones to check after launch. After go-live, watch closely Add the new domain as a verified property in Google Search Console straight away and use the Change of Address tool. Then watch your crawl error reports daily for the first fortnight. A spike in 404s tells you a redirect misfired. Catch it within days and the damage is contained. Leave it for weeks and you have handed competitors a free ranking opportunity on terms you already owned. Does Google Ever Fully Recover the Old Site's Ranking Power? Yes, in most cases it does, but the timeline varies more than most people expect. Google needs to crawl the old URLs, follow the 301 redirects, process the destination pages, and then reassign the authority it previously held against the old domain to the new one. For a site that Google crawls frequently, that process might take a few weeks. For a smaller site that sits lower on Googlebot's priority list, the same process can stretch across several months. The quality of the redirect implementation matters too. If the old-to-new URL mapping is messy, with chains of redirects, incorrect status codes, or URLs that resolve inconsistently depending on trailing slashes and capitalisation, Google gets confused and some of that authority does not transfer. Then there is the backlink picture. If a significant portion of your inbound links still point to old URLs that 404 rather than redirect, that link equity is gone. Rushed migrations are where the permanent gaps come from. A site moved without a thorough technical SEO audit beforehand often has redirect coverage that looks complete but misses hundreds of long-tail URLs that were passing authority without anyone noticing. Given enough time and a clean implementation, recovery is the normal outcome. Take shortcuts and you tend to leave a dent that no amount of waiting fixes. ------------------------------------------------------------ # Kinsta WordPress Hosting: What You Actually Get Source: https://yorkshiredesign.co.uk/kinsta-wordpress-hosting-what-you-actually-get/ Published: 2026-08-04 > Kinsta sits near the top of most managed WordPress hosting roundups, and the price reflects that. Plans start at around £30 a month for a single site, which is a jump if you're used to shared hosting. Whether that cost is justified depends entirely on what your site actually needs. This isn't a list of features pulled from their marketing page. It's a straight comparison of where Kinsta earns its place and where it probably doesn't. What 'Managed WordPress Hosting' Means at This Price Point The word 'managed' gets applied to hosting plans ranging from a few pounds a month all the way up to Kinsta's territory, and they are not describing the same thing. At budget hosts, 'managed' usually means WordPress comes pre-installed and someone will answer a support ticket if the server goes down. At Kinsta it means something considerably more hands-on at the infrastructure level. You get automatic daily backups, server-side caching, a custom control panel called MyKinsta, staging environments, PHP version management, and a team of WordPress-specific engineers on live chat around the clock. The server itself runs on Google Cloud's premium tier network, which affects routing and therefore real load times for real visitors, not just benchmark scores. You are not sharing that environment with thousands of other sites on an oversold shared box, and that is where a lot of the performance difference comes from. None of that means Kinsta is the right fit for every site. A five-page brochure site with light traffic may never feel the difference. The gap becomes tangible with the hosting factors that affect WordPress speed, particularly under load, or when Core Web Vitals scores start to matter for search visibility. That is the baseline you are comparing against. The Infrastructure Under the Hood Kinsta runs every site on Google Cloud Platform, and that choice shapes performance in ways that go deeper than the marketing copy suggests. The servers use C2 compute-optimised machines, which Google designed for workloads that need fast, consistent processing rather than raw bulk capacity. Pair that with Nginx handling requests instead of Apache, and you get a server stack that deals with concurrent traffic considerably more cleanly. PHP 8.x sits on top, bringing real speed improvements in how WordPress executes code compared to older PHP versions still running on shared hosts. Taken together, the stack removes several of the common bottlenecks that cause slow Time to First Byte on otherwise well-built sites. Where it gets interesting for WordPress specifically is how server-level caching fits into all of this. Kinsta handles page caching at the server layer, which means fewer round-trips to PHP for standard page loads. The spec sheet looks impressive, and in practice the foundations hold up. For most sites it removes hosting as the variable you need to worry about. How Kinsta Performs Against Core Web Vitals Time to First Byte and LCP TTFB is where Kinsta earns its price. Google Cloud's premium tier infrastructure, combined with Kinsta's server-level caching, consistently brings time-to-first-byte down to well under 200ms on a clean install. That matters for LCP because a slow server response pushes every subsequent load event back before the browser has even started rendering. Sites migrated from shared hosting routinely see their LCP scores drop by several hundred milliseconds on Kinsta without a single line of code changing. The server sets the ceiling on your TTFB. Everything above it sits in your own codebase. If your theme loads a 1.2MB hero image as the largest contentful element, or your WordPress plugins are queuing six render-blocking scripts, Kinsta's infrastructure absorbs none of that. A fast server under a bloated theme is still a slow site. CLS Is Your Problem to Solve CLS is almost entirely yours to fix. The host has nothing to do with layout shift caused by fonts loading late, images missing width and height attributes, or ad slots that reflow the page. No amount of infrastructure investment touches that. Kinsta vs Shared Hosting: Who Should Switch The price difference is significant enough that it deserves a straight answer rather than vague promises about "enterprise infrastructure". Kinsta earns its cost when a site is already generating consistent traffic, running WooCommerce at any real volume, or hitting performance ceilings that no amount of caching fixes can solve. A content-heavy site with several thousand monthly visitors, where a slow Time to First Byte is dragging down conversions, will feel the difference. The same goes for any business where downtime has a measurable cost. In those situations the gap between a £5 shared plan and Kinsta's entry tier closes faster than most people expect. For a brochure site, a small portfolio, or a blog pulling a few hundred visits a month, a well-configured shared or VPS plan does the job. The real bottleneck on those sites is usually plugin weight and render-blocking assets, not the server tier. Kinsta makes sense when the site has outgrown its host. Not before. The MyKinsta Dashboard and Developer Tools MyKinsta is tidy. Everything you'd reach for on a regular basis sits where you'd expect it, and the interface never feels like it was designed by committee. The staging environment is where the dashboard earns its keep for most people. One click creates a copy of your live site, you make changes, and you push them back without FTP or manual database exports. Site cloning works the same way, which cuts the time to spin up a new build considerably. SSH access and WP-CLI are both there out of the box, so if you're comfortable working from a terminal, you're not fighting the host to get in. The analytics panel shows cache hit rates, bandwidth, PHP worker usage, and top traffic sources. That is more useful than the vague graphs most hosts offer. If you look after plugins that affect site performance, having PHP worker data visible makes it far easier to trace the cause of a slowdown. A simpler shared host handles all of this invisibly. Kinsta hands you the controls, and that suits developers or hands-on site owners well. For a basic brochure site with no technical support, it can feel like more dashboard than you bargained for. Where Kinsta Falls Short Plan Limits and Overage Charges The plan limits are where most people run into trouble. Each tier caps both the number of WordPress installs and monthly visitor counts, and if you push past either ceiling mid-month you are looking at overage charges rather than a graceful warning. A small agency managing half a dozen client sites on a lower-tier plan can find the maths working against them fairly quickly. Restricted Plugins Kinsta also runs a list of WordPress plugins it restricts or blocks outright, largely because they conflict with its server-level caching layer. That is a reasonable technical decision, but if a client's existing setup relies on one of those plugins, you either find a replacement or you push back on the migration. Neither is always straightforward. No Email Hosting There is no email hosting. Kinsta is a pure WordPress platform, so you need a separate provider for business email. That catches people off guard more often than you would expect. None of this makes Kinsta the wrong choice, but these are the friction points that surface once you move past the initial setup and start running a real site day to day. What Kind of Site Gets Full Value Kinsta earns its price tag on sites where downtime or sluggish load times cost money. An e-commerce store processing daily orders, a membership site with hundreds of concurrent logins, a SaaS marketing page feeding a paid acquisition funnel, these are the scenarios where the infrastructure pulls its weight. The managed environment also suits developers or technical owners who want root-cause diagnostics rather than a support agent who just clears the cache and closes the ticket. If you already understand how poorly chosen plugins compound server load, you'll get far more out of Kinsta's tooling than someone who finds the dashboard confusing. Small brochure sites, hobby blogs, or anything running on a tight budget will likely find the monthly cost hard to justify against what cheaper managed hosts can provide. If Kinsta doesn't fit the budget right now, the sensible move is to look at hosts that still prioritise server-level performance without the premium price point. What matters most is whether the infrastructure matches the actual demands of the site, not the brand name on the invoice. A leaner setup, properly configured, will outperform an expensive host left on default settings every time. ------------------------------------------------------------ # 7 Ways Small Businesses Can Use AI to Publish Content Faster Source: https://yorkshiredesign.co.uk/7-ways-small-businesses-can-use-ai-to-publish-content-faster/ Published: 2026-08-04 > Most small business owners know they should publish more content. The stumbling block is rarely ideas , it is the hours it takes to turn an idea into something readable, formatted, and live on the site. AI does not replace the thinking, but it cuts the mechanical work down considerably. These seven approaches are practical, low-cost, and genuinely shift the time you spend from grinding through a blank page to reviewing something that is already mostly there. Start with a content brief, not a blank page Most content plans fall apart before a word gets written. Not because the writer lacks ideas, but because the writing starts before the thinking is done. Ask an AI to produce a structured brief before a single sentence of the actual article gets written, and the whole process tightens up considerably. A good prompt might be something like: "Write a content brief for a small business audience on . Include the target reader, the main angle, four or five section headings, and a suggested word count per section." What comes back is a working skeleton. The angle is set, the scope is clear, and there are no mid-draft moments where the writer loses the thread and has to backtrack. That brief becomes the thing you write to, not the thing you wish you'd had after three rounds of edits. The real gain is fewer rewrites. When the structure is agreed upfront, the writing phase moves in one direction. AI automation for small business content works best when the thinking and the writing are treated as two separate steps, with the brief sitting between them. Turn one topic into a full content cluster Before you open any AI tool, spend five minutes mapping what a single topic can produce. A core article on "how to choose an accountant for your small business" can branch into a short FAQ page covering the four or five questions people search most, a two-sentence social caption pulling the sharpest takeaway, a 90-word email summary for your newsletter, and a meta description written to earn the click. That is five assets from one session of thinking, and the groundwork is the same for all of them. Map that expansion first, write the core piece second, then use the AI to reformat and compress for each destination rather than starting from scratch each time. The brief you give the AI changes slightly per format, but the research, the angle, and the facts stay constant. That is where the real time saving lives. Getting into this habit matters more than any particular tool. Most small businesses abandon a structured content strategy because each piece feels like a separate project. Treating one topic as a cluster removes that friction from the start. Let AI handle the first draft, then cut it into shape The draft that comes back from an AI tool is a starting point, full stop. It will often be wordy, a little vague, and written in a tone that could belong to any business in any industry. Your job is to cut it into shape. Pull out the padding, shorten the sentences that meander, and wherever the AI has made a general claim, replace it with something specific. If you run a bathroom fitting company and the draft says "we provide quality services," swap that out for what you do differently, the detail only you know. Most of the editing work comes down to one question, does this sound like us, or does it sound like a press release from nobody in particular? The review habit that matters most is reading the draft aloud, or at least in your head as if you were saying it to a customer face to face. You will catch the awkward phrasing, the repeated words, and the sentences that run two beats too long. For small businesses where content writing for SEO doubles as your primary way of building trust with new visitors, that voice check is not optional. It is the difference between copy that converts and copy that gets closed. Automate the publish workflow, not just the writing Getting a draft written is only half the job. The part most people overlook is everything that happens after. Opening WordPress, pasting the text, fixing the formatting that breaks in transit, uploading a featured image, setting the category, filling in the meta title and description, remembering to set it as a draft rather than accidentally pushing it live. Each of those steps takes a minute or two, and across a week of publishing they add up fast. A tool like n8n can watch a specific Google Doc folder or a Notion database, pick up a finished piece, and push it straight into WordPress as a staged post with the category, featured image URL, and meta fields already mapped from a simple template you set once. That single pipeline saves somewhere between 20 and 30 minutes per piece, which across ten articles a month is a meaningful chunk of time back. The setup is a few hours of work. The saving is permanent. If n8n feels like too much to start with, there are lighter options. WordPress's built-in REST API accepts posts from almost any automation layer, and for small teams already living in Notion, connecting your first automated workflow is often simpler than people expect. The real win is removing the manual hand-off entirely so a finished draft does not sit waiting to be published. Where AI goes wrong and where you have to step in AI writes confidently. That confidence is the problem. A language model has no idea what your business charges, which services you offer under what name, or what a real customer told you last Tuesday. It cannot cite a result you produced, name a product from your catalogue, or take a position that might put someone off. That last point matters more than people expect. The kind of blunt, specific opinion that tells a reader a practitioner wrote this, rather than a machine filling a word count, is exactly what Google's quality assessors look for when they decide whether content deserves to rank. Generic, hedged prose that could have come from any source reads as thin content, and thin content sits. So does anything that invents numbers to sound authoritative, which AI will do the moment you leave a gap unfilled. The places where human editing is non-negotiable are fairly predictable. Pricing, named services, practical decisions about where to spend your AI budget, real customer outcomes, and any claim that only holds true for your specific business. A quick pass with those additions transforms a plausible-sounding draft into something that earns trust. Building a repeatable rhythm around AI output The weekly loop that keeps the queue full A single AI draft is useful. A fixed weekly cadence is what moves the needle over time. The pattern that tends to work best is straightforward: Monday you write a brief, even a rough one, covering the topic, the angle, and two or three points you want to land. Tuesday the draft comes back from your AI tool. Wednesday you edit, tighten, add any specific detail the AI could not know, and schedule the post. That three-day loop means you are never sitting down to a blank page. You always know what stage each piece is at, and the queue stays full without any single session feeling like a marathon. Run it for a month and you have four posts. Run it for six months and you have a body of content that earns traffic while you are busy doing everything else a small business demands. The compounding effect only works because the system is boring and repeatable, not because any individual piece was remarkable. For anyone figuring out how to structure AI tasks into a sustainable weekly workflow, the brief is the piece most people skip and the reason most attempts stall after a few weeks. One rule to keep Protect the rhythm above the quality of any single draft. A published piece that is eight out of ten beats a perfect piece that never ships. The minimum viable setup to get started this week What you actually need You need three things and nothing more. A capable AI model such as Claude or ChatGPT, a working WordPress install, and a repeatable prompt template you have tested yourself. The prompt matters more than most people expect. Something like "write a 600-word blog post for a business aimed at homeowners in , covering , and keep the tone conversational" will produce something usable far faster than an open-ended request. Spend an afternoon running the same prompt five or six times, adjusting it each time, until the output reliably needs only light editing rather than a full rewrite. That is the real setup work, and it pays to do it once properly rather than skipping straight to publishing. What a realistic first month looks like Four to six published posts, not forty. That is enough to see how the content indexes and whether your prompt template is producing anything Google finds coherent. The temptation once the workflow clicks is to flood the site with posts, but thin content published at speed does more harm than a smaller number of well-edited pieces. Use the first month to refine your approach to content planning rather than chasing volume. Traffic takes time to follow, and no setup, however efficient, changes that. ------------------------------------------------------------ # Why LCP Is the One Speed Metric Clients Actually Feel Source: https://yorkshiredesign.co.uk/why-lcp-is-the-one-speed-metric-clients-actually-feel/ Published: 2026-08-04 > Ask a client what they thought of their new site and the first thing they mention is usually how fast it felt. Not the mobile score, not the layout shift number, not any lab metric. Just that gut-level impression of the page appearing. That moment is almost always controlled by Largest Contentful Paint. It is the one performance number that maps directly onto how a real person experiences loading a page, which is exactly why it is worth understanding properly. What LCP Measures LCP is the browser's best guess at the moment a page feels loaded. Not when the first pixel appears, not when every last script has fired. The specific point when the biggest visible element lands on screen. That element is usually a hero image, a large block of text, or a banner sitting above the fold. The browser watches the page build itself, tracks which element takes up the most space in the viewport, and records the timestamp when that element finishes rendering. That timestamp is your LCP score. Google considers anything under 2.5 seconds good and anything over 4 seconds a problem, with a middle band where pages scrape by without excelling at either end. The reason this matters is that the biggest element is almost always the one your visitor is consciously or unconsciously waiting for before they decide the page has arrived. A spinner finishing in the corner of the screen means nothing to them. The hero image completing does. Raw page speed, in the purely technical sense, measures things like time-to-first-byte or the waterfall of network requests. Most visitors never perceive those numbers directly. LCP is different because it maps to something a real person notices, the moment the page stops feeling empty. That is why it sits at the centre of the Core Web Vitals scoring framework, rather than the dozens of other timing signals browsers collect behind the scenes. Why Other Speed Metrics Miss the Point TTFB, FCP and TBT all have legitimate uses, but none of them map cleanly to what a visitor experiences when a page loads. Time to First Byte measures how quickly your server responds, which matters for infrastructure decisions but tells a user nothing about whether they can see anything useful yet. First Contentful Paint fires the moment any content appears, even if that content is a loading spinner or a tiny navigation logo tucked in the corner. Total Blocking Time captures how long the main thread is tied up, which is important for interactivity, but again it is a number that lives inside a developer's console, not in a visitor's perception. The gap between these metrics and real-world experience is why you can hand a client a PageSpeed Insights report full of decent scores and still have them tell you the site feels slow. They are not wrong. They just felt something the numbers did not show. LCP is different because it measures the moment the dominant piece of content lands, usually the hero image or the main heading block. That is the visual beat where a visitor decides whether the page has arrived or whether they are still waiting. The page speed metrics Google scores you on are all worth understanding, but if you had to pick one that a real person can feel, it is this one. What Causes a Poor LCP Score Hero images and server response Google's guidance points to four main culprits, and on WordPress sites you see all four with depressing regularity. Hero images are the most common offender. A theme ships with a full-width banner image that's 2MB, uncompressed, served without fetchpriority="high", and loaded lazily because someone left the default settings untouched. The browser queues it behind everything else, and the LCP time balloons to four or five seconds before the image even starts painting. Slow server response causes quiet devastation in a different way. If the time to first byte is above 600ms, the browser is already behind before it has downloaded a single asset. Shared hosting on an overloaded server will do this every time. Render-blocking resources and client-side rendering Render-blocking resources compound the problem fast. A theme that enqueues three Google Fonts calls and two undeferred JavaScript files is effectively making the browser sit on its hands before it can touch the main content. Those delays stack. Client-side rendering is the fourth culprit, and the one most often overlooked during a build. Builders that lean heavily on JavaScript to assemble the page mean the server sends an almost empty HTML document, and the browser has to run the JS, parse the result, and then paint the LCP element. That entire process happens after load, which is why a site can feel fast on a developer's machine and sluggish everywhere else. If you want to understand how Core Web Vitals scoring works across these delays, the relationship between TTFB and LCP is a good place to start unpicking it. How Clients Describe a Bad LCP Nobody rings up and says "my Largest Contentful Paint is sitting at 6.2 seconds." What they say is "it just felt slow" or "the page kind of hung there before anything loaded" or, the one that sticks with me most, "it looked broken." That last one is telling. When the main image or headline block takes too long to appear, visitors cannot tell whether something has gone wrong with the site. The browser is loading, the tab is spinning, but the screen is visually empty. That gap between the moment a user clicks and the moment they see something real and meaningful is exactly what Google's Core Web Vitals scoring is trying to measure with LCP. Clients feel it as impatience, then doubt, then a back button. The score just puts a number on it. That translation matters when you are explaining a technical audit to someone who runs a plumbing business or sells handmade ceramics. They do not need to understand render pipelines. They need to know that the "it felt sluggish" complaint their customers keep mentioning is fixable, and that there is a specific measurement telling you exactly how bad the problem is. Does LCP Affect Rankings? Yes, but not in the way most people assume. LCP is part of Google's Core Web Vitals assessment, which feeds into a ranking signal called Page Experience. It counts. It is just not the only thing that counts. Google has been transparent about this for a while now. Core Web Vitals are a tiebreaker, not a trump card. A page with useful, well-structured content and strong relevance signals will outrank a fast-loading page that says very little. Where LCP starts to tip the scales is when two pages are broadly similar in quality and the crawlers are choosing between them. At that point, the site that loads its main content in under 2.5 seconds has a real edge over one sitting at 4 or 5 seconds. If you look at the page speed metrics Google scores you on, LCP carries the most visible weight of the three Core Web Vitals, partly because it is the one that directly maps to how a real visitor experiences a page loading in front of them. Fix your content first, then fix your speed. Both matter, and in competitive niches where the content quality between sites is close, a poor LCP score can be the quiet reason a page stalls on page two. Where to Start if Your LCP Score Needs Work Sort the image first The single most reliable place to start is the image. On most WordPress sites, the LCP element is a hero image or a large above-the-fold graphic, and the fix almost always falls into one of three areas, the file is too heavy, it is not preloaded, or it is being loaded lazily when it should not be. Strip the lazy-load attribute from your hero image first. Then check whether the image is preloaded with a <link rel="preload"> tag in the document head. If neither of those is in place, sorting them out tends to move the needle faster than anything else on the list. Check hosting response time and fonts After the image, look at your hosting response time. A slow server adds latency before a single byte of your image has transferred, and no amount of image optimisation fully compensates for a host that takes 600ms just to respond. You can read Google's own guidance on the page speed metrics Google scores you on to understand how TTFB feeds directly into your LCP window. Fonts are the next thing to check. A render-blocking web font can delay the LCP element by several hundred milliseconds even when your image is perfectly optimised. On a typical WordPress site, a focused round of fixes takes two to four weeks to show movement in field data. Lab scores update immediately, but real-world Chrome User Experience Report data reflects actual visits accumulated over 28 days, so patience matters here. ------------------------------------------------------------ # From Brief to Published: How AI Changes the Workflow Source: https://yorkshiredesign.co.uk/from-brief-to-published-how-ai-changes-the-workflow/ Published: 2026-08-04 > Most people assume AI just helps with writing. Give it a prompt, get some copy back, paste it in. That's the surface layer. Underneath, there's a quieter shift happening to the whole pipeline, from the moment a brief is written to the second a post goes live. Understanding where that shift happens, and where it doesn't, saves a lot of wasted time chasing the wrong tools. What a Traditional Brief-to-Publish Workflow Looks Like Most content workflows have more steps than people admit, and the friction hides in the gaps between them. A typical brief starts life as a rough idea, a keyword, or a client request dropped into a document or a thread somewhere. Someone turns that into a structured brief, which means agreeing on audience, tone, angle, word count, and internal links before a single sentence gets written. That brief then travels to a writer, who may come back with questions, a first draft, or both. The draft goes to an editor, gets marked up, returns to the writer for revisions, then moves on to someone who handles SEO checks, metadata, and formatting for the CMS. After that, there is usually a final proofread, an image sourcing step, and someone publishing the thing. On a well-run team, that chain works. But each handoff is a potential delay, a misread instruction, or a version control problem waiting to happen. The part people most often underestimate is the brief itself. A vague brief produces a draft that does not quite fit, which means extra revision rounds, which means the whole chain takes longer. The content still gets published eventually, but the cost in time is real, and it compounds across every piece a team produces. Where AI Slots In Without Breaking Anything The handoff points where AI earns its place are narrower than most people assume, and that is fine. Research is the obvious one. Feed a topic and a rough angle into a capable model and it returns a structured summary of what has already been covered, what questions keep surfacing, and where the obvious gaps sit. That used to take a decent chunk of a morning, scanning tabs, pulling threads, deciding what matters. An AI handles the scan in minutes, leaving the judgement call about which angle to pursue with the person who understands the audience. Outline drafting follows the same logic. A rough structure built from that research gives a writer something solid to push against, and pushing against a draft is always faster than staring at a blank document. Metadata generation is the other place AI earns its keep. Title tags, meta descriptions, and social snippets are repetitive by nature. The rules are well-established, the character counts are fixed, and the task does not change much from one piece to the next. You can read more about how smaller operations are applying AI to repetitive marketing tasks without overhauling everything they already have. None of this replaces the editorial layer. It handles the mechanical groundwork so the actual thinking gets more time. Why Getting the Brief Right Still Matters Garbage in, garbage out Feed a vague prompt into an AI content tool and you will get vague output back. That is not a flaw in the model. A brief that says "write something about our new service" gives the machine almost nothing to act on, and what comes back will be generic enough to belong to any business in any sector. The AI fills the gaps you left open, and it fills them with the safest, most average thing it can produce. If your brief names the target reader, the specific problem being solved, the tone you want, and the one action you need the reader to take, the output narrows considerably. You get something you can use rather than something you need to rewrite from scratch. What a tight brief actually includes Think of the brief as the part of the process that no automation can do for you. The details that matter most are the ones a machine cannot assume. Who is this piece for? What do they already know? What are you asking them to do at the end? For anyone exploring how to embed AI automation into their content process, the brief is where the real thinking sits. Spend ten minutes writing a tight brief and you save an hour fixing output that drifted in the wrong direction. That trade pays off every time. Review, Edit and Publish: What Stays Human The problems AI drafts tend to carry AI can draft quickly, but the output nearly always arrives with rough edges. Tone is the most common problem. A generated paragraph might be technically accurate and structurally sound, yet feel flat or slightly off-brand, the kind of thing a reader notices without being able to say exactly why. Facts are another weak spot. AI pulls from training data, not live sources, so a figure that was correct eighteen months ago may sit in the draft looking entirely plausible while being out of date. Then there is context. A client's specific situation, a product nuance, a recent change to the business, none of that is in the model's memory, and no amount of prompting fully fixes it. Someone who knows the subject has to read the draft with that knowledge and adjust accordingly. The editing step is where realistic expectations about AI-generated content get tested against the actual output. Treat it as a capable first draft, not a finished article. Before you hit publish Final checks still need a person. SEO meta, internal links, image alt text, category tagging, and a read-through that asks whether this sounds like us. That last part cannot be automated. How This Looks Inside WordPress WordPress is where most of this lands in practice, and the connections are more direct than people expect. A typical setup pipes content from an AI drafting tool straight into a post or custom post type, usually via the REST API or a plugin that talks to an external automation platform. The draft arrives with a populated title field, a meta description, assigned categories, and sometimes a featured image pulled from an AI image source. What does not arrive ready is editorial judgement. Internal links still need a human to place them sensibly. Schema markup may need checking against the actual page structure. And if the site runs a custom theme with its own field setup, someone needs to confirm the right fields got the right data. The automation handles the repetitive shell of the post. The things that require knowing how the site actually works still need attention. For anyone running AI workflow automation for the first time, WordPress is a reasonable place to start because the tooling around it is mature. Zapier, Make, and custom PHP scripts can all push content into WordPress reliably. The cleaner the site's underlying structure, the smoother the pipe. A cluttered install with conflicting plugins will cause problems that no automation layer fixes on its own. How Long This Workflow Shift Takes to Bed In Longer than most people expect, and that is not a problem with the tools. When you bring AI into a brief-to-publish process, the first few weeks are mostly about figuring out where it fits, which tasks benefit from automation, and which ones still need a human hand on them. You are not just installing software. You are rethinking a process that probably took years to settle into a comfortable rhythm, and asking your team, or yourself, to rebuild habits around something that behaves differently every time you prompt it. A common pattern is that output quality dips slightly before it improves. The prompts are rough, the review steps are not yet defined, and people are still second-guessing whether to trust the draft or rewrite it from scratch. Getting past that stage takes four to six weeks of genuine daily use, not occasional experiments. If you want a realistic read on where small businesses tend to stumble first, the guidance around getting the initial setup right for smaller operations is useful to read before you commit to a particular approach. The workload reduction is real. It just arrives gradually, not on day one. ------------------------------------------------------------ # Bing’s Growing Market Share: What It Means for Your SEO Source: https://yorkshiredesign.co.uk/bings-growing-market-share-what-it-means-for-your-seo/ Published: 2026-08-04 > Most people set up their SEO around Google and stop there. That made sense for a long time, and Google still dominates. But Bing's share of search has been creeping upward, particularly among desktop users and anyone who uses a Windows machine without changing the default browser. Before you dismiss it, it's worth understanding exactly where that growth is coming from, because the answer changes whether or not any of this should shift what you do. Where Bing's Numbers Are Actually Coming From The "Bing is growing" headline gets repeated a lot, but the data behind it is more specific than the summary suggests. A big part of it comes down to Windows defaults and the Edge browser. Every new Windows machine ships with Edge as the default browser and Bing as the default search engine, and a meaningful share of users never change either. That is not Bing winning on merit against Google. It is Bing holding a captive audience that Microsoft has spent years carefully not losing. Older demographics lean heavily into this pattern, particularly users who set up a PC years ago and have no strong reason to swap. Add Copilot into the picture and the dynamic shifts slightly. Microsoft has embedded AI-assisted search directly into the Windows taskbar, meaning users who ask Copilot a question are, under the hood, running a Bing query whether they know it or not. That integration is expanding Bing's query volume in ways that traditional browser market-share reports undercount. None of this makes Bing a strategic afterthought. These audiences are real, they search with intent, and in sectors like financial services, B2B software, and healthcare, the case for treating Bing traffic seriously is harder to dismiss than most people assume. The growth is not evenly spread across every niche, but where it is present, it is consistent enough to act on. Google SEO and Bing SEO Are Not as Different as You Think The assumption that ranking on Bing demands a completely separate workstream is mostly wrong. Clean technical structure, useful content, well-earned backlinks, good page speed, and clear site architecture all pull weight on both engines. If you have spent time getting those fundamentals right for Google, a large chunk of that work carries over. A site that loads fast, marks up its content clearly, and earns links from credible sources will perform better on Bing for the same reasons it performs better anywhere else. The overlap is far bigger than most people building SEO strategies tend to account for, which means the cost of showing up on Bing is lower than it looks. Where the real differences sit Bing places noticeably more weight on exact-match anchor text. If your link profile leans heavily on branded or generic anchors, you may rank lower there even with solid overall authority. Domain age also carries more obvious influence in Bing's ranking signals, which can feel frustrating for newer sites. On the structured data side, Bing reads Schema markup and processes open graph metadata in ways that diverge slightly from how Google prioritises those signals. Testing your structured data in Bing Webmaster Tools separately is a sensible habit rather than an optional extra. One strategy, tuned carefully, covers most of the ground on both. What Bing AI Search Does to Organic Clicks Copilot sits at the top of a growing share of Bing results pages, pulling a summarised answer directly from indexed content and presenting it before a user ever sees the blue links below. Your page can be the named source, your structured data can be the reason the answer exists at all, and the user still has no reason to click through. The value exchange that used to happen at the click now happens at the summary. It is not a theoretical risk. It is the same pattern that played out when Google rolled out featured snippets, and Bing is moving faster on it than most site owners have noticed. The pages most exposed are the ones built around single, clean answers. Definition pages, FAQ sections, how-to guides with a clear numbered process. Anything a language model can restate in two sentences loses the click almost every time. That does not mean pulling back on structured, well-organised content. It means being deliberate about what your pages contain beyond the quotable answer. Depth, context, proprietary data, a specific point of view, comparison tables, step-by-step detail that a summary cannot usefully compress. For anyone thinking through how AI-powered search affects organic traffic across both major engines, the pattern is consistent. Pages that give a reader a reason to stay are the ones that survive a world where the top of the results page increasingly answers the question before anyone clicks. The Signals Bing Uses That Google Largely Ignores Social signals and crawl hygiene Social signals carry real weight on Bing in a way Google has never confirmed for its own algorithm. A page that picks up genuine shares and engagement on LinkedIn or Facebook tends to get a small but measurable lift in Bing's results. If you are producing content and not distributing it properly, you are leaving ranking potential on the table. Bing also indexes more slowly than Google, which means crawl hygiene matters more here. If your sitemap is messy, your internal links are broken, or you have a run of thin pages that waste crawl budget, Bing will not work around it the way Googlebot often does. It just will not get there. What Bing Webmaster Tools shows you Bing Webmaster Tools surfaces keyword-level click and impression data in a more readable format than Search Console manages in several respects, and it is far less used, so the keyword gaps you spot there tend to be fresh. Most site owners have not looked. None of this demands a separate strategy. It does demand attention to the technical foundations you should already have in place. Should You Optimise for Bing Separately? For most sites, no. The overlap between solid Google SEO and Bing performance is large enough that you are already doing most of the right things. Clean page structure, well-written content, a fast-loading site, proper title tags and meta descriptions, good internal linking, a healthy backlink profile. Every one of those moves the needle on both engines. Where people waste time is treating Bing as a completely separate discipline with its own content strategy, its own keyword research, and its own optimisation runs. That is almost always unnecessary overhead for a site that is already well-maintained on the Google side. There are two cases where separate attention pays off. First, high-ticket B2B businesses where Bing's desktop-heavy, older professional audience is bigger than Google's for that sector. Second, any site that has never been submitted to Bing Webmaster Tools and has gaps in its index as a result. That second one takes twenty minutes to fix and is the most common oversight I see. Check Bing Webmaster Tools, submit your sitemap, confirm your key pages are indexed, then get back to the work that benefits both engines at once. The One Practical Step Most Sites Skip Most sites that have had Google Search Console running for years have never been submitted to Bing Webmaster Tools. Not because the owner decided against it, but because it never came up. Setting up Bing's organic search presence starts with a five-minute verification step. Skip it and Bing's crawler is working blind on your site. It may index some pages eventually, but you get no data, no error reports, and no way to submit a sitemap. For a search engine that now powers Copilot, Microsoft Edge, and a growing slice of desktop and enterprise traffic, that is a surprisingly large blind spot to carry around. The process is straightforward. Go to Bing Webmaster Tools, sign in with a Microsoft account, add your site, and verify ownership using an XML file, a meta tag, or by importing directly from Google Search Console. That last option takes about thirty seconds if you already have GSC set up. Once verified, submit your sitemap. That single action tells Bing exactly what pages exist and how often they change. It does not guarantee rankings, but it removes the single biggest barrier between your content and Bing's index. There is no good reason to leave it undone. ------------------------------------------------------------ # Schema Markup for Local Businesses: What to Add and Where Source: https://yorkshiredesign.co.uk/schema-markup-for-local-businesses-what-to-add-and-where/ Published: 2026-08-03 > Most local business owners hear 'schema markup' and picture something complicated that probably isn't worth the bother. The reality is that a handful of well-placed structured data types can meaningfully sharpen how Google reads your site, and most of them take under an hour to add properly. The tricky part isn't the code, it's knowing which types to bother with and where they actually belong, because adding schema in the wrong place or with the wrong fields does nothing useful. What Schema Does for a Local Business Google does not read your website the way a person does. It reads signals, and schema markup is one of the clearest signals you can give it. Without structured data, Google has to guess at the connections between your business name, your address, your services, and the reviews people leave. It can usually piece something together, but "usually" is not a strategy. Schema markup removes that ambiguity by giving Google a structured, machine-readable description of exactly who you are and what you do. Think of it as the difference between handing someone a printed map versus describing the route in conversation. When a local search for "emergency plumber near me" fires at 11pm, Google is matching that query to real-world entities, a business, a location, a category, a trust signal. Businesses with properly implemented structured data make that matching process considerably easier, which means they show up in rich results, map packs, and knowledge panels more reliably than businesses that leave Google to figure it out alone. The practical difference shows up in search results themselves. A local business with schema can surface star ratings, opening hours, and a phone number directly in the result snippet. Without it, you get a plain blue link and a description Google wrote for you. One of those earns a click. The other gets scrolled past. LocalBusiness Schema: The Foundation LocalBusiness is the schema type that underpins everything else. Without it, Google has no structured starting point for understanding who you are, where you operate, or when you're open. The fields that carry the most weight are name, address, telephone, openingHoursSpecification, and geo coordinates. Each one answers a different question a search engine asks before it considers surfacing you in local results. Leave two or three of them out and you've handed Google a half-finished picture, which is often treated much the same as no picture at all. A plumber with a name and phone number but no geo coordinates is invisible to the radius-based logic that drives map pack rankings. A restaurant with address and coordinates but no opening hours is a liability to Google, because serving a result for somewhere that might be shut damages the user experience Google is trying to protect. The openingHoursSpecification field trips people up most often. It requires day-by-day structured data, not a plain text string like "Mon-Sat 9-5". You can read the exact expected format in the full breakdown of local business schema fields before you publish anything. A partial implementation is not a foundation you build on later. It's noise that competes with your correct data. Service Schema and What You Actually Do LocalBusiness schema tells Google you exist, where you are, and how to reach you. It says nothing about what you sell. That gap is where Service schema earns its place, and it matters most for businesses that work across a region rather than waiting for customers to walk through a door. A plumber covering three counties, a web designer taking on clients nationwide, a mobile dog groomer with no fixed premises. None of them have a product catalogue, but they all have distinct services that deserve their own structured description. Adding a Service block for each offering, and pointing it to the relevant page on your site with the structured signals Google weighs for service-area businesses, keeps your markup grounded in real content rather than floating as a vague, single-block description of everything you do. A shopfront selling physical goods rarely needs this. Service schema is built for businesses whose value is the work itself. The structure is straightforward. Each Service item should include a name, a short description that matches the copy on that page, and a provider reference back to your main LocalBusiness entity. If you offer five services and have five pages, you build five blocks. The temptation is to lump everything into one generic entry, but that gives Google nothing useful to connect to a specific search. A single "we do plumbing" block is far weaker than a block for boiler installation, another for drain clearance, and another for emergency call-outs, each mapping to the page a searcher would actually land on. Review and FAQ Schema Review markup, what changed and what still works Review schema is probably the most misunderstood markup a local business can add. The old pattern, adding aggregate rating markup to your own site using reviews you collected yourself, no longer earns star ratings in Google's search results. Google removed that rich result for self-serving review markup some time ago, and many businesses are still adding it out of habit. Where it does still work is on genuine third-party review platforms, or on pages that aggregate independently verified reviews through a recognised provider. If you run a service business and you're expecting stars to appear under your homepage listing just because you dropped some JSON-LD on the page, you'll be disappointed. The markup won't break anything, but it won't produce a rich result either. FAQ markup, still useful, just not for the reason most people think FAQPage schema is a different story, though the picture has shifted there too. Google pulled FAQ rich results from most search features for the majority of websites, limiting them largely to authoritative government and health sites. For a typical local business, FAQPage markup is unlikely to produce an expanded result in the SERP. That said, structured FAQ content still has value for local SEO signals because it gives search engines a clean, unambiguous reading of your questions and answers, which can feed into AI-generated responses and voice search. Add FAQ markup if you have a genuine FAQ section. Skip it if you're building one purely to chase a rich result that almost certainly won't appear. Where to Put the Code in WordPress Schema goes in the <head> of the page. That's the short answer, and most plugin documentation will tell you the same. WordPress gives you several routes, a dedicated schema plugin like Rank Math or Yoast, a code snippets plugin, or direct edits to your theme's functions.php. Each works, but the choice has real consequences. The most common mistake I see is using a sitewide schema plugin set to output LocalBusiness markup on every single URL, including blog posts, tag archives, and WooCommerce product pages. Google then sees your local business schema attached to a page that has nothing to do with a local business listing, and that tends to produce validation warnings rather than rich results. The fix is straightforward. Scope your LocalBusiness JSON-LD to the homepage, contact page, and any location-specific landing pages only. If you're using Rank Math, the display conditions setting handles this cleanly. If you've hand-coded it via a snippet, a simple conditional check against is_front_page() or a specific page ID does the job. Once you've placed the code, run the URL through Google's Rich Results Test to confirm it validates without errors. Look past the green tick and check the detected fields, because a schema block can pass validation while still missing properties Google uses for local pack rankings. The Fields Google Validates Errors versus warnings, they are not the same thing Search Console's structured data report splits problems into two buckets. Errors disqualify a result from enhanced features. Warnings flag missing recommended properties. For a LocalBusiness schema, the fields that reliably trigger errors are name, address, and url. Leave any of those out and Google cannot confirm your markup is valid. The address block itself needs to be broken into sub-properties properly. That means streetAddress, addressLocality, postalCode, and addressCountry all need to be present as separate fields rather than one concatenated string. Validators will accept a single string and show it as passing, but Search Console reads it differently and will flag the schema as incomplete. That gap between what a third-party validator shows you and what Google's own report surfaces is something people run into more than you'd expect. What warnings actually mean Missing openingHours, telephone, or priceRange will show up as recommended fields in Search Console, but they will not prevent your markup from being valid. Most schema plugins surface every optional property as though it carries the same weight as a required one, which muddies the picture considerably. If you want to see exactly what Google considers an error versus a warning, the Rich Results Test tool shows both categories side by side. Check that before assuming your markup is clean. ------------------------------------------------------------ # Website Accessibility: What UK Businesses Must Do Source: https://yorkshiredesign.co.uk/website-accessibility-what-uk-businesses-must-do/ Published: 2026-08-03 > A solicitor in Leeds updates her firm's website, adds a client enquiry form, and assumes the job is done. Six months later a prospective client with a visual impairment can't read the form fields, can't submit, and leaves. No complaint is filed, but that client is gone. UK accessibility law has had teeth for years, and most small business websites are still not compliant. Here is what the rules actually require, and a practical place to start. What UK Law Says The Equality Act 2010 requires organisations to make "reasonable adjustments" so that disabled people can access goods and services, and that includes your website. There is no exemption for small businesses or sole traders. The Act covers any organisation serving the public, so if someone cannot use your site because of a visual impairment, a motor condition, or a cognitive difficulty, you are potentially in breach. On top of that, public sector bodies must also meet the Public Sector Bodies Accessibility Regulations, which mandate compliance with WCAG 2.1 AA as a minimum standard and require a published accessibility statement. Private sector organisations are not bound by those specific regulations, but the Equality Act still applies and carries real weight if a complaint reaches a tribunal. Know which standard applies to you, audit your site against it, and document what you find. A website accessibility checklist is the most useful starting point because it turns a broad legal concept into concrete, fixable items. Who Is Covered Public sector organisations face the toughest rules under the Public Sector Bodies Accessibility Regulations (PSBAR), which came into force in 2018 and require government websites and apps to meet WCAG 2.1 AA as a legal baseline. Private businesses are not subject to PSBAR, so it is easy to assume accessibility law does not apply to them. It does. The Equality Act 2010 covers any organisation that provides goods, facilities or services to the public, and a commercial website counts as a service. A disabled user who cannot complete a purchase, book an appointment, or read your terms because of a missing accessibility feature could bring a claim against you. It does not require the site to be wildly broken either. Something as mundane as images with no alt text, or a checkout form that a screen reader cannot navigate, could be enough to form the basis of a complaint. Take an online clothing retailer as a concrete example. If a visually impaired customer cannot use the checkout because the form fields carry no labels that assistive technology can read, that business faces real legal exposure, not just bad press. The practical gap between PSBAR and the Equality Act is narrower than most people think. A thorough audit of how your site performs for real users is where most businesses discover these issues exist at all. The WCAG Standard Which level applies to you The benchmark UK regulators and courts point to is WCAG 2.1 Level AA, published by the World Wide Web Consortium. It sits in the middle of three conformance levels. Level A is the floor, AA is what most organisations are held to, and AAA is reserved for specialist services where every user has a specific accessibility need. Public sector bodies in the UK are legally bound to AA under the Public Sector Bodies Accessibility Regulations, and private businesses facing an Equality Act claim will almost certainly be measured against the same standard. AA is the target. The four principles behind the standard WCAG organises its requirements under four principles. Perceivable means users can see or hear your content, so images need alt text and videos need captions. Operable means every function works without a mouse, keyboard-only navigation included. Understandable means your forms give clear error messages and your language does not require a law degree. Robust means the code is clean enough for screen readers and assistive tools to interpret reliably, which is where a lot of otherwise decent sites fall apart. A Practical Accessibility Checklist Images, keyboard navigation, and colour contrast Start with images. Every image that carries meaning needs an alt attribute describing what it shows, not just its filename. A photo of a solicitor's office front door should read something like "Front entrance of Smith & Co Solicitors on Market Street", not "img_0047.jpg". From there, tab through your entire page using only the keyboard. Every link, button and form field should receive a visible focus state and respond correctly. If your cursor disappears into the page and you lose track of where you are, something is broken. Check colour contrast next. The visual design choices that look sharp in a mockup often fail in practice. Body text needs a contrast ratio of at least 4.5:1 against its background, and WCAG's own contrast checker will give you a pass or fail in seconds. Forms, links, and heading structure Form fields need visible labels that stay on screen, not placeholder text that vanishes the moment someone starts typing. Links should say where they go. "Click here" tells nobody anything. "Download our accessibility policy PDF" does the job. Finish with heading structure. One H1 per page, then H2s for major sections, H3s beneath those. Screen readers use that hierarchy to navigate, so skipping levels causes real confusion for users who rely on them. WordPress Sites Have a Specific Problem Here WordPress is brilliant for building sites quickly. That speed has a cost, and accessibility is often where it shows up first. Page builders and theme frameworks generate a lot of markup automatically, and that markup frequently bypasses the standards that screen readers and keyboard users depend on. The most common pattern I see is icon-only buttons with no accessible label at all. A sighted user reads "close" or "menu" because they see the icon. Assistive technology reads nothing, or reads the raw CSS class name, which is meaningless. Form fields are another consistent weak spot. Automatically generated contact forms often pair an input with a placeholder rather than a real <label> element, which means the field label vanishes the moment someone starts typing. Slider and carousel components tend to produce focus traps or expose every slide to the DOM at once, confusing the reading order completely. Dropdown navigation built by theme frameworks often fails keyboard traversal too, because the aria-expanded attribute either is not there or never updates its state. None of this means WordPress itself is inaccessible. The problem is that many of these tools were built for visual output, not the kind of structural integrity that makes a site work for everyone. Catching these issues requires getting under the surface, not just running a quick automated scan. Accessibility Statements When you are legally required to publish one An accessibility statement is a published page on your website that explains how accessible it is, what known issues remain, and how visitors can contact you if they hit a barrier. For public sector bodies in the UK, publishing one is a legal requirement under the Public Sector Bodies Accessibility Regulations 2018. If you run a council website, an NHS service, a university, or any other public authority, you have no choice in the matter. The statement must follow a specific format, reference the WCAG 2.1 AA standard, and be updated at least annually. Skipping it is not a grey area. Why private sector businesses should bother anyway Private sector businesses are not legally required to publish one, but doing it anyway is useful. It signals to disabled users that you have thought about them, and it gives you a credible place to log known issues you are still working through rather than pretending they do not exist. Writing a basic statement takes an hour or two. The Government Digital Service publishes a sample template you can adapt, and most of the content is factual, what you tested, when, and what you found. Getting the Technical Side Fixed Automated scanning tools will flag the obvious problems, colour contrast failures, missing alt text, unlabelled form fields. They miss a significant portion of real accessibility issues. Screen reader behaviour, keyboard navigation order, focus states that disappear mid-page, ARIA labels applied in the wrong place, these are the things that only show up when someone reads the code and tests it properly. That kind of audit takes time, and cutting corners on it means the problems move somewhere less visible rather than disappearing. Most businesses do not need a six-month remediation project. They need someone who looks at what is broken, fixes the structure, and documents what was changed and why. That is the approach taken here at Yorkshire Design. The work is technical and thorough, and it is not rushed, because a quick pass rarely holds up. If your site has not had a proper accessibility review and you want the detail done right, a good first step is to understand how hidden site problems affect real users, then get in touch to talk through what an honest audit would involve for your specific setup. ------------------------------------------------------------ # One Script Tag That Killed a Product Launch Before It Started Source: https://yorkshiredesign.co.uk/one-script-tag-that-killed-a-product-launch-before-it-started/ Published: 2026-08-03 > The campaign was ready. The email had gone out. And the page sat there, not loading, while traffic piled up and conversion rate tanked in real time. A single third-party script, loaded in the wrong place, had frozen the render path before a single user could see the product. Nobody spotted it during testing because the office internet was fast enough to mask it. That is how render-blocking works. It waits for the worst possible moment. What render-blocking means When a browser loads a page, it reads the HTML from top to bottom, building as it goes. Hit a script tag and everything stops. That pause is not a technicality. The browser has no way of knowing whether the script it just found is about to rewrite the entire page structure, so it refuses to render anything below that point until the file has fully downloaded and executed. On a fast connection with a small file, the delay might be a fraction of a second. On a slower connection, or with a script hosted on a third-party server that takes its time responding, that pause stretches. The rest of the HTML is sat there, complete and ready, but the browser will not touch it. Your product hero image, your headline, your call-to-action button, all of it is locked behind one file the browser is patiently waiting on. The page is not broken. It is just held hostage until that script finishes doing whatever it came to do. Place that script tag in the <head> and the effect is worst of all. Nothing visible renders until the script clears. A visitor on a patchy mobile connection sees a blank screen, and most of them leave before the page ever appears, with no idea a perfectly good product was sitting just a few milliseconds behind the freeze. The scripts that cause most of the damage The usual suspects are third-party tags loaded synchronously in the <head>. Analytics snippets, live chat widgets, A/B testing libraries, ad network pixels. Each one feels perfectly reasonable when you drop it in during development. Your broadband is fast, the server is close, and the script loads in a blink. What you do not see is that the browser has to fully fetch, parse, and execute that script before it renders a single pixel of the page. Add three or four of these tags together and you have handed control of your page load to four different third-party servers, any one of which can stall the whole thing. An A/B testing library is particularly brutal here because it needs to intercept the page before anything renders, so by design it sits right at the top of the <head> and blocks everything behind it. On a slow mobile connection, or when that third-party server has a rough few seconds, your product page just hangs. The cruel part is that render-blocking behaviour rarely shows up on a developer's machine because local conditions mask it completely. Real users on congested networks get the unfiltered version. Moving these tags to load with async or defer, or shifting them out of the <head> entirely, breaks that chain. The page starts painting immediately, and the scripts catch up once the main content is already visible. Why staging and local testing miss it Your office broadband is probably delivering pages in under a second. Your staging environment sits on the same network, often with a browser cache already warm from the last time you checked it. That script tag loading a third-party widget or analytics library resolves in 40ms, feels fine, gets a green light. Nobody flags it. The problem is that 40ms figure has nothing to do with the conditions your customers are in when you go live. A mobile user on a patchy 4G connection, nowhere near your CDN's nearest node, can see that same request take 800ms or longer. That is not an edge case. Staging environments almost never simulate real network throttling, and most developers do not run Chrome's DevTools in slow-3G mode as a matter of habit before signing off. When traffic arrives on launch day from real devices across real connections, the render-blocking behaviour of a single script that nobody caught in testing stalls the entire page. The browser sits there waiting for a response before it will paint anything visible, and the user sees a blank screen long enough to leave. That gap between your comfortable local test and what a real visitor experiences is where product launches fall apart. How to find the offending script before launch Reading the waterfall in DevTools Open Chrome DevTools, go to the Performance tab, and record a fresh page load with the cache disabled. What you are looking for in the waterfall is a long horizontal bar sitting right at the top of the timeline, blocking everything beneath it. That is your parser-blocked script. The browser has hit a <script> tag in the <head>, stopped parsing the HTML, and is waiting for the file to download and execute before it continues. The visual render does not start until that bar ends. On a slow connection or a cold CDN, that single block can add two or three seconds before the user sees anything at all. Using PageSpeed Insights PageSpeed Insights gives you a faster route if you are not comfortable reading a waterfall. Run the URL and look for the "Eliminate render-blocking resources" audit under Opportunities. It will list every script and stylesheet holding up the first paint, with an estimated saving next to each one. Cross-reference that list with the render-blocking script impact details to understand which offender is doing the most damage. Check the script's position in the source too. Anything loading synchronously in the <head> without async or defer is almost certainly your problem. WordPress makes this harder than it should be Most plugins do not ask permission before adding scripts to your header. They just do it. The mechanism is wp_enqueue_script(). When a plugin registers a script without the $in_footer argument set to true, or without an async or defer strategy, it lands in <head> and blocks every byte of rendering that follows. To audit what has been enqueued and where, open DevTools, go to the Network tab, filter by JS, and reload. Sort by initiator. Anything WordPress core or a plugin loaded before your first paint is a candidate for review. You can also install Query Monitor, which maps every enqueued script back to the plugin or theme that called it, showing the handle, the source, and the load position in plain English. It takes the guesswork out of tracking down the culprit. Fixing it means touching the registration call. A corrected wp_enqueue_script() with the defer strategy looks like this: wp_enqueue_script( 'my-handle', get_template_directory_uri() . '/js/my-script.js', array(), null, array( 'strategy' => 'defer' ) );. If you cannot edit the plugin directly, use a small snippet in your theme's pre-publish technical checklist or a code plugin to dequeue and re-register the offending script with the correct arguments. That single change can take a render-blocking resource off the critical path entirely. Pre-launch sign-off checklist Test under real conditions, not office ones The check that catches render-blocking scripts before they cost you has to happen on the exact URL under campaign conditions. Load the live landing page on a throttled mobile connection, run a PageSpeed Insights test against that specific page, and look at what the waterfall is doing before the first meaningful paint. Third-party scripts are almost always the culprit. A retargeting pixel loaded synchronously, an A/B testing library injected into the head, a live-chat widget nobody remembered was still active. Any one of them can push your Largest Contentful Paint past the three-second threshold where bounce rates climb sharply. Run this test at least 48 hours before the campaign goes live, so there is time to defer or remove whatever you find. Assign the check to a named person Ownership matters here. If nobody on the team is assigned this check, it does not happen. Name a person, set a date, and treat the PageSpeed result as a hard sign-off criterion alongside copy and pixel verification. Where clients come to Yorkshire Design without that process already in place, a technical SEO audit covers this ground thoroughly before any campaign spend begins. It takes time done properly, but the cost is trivial compared to burning a launch budget on a page that never loads cleanly. ------------------------------------------------------------ # How to Turn One Blog Post Into Six Pieces of Content Using AI Source: https://yorkshiredesign.co.uk/how-to-turn-one-blog-post-into-six-pieces-of-content-using-ai/ Published: 2026-08-02 > Most people write a blog post, publish it, share it once, then start from scratch next time. That's a lot of work abandoned after a single use. A post that took four hours to research and write already contains everything you need for a LinkedIn update, a short-form video script, an email, a FAQ section, and more. AI makes the extraction fast. The question is knowing which parts to pull and what to do with them. Why one post is never just one post Most people finish a blog post, hit publish, share it once, and move on. That's leaving most of the work on the table. Every well-researched post contains far more than its word count suggests. Each section answers a specific question. Each claim could anchor a standalone social update. Each example you used to make a point concrete is a short video script waiting to happen. A 1,500-word article on, say, choosing the right hosting for WordPress might hold six distinct arguments, four reader objections addressed in passing, and two or three comparisons a reader could lift straight into a decision. A repurposing workflow reads the same post the way a butcher reads a carcass, nothing useful gets left behind. The raw material was always there. The question is whether you have a system to extract it, and that's where AI content tools change the maths, because reformatting at scale used to eat time nobody had. The format a piece of content takes shapes who sees it and when. A LinkedIn carousel catches a different reader than the original post ever will. A short script adapted from your introduction reaches someone who will never click through to a blog. Content repurposing with AI doesn't mean spinning the same words into thin copies. It means mapping what you already wrote to the platforms, formats and audiences your original post never reached. Start with the right kind of post The post you choose as your source material matters more than the AI tool you use to repurpose it. A detailed how-to, a thorough myth-busting piece, or a long opinionated take gives you something to actually work with. These formats carry substance underneath the headline, a clear argument, real steps, concrete examples, and often a handful of distinct sub-points that can each stand alone in a different format. A 300-word post that barely fills a screen has none of that. Once you strip out the intro and the closing paragraph, there is nothing left to reshape. AI cannot conjure depth that was never there to begin with, so feeding it a thin post produces thin outputs, just dressed up differently. Before opening any tool, run a quick check on your candidate post. Ask yourself whether it contains at least one strong opinion, a clear process with multiple steps, or a claim that most people get wrong. If you can answer yes to at least two of those, the post has enough structure to branch into other formats. For a more grounded take on what makes a page worth building on in the first place, the thinking around writing content that search engines find genuinely useful applies here too. Long-form posts with real editorial weight are the clear starting point. Short, thin posts are not candidates, no matter how well they performed. The six formats and how AI handles each one LinkedIn, email, and short video Each format needs a different prompt approach, otherwise AI defaults to a generic summary that could have come from anywhere. For a LinkedIn post, ask the AI to extract the single strongest argument from your post and reframe it as a first-person observation with one concrete example pulled from the body copy. For a short-form video script, point it at your intro paragraph and one key section, then ask for a 60-second spoken script that opens with the problem before it names the solution. The email newsletter version works best when you prompt for a 150-word digest written as if you're telling a colleague the one thing they need to take away, not a miniature version of the full article. FAQ blocks, quote cards, and follow-up outlines For an FAQ block built around search intent, ask AI to list the five questions a reader would still have after finishing the post, then answer each in two sentences. Quote cards are simpler. Paste your strongest standalone sentences and ask AI to identify which three land without any surrounding context. The follow-up post outline is where things get genuinely useful. Prompt AI to read the original and flag every question it raises but doesn't fully answer, then turn those gaps into section headings for a second article. That process alone can map out your next month of content from a single well-written post, and the output is specific enough to hand straight to a writer or use as your own working brief. Where AI gets this wrong The register problem The most common failure isn't that AI produces the wrong format, it's that it produces the wrong register. Ask an AI to turn a punchy, opinionated blog post into a LinkedIn update and you'll often get something that reads like a press release, measured, hedged, a little too careful. Ask it to summarise that same post into an email intro and the hook that made the original compelling gets buried under a polite scene-setter. This happens because AI summarises toward the mean. It smooths out the rough edges that made the original distinctive, and in doing so strips out exactly the things that made a reader stop scrolling. For anyone doing content writing for SEO and audience retention, that flattening is a real cost, not a minor quibble. Voice is the first place to fix this. Read the AI draft aloud next to a paragraph from the original post. If it no longer sounds like the same person wrote it, rewrite the opening two sentences from scratch in your own words, then let the rest follow. The specificity problem AI FAQ answers have a habit of going broad. "It depends on your goals" is the kind of answer that helps no one. If the original post named a real number, a real tool, or a real scenario, check that the repurposed version kept it. If the detail got dropped, put it back. That one concrete thing is usually the reason the answer is useful at all. How to build a repeatable system around this Done once, repurposing is interesting. Built into a routine, it starts to pay back properly. The sequence that actually sticks runs in the same order every time. Write the long-form post first, because everything else comes from it. Then run your AI extraction prompts against the finished draft, pulling out the LinkedIn post, the email intro, the short-form script, the FAQ snippet, and whatever else fits your channels. Once all six outputs exist as rough cuts, do a single editing pass across all of them in one sitting rather than polishing each piece separately as you go. That one pass keeps the voice consistent and stops you spending forty minutes on a tweet. Finally, slot everything into a two-week schedule so the pieces land with breathing room between them. The same idea reaches the same reader through different surfaces, and each touchpoint reinforces the one before it. If you write SEO-structured long-form content as your source material, the signal compounds across channels rather than sitting in one place going nowhere. The real return is not the six pieces themselves. It is that the original post stops being a one-day spike in traffic and starts doing continuous work across multiple platforms for the next fortnight, with no extra research involved. Keeping the outputs connected Why coherence matters more than volume Six pieces of content that share no common thread do not build anything. They scatter. The formats only compound into something useful when each one carries a consistent core claim, uses recognisably similar phrasing at the key moments, and points the reader back toward the original post. Think of the LinkedIn carousel that summarises your article's main argument, then drops a link to the full piece. Or the email that opens with the same central question the post answers, so a subscriber who clicks through already knows what they are getting. That consistency is what signals topical depth to search engines rather than just volume. Good content writing for SEO has always been about coherence across a topic, not isolated pages doing their own thing. Internal links and the network effect Internal links matter here more than most people allow for. When your short-form posts, threads and video scripts reference each other, you are building a network where authority flows inward rather than draining away. A reader who finds the newsletter version and follows a link to the original article is now two interactions deep before they have even seen your service pages. Get that connective tissue right and the six formats work together. Miss it and you are just producing volume. ------------------------------------------------------------ # Google Search Console Setup: What to Do After You Verify Your Site Source: https://yorkshiredesign.co.uk/google-search-console-setup-what-to-do-after-you-verify-your-site/ Published: 2026-08-02 > Verifying your site is the easy part. Most people tick that box and then open Search Console once a month, glance at a few numbers, and close the tab. That's most of the value left on the table. The real setup happens after verification, and it takes maybe an hour done properly. Get those steps right and you'll have a far cleaner picture of how Google actually sees your site. Submit Your Sitemap First Verification proves you own the site. It does not tell Google what to crawl. That is what a sitemap is for. An XML sitemap is a plain list of URLs you want Google to know about. Without one, Googlebot finds pages by following links, which sounds fine until you have product pages with no inbound links, blog posts buried three clicks deep, or new content that went live last week. The crawler may find those pages eventually, but that "eventually" can mean weeks. Submit a sitemap and you hand Google a direct inventory, cutting out the guesswork considerably. The submission itself takes thirty seconds inside Search Console under Indexing > Sitemaps. The bit most people skip is checking whether the sitemap was actually processed. Accepted and processed are not the same thing. A sitemap can sit in Search Console with a green tick and still return zero discovered URLs if the file is malformed, points to a staging URL, or is blocked in your robots.txt. Check the "Discovered URLs" count after a day or two. If it reads zero, or far fewer URLs than you expect, fix the sitemap before you do anything else. Most WordPress installs generate a sitemap automatically through Yoast, Rank Math, or the built-in core sitemap at /wp-sitemap.xml. The common failure is submitting the URL and never returning to it. Revisit the Sitemaps report a week after submission and confirm the numbers look right. Set Your Preferred Domain and URL Prefix Most sites exist under two addresses at once. Your homepage loads at both https://www.yourdomain.co.uk and https://yourdomain.co.uk, and to Search Console they are two completely separate properties. Verify only one and Google encounters the other unrecorded. Your click data, impressions, and index coverage end up split across two buckets, and you are looking at half the picture every time you open your reports. The fix is straightforward. Verify both versions, then tell Google which one is canonical by adding both as URL-prefix properties and setting a preferred domain inside the Domain property settings if you are using that method. Picking the right version matters less than picking consistently. Whichever address your server actually serves to visitors is the one to nominate as primary. If your DNS and server configuration already redirects the non-www version to www, make the www property your preferred domain and point your sitemap at that same address. It is a five-minute job that saves a lot of head-scratching later when your numbers do not add up. Check the Coverage Report Before Anything Else The Page Indexing report (Google renamed it from Coverage a while back, though you will still hear both terms) is the first place to go after verification. Pull it up and look at the Excluded tab straight away. What the excluded tab actually tells you A handful of excluded URLs is normal. A few hundred is a problem you need to understand. The status that trips people up most often on WordPress sites is "Crawled, currently not indexed," which means Google visited the page, read it, and decided not to include it. That usually points to thin content. The usual suspects are tag archive pages, date archives, or author pages with a single post on them. Noindex tags left over from a staging environment are one of the more painful causes. A site gets built on a dev server with search engines blocked, goes live, and nobody removes that setting. The entire domain can sit delisted for weeks before anyone notices. How to work through the excluded URLs If you have already worked through the initial verification steps in a practical setup guide, you will have a clean baseline to compare against. Cross-reference the excluded URLs with your actual site structure. Are they pages you want indexed? If not, confirm they carry a deliberate noindex and move on. If they should be indexed, dig into the page itself. A robots.txt block, a thin word count, or near-duplicate content will usually explain it faster than any tool will. Reading the Performance Report Without Getting Lost The Performance report is where most people either get useful information or spend twenty minutes staring at numbers that mean nothing to them. The four metrics at the top, Clicks, Impressions, CTR, and Average Position, are all connected but tell different stories. What the four metrics mean together Impressions count how often your pages appeared in search results. Clicks count how many people followed through. CTR is the ratio between the two, and Position tells you where you typically ranked. A page sitting at position 4 with 2,000 impressions but only 40 clicks has a CTR of 2%. That suggests the title or description is not compelling enough to earn the tap, even though the ranking itself is reasonable. Where the filtering makes it useful Filtering by query and page is where the report earns its keep. Switch to the Pages tab and sort by Impressions to find your highest-visibility content. Then click a specific page and toggle to Queries to see exactly which search terms are pulling people in. That combination often surfaces something surprising, a page you wrote about one topic drawing traffic for a slightly different one. That is a prompt to either adjust the content or build a new page that serves that query properly. Do not just observe. Take the queries with solid impressions but poor CTR and test a rewritten title tag. Check whether the Coverage and Indexing reports confirm those pages are being indexed cleanly. The data only moves if you act on it. Connect to Google Analytics and Google Ads Most sites run Search Console, Analytics, and Ads as three separate silos. That is a waste, because the moment you link them, each one fills a gap the others leave. Linking Search Console to Analytics The connection between Search Console and Google Analytics is the more useful of the two. Once linked, you get organic search data sitting inside Analytics alongside your session data, conversions, and goal completions, so you can see which queries drove a user who then did something useful on the site. Without it, Analytics shows you organic traffic as a lump. With it, you can trace a specific keyword through to a specific outcome. To link them, open Search Console, go to Settings, find the Associations panel, and add your Analytics property. You will need admin rights on both accounts. The process takes about two minutes and the data starts appearing in the Analytics Search Console reports the same day. If you are already tracking organic performance metrics inside Search Console, seeing those sit alongside your paid spend in one place makes the comparison far sharper. Linking Google Ads Linking Google Ads follows the same logic. You can see exactly where paid clicks begin and organic impressions leave off, which stops you bidding on terms you already rank strongly for and wasting budget in the process. Which Alerts to Turn On Search Console sends email notifications for several different things, and the default settings are not always what you would expect. The alerts to keep are the ones that flag problems you cannot easily spot yourself. Manual actions are the clearest example. If Google's review team penalises your site, you will not see it anywhere in your day-to-day traffic data until the damage is already done. Security issues, such as detected malware or hacked content, fall into the same category. Coverage drop notifications, which fire when a meaningful chunk of your indexed pages suddenly disappears from search results, belong on that list too. Those three cover the scenarios where an email at the right moment changes what you do next. If you are also setting up your property settings and ownership verification around the same time, check the notification preferences immediately after, because they sometimes reset during that process. Performance summary emails are a different matter. They land weekly or monthly, repeat information you can see in the dashboard whenever you choose to look, and rarely tell you anything you could not have found yourself. Most people stop reading them after the first few weeks. Keep manual actions, security issues, and coverage alerts switched on. Turn off everything else. You get the signal when it matters, without the noise that trains you to dismiss every email Search Console sends. ------------------------------------------------------------ # WebP vs JPEG in WordPress: Which Format Actually Loads Faster Source: https://yorkshiredesign.co.uk/webp-vs-jpeg-in-wordpress-which-format-actually-loads-faster/ Published: 2026-08-02 > Swap every JPEG to WebP and your site loads faster. That's the received wisdom, and it's mostly true, but the detail matters more than the headline. File size alone doesn't tell you what a browser actually does with the image, and the wrong conversion settings can shave 10kb off a file while quietly introducing a quality problem that puts visitors off. Here's how the two formats actually compare inside a WordPress install, and where each one earns its place. What the Size Difference Actually Looks Like The 25-35% figure people quote for WebP is real, but without a concrete example it stays abstract. Take a typical product photograph saved as a JPEG at quality 80. At around 1200 pixels wide, that file commonly lands somewhere between 180 KB and 250 KB depending on the image content. Export the same photograph as WebP at an equivalent perceived quality and you're usually looking at 120 KB to 170 KB. On one image, that gap is modest. Across a page that loads eight or ten product photos simultaneously, you've cut anything from 600 KB to over a megabyte of transfer before a visitor has scrolled past the fold. On a slower mobile connection, that difference is felt, not just measured. Google's own Lighthouse tool flags uncompressed or format-inefficient images as one of the highest-impact fixes precisely because the cumulative weight adds up so quickly across a typical page load. WebP earns its keep most with photographs and images that contain a lot of fine detail and gradient tones. Flat graphics with hard edges and solid blocks of colour see a smaller gap, sometimes barely noticeable. So the real-world saving on any given page depends on what images are on it, which is why the optimisation settings that matter most are always image-type-specific rather than a single blanket rule. How WordPress Handles Format Conversion What core does natively Since WordPress 5.8, the platform has included native WebP support, meaning it accepts WebP uploads and generates WebP thumbnail sizes the same way it handles JPEG or PNG. What it does not do is automatically convert your existing JPEG library into WebP files on upload. If you drag a JPEG into the media library, it stays a JPEG. WordPress core registers the format and processes it; the conversion step is entirely your responsibility. This catches a lot of people out, particularly those who assume upgrading WordPress itself is enough to start serving faster images. Browser compatibility is handled at the server level, not by WordPress core. Apache or Nginx can be configured to serve a WebP file when a matching one exists and the browser sends an Accept, image/webp header, but WordPress itself has no built-in mechanism to detect browser support and swap formats on the fly. What plugins add Plugins like Imagify, ShortPixel and Smush fill the gap by converting images to WebP at the point of upload, storing both the original and the converted file, then using either a rewrite rule or a JavaScript-based swap to serve the right format per browser. For anyone working through WordPress image optimisation settings, the plugin layer is where most of the real format-switching control sits. Browser Support and Why It Stopped Being a Problem For years the standard objection to WebP was Safari. Apple was late to support it, which meant a chunk of real traffic, particularly on iPhones and Macs, would hit a broken image if you served WebP without a fallback. That concern made sense at the time. Safari added full WebP support back in version 14, and given how aggressively Apple pushes iOS updates, the vast majority of Safari users have been on a compatible version for quite some time now. Chrome, Firefox and Edge supported WebP much earlier. Across the browsers your visitors are using, WebP coverage is about as close to universal as web standards get. The old conditional logic, serving JPEG to Safari and WebP to everyone else, is mostly dead weight now. There is one situation where a JPEG fallback still has a purpose. If your audience skews toward older embedded browsers, certain smart-TV web views, or legacy enterprise environments where software updates lag by years, a small percentage of users may still miss WebP. Plugins that handle WordPress image optimisation settings often generate both formats automatically and serve the right one via the srcset attribute or a <picture> element, so you get WebP for everyone who can use it and JPEG for the rare edge case, with no manual work involved. For most sites, that automated approach is the right call rather than ditching WebP to play it safe. Where JPEG Still Wins Photography portfolios with strict colour-fidelity requirements are one area where JPEG keeps a genuine foothold. High-end retouching studios and commercial photographers often supply finished assets as sRGB JPEGs, colour-profiled and signed off by the client. Converting those to WebP inside WordPress can shift saturation subtly, particularly on wide-gamut displays, and that matters when a client is comparing a screen proof to a physical print. The same logic applies to editorial workflows where the client supplies and reuses their own image library. If a magazine publisher drops the same JPEG into WordPress, their CMS, and their print pipeline, introducing a WebP conversion mid-flow creates version-control headaches that no page speed gain justifies. Email is the other clear case. Images linked from a WordPress media library into HTML email campaigns need to be JPEG or PNG. WebP support in email clients is patchy at best, and a broken image in a newsletter is a worse outcome than a slightly heavier file. Third-party gallery embeds follow the same pattern. If a platform like Flickr or a licensed stock provider serves the image from its own CDN, the image optimisation settings that actually matter are on their infrastructure, not yours. You have no control over format, and trying to proxy or re-serve those assets just to get WebP introduces more complexity than it removes. The Conversion Settings That Actually Matter Most people batch-convert their media library, see smaller file sizes, and assume the job is done. The settings behind that conversion decide whether you've improved anything at all. Quality, encoding mode, and chroma The quality slider is the first place things go wrong. WebP at quality 80 is not the same as JPEG at quality 80. WebP's compression is more efficient, so you can often drop to 75 or even 70 and see no perceptible loss on standard photography. Go below 65, though, and you start to lose fine edge detail, particularly in images with text, thin lines, or fabric texture. The format also gives you a choice between lossy and lossless encoding. Lossy handles photographs well. Lossless is intended for graphics with flat colour, logos, and illustrations where pixel-perfect accuracy matters. Batch-converting a whole library to lossless WebP will produce files larger than the JPEGs you started with, which defeats the purpose entirely. Chroma subsampling is a separate consideration. Most lossy WebP encoding reduces colour information independently of luminance, which is fine for most web images but can affect product shots where accurate colour is the whole point. If your client sells paint or fabric, test a handful of images manually before you commit to bulk settings. Stripping metadata Camera EXIF data, colour profiles, and GPS coordinates can add anywhere from a few kilobytes to over 30 KB per image. Plugins that handle WordPress image optimisation settings will usually offer a strip-metadata toggle. Turn it on. The colour profile is the one exception, preserve it if colour accuracy is critical, but for general web use, stripped files load faster and hand nothing personal to anyone scraping your site. Choosing the Right Approach for Your WordPress Site The decision comes down to where in your stack you want the conversion to happen. Converting on upload, using a plugin that rewrites the file as WebP the moment it lands in your media library, is the simplest path for most sites. It handles new images automatically, requires no server configuration, and works on shared hosting where you have little control over the environment. The catch is your existing JPEG library sits untouched until you run a bulk reprocess, which on a site with several hundred images can take a while and occasionally stalls partway through. Server-level conversion via an image CDN or a module like on-the-fly WebP delivery configured through your image optimisation settings is more reliable at scale, because it serves the right format per browser without touching the originals at all. For an existing JPEG library, the pragmatic move is to bulk-reprocess through your chosen plugin, then spot-check a handful of the heaviest images in PageSpeed Insights rather than just comparing raw file sizes in the media library. Raw file size is not the metric that matters most. What you are watching is Largest Contentful Paint, because a hero image that shaves 40 KB off its file size but still loads late due to poor prioritisation will not move your LCP score at all. Fix the format, then check the timing. ------------------------------------------------------------ # WordPress Child Themes Explained: When You Need One and When You Don’t Source: https://yorkshiredesign.co.uk/wordpress-child-themes-explained-when-you-need-one-and-when-you-dont/ Published: 2026-08-02 > Most people encounter the idea of a child theme at the worst possible moment , right after a theme update wiped out every custom tweak they'd spent hours making. A child theme stops that from happening. It's a small layer that sits on top of your main theme and holds all your changes safely, so updates to the parent theme don't erase them. Whether you actually need one depends on how you're building your site, and that's what this guide works through. What a Child Theme Is A WordPress child theme is a separate layer that sits on top of an existing theme and holds only your changes, nothing else. Think of it like a car engine straight from the factory. The parent theme is that engine, thousands of hours of engineering, tested and tuned, doing the real work under the bonnet. When you want to change the colour of a component or swap out a bracket, you don't pull the engine apart. You work on a copy of the part, keep the original untouched, and fit your modified version on top. That's exactly what a child theme does. It inherits every style, template and function from the parent automatically, so your site still looks and behaves as expected. The only thing stored in the child theme is what you personally changed, which might be a handful of lines in a stylesheet or a single modified template file. The practical upside is straightforward. When the parent theme receives a security update or a bug fix, you apply it without wiping out your own work. Your modifications live separately and survive the update intact. The Problem It Solves Most people who edit a parent theme directly don't realise the risk until the damage is done. You open the theme editor, tweak a font size, adjust some spacing, maybe drop a line of custom CSS into the stylesheet. It looks exactly right. Then a few weeks later the theme author pushes an update, you click that familiar blue button, and every single change you made disappears. The update overwrites the theme files completely, which is precisely what it is supposed to do. The problem isn't the update mechanism. The problem is that your edits were sitting in files that were never meant to be touched. A child theme separates your customisations from the parent's core files. WordPress loads the child theme first, falls back to the parent for anything you haven't overridden, and your changes survive every update cleanly. If you're curious how the structure beneath a theme works, understand it before you start customising anything. The fix is straightforward once you know the cause. The painful part is usually finding out the cause after the fact. What Lives Inside a Child Theme The style.css file A minimal child theme is two files. The first is style.css, which does less than its name suggests. Its real job is the header comment block at the top, where WordPress reads the theme's name, version, and most importantly the Template: line that points back to the parent. Without that single line, WordPress has no idea the two themes are connected. You can add actual CSS rules beneath it, and many developers do, but the file earns its place just by declaring the relationship. The functions.php file The second file is functions.php. This is where the child theme loads the parent's stylesheet and where you add any PHP customisations, hooks, or extra functionality. Changes here stay completely separate from the parent's own functions.php, so a parent theme update cannot overwrite them. That separation is the whole point. The parent theme carries the full design system, the template files, and the layout logic. The child theme holds only what you changed. Picture a site where you need custom fonts and a tweaked header colour. Rather than editing the parent directly, those two rules sit in the child's style.css and survive every future update untouched. If you want to understand how theme architecture feeds into broader performance and structure decisions, that connection runs deeper than most people assume. When You Need One The clearest signal is whether you're touching the theme's files directly. If you open functions.php to add a custom function, edit style.css to change a font size, or drop a PHP snippet into a template file, you're working inside code that a theme update will overwrite completely. One click on "Update" and your changes are gone, with no warning and no recovery. The same applies to custom CSS that goes beyond what the WordPress customiser holds safely. A few colour tweaks in the customiser are fine. But if you're writing rules to restructure layouts, override third-party plugin styles, or fix display issues on specific page templates, those belong in a child theme's stylesheet where they'll persist. PHP hooks, custom page templates, and any caching configuration tied to theme behaviour all follow the same rule. If it lives in a theme file and you wrote it yourself, protect it with a child theme. Set it up before you start, not after you've already lost a week of work. When You Can Skip It Not every WordPress site needs a child theme. For a lot of builds, it's an unnecessary layer of complexity. If your site is built on a block theme using Full Site Editing, the customisation you make lives inside the database, not in theme files. The same goes for page builders like Elementor or Bricks, where your layouts and styles are stored as post data rather than in PHP templates. Even a classic theme where everything is managed through the WordPress Customiser or a dedicated plugin puts your changes somewhere WordPress itself controls. In none of those cases does a core theme update have any path to overwrite your work, because your work was never sitting in the theme folder to begin with. You can find a similar principle when understanding how WordPress caches and stores data at different layers. What matters is where your changes actually live, not what they look like on the surface. Skipping a child theme in these setups isn't cutting corners. It's just reading the situation correctly. Block Themes and Full Site Editing Block themes handle customisation in a fundamentally different way to classic themes, and that changes the child theme calculation considerably. With a classic theme, editing a template file means touching PHP inside the theme folder, so a child theme is the obvious protective layer. Block themes built for Full Site Editing store their templates and style variations in the database instead, pulled out through the Site Editor rather than through raw files. That means when you make changes in the Site Editor, those changes live in your database and survive a theme update automatically, because the update only touches the files, not your saved database records. A child theme adds no protection there. There's nothing in the files to overwrite. For most block theme users, a child theme is unnecessary. Your typography tweaks, colour choices and custom templates are database entries, not files. Where it does still apply is if you're writing custom PHP, adding template parts as actual files, or modifying the theme at a code level rather than through the editor. At that point, the old rules come back into play. Setting One Up The manual route Create a folder inside wp-content/themes/, name it something like twentytwentyfour-child, then add a style.css with a header block that names the parent theme and a functions.php that enqueues the parent stylesheet. That's it. WordPress picks it up automatically, and you activate it from the Themes screen like any other theme. No build tools, no terminal commands, no engineering degree required. The plugin route If that still feels fiddly, a plugin like Child Theme Configurator does the same job through a form in your dashboard. Either way, setting up a child theme isn't the hard part of a WordPress project. The hard part is knowing when to bother, which is what the rest of this article covers. Where it does matter is in how WordPress handles assets and caching once your custom stylesheet is in place, so understanding that layer saves you chasing phantom style issues after a parent theme update. ------------------------------------------------------------ # Pretty But Broken: When a Beautiful Website Kills Sales Source: https://yorkshiredesign.co.uk/pretty-but-broken-when-a-beautiful-website-kills-sales/ Published: 2026-08-02 > A website that turns heads does not automatically turn visitors into customers. Plenty of beautifully built sites sit there looking polished while quietly haemorrhaging enquiries. The visual work is real, the photography is sharp, the layout is considered. But something underneath is fighting against every sale. Knowing where that gap opens up, and how to close it, is the difference between a site that wins awards and one that actually pays for itself. Speed Is the First Thing a Pretty Site Kills A slow page doesn't frustrate users. It erases them. They leave before they've read a single word. The usual suspects are easy to spot once you've seen enough of them. A full-width video background that weighs 18MB before a single font has loaded. Three custom typefaces stacked into the design because the branding deck called for it. A hero image exported at print resolution and never touched again. Each of these feels like a reasonable creative choice in isolation, but together they routinely push load time past the four-second mark, and often past eight. Google's own research has shown for years that the probability of a user bouncing rises sharply with every additional second of load time. By the time the page is fully rendered, the person who was almost a customer has already hit the back button and moved on to a competitor whose site came up faster. This is what Core Web Vitals measure. Largest Contentful Paint tracks how long it takes for the biggest visible element to appear, and a hero video or an uncompressed background image will blow that threshold without effort. Cumulative Layout Shift catches the page jumping around as custom fonts swap in. First Input Delay records how long before the page responds to a tap or a click. None of these metrics care how beautiful the design is. They measure the experience the visitor had, and a site heavy with visual ambition tends to fail all three. Navigation That Looks Minimal but Works Badly Hamburger menus on desktop became fashionable because they look clean. The problem is that real users, not designers reviewing a prototype, open those menus far less often than a clearly visible navigation bar. When someone lands on a homepage looking for a specific service, they scan the top of the page first. If they see a stacked icon where links should be, a meaningful percentage of them don't click it. They assume the site doesn't have what they need, and they leave. The design team looked at the same menu in a review session and found it elegant. The visitor on a Tuesday afternoon found it confusing. That gap between the two reactions is where conversions go missing. Hover-only dropdowns and label-free icon navigation create the same problem from a different angle. A basket icon, a magnifying glass, a silhouette of a person -- these make sense to someone who built the site. For a first-time visitor, especially on a business that isn't Amazon or Google, they're guesses. If a user can't reach the page they need within two clicks, the considered colour palette and the careful typeface choice count for nothing. Navigation is functional infrastructure. It needs to work before it gets to look good. What the Call-to-Action Is Actually Doing The contrast problem A ghost button, the kind outlined in a thin border with transparent fill, can look elegant against a full-bleed hero image. Designers love them. Visitors miss them. The eye needs contrast to register something as clickable, and a pale outline sitting over a pale background does not provide it. Copy does more work than shape The same problem appears when a CTA is written as though it were a design label rather than an instruction. "Explore" or "Discover more" tells nobody what happens next. "Get a free quote" tells them exactly what they are pressing and what they receive. That difference in copy is not subtle. It is the difference between a button people click and one they scroll past. The clearest way to see this is to look at sites where the primary action has been subordinated to the aesthetic. A dark-mode portfolio with charcoal buttons on a near-black background, or a lifestyle brand where the CTA text is set in the same thin typeface as the surrounding body copy -- both face the same issue. The call-to-action has been styled into the furniture. If you are finding that visitors land, browse, and leave without enquiring, it is often the visual hierarchy that is letting them slip away, not the product itself. A plainer button in a colour that stands out will almost always outperform the one that photographs well. Mobile: The Gap Between Design Mockup and Real Device Most design tools show you a pixel-perfect preview at a width your customers rarely use. A 1440px canvas looks composed, balanced, and professional. Then you load the same page on a mid-range Android, the kind of phone a significant portion of your visitors carry, and things start to shift. Text overlaps a button. A product image refuses to reflow and pushes the layout sideways. The checkout form has fields so tightly packed that tapping the right one takes two or three attempts. None of this shows up in a Figma mockup or a browser preview on a widescreen monitor, because those environments are forgiving in ways that real devices are not. A phone running Chrome on Android with a slightly older GPU and a modest screen density will expose every assumption the design made about spacing, font scaling, and touch target size. Tap targets are a common casualty Google's own guidance recommends a minimum of 48 by 48 pixels for interactive elements. When a designer works at desktop scale, those buttons can shrink well below that threshold on smaller screens without anyone catching it during sign-off. If your site looks great but stops people from completing a purchase, testing on an actual mid-range device, not a browser's responsive mode, is where the real picture emerges. Forms, Checkout and the Points Where People Give Up Most design reviews never reach the checkout. That's the problem. The friction that kills conversions isn't usually a bad colour choice or an awkward layout. It's a multi-step form that wipes every field when someone mis-types their postcode. It's a required phone number field on a contact form that has no conceivable reason to need a phone number. It's the checkout that stops dead and demands an account before it will take a payment. None of these show up in a design walkthrough because they only reveal themselves when someone is trying to complete a task under slight pressure, on a phone, with one hand. The most common pattern is a form reset on validation error. The user fills in six fields, gets one wrong, and starts from scratch. Most people don't restart. They leave. A close second is the forced account creation gate, which research from the Baymard Institute consistently identifies as one of the leading reasons for checkout abandonment. The fix is usually a guest checkout option that already exists in the platform and just needs switching on. If a site isn't converting the way the traffic suggests it should, the form flow is the first place to look. Work through each form as a first-time visitor, on a mobile, and deliberately trigger a validation error. What you find there is rarely glamorous, but it's almost always the answer. How to Tell Whether Your Site Has This Problem Start with the traffic-to-enquiry gap If your traffic numbers look healthy but enquiries stay flat, that gap is telling you something. A high bounce rate paired with decent visitor counts is the clearest sign that people are arriving, taking one look, and leaving without acting. The page attracted them; something on it pushed them away. Before you touch a single font or colour, open the question of why visitors aren't converting and read what your analytics say about exit points, not just overall traffic volume. Heatmap and scroll data sharpens that picture fast. If a tool like Hotjar shows most visitors dropping off two-thirds down the page, anything below that line is invisible to real users, regardless of how much thought went into it. Two tests that cost nothing Run the site through PageSpeed Insights and pick up your phone. A five-minute walkthrough on an actual handset, thumbing through the page as a first-time visitor would, surfaces layout breaks, undersized tap targets, and slow load sequences that no desktop review ever catches. Both tests take less time than a full analytics deep-dive, and between them they tend to flag the problems costing you enquiries. Numbers confirm what you already sense. Trust the gut feeling that something is off, then find the evidence to pin it down. ------------------------------------------------------------ # Local SEO for Service Businesses: What Google Actually Looks For Source: https://yorkshiredesign.co.uk/local-seo-for-service-businesses-what-google-actually-looks-for/ Published: 2026-08-01 > Ask ten people what makes a local service business rank on Google and you'll get ten different answers, most of them wrong. The truth is less mysterious than the advice suggests. Google is trying to answer one question on a searcher's behalf, which business nearby can actually do this job? Everything Google checks is pointed at that single question. Get the fundamentals right and the ranking tends to follow, though it does take time to build. What 'local' means to Google Google doesn't treat every search the same way. The moment it detects that someone needs something nearby, it switches into a completely different mode. Search "emergency plumber" and Google assumes you want someone within driving distance right now, not a directory of national companies. Search "how to fix a leaking radiator" and it serves guides, videos, and DIY forums because nothing in that phrase signals a nearby need. The distinction matters because these two queries can contain almost identical words yet produce entirely different results pages. One triggers the local pack, the map, and proximity-ranked listings. The other returns informational content from anywhere in the world. Google calls this reading "local intent", and it makes the decision based on a combination of your device location, the phrasing of the query, and patterns in what people who typed those same words actually clicked on before. For service businesses, this is the mechanism that shapes whether you appear at all. The whole of local SEO flows from that single classification decision Google makes in the first fraction of a second. Your Google Business Profile and why it carries so much weight Your Google Business Profile is the listing that appears when someone searches for your business by name, or when Google decides your business fits what someone nearby is looking for. It shows up in the map pack, the knowledge panel on the right-hand side of search results, and sometimes in featured snippets. Getting it right matters more than most people expect. Google reads specific fields to decide whether your business is relevant and trustworthy enough to show. The category you choose is probably the single most influential field. It tells Google what type of business you are before anything else. After that come your service areas, your opening hours, and the services you list individually, all of which feed into how Google matches you to searches. A plumber who sets "Plumber" as their primary category, lists the right towns under service areas, and keeps opening hours accurate will consistently outrank a competitor with a vague category and a half-finished profile. The fields most businesses leave blank or guessed are service areas and secondary categories. Both are free to fill in and both carry real weight in how local rankings shift once the groundwork is done properly. Opening hours matter too, and not just for customers. Google treats mismatched or missing hours as a trust signal that something is unverified. How Your Website Supports Local Relevance NAP consistency Your Business Profile and your website aren't separate tools pulling in different directions. Google cross-references them. If your profile lists a phone number that doesn't match what's on your contact page, or names a service area that your site never mentions, that mismatch costs you. NAP consistency, meaning your name, address, and phone number matching exactly across both, is one of the most overlooked details in local SEO. It sounds minor, but Google treats matching signals as confirmation that a business is what it claims to be. A contact page with just an address and a phone number leaves a lot of ranking signal sitting idle. Dedicated service and location pages The sites that tend to perform well locally have dedicated service pages, each one written to a specific trade or location rather than a catch-all overview. A plumber covering three towns gets more traction from a page built around each of those towns than from a single "we cover the whole region" paragraph. Those pages give Google something concrete to match against a searcher's query. If you want to understand what Google is reading across your site, the overview in what Google looks at when ranking pages is a useful reference point. Reviews and What Google Does With Them A perfect five-star average sounds impressive, but Google pays much more attention to the shape of a review profile than the score alone. A plumber with forty reviews spread across the last eighteen months tells Google something useful. Real customers keep hiring them, and people keep bothering to write about it afterwards. A competitor sitting on a single glowing review from three years ago offers no such signal. Recency matters because service quality changes. Volume matters because a handful of reviews could be friends and family. Google weighs both, alongside how often the business actually responds, because an owner who replies to feedback is demonstrably engaged with their reputation. Response behaviour is the part most businesses ignore. Replying to a review, good or bad, shows Google the listing is actively managed. That alone separates you from the dozens of local competitors who claimed their profile and then forgot about it. If you want to understand what else shapes local visibility beyond reviews, the fundamentals stack up quickly once you know where to look. Local Citations and the Consistency Problem A citation is any mention of your business name, address and phone number on another website. Google uses them to verify that your business is real and where you say it is. The problem most businesses run into is tangled history. Your name might be "Parker Plumbing Ltd" on Google Business Profile but "Parker Plumbing" on Yell.com and "Parker Plumbing Services" on a local directory from 2011. Your phone number might have changed twice since then, and an old address could still be sitting on a handful of sites you forgot you ever signed up to. Google reads all of these signals together, and when they don't line up, it loses confidence in your listing. That eroded confidence tends to push you down in the local results without any obvious warning. The same problem affects the broader picture too, since several of the signals Google weighs come back to how consistently your information appears across the web. The audit itself is straightforward. Search for your business name alongside your town and check what comes up. Note every directory listing and compare the name, address and phone number against your Google Business Profile. Fix the mismatches directly on each platform, prioritising the high-authority directories first. The technical side that decides close races Page speed and Core Web Vitals When two businesses look equally trustworthy on paper, the same number of reviews, similar content, comparable links, Google starts looking underneath the bonnet. Page speed is one of the first things it notices. A slow site on mobile signals a poor experience, and Google has been open about the fact that Core Web Vitals feed directly into how pages are assessed. These are real measurements, how fast the largest visible element loads, how quickly the page responds to a tap, how much the layout shifts while loading. None of it is invisible to Google, and none of it is invisible to the person who just waited four seconds for your contact number to appear. Hosting matters here more than most people realise. Shared hosting packed with unnecessary add-ons tends to slow response times before your page has even started loading, and that delay compounds every other speed problem on the site. Structured data Marking up your business type, service area and opening hours in schema gives Google something concrete to read rather than something to guess at. It is not a magic ranking switch, but it removes ambiguity, and removing ambiguity tends to help. What to focus on first Start with your Google Business Profile and get it completely filled in. Accurate categories, a proper business description, opening hours, photos that show the work rather than a stock image. A lot of businesses rush past this and then wonder why they're not showing up in the map pack. After that, make sure your name, address, and phone number appear consistently across every directory and citation that mentions you. Even an abbreviated street name in one place or an old phone number somewhere else gives Google a reason to feel less certain about you. Once those foundations are solid, reviews become your next priority. Not a one-off burst, but a steady trickle of genuine feedback over time. From there, your attention shifts to the content on your website. Pages that name the services you offer and the areas you cover give Google something to work with. If your business sells a service rather than a product, the signals that matter are slightly different to what you'd expect from a product-focused SEO approach. None of this compounds overnight. Local SEO builds the way trust builds, slowly and then noticeably, as each signal reinforces the last. ------------------------------------------------------------ # What n8n Actually Does and Whether It Beats Zapier Source: https://yorkshiredesign.co.uk/what-n8n-actually-does-and-whether-it-beats-zapier/ Published: 2026-08-01 > Most people assume Zapier is the only serious option for automating business workflows. That assumption is understandable , Zapier has been around long enough to feel like the default. But n8n has been quietly eating into that space, and for businesses that want real control over their automations without paying per-task fees that compound fast, it tells a different story. This piece breaks down what n8n actually does, where Zapier still wins, and how to work out which one fits your situation. The Myth That Automation Tools Are All the Same Calling n8n and Zapier the same tool is like calling a Honda Civic and a flatbed truck the same vehicle because both have four wheels and an engine. The comparison breaks down the moment you look under the bonnet. Zapier is a managed cloud service. You pay per task, per month, and every workflow runs on Zapier's own servers. That model suits someone who needs a handful of straightforward connections, a contact form that drops leads into a spreadsheet, or a new Stripe payment that fires a Slack notification. It is quick to set up, the interface is approachable, and for low-volume work the cost stays manageable. But once your automations get complex or your task count climbs into the tens of thousands each month, the pricing compounds fast. You are also handing your data and your workflow logic to a third-party platform you have no control over. n8n takes a different approach at the architecture level. Self-host it on your own server and your data stays on your infrastructure, with a fixed monthly cost regardless of how many automations run. It also ships with a code node that lets you drop raw JavaScript or Python directly into a workflow, something Zapier does not offer. That single capability opens the door to complex, conditional logic that point-and-click tools cannot handle. The two products serve different problems, and picking the wrong one is an expensive mistake to unpick later. What n8n Is Built to Do n8n is a workflow automation tool built around a visual node editor. Each node represents a single action, fetch data from a source, transform it, push it somewhere else. You wire nodes together to describe exactly what should happen and when. That might sound similar to Zapier on the surface, but the architecture underneath is quite different. n8n is open-source and designed to run on your own server, which means every piece of data your workflows handle stays inside your infrastructure. No third-party platform sees your customer records, your invoice data, or anything else passing through the pipeline. For businesses in regulated industries, or anyone who has spent time thinking about where their data ends up, that distinction matters considerably. The self-hosted model also changes the cost structure entirely. Pay for server capacity once, and whether your automations run a hundred times a month or a hundred thousand, the bill does not change because of volume. The other thing n8n gives you is real control over the logic. You can write custom JavaScript directly inside a node when the built-in options do not quite fit, which is the kind of flexibility that connecting automation to a WordPress site often demands in practice. It is not the fastest tool to pick up. The trade-off for that flexibility is a steeper initial setup compared to a point-and-click SaaS tool. That is worth knowing going in. Where Zapier Still Has the Edge If you need something connected and running by this afternoon, Zapier is hard to argue with. The interface is clean, the setup logic is close to plain English, and the library of pre-built integrations runs to thousands of apps. Pick a trigger, pick an action, test it, switch it on. For someone who just wants a new Typeform submission to land in a Google Sheet and fire a Slack message, that process takes about ten minutes. There is no server to think about, no Docker container to spin up, no YAML file to stare at. Zapier handles all of that invisibly, and for a huge slice of businesses, that is the right trade. The hosting overhead people underestimate That zero-hosting requirement matters more than people give it credit for. n8n's self-hosted option is excellent, but someone still has to set it up, keep it updated, and make sure it stays online. That overhead is not nothing, and if your team has nobody comfortable doing that, it changes the calculation. Ecosystem breadth Zapier also wins on raw integration coverage. If you are trying to connect a niche CRM or a less common payment platform, the chances of finding a ready-made Zapier integration are high. With n8n you may need to fall back on a generic HTTP request node and do some reading. For businesses where saving time is the immediate priority rather than gaining fine-grained control, Zapier's convenience is a real advantage, not a consolation prize. The Pricing Model Nobody Warns You About Zapier charges per task, and that sounds perfectly reasonable until your automations start doing real work. A single Zap that pulls a lead from a form, looks up a CRM record, sends a Slack message, and logs a row to a spreadsheet counts as four tasks, not one. Run that across a few hundred enquiries a month and you are burning through your plan faster than you expected. Move up to a higher tier and the price jumps sharply. Many businesses hit this wall somewhere between their first and second year of serious automation, right when the workflows that are saving time start costing more than the time they save. n8n works differently. The cloud version uses a flat monthly fee based on active workflows rather than individual task executions. Self-host it and the execution cost drops to almost nothing, with only infrastructure to pay for. For businesses running high-volume, multi-step automations, that distinction matters a lot. If you are curious how this kind of automation fits a growing business, the model makes more sense when you map it to real workflow volumes first. Zapier's pricing works fine at low volume. The problem is low volume rarely stays low. Where n8n Fits Inside a WordPress Setup WordPress and n8n connect cleanly through webhooks and the REST API, and that combination opens up more than most people expect. What a typical integration looks like A typical Zapier integration with WordPress tends to stay shallow. A new post triggers an email, or a form submission lands in a spreadsheet. n8n goes further because you control the whole flow yourself, with no connector sitting between you and the API. You can build a workflow that takes an AI-generated article, formats the content, assigns the right category and tags, sets a featured image, and publishes it as a draft, all without touching the editor. Or you might pull enquiry data from a Contact Form 7 submission via webhook, run it through a conditional logic branch, and push a notification to Slack only if the form matches a specific product interest. That kind of granular automation inside WordPress takes real time to wire up properly. But once it is running it handles volume a human could not match. Working with the REST API The REST API side is where things get interesting for content-heavy sites. You can feed AI-generated output directly into post fields, update custom meta, or sync WooCommerce product data on a schedule. Zapier can technically do some of this, but you hit rate limits and restricted endpoints fast. n8n, self-hosted, does not impose those ceilings. How to Choose Without Getting It Wrong The fastest way to narrow this down is to look honestly at three things. How complicated your workflows are. Whether anyone on your team can read a bit of code, or is willing to learn. And how many tasks you expect to run each month. If your automations are mostly linear, a form submission triggering an email and a spreadsheet row, Zapier handles that cleanly with no setup friction. But if you need conditional branching, loops, or data from multiple sources stitched together before anything fires, you will hit Zapier's limits faster than you might expect. n8n was built for that kind of complexity, and it shows. The self-hosted version lets you run unlimited tasks without a per-task bill climbing against you, which matters once volume picks up. A business processing hundreds of daily records through an automation will feel the cost difference sharply within a few months. Technical appetite is the real deciding factor. n8n rewards patience. Zapier rewards speed. If nobody in your business is comfortable poking around a workflow that breaks at 2am, Zapier's support structure is a genuine safety net. For those who do want that control, and who are already thinking about where AI automation fits into their wider setup, n8n opens doors that Zapier keeps shut. ------------------------------------------------------------ # How One Render-Blocking Script Can Wreck Your PageSpeed Score Source: https://yorkshiredesign.co.uk/how-one-render-blocking-script-can-wreck-your-pagespeed-score/ Published: 2026-08-01 > Most people assume a slow PageSpeed score means a generally slow site. Often it comes down to a single file sitting in the wrong place. One render-blocking script, loaded in the before anything else can paint to the screen, is enough to pull three Core Web Vitals metrics down at once. Understanding why that happens, and how to diagnose it on your own site, is the difference between chasing a vague score and fixing an actual problem. What the Browser Actually Does When It Hits a Blocking Script When a browser loads a page, it reads the HTML top to bottom and builds the DOM as it goes. The moment it finds a <script> tag without a defer or async attribute, it stops. Completely. It cannot continue parsing the HTML until that script has been fetched from the server, downloaded, and fully executed. Nothing renders during that pause. No text, no layout, no images. The browser is waiting on a file it had no choice but to prioritise. If that file sits on a slow external server, the pause can stretch to several seconds before a single pixel appears on screen. This is the parse-halt. It is not a minor delay baked into the loading process. The browser is doing exactly what it was told, because whoever placed that script in the <head> gave it no other option. Why the Score Hit Is Bigger Than You'd Expect A single blocking script does not damage one metric. It damages three simultaneously, and PageSpeed Insights scores all of them. First Contentful Paint (FCP) is delayed because nothing paints until the script finishes. The parse-halt sits directly between the browser and the first visible content. Largest Contentful Paint (LCP) takes the same hit. If the hero image or headline cannot even begin rendering until the script clears, the LCP timestamp shifts back by the full duration of the block. Total Blocking Time (TBT) rises because long JavaScript tasks on the main thread, which is exactly where a blocking script runs, are counted directly against this metric. Three metrics, one file. That compounding effect is why a site can look and feel reasonable yet score poorly. The blocking happens before the user perceives anything at all, which makes it easy to miss without looking at the right data. The Usual Suspects on Real WordPress Sites The same culprits appear again and again. Third-party chat widgets are a common one, loaded synchronously in the <head> because the vendor's embed snippet was copied in without modification. Analytics tags fired in the wrong order add another layer, particularly when Google Tag Manager is placed above the fold and then used to fire additional scripts. Font loaders from Google Fonts or Typekit, when embedded as <link> without preconnect hints, can stall rendering too. Tag manager payloads deserve specific attention. A single GTM container can house a dozen tags firing on page load, each one adding weight and execution time. The container itself may not be blocking, but what it fires can be. Defer, Async, or Remove These three options are not interchangeable. Getting the wrong one causes broken functionality, not just a bad score. AttributeWhat it doesBest forAvoid whendeferDownloads in parallel, executes after HTML is parsedScripts that depend on the DOM being readyScript must run before DOM builds (rare)asyncDownloads in parallel, executes as soon as readyFully independent scripts (analytics, ads)Script depends on another script's outputRemove entirelyScript is not loaded at allScripts no longer in use, or duplicated elsewhereScript provides active functionality The async dependency trap The silent risk is applying async to a script that depends on jQuery or another library. If that library loads a fraction of a second later, the dependent script executes first and throws an error. The page may look fine on the surface but a form, a slider, or a checkout step breaks. Always check execution dependencies before choosing async. Finding the Blocking Script on Your Own Site Start with the waterfall Open Chrome DevTools and go to the Network tab. Reload the page and look at the waterfall view. Any script that creates a long horizontal bar before the first paint marker is a candidate. The width of the bar shows download time; what matters is whether it sits on the critical path before content appears. Check coverage next Open the Coverage tab (Shift+Cmd+P on Mac, search "Coverage"). This shows how much of each loaded script is actually executed on page load. A file that is 90% unused on load is a strong candidate for deferral or conditional loading. In PageSpeed Insights, the Opportunities section names render-blocking resources directly and gives you an estimated saving in milliseconds. Prioritise by that number. A file saving 400ms matters more than one saving 40ms, regardless of file size. When a Plugin Is the Problem WordPress-specific performance work often reveals that the blocking script was never intentionally added. It arrived inside a plugin, and the script loading behaviour was never part of the decision to install it. A contact form plugin, a cookie consent tool, a booking widget. Each can register scripts in the <head> with no defer attribute and no loading condition. A pattern we see constantly is a plugin loading its scripts site-wide when it only needs to run on one or two pages. The fix is conditional loading. Use wp_enqueue_scripts with an is_page() check so the script only fires where it is needed. For plugins where that is not configurable, a lightweight script manager plugin can handle the conditions without touching theme files. If a plugin cannot be configured and cannot be conditionally loaded, the question becomes whether it is worth keeping. You can dig further into how measured load time diverges from the score to understand whether a given script is genuinely harming real user experience, or whether the PageSpeed number is the only thing suffering. That distinction matters before you start swapping plugins. ------------------------------------------------------------ # How to Audit Your WordPress Plugins and Cut the Dead Weight Source: https://yorkshiredesign.co.uk/how-to-audit-your-wordpress-plugins-and-cut-the-dead-weight/ Published: 2026-08-01 > Most WordPress sites collect plugins the way a garage collects old paint tins. Something gets installed to fix a problem, the problem goes away, and the plugin stays. Do that enough times and you're running fifteen active plugins where six would do the same job. This audit walks you through exactly how to find which ones are worth keeping, which are quietly hurting your site, and how to remove them without breaking anything. Start with a Snapshot Before You Touch Anything Before you deactivate a single plugin, back everything up. Not as a precaution. As a rule. A full backup covers your database and your files, and it needs to be a fresh one taken minutes before you start, not the automated copy from three days ago. Once that is done, open a plain spreadsheet and document what you have. For every plugin, note its name, the version currently installed, whether it is active or inactive, and what you believe it does. That last column matters more than people expect. You will almost certainly find plugins you cannot immediately explain, and that ambiguity is exactly what this audit is designed to resolve. Note your current Core Web Vitals scores too, whether from Google Search Console or PageSpeed Insights, because those numbers give you a baseline to measure against once you start making changes. This groundwork takes maybe twenty minutes, but it stops a two-hour audit turning into a two-day recovery job. Skipping it is the most common reason plugin tidying goes wrong. Reading the Plugin List with Fresh Eyes Go to Plugins in your WordPress dashboard and look at the full list as if you have never seen it before. Filter inactive plugins first. Any plugin that has been deactivated and left sitting there is already dead weight, because WordPress still loads parts of its code on every request regardless of whether it is switched on. If you cannot remember why you installed something, that is a signal to act on immediately. Sort by "Last Updated" next. Anything with no update in two years deserves real scrutiny. A plugin that has not been touched in that time has likely been abandoned by its developer, which creates a slow drip of security exposure over months. Once you have filtered by status and date, go through what remains and ask one question about each entry, what would break if this disappeared tomorrow? If the answer is nothing obvious, add it to a shortlist for removal. A good WordPress performance audit will show you which plugins are affecting load times versus which ones are just sitting idle. Do not rush this. A methodical pass through 40 plugins takes twenty minutes, and it pays back every time the site loads. Testing Each Plugin's Real Cost Suspicion alone will not tell you which plugin is the problem. Query Monitor will. Install it on a staging copy of your site, then load a representative page and open the panel. You will see every database query that fired, which function called it, and how long each one took. A caching plugin might run 4 queries per load. A half-forgotten social sharing bar might fire 47. That gap stays invisible until you look. The same panel shows you which plugins are running queries on admin screens, and a slow dashboard compounds over hundreds of visits from you and any editors on the site. Always do this on staging, not live. Changing things on a production site while real visitors are on it is asking for trouble. Once you have the query data, cross-reference it with a front-end load test using something like GTmetrix or PageSpeed Insights, before and after deactivating a suspect plugin. A plugin that adds 30 database queries and loads three external scripts is costing you on two fronts at once. If you want a more structured approach before you start pulling things out, a thorough performance audit gives you a clearer picture of where the real weight sits before anything gets removed. The Questions That Decide Whether a Plugin Stays Before you remove anything, work through the same four questions for every plugin on your list. Does another plugin already cover this? Duplication is more common than people expect, especially around caching, SEO metadata, and image handling, where sites can end up with two tools fighting each other. Does WordPress itself now handle it natively? Block themes and the core editor have absorbed a lot of functionality that once needed a dedicated plugin. Check before you assume you need one. Does your theme include it? Page builder themes in particular bundle form builders, sliders, and social icons that make a separate plugin pointless. Does the functionality justify the overhead? A plugin that adds a single shortcode to one page probably does not justify the database queries, admin overhead, and update cycle that comes with it. If that last question is unclear, look at what breaks when you deactivate it on a staging copy. If nothing breaks, that tells you everything. This is where most plugin lists get trimmed fastest. Not by finding bad plugins, but by finding unnecessary ones. Removing Plugins Safely and in the Right Order Never delete a plugin without deactivating it first. That single step catches most problems before they happen. Deactivating gives WordPress a chance to unhook the plugin's functions cleanly, and it lets you see whether anything breaks before the files are gone for good. Work through your list one plugin at a time, not in batches. Deactivate, reload the front end, check a few key pages, log in and out, run through any forms or checkout flows. If something looks wrong, you still have the plugin's files sitting there and can reactivate in seconds. Once you are satisfied nothing has broken, then delete. It is a slower process than binning the lot in one go, but it saves the kind of panicked rollback that costs far more time than the audit itself. If you want a proper safety net, do all of this on a staging environment first, where any breakage is invisible to visitors and easy to unpick without pressure. Pay particular attention to plugins that added shortcodes or custom database tables. Deleting those can leave visible broken output or orphaned data that needs cleaning up separately. What a Cleaner Plugin List Does for Performance and Security The performance side Every active plugin adds PHP that runs on each page request. Some plugins hook into a dozen WordPress filters; others fire database queries before a single line of your content has loaded. Strip out five redundant plugins and you can shave a meaningful chunk off your server response time without touching a single setting. The database side matters too. Plugins that log events, cache transients, or track user behaviour write constantly to your wp_options table, and over months that table bloats. A leaner set of plugins means fewer rows, faster queries, and a WordPress install that does not groan under its own weight. If you want to see exactly where the drag is coming from before you start cutting, a thorough performance audit is the sensible first step. The security side Each plugin is a codebase maintained by someone else, and any one of them can carry an unpatched vulnerability. Fewer plugins means a smaller surface for an attacker to probe. Deactivated but still-installed plugins still sit in your file system and can still be exploited. Remove them entirely. Keeping It Clean Going Forward The easiest way to keep the plugin list under control is to treat it as a recurring task rather than a one-off fix. A quick quarterly check takes maybe twenty minutes. Open your plugins screen, look at anything you have not touched in three months, and ask whether removing it would change anything on the live site. If the answer is no, it goes. That habit alone stops the slow creep where a site that launched with fourteen plugins reaches forty-two over two years. Before installing anything new, check the last updated date, the active install count, and whether it has been tested with your current version of WordPress. A plugin abandoned eighteen months ago is a liability before you have even activated it. The bigger discipline is asking what problem you are actually solving before you reach for a plugin at all. A lot of installs happen because someone Googled a symptom and clicked the first result. Sometimes the fix is four lines of code in a child theme's functions.php, not another dependency sitting in your stack. If you are unsure whether your current setup is pulling its weight, a proper WordPress performance audit will show you exactly where the weight is coming from. ------------------------------------------------------------ # Kinsta vs SiteGround: Which Host Is Worth the Monthly Cost Source: https://yorkshiredesign.co.uk/kinsta-vs-siteground-which-host-is-worth-the-monthly-cost/ Published: 2026-08-01 > Kinsta charges roughly four times more than SiteGround for an equivalent site. That gap is hard to ignore when you're choosing a host, but the price difference only matters if you understand what you're actually paying for, and what you're giving up by going cheaper. These two hosts are built on fundamentally different architectures, and the right choice depends less on budget than on what your site genuinely needs from its infrastructure. What Separates the Two Architectures These two hosts are built differently, and that matters more than any feature comparison spreadsheet would suggest. Kinsta runs entirely on Google Cloud Platform, and every site gets its own isolated container. Your site's processes, resources and file system are completely separate from every other site on the platform. If a neighbour gets hammered by traffic or has a rogue plugin eating CPU, you don't feel it. SiteGround takes a different path. It runs on shared infrastructure, with LiteSpeed web server and its own caching layer doing the heavy lifting to keep response times competitive. On a quiet shared server with sensible cache configuration, SiteGround can feel fast. But it is still a shared environment, which means the ceiling on performance and isolation is lower. Neither approach is wrong. Container-based isolation solves a problem that most small business sites never encounter. Shared hosting with a well-tuned cache solves the problem most sites do have, which is getting pages out quickly without paying for dedicated resources. The architecture question is about which problem you need solving, and at what point in your site's growth. Performance Under Real Traffic How isolation affects your numbers Kinsta's containerised setup means a traffic spike on someone else's account has no effect on yours. When a page suddenly pulls three times its usual visitors, your allocated CPU and RAM stay yours. SiteGround's entry-level shared plans don't offer that same separation. Under sustained load, a busy neighbour can chip into the resources your site draws from, and that shows up exactly where it hurts most, your Core Web Vitals scores. Google uses those scores as a ranking signal. A host that wobbles under pressure isn't just an inconvenience, it's a drag on visibility. Largest Contentful Paint and Time to First Byte are the two metrics most directly connected to server behaviour, and both will slip on shared infrastructure the moment another account on that machine starts pulling hard. SiteGround does offer a step up through its cloud and dedicated tiers, and performance there is considerably more stable. But those plans cost significantly more, which changes the comparison with Kinsta entirely. Object caching and what it actually does Object caching, which both platforms support, can look like a performance boost on paper but often adds hidden complexity, particularly on sites that aren't running a high volume of repeated database queries. Understanding what your host is doing under the bonnet matters as much as the headline server specs on managed platforms like Kinsta. What SiteGround Gets Right SiteGround's managed WordPress offering is more capable than its price suggests. Staging is built in and straightforward, daily backups run automatically, you can restore a specific file rather than rolling back the whole site, and managed WordPress updates mean you are not logging in every week to push core and plugin versions manually. For a business running a brochure site or a modest WooCommerce shop with a few hundred orders a month, those are real time-savers with no engineering overhead on your side. At roughly a quarter of Kinsta's monthly cost on comparable traffic tiers, it is hard to make the numbers stack up against a premium host unless your site has a specific performance problem that cheaper infrastructure cannot solve. What most people underestimate is how far SiteGround's caching layer and server configuration will carry a well-built site. A lean WordPress install, properly compressed images, and a minimal plugin footprint will perform comfortably on SiteGround for the majority of small-to-medium sites. The performance ceiling only starts to matter when traffic spikes become frequent, or when the site carries complex queries and dynamic content that no amount of caching fully absorbs. Before that point, the extra spend on Kinsta buys you headroom you may never need. Where Kinsta Earns Its Price Traffic spikes and downtime tolerance The clearest case for Kinsta is a site where traffic spikes unpredictably and going offline costs real money. A WooCommerce store running a flash sale, a membership platform pushing out a new course to thousands of subscribers at once, a multi-site network serving different regional brands from a single WordPress install. These are the situations where Kinsta's architecture stops being a luxury and starts being a necessity. Its container-based infrastructure on Google Cloud means each site gets isolated resources, so a traffic surge on one install doesn't drag every other site down with it. SiteGround's higher-tier plans are decent, but they're still sharing a physical environment in ways that show under sustained load. Downtime tolerance is the other honest filter. If an hour of unavailability costs your client a few hundred pounds in lost orders and a support queue full of complaints, the price difference between these two hosts becomes a rounding error. How it compares to other managed options If you're weighing up how Kinsta sits against other managed options beyond SiteGround, the comparison with Cloudways covers the trade-offs from a different angle and is useful to read alongside this one. Pricing Compared Across Tiers Kinsta costs more. That's the short answer. The question is whether what you get in return justifies the gap. At entry level, SiteGround's StartUp plan sits at a noticeably lower monthly price than Kinsta's Starter, though SiteGround's renewal rate climbs sharply after the first term, which catches people out. Kinsta's pricing stays consistent from the start, so the number you see is the number you keep paying. Mid-tier is where the comparison gets more interesting. SiteGround's GrowBig allows multiple sites and adds a staging environment. Kinsta's Pro plan covers two sites with more generous monthly visit allowances and CDN bandwidth included as standard. By the time you reach growth-level plans, both hosts bundle CDN, but Kinsta's is powered by Cloudflare's Premium Tier network, which meaningfully affects delivery speed for international visitors. SiteGround leans on its own CDN, which is competent but a step behind on raw performance. Per pound spent, SiteGround wins on price. Kinsta wins on what the price includes from day one. If you want a fuller look at how Kinsta's pricing holds up against a dedicated managed host, the Kinsta vs Cloudways breakdown covers that ground in detail. Migration, Support and the Day-to-Day Reality Migration is not a minor detail Both hosts advertise free migrations, but the detail matters. Kinsta migrates one site for free on entry-level plans and charges for additional moves. SiteGround also offers a free migration plugin and manual help on higher tiers, though the quality of that hands-on assistance varies depending on who picks up the ticket. A botched migration, one where redirects break, uploads get corrupted, or a WooCommerce database table silently fails to transfer, can easily cost you more in lost revenue and recovery time than a full year's difference in monthly fees between the two hosts. Treat migration as a serious operational event, not an afterthought. If you are moving a complex site, test your staging environment thoroughly before cutting over. Neither host eliminates the risk entirely. Support quality day to day Kinsta routes every query through a team with genuine WordPress knowledge. SiteGround's support is fast and generally competent for standard hosting questions, but responses can feel more scripted once you push beyond the basics. For technically demanding issues, the depth of that first response makes a real difference to how quickly you get back up and running. Which One to Pick The decision is simpler than most hosting comparisons make it sound. If your site takes payments, generates leads, or runs any kind of e-commerce, Kinsta is the more defensible spend. A single hour of downtime or a slow checkout page costs more than a month's hosting fee. The performance headroom, the automatic daily backups, and the hands-on support start to look cheap when you think about what a bad day costs you. Sites built on WooCommerce, membership platforms, or booking systems tend to see the difference in page speed almost immediately after migrating, and that faster load time has a direct knock-on for conversion. For a brochure site or a small blog that doesn't depend on traffic to generate revenue, SiteGround does the job at a fraction of the price. Paying Kinsta rates for five static pages and a contact form is hard to justify. If you want to see how hosting costs compound over time, it's rarely the monthly headline figure that catches people out. Ask yourself one question before you commit. Does this site lose money when it runs slowly or goes down? If yes, Kinsta pays for itself. If no, SiteGround is the more sensible place to start. ------------------------------------------------------------ # Bing Is Gaining Ground. Is Your SEO Strategy Ready? Source: https://yorkshiredesign.co.uk/bing-is-gaining-ground-is-your-seo-strategy-ready/ Published: 2026-08-01 > Most SEO work is aimed squarely at Google, and for good reason. But Bing's slice of UK search has been growing quietly, and AI-powered features like Copilot have made it harder to ignore. Plenty of sites have spent years optimising for one engine while the other chips away at their potential traffic. This post looks at what that shift actually means in practice, and what you'd need to change, or check, to make sure your site is ready for both. The Numbers That Changed the Conversation Bing's share of UK search has crept past the point where you can comfortably ignore it. On desktop, Bing consistently holds somewhere between 10 and 15 percent of UK searches, and among users over 45 the figure sits higher still, partly because Edge ships as the default browser on every new Windows machine. That demographic skews toward B2B decision-makers, higher household income, and considered purchases rather than impulse ones. For plenty of businesses, that is not a fringe audience. The AI integration has complicated the picture further. Since Microsoft folded Copilot into the Bing interface, raw market-share numbers have started underselling actual usage. People who would never have typed a query into Bing are now using Copilot inside Teams, inside Edge, inside the Windows sidebar, and the results those tools surface are pulled directly from Bing's index. The query count and the reach of Bing's results have quietly diverged. None of this makes Bing a replacement for Google, and anyone telling you to abandon your existing strategy is jumping to the wrong conclusion. What has changed is the cost of ignoring it. A site that ranks well on Google but has never been looked at through the lens of Bing's crawler, its structured data preferences, or its AI-driven results pages is almost certainly leaving traffic on the table. How Bing Crawls and Ranks Differently to Google Keyword signals and on-page clarity Bing and Google both crawl the web and match pages to queries, but the signals they weight are meaningfully different. Bing places stronger emphasis on exact-match keywords in page titles and headings than Google does. Google has spent years moving toward topical relevance and entity understanding, so a page it ranks on a broad semantic match may not perform on Bing without the specific phrase present in the markup. On-page clarity matters more on Bing too. It tends to reward pages where the subject is obvious from the structure rather than inferred from surrounding context. If your content relies on implied meaning or thin keyword density because you optimised purely for Google's natural language processing, Bing's crawler may not make the same generous leap. Bing also pays closer attention to social signals, particularly from Facebook and LinkedIn, as indirect indicators of content authority. Links and technical health Backlink quality still counts, but Bing has historically been more receptive to link volume alongside authority, whereas Google has steadily shifted toward quality over quantity. Keep that in mind if your profile skews older and broader. Page speed and technical site health matter on both engines, though Bing is generally considered less forgiving of crawl errors and redirect chains. Fix the foundations and both search engines benefit. What Bing AI Search Does to Your Organic Visibility Bing's Copilot integration does something fairly fundamental to how organic results work. Instead of sending users down to a list of blue links, it synthesises an answer directly on the results page, pulling from whichever sources it judges most useful. A page sitting in position four or five can contribute to the AI-generated answer at the top, while a page sitting in position one gets skipped entirely if its content is too thin or too vague to be cited. Ranking, in the traditional sense, matters less than whether your content is the kind of thing the engine actually wants to quote. Feeding those answers takes a different kind of writing. Specific, clearly structured content with direct answers to real questions is what gets pulled in. A paragraph that dances around a topic won't make the cut. The practical implication is that you need to think about whether each page answers something concrete, not just whether it targets the right keyword. Headers that reflect real questions, concise paragraphs that reach a conclusion, and content that doesn't bury its point in filler all make it easier for Copilot to surface your page as a source. If you're already paying attention to how Bing's AI answers affect organic traffic, you'll know this is less about chasing a position and more about being useful to the engine doing the summarising. Bing Webmaster Tools Why most sites haven't set it up Bing Webmaster Tools is free, takes about ten minutes to set up, and the vast majority of sites ignore it completely. That is a straightforward mistake. The platform gives you URL submission, a crawl control panel, a backlink explorer, and a keyword research tool that pulls data directly from Bing's own index. None of that is available through Google Search Console, so there is no duplication. It is a separate window into how a different search engine reads your site. If your XML sitemap is not submitted there, Bing is discovering your pages on its own schedule, which tends to be slower. Submitting it directly can noticeably compress that crawl lag, especially on newer content or recently restructured sites. The reports most people skip past The SEO reports section is where most people stop short. Bing flags issues like missing meta descriptions, thin pages, and slow-loading resources, often surfacing problems that Google's tooling glosses over. It is a second opinion on your site's health, and a useful one. If you're already thinking about where technical site health fits into a broader search strategy, Bing Webmaster Tools belongs in that conversation. Set it up once and check it alongside your regular Google Console review. The data doesn't overlap. It adds to it. Content Strategy That Works for Both Engines The overlap between what ranks on Google and what ranks on Bing is real, but it isn't total. Strong, authoritative content tends to do well on both. Thin pages stuffed with keywords tend to do badly on Bing specifically. Bing places heavier weight on clear on-page signals than Google does. That means proper heading structure, genuine depth on a topic, and content that reads like it was written by someone who actually knows the subject. Google has grown sophisticated enough to reward relevance even when the page is a structural mess. Bing is less forgiving on that front. A page that gets away with loose formatting and shallow copy on Google may stall on Bing because the engine cannot extract a confident topical signal from it. The practical lesson is straightforward. If your content has real depth and a clean structure, it tends to travel well across both engines. If it has been written purely to hit a keyword density target, Bing will surface that faster than Google will. Improving for Bing rarely means building separate content. It means doing the things you should have been doing anyway, covering topics properly, using headings that reflect the actual structure of the page, and making sure your technical SEO foundations are sound underneath. One engine rewards you for it more visibly. Both eventually do. Do the Comparison Before You Change Anything Before changing a single title tag or spinning up a Bing Webmaster Tools account, pull up your Google Search Console and Bing Webmaster data side by side. Most people have never done this, and the gap it reveals is often more instructive than any audit. You might find that a handful of your most commercially important pages rank on page one in Google but don't appear in Bing's top fifty at all. That is not a minor detail to file away. It tells you exactly where to start, and it tells you something specific about how the two crawlers are reading your site differently, whether that is a structured data gap, a slower page on mobile, or thin content that Google has learned to overlook but Bing hasn't. The comparison also works in reverse. Some pages rank better on Bing than on Google, and understanding why can be instructive, particularly if your technical SEO foundations are stronger than your link profile. Bing tends to weight on-page signals more heavily in those cases. The answer to where you should focus next is usually sitting in the data you already have, unread. ------------------------------------------------------------ # When To Fire Your SEO Agency And Start Fresh Source: https://yorkshiredesign.co.uk/when-to-fire-your-seo-agency-and-start-fresh/ Published: 2026-08-01 > Six months of reports, a lot of confident-sounding calls, and your enquiries have not shifted. Sound familiar? Knowing when a relationship with an SEO agency has genuinely run its course is harder than it sounds, because bad results and slow results can look identical on the surface. This piece lays out the real signs to watch for, what the data actually needs to show before you pull the plug, and what a clean start should look like when you do. The Difference Between Slow Progress and No Progress SEO takes time. That's not an excuse, it's just the reality of how search engines work. But "takes time" and "nothing is happening" are not the same thing. After three to four months of consistent work, you should be able to point to specific signals of forward movement, even if traffic hasn't shifted yet. Google Search Console impressions tend to grow before clicks do. Pages sitting at position 18 or 22 should be edging toward the top ten, not staying frozen. Crawl coverage should be stable or improving, with fewer 404s appearing and no new waves of indexing errors. If your agency is running a proper technical foundation alongside content work, you'd expect crawl stats trending in the right direction, indexed page counts growing on the right URLs, and target pages at least appearing in query data for the terms they're meant to rank for. None of this is dramatic. It's incremental and measurable if someone is paying attention at the page level rather than just watching the overall traffic line. The real warning sign is flatness across all of those signals simultaneously. One metric stalling can have a straightforward explanation. When impressions, crawl health, and ranking positions on your core pages all show no movement over five or six months, that's a pattern, not a rough patch. What Your Monthly Report Should Contain A solid monthly report tells you what moved, what didn't, and why. That means specific ranking changes on specific pages, not a site-wide average. It means crawl coverage data showing whether Google is reaching the pages you care about. It means Core Web Vitals scores per URL, so you can see if a slow product page is sitting below the threshold that affects how Google treats it in mobile search. When an agency pulls changes like this together into one readable document, you can see the work. You can connect the action taken in week two to the ranking shift in week four. That cause-and-effect chain is the whole point. What you don't need is a domain authority score dressed up as progress. Domain authority is a third-party metric with no direct bearing on how Google ranks your pages. The same goes for social share counts, keyword density notes, and those vague summary lines that read "we continued to optimise your website this month." That tells you nothing. If you want to understand what separates hollow reporting from the kind that guides real decisions, the metrics that matter are a good place to benchmark what you should be asking for. Reporting isn't just a deliverable. It's the evidence that the work is real. Five Signs the Relationship Has Already Broken Down Access and visibility The clearest early warning is getting locked out of your own data. If your agency controls the Google Search Console property and you have no direct login, that is not a workflow preference. It is a dependency they are creating. Healthy agencies give clients full access from day one. Keyword drift and vanity metrics Watch for keyword targets that have drifted miles from what the business sells. If the monthly report celebrates ranking for terms your customers would never search, someone is chasing vanity numbers to justify the invoice rather than thinking about your revenue. Backlink reports are another place this surfaces fast. A list of directory submissions to sites with no relevance to your industry is not link building. It's box-ticking. Audits that go nowhere Promised technical fixes that never arrive are the most expensive sign of all. A site audit landing in your inbox in month one, then nothing shipped six months later, should raise serious questions. If those fixes are still sitting unresolved, your underlying technical problems are dragging on rankings every single day. Reports built without Google's own data The last tell is reporting that never once references Google's own tools. If monthly updates are built entirely from third-party rank trackers with no mention of Search Console impressions, click-through rates, or crawl coverage, the agency is either not looking at the authoritative source or hoping you won't notice the gap. Real SEO work lives inside the data Google provides, and any report that sidesteps it deserves a straight question about why. Before You Leave: What to Audit First Who owns the accounts Before you switch agencies or go it alone, spend a few hours going through everything the outgoing agency touched. Start with access. Do you own the Google Search Console and Google Analytics properties outright, with your email as the primary owner? Do you hold the keys to your Google Business Profile, any paid ad accounts, and the hosting control panel? Agencies sometimes set these up under their own accounts and hand over only a secondary user role, which means a clean break can leave you locked out of months of data. Confirm every account sits in your name before you serve notice. What was changed on the site Next, pull a record of the technical changes made to your site. Ask for a changelog if one exists. If not, check your CMS revision history and any third-party monitoring logs. You want to know what plugins were installed, whether any redirects were added, and whether canonical tags or robots.txt was altered. Understanding what your site's underlying technical structure looks like at the point of exit tells you exactly what the next person is inheriting, good or bad. Finally, get a list of every link built on your behalf, every piece of content published, and any citations created. That work has real value. Don't let it walk out the door undocumented. Starting Fresh Without Losing Ground A clean restart does not mean scrapping everything and hoping for the best. Done properly, it means understanding exactly where you stand before a single piece of new work begins. Start with a proper technical audit. Not a surface-level report generated by a free tool, but a thorough crawl that shows what Google is seeing. That means checking for crawl budget waste, duplicate content, orphaned pages, broken internal links, and redirect chains that have accumulated over months of neglected work. A crawl budget review is particularly telling on larger sites where Google may be spending its time on low-value pages and missing the ones that matter most. Alongside that, a real keyword gap analysis tied to what the business sells is non-negotiable. Too often, previous agencies optimise for terms that look impressive in a report but bear no relation to how customers search, or what the site is trying to convert. If you want to understand what a thorough technical reset involves, the technical fixes that move WordPress rankings give a clear picture of the groundwork that often gets skipped. On timeline, be realistic. Expect three to six months before new, properly grounded work begins to register in rankings. That is not a failure of the approach. It is how search engines respond to change. What Good SEO Work Looks Like From the Outside Transparency from month one A well-run engagement never leaves you guessing. From the first month, you should receive a clear explanation of what's been done, why it was done, and what the next phase involves. That means work you can verify, pages that have been audited and corrected, content that's gone live, technical issues identified and fixed, and rankings you can cross-reference in Google Search Console. A good provider will flag problems a previous agency missed, explain them in plain English, and show you the before-and-after. What we see when we take over a site Over three to six months, you'd expect to see organic traffic trending in the right direction, even modestly, with a clear story behind any movement. The metrics reported should connect directly to the work done, not just a generic graph with no explanation attached. When we take over sites that have been sitting on monthly retainers elsewhere, the contrast is often stark. The sites where real work was happening are obvious the moment you look under the bonnet. The ones where nothing was done are equally obvious, and that's a harder conversation to have with a client than it should be. The standard to hold any new provider to is straightforward. If you can't see the work, and they can't show it to you, the metrics you're being shown are likely decorating the absence of one. ------------------------------------------------------------ # What Clients Actually See When You Show Them a Staging Site Source: https://yorkshiredesign.co.uk/what-clients-actually-see-when-you-show-them-a-staging-site/ Published: 2026-08-01 > Most clients have never seen a staging site before you send them the link. They click through expecting a finished website, and what greets them looks almost right but slightly off. The fonts load a beat late, the images are placeholders, and the mobile view nobody thought to test on is showing something unexpected. That first impression shapes the whole conversation that follows, so getting ahead of it matters more than the design itself. The Gap Between 'Done' and What They're Looking At The moment you paste a staging URL into an email, most clients read it as a finished website. They're not thinking about temporary domains, placeholder content, or the fact that the fonts look slightly off because the CDN isn't connected yet. They open the link on their phone, scroll for twenty seconds, and start forming opinions. By the time you're on a call together, they've already decided something is wrong with the colour of the button, or why does the hero image look blurry, or the logo seems small. None of those things have anything to do with whether the build is structurally sound. But that's the feedback you get, because the browser didn't tell them they were looking at a work-in-progress. It just loaded a page, and a page is a page as far as a client is concerned. The practical problem is that this pulls the conversation in the wrong direction at the wrong stage. You end up defending visual details that will change anyway during final polish, while the actual decisions that need signing off, such as content placement, navigation structure, and feature completeness, get pushed to a second or third review. That costs time on both sides, and it happens almost every time a staging link goes out without any framing around it. Why the First Thing They Notice Is Usually Wrong Show a client a staging site and within thirty seconds they'll tell you the button colour looks slightly off, or that they want the font a touch bigger. It's not a criticism of them. It's just where the eye naturally lands. Colour and type are immediate, tactile, easy to form an opinion on. What doesn't get mentioned is the stuff that took the most time to get right. The way the page loads in under two seconds on a mobile connection. The clean template hierarchy underneath. The fact that the layout holds together properly on a 375px screen rather than collapsing into an overlapping mess. That work is invisible because it was done correctly. A slow or broken version of those same things would have been noticed immediately. The structural layer, the performance architecture, how requests are handled, how assets are sequenced, is only visible when it fails. Clients don't see what's sitting in the build keeping things fast and clean. They see the surface, and the surface is where they've been conditioned to have opinions. Knowing this changes how you walk someone through a preview. If you just hand over a URL and wait, you'll spend the next hour discussing typeface choices while the real work goes unexamined. What a Staging Environment Actually Contains Placeholders clients mistake for design decisions A staging site is a copy of the build at a point in time, not a finished product. It will usually have the theme applied, the page templates in place, and the rough layout working. What it almost certainly won't have is the real photography, the final copy, or the compressed and properly sized images that will load on the live site. Developers often pull in placeholder text just to fill the layout, and those blocks of Lorem Ipsum sitting beneath a hero image are not neutral to a client who has never seen a staging build before. They read them as a design choice, or worse, as a mistake. The performance trap Uncompressed images are the other quiet trap. A staging build frequently pulls in raw uploads, sometimes several megabytes per image, because performance optimisation happens later in the process. The page loads slowly, and the client's first impression is that the site is sluggish. This is where a clear briefing before the review call saves a lot of confusion. Walk through what is placeholder, what is structural, and what is locked. Explain that the fonts and colours are final, but the stock images are stand-in assets that the full website redesign process will replace with supplied photography. When a client understands the vocabulary of a staging environment, they stop reviewing the wrong things and start giving you the feedback that moves the project forward. The Feedback You Get Versus the Feedback You Need Hand a client a staging link with no guidance and you'll almost always get the same kind of response. The logo feels a bit small, they'd prefer a different shade of blue for the buttons, could the font be slightly bolder on the homepage headline. That feedback is easy to give because it's visual and immediate. What they won't mention, because they don't know to look, is that the mobile menu collapses behind the hero image on an iPhone SE, or that tapping the contact button on a mid-range Android sends them to a blank page. They won't clock that the homepage takes four seconds to respond on a 4G connection, or that the service dropdown buries the most-visited page two levels deep. These are the things that affect enquiries after launch, and clients miss them every time without a structured brief. The fix isn't complicated. Give them a short list of specific things to check before they open the site. Ask them to try the main navigation on their phone. Ask them to find a particular product or page as if they'd arrived from Google. That shifts attention from surface decoration to actual behaviour. Visual tweaks take twenty minutes. Broken mobile states found post-launch take considerably longer to untangle, and the client rarely remembers they didn't spot it during review. How to Frame the Staging Review Before You Send the Link The briefing note you send before the link matters as much as the link itself. Without any context, a client opens a staging URL and their attention lands wherever it happens to land, usually on something cosmetic like a font size or a button colour, rather than the structural decisions that still need sign-off. A short paragraph sent ahead of the review changes that completely. Tell them what they are looking at and what stage of the build it represents. Explain that placeholder images may still be in place, that mobile styling is confirmed but not yet pixel-perfect, and that you are specifically asking them to check the page order, the navigation labels, and whether the content says what they need it to say. That framing alone shifts the conversation from "I'd make this blue" to "we need a contact form on this page." The feedback becomes usable rather than decorative. Keep the note brief, four or five sentences at most. Name the two or three things you want a decision on, and tell them what to ignore for now. If there is a deadline for feedback, state it clearly. Clients rarely push back on a structured review process. Most find it a relief to be told exactly where to focus their time. When Staging Reveals a Real Problem Worth Stopping For Sometimes a client looks at the staging site and flags something that has nothing to do with colour or font size. They notice that a contact form submits with no confirmation message, or that a service page they mentioned three times during the brief never made it into the navigation. Those are structural gaps, not stylistic preferences. Missing them before launch means fixing them under pressure afterwards, which always takes longer and costs more goodwill than catching them now. The same goes for broken links on a key conversion path, or a mobile layout that collapses a critical call-to-action below the fold. When a client spots one of these, the right response is to stop, log it, and fix it properly before moving forward. The trickier situation is when a genuine issue and a personal preference arrive in the same feedback email. A client might flag a real navigation problem in the same paragraph as a request to change a heading font they've already approved. Treating both with equal urgency is where projects drift into revision loops that no one planned for. Knowing the difference protects both sides. Structural problems get fixed. Preference changes get discussed against the original brief. ------------------------------------------------------------ # Why Google Sometimes Still Ranks Slow Websites Source: https://yorkshiredesign.co.uk/why-google-sometimes-still-ranks-slow-websites/ Published: 2026-08-01 > A client once showed me a competitor's site that took over six seconds to load on mobile. No caching worth mentioning, images served at full resolution, a theme that looked like it hadn't been touched since the early days of flat design. Their own site was clean, fast, and properly optimised. The competitor still sat two positions higher. That kind of thing is frustrating until you understand what Google is actually weighing up when it decides who goes where. Speed Is One Signal Among Many Core Web Vitals are a confirmed ranking factor. They are not a dominant one, and treating them as though they were leads to a lot of wasted effort. Google processes hundreds of signals when it decides which pages to surface. Content relevance sits at the top of that pile, followed by backlink authority, topical depth, and how well a page answers the query. Page speed matters, but in Google's overall weighting it sits considerably further down. A page that loads in 4 seconds and comprehensively covers a subject will, in most cases, outrank a page that loads in under a second but says very little. That might feel counterintuitive if you've spent time chasing performance scores, but it's consistent with how Google has always behaved. It is trying to find the most useful result, not the fastest one. Where speed becomes a real differentiator is when two pages are closely matched on everything else. If content quality, authority, and relevance are roughly equivalent, a faster site does pull ahead. But that scenario is less common than most people assume. In practice, the gap in content quality between competing pages is usually wide enough that a slow site with something useful to say keeps its rankings despite the performance deficit, often comfortably. What the Slow Site Usually Has That the Fast One Doesn't The sites that hold rankings despite poor load times almost always carry something that took years to build, and that a faster competitor hasn't had time to accumulate. The most common factor is domain age combined with a backlink profile that grew organically over a long period. A site that has been earning links since the mid-2000s carries a weight of trust that no amount of performance tuning can replicate overnight. Google interprets those links as editorial endorsements from across the web, and that accumulated trust tends to outweigh a slow server response, at least until a faster rival closes the content gap too. You see this pattern most often in established industries where a few older sites have owned the conversation for so long that newer, technically cleaner competitors are still working their way up. Topical coverage plays a big part in this too. A slow site that has covered every angle of a subject, published consistently, and built up internal linking across dozens of pages gives Google a complete picture of its authority on that topic. A look at what Google weighs when ranking makes clear that topical depth carries real weight, and it is the kind of depth that only comes with time. Click-through history matters as well. A site users have clicked on, returned to, and spent time with has behavioural signals that reinforce its position. That track record doesn't vanish the moment a faster site appears. How Google Measures Page Experience Google does not use the score you see on PageSpeed Insights to decide rankings. That score comes from a lab test, a simulated run against a fixed set of conditions. What Google uses is field data from the Chrome User Experience Report, known as CrUX. CrUX collects real measurements from real Chrome users visiting real pages, aggregated over a rolling 28-day window. A site might score 54 in the lab and still show green passes in CrUX, because the people visiting it on decent connections in typical conditions are loading it well within the bands Google cares about. Lab scores vs field data The lab test is a diagnostic tool for finding problems. CrUX is what feeds into Google's Page Experience signal. Treating them as the same thing leads to a lot of wasted effort chasing a number that Google is not watching. A local services site with modest traffic and a loyal returning audience on fast broadband might produce consistently clean CrUX data, even if a PageSpeed test run on a throttled mobile connection makes it look sluggish on paper. The score you see is not the score that matters. What the passing bands actually require Pass Largest Contentful Paint under 2.5 seconds for at least 75% of visits, keep Cumulative Layout Shift below 0.1, and meet the Interaction to Next Paint threshold, and Google considers the experience good regardless of what any lab number says. The Pass/Fail Nature of Core Web Vitals Google's Core Web Vitals scoring works on a pass/fail basis, not a continuous scale that rewards every incremental improvement. Once a page clears the 'Good' band on Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, it has done its job in the algorithm's eyes. A site loading in 1.8 seconds and one loading in 0.9 seconds can sit at exactly the same position in the rankings, because both have cleared the threshold and neither earns anything extra for the gap between them. That binary nature is the part most people miss when they're puzzling over why a noticeably slower competitor keeps outranking them. The practical consequence is that PageSpeed scores mean less than whether the passing bands are met. Chasing a perfect 100 on Lighthouse when you're already in the 'Good' range is effort spent on something Google cannot distinguish from a score of 75. That's not an argument against optimising further. Faster pages convert better, retain visitors longer, and reduce bounce rates on mobile. But the ranking benefit stops at 'Good', so if a slow site has cleared that bar and your faster site hasn't, the algorithm will not save you from the comparison. When Speed Does Flip the Result Speed rarely decides rankings on its own. But there are specific situations where it tips the balance. The clearest case is a closely contested query where the top few results are near-identical in authority, backlink profile, and content depth. Google has no strong editorial reason to prefer one over another, so the signals it can measure precisely start to carry more weight. Page Experience is one of those signals. A 2.1-second LCP against a competitor's 4.8-second one stops being noise and starts being a differentiator. The same dynamic shows up on mobile-heavy traffic, where Core Web Vitals scoring is measured against real-world mobile data, not a desktop proxy. A page that loads cleanly on a mid-range Android phone on a 4G connection is serving that audience better, and Google's data reflects it. If you've ever wondered why your PageSpeed score doesn't map neatly to your position, this is often why. The relationship is conditional, not constant. Where speed matters most Thin-content pages are where speed becomes the most decisive factor. A location page, a category archive, or a sparse product listing often has little else for Google to weigh up. No depth of content, no strong E-E-A-T signal, nothing that clearly separates it from the next page in the results. In that vacuum, a fast, stable page experience is one of the few real edges left. What This Means for Your Own Site Speed improvements are worth doing, but they work best when they sit inside a broader effort to make your site cleaner and more credible overall. If a competitor has years of quality backlinks, a well-structured site, and content that answers what people are searching for, shaving 0.4 seconds off your Largest Contentful Paint is unlikely to flip the rankings on its own. What speed work does do is remove a reason for Google to doubt you. A slow, bloated site signals neglect, and that matters at the margins. Fix the performance issues because they make the site better for real visitors, because they reduce bounce rates, and because they contribute to a trustworthiness that accumulates across everything Google evaluates. Think of it as tidying up the foundations rather than pulling a lever labelled "rank higher". The sites that tend to see meaningful movement after a speed pass are those where performance was genuinely terrible and the rest of the site was already in reasonable shape. If your PageSpeed scores are sitting in the red and you've never looked under the bonnet, there is probably real ground to recover. But if you're chasing a stronger domain with a tidier score, the gap won't close on speed alone. There are often less obvious reasons a site stays slow even after the obvious fixes have been made. Getting those sorted is the unglamorous part of the job, and it tends to take more time than people expect. ------------------------------------------------------------ # Why Google Still Ranks Slow Sites (And What That Really Means) Source: https://yorkshiredesign.co.uk/why-google-still-ranks-slow-sites-and-what-that-really-means/ Published: 2026-08-01 > Roughly one in three pages ranking on the first page of Google loads in over three seconds on mobile. If page speed were the hard gate everyone assumes it is, those pages simply would not be there. So what is actually going on? Speed matters, but it competes with a dozen other signals, and understanding that competition is the difference between chasing numbers that do not move the needle and fixing the things that do. Speed Is One Signal, Not the Signal Core Web Vitals matter. But they sit inside a ranking system with well over 200 signals, and Google has never pretended otherwise. Think of it like a job interview. Turning up on time is expected, but it doesn't get you hired on its own. A candidate with the right experience, strong references, and solid answers to hard questions will beat the punctual one with nothing else to offer. Google's algorithm works in much the same way. A slow site backed by years of editorial content, hundreds of quality backlinks, and a topic it owns outright can outrank a fast, technically clean rival whose pages are thin and freshly published. The ranking system is trying to answer one question above all others, which result helps this user most? Speed is part of the answer, but it's rarely the decisive part. Where page experience scores tend to swing things is in competitive searches where two pages are close on content quality and authority. At that point, the faster one often edges ahead. But if the content gap is wide, technical performance has very little leverage. A news site running on creaky infrastructure but breaking stories nobody else has will hold its rankings. A perfectly optimised five-page brochure site with no real depth behind it won't climb past established rivals just because it scores green on PageSpeed Insights. What Google Weighs Alongside Speed Google's ranking system is not a checklist where a slow LCP score automatically cancels out everything else a page has going for it. The algorithm weighs dozens of signals simultaneously, and some carry considerably more weight than Core Web Vitals in most competitive searches. Topical authority Topical authority is the clearest example. A site that has published thorough, well-sourced content on a subject for several years, attracted editorial backlinks from respected sources, and built a genuine pattern of user engagement will outrank a technically faster site that launched six months ago with a handful of thin pages. Google has invested heavily in understanding what a site is fundamentally about, and that depth of signal takes a long time to accumulate. A poor CLS score is a real mark against a page, but it sits alongside hundreds of other inputs, not above them. Backlinks Backlinks remain one of the strongest individual signals. A page with authoritative links pointing at it is telling Google something that pagespeed metrics simply cannot, that real editors considered this content worth referencing. No amount of performance optimisation replicates that. User engagement Engagement patterns matter too. If searchers consistently click through, read the content, and don't immediately bounce back to the results page, Google reads that as a quality signal. You can dig into how Google weighs these on-page factors in more detail, but the short version is that speed is one input in a system built to balance many. The Threshold Problem: Pass, Not Perfect Google's Core Web Vitals don't work like a leaderboard where the highest raw score wins. They work in bands. Each metric, Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift, sits inside one of three ranges: Good, Needs Improvement, or Poor. Once a page clears the Good threshold, there is no additional ranking credit for going faster. A site hitting LCP in 1.8 seconds and one hitting 2.4 seconds are, from Google's perspective, in the same band. That distinction matters a lot for how you read competitor rankings. A page in the Good range on all three metrics is treated as passing the test, not as having a score to beat. This is where slow-looking sites can still outrank faster ones. A rival might post a PageSpeed Insights score of 62 but clear every Core Web Vitals threshold in the field data, while your score of 88 reflects lab conditions that field data doesn't confirm. Google uses the field data behind PageSpeed Insights scores, not the lab number, for ranking signals, so the raw score headline can mislead you entirely. Chasing a perfect score is often the wrong goal. Get every metric into Good territory, then put your attention on content quality, authority, and structured data, because those factors keep pulling weight regardless of whether your LCP is 2.4 seconds or 1.2. When Speed Becomes the Deciding Factor Speed starts to matter most when everything else between two competing pages is effectively equal. Imagine two well-written articles targeting the same query, both sitting on authoritative domains, both with solid backlink profiles and relevant content. Google has to break the tie somehow, and Core Web Vitals give it a measurable, consistent signal to do exactly that. In those tightly contested positions, a page with a Largest Contentful Paint under 2.5 seconds and minimal layout shift can edge out an otherwise comparable page that takes four seconds to settle. The gap doesn't have to be dramatic. A few hundred milliseconds, consistently, across a crawl cycle, is often enough. Mobile search amplifies this considerably. When someone on a phone searches for something with clear immediate intent, a slow page doesn't just rank slightly worse. It loses the visitor before they even read the first line, and that bounce behaviour feeds back into how Google reads engagement. If you want to understand how that PageSpeed score translates into a real ranking signal, the relationship between measured performance and search position is tighter on mobile than most people assume. Speed rarely wins outright from a weak position. Where it tips an outcome is in that narrow band at the top, where content quality and authority have already converged. What a Slow-Ranking Competitor Actually Tells You A competitor sitting above you with a sluggish site is not proof that speed doesn't matter. It's a prompt to look harder. When a slow site outranks a faster one, something else is doing the heavy lifting. Nine times out of ten it's link equity built over years, a domain that's been trusted since the early days of the industry, or a deep catalogue of well-aged content that Google has had years to index and evaluate. Strip those advantages away and the speed problem would surface fast. That context matters because the temptation, when you spot a slow-ranking rival, is to conclude that the technical work isn't worth bothering with. That's the wrong read. What their position tells you is where to focus your energy next, not what you can afford to ignore. If their backlink profile and content depth are the real engine behind their ranking, that's your gap to close. Doing it on top of a fast, well-structured site puts you in a considerably stronger position than copying their neglect. Patience matters here. A site rebuilt properly takes time to gain ground, and anyone telling you otherwise isn't being straight with you. The Slow Erosion Nobody Notices Until It's Done A sudden ranking drop is easy to spot and, in some ways, easier to respond to. The more damaging pattern is the slow erosion that happens when a rival spends six months tightening both their content depth and their load times at the same time. You don't notice it as a single event. You notice it three months later when your click-through rate has drifted down a couple of percentage points and their pages are sitting just above yours on queries you used to own comfortably. Google doesn't announce that shift. It just reflects what users are doing, and users are spending longer on the faster, more thorough page instead of yours. That behaviour compounds. Return visit rates drop, average session depth drops, and those engagement signals feed back into how Google weighs the two pages against each other over the next crawl cycle. The user-side cost is where it gets measurable. A page that takes four or five seconds to load on mobile loses a significant share of visitors before they've read a single line, and those people rarely come back. If you're unsure where your site stands on this, the breakdown in what PageSpeed scores actually measure is a good place to start before drawing conclusions from the headline number alone. Speed alone won't rescue thin content. But slow speed plus thin content is a combination that chips away at positions you've spent real time building, and it does it quietly enough that most people don't catch it until the damage is already done. ------------------------------------------------------------ # WordPress Image Compression: What Actually Cuts File Size Source: https://yorkshiredesign.co.uk/wordpress-image-compression-what-actually-cuts-file-size/ Published: 2026-07-31 > A freshly uploaded JPEG can sit at 4MB and nobody bats an eyelid. The image looks fine in the media library, the page loads slowly, and the site owner wonders why their scores are poor. Image compression in WordPress is one of those areas where the settings exist, plugins promise the world, and yet most sites are still carrying far more weight than they should. What actually shifts the numbers is a shorter list than most guides admit. Why "compressed" does not always mean smaller Compression is not a single dial you turn up. There are two fundamentally different methods, and picking the wrong one for your image type can shave almost nothing off the file size. Lossless compression removes redundant data without touching the visible image, which sounds ideal until you consider how little redundant data a photograph holds. Run a high-resolution JPEG of a product shot through a lossless compressor and you might trim 3 to 5 percent off the file. That same image put through a well-tuned lossy process, which selectively discards fine detail the eye rarely notices, can drop 60 to 70 percent with no visible degradation at normal screen sizes. The method matters far more than the act of compressing. PNG files are the other common trap. They respond well to lossless tools because they carry a lot of flat colour and clean edge data, but throw a PNG compressor at a photographic PNG and the savings are meagre. Converting it to a JPEG or WebP first, then compressing, is where the real reduction happens. The assumption that any compression pass is doing meaningful work is what causes bloated media libraries. A plugin can report "image optimised" and deliver a file that is still 900 KB. Always check the actual byte count before and after, not just the percentage the tool claims. The format question comes before the compression setting Most people reach straight for the quality slider. Format choice does heavier lifting than any compression setting will. A JPEG exported at 80% quality is still a JPEG. Switch that same image to WebP and you typically get a smaller file at the same visual result, without touching the quality number at all. AVIF pushes that further still, often cutting file size noticeably compared to an equivalent WebP, though browser support means it works best as a progressive enhancement rather than a hard default. For photographs and anything with gradients or subtle tonal variation, WebP is the right call. PNG stays useful only where you need a transparent background and cannot accept any quality loss. AVIF is worth serving where your audience's browsers will reliably support it. Flat graphics, logos and icons are a different matter. Those suit SVG where possible, or a well-compressed PNG where SVG is not practical. Serving a photograph as a PNG because it was exported that way originally is one of the most common causes of bloated page weight. Once the format is right, compression settings become a fine-tuning exercise rather than the main event. Get the format wrong and no slider value will rescue the result. You can read more about the practical choices around file size, format and lazy loading if you want to go deeper on this. What WordPress plugins do to your images How the processing works When you upload a JPEG or PNG, a plugin like ShortPixel or Imagify sends that file to its own remote servers, processes it through compression algorithms, then returns a smaller version and overwrites the original (or keeps a backup, depending on your settings). What happens under the hood varies by mode. Lossy discards pixel data the eye struggles to notice, which gets file sizes down dramatically. Lossless strips metadata and redundant colour information without touching the visible image. Most sites use lossy for photographs and lossless for logos or flat graphics, and the better plugins let you set that per image type rather than applying one blanket rule. The thumbnail problem Where plugins stop short is thumbnail regeneration. WordPress creates multiple resized versions of every upload, and a plugin that only processes the full-size image leaves those smaller crops untouched. That matters more than most people realise because those thumbnails are often what loads on the page. A product grid, a blog index, a widget sidebar, all of these pull cropped versions, not the original. If you install a compression plugin after uploading hundreds of images, it will not automatically reprocess the old thumbnail sizes. You need to trigger a bulk regeneration, either through the plugin itself or a tool like Regenerate Thumbnails, otherwise a significant portion of your image file size savings stays on the table. The original file is the problem most plugins cannot fix Compression works on what you give it. Upload a photograph straight from a camera or a stock site and you are often looking at something 4000, 5000, even 6000 pixels wide. A plugin will squeeze the file, strip some colour data, maybe convert it to WebP, and hand it back noticeably smaller. That feels like progress. But if your content column is 800 pixels wide, the browser is still downloading an image more than five times the size it needs, then scaling it down on the fly. No amount of compression closes that gap entirely. A 400 KB version of a 5000px image is still a bloated file for a slot that a 90 KB, properly sized image would fill without complaint. The real savings come from resizing before compression, not after. Serving a correctly dimensioned source file and then compressing it is a fundamentally different outcome to compressing an oversized one and hoping for the best. Most plugins do offer some form of resizing, but the default settings often cap dimensions at figures that still leave plenty of unnecessary pixels in place. It pays to check what your plugin is doing, because what plugin defaults skip is almost always the source size rather than the compression level. Where lazy loading fits in Two different mechanisms Lazy loading and compression are not the same thing. People conflate them because both reduce what the browser downloads, but they operate at completely different points in the process. Compression shrinks the file itself. Lazy loading delays when the browser fetches it. If you have a 900 KB hero image sitting uncompressed at the top of the page, adding loading="lazy" to it fixes nothing for that first page load. The browser still pulls the full 900 KB the moment it renders. Where lazy loading earns its place is below the fold, deferring images the visitor may never scroll to at all. For a page with a dozen product shots or a long gallery, that deferral cuts the volume of data transferred on arrival. That matters for how search engines score your pages on performance signals and how quickly the page becomes usable. Never lazy load your LCP image The image you must never lazy load is your Largest Contentful Paint candidate, typically the hero image or the first prominent photo a visitor sees above the fold. Lazy loading that image actively damages your LCP score because the browser has to wait before it even begins fetching it. Compress that image hard, serve it in a modern format, and let it load immediately. Everything below the fold is fair game. Reading your results, not the plugin's promises Plugin dashboards are optimistic by design. A compression tool might report that it saved 68% on an image, but that figure often measures the reduction from an uncompressed original, not from what your server was already storing or what the browser downloads. The number looks impressive on a settings screen and means very little in practice. To get an honest picture, open Chrome DevTools, go to the Network tab, filter by "Img", reload the page without cache, and look at the Transfer Size column. That column shows exactly what the browser fetched. If a 400 KB image is still showing 380 KB there after "optimisation", the plugin has not done what it claimed. PageSpeed Insights gives you a second check. Load your URL, scroll to the "Serve images in next-gen formats" or "Efficiently encode images" diagnostics, and look at the potential savings listed per file. Google measures what it sees from the outside, which is the only measurement that matters for your rankings and load time. You can see this reflected in how technical SEO improvements tie directly to page performance scores rather than internal tool metrics. Cross-reference both sources. If DevTools and PageSpeed agree a file is still oversized, no plugin dashboard percentage will change that reality. ------------------------------------------------------------ # Google AI Overviews: What Actually Happens to Your Traffic Source: https://yorkshiredesign.co.uk/google-ai-overviews-what-actually-happens-to-your-traffic/ Published: 2026-07-31 > Plenty of site owners have noticed a dip in clicks without any obvious reason. Rankings look fine, impressions are holding, but the traffic just isn't arriving the way it used to. In many cases, Google's AI Overviews are sitting between the search result and the click. Understanding what that actually means, and which sites feel it most, is the clearest way to work out whether you need to change anything. What an AI Overview Is Google's AI Overviews are generated summaries that appear at the very top of certain search results pages, above the traditional blue links, above paid ads, and above featured snippets. Google builds them using its Gemini model, which reads and synthesises content from pages it has already crawled and indexed. It is not fetching live web pages at the moment you search. It draws on what it has already stored, weights sources it considers reliable for that query, and writes a condensed answer in its own words. The result sits inside a distinct grey box with a "Generated by AI" label and, usually, a small cluster of source attribution links tucked below the summary text. Those attribution links do show as clickable references, though they tend to appear smaller and less prominent than a standard organic result. The overview itself does not quote pages verbatim. It paraphrases and compresses, meaning a site can contribute to an overview without a single sentence from its content appearing word for word. They do not appear on every query. Google reserves them mainly for informational searches, questions that benefit from a synthesised answer rather than a direct visit to a specific page. Commercial searches, navigational queries, and anything where the user clearly needs to click through to complete a task tend to show standard results instead. Traffic Patterns to Watch Where clicks disappear The split broadly falls along intent lines. Informational queries, the kind where someone wants a quick definition, a how-to summary, or a straightforward fact, are where Overviews hit hardest. Google surfaces a synthesised answer at the top of the page, the user reads it and leaves, and your page never gets the visit even if you ranked first. Think of searches like "what is crawl budget" or "how does noindex work". The answer fits neatly into a few sentences, the Overview delivers it, and there is nothing left to pull the user further down the page. For sites built on high-volume, low-depth informational content, that can mean a noticeable drop in traffic without any change in rankings. Where Overviews send traffic your way The opposite happens with queries that carry commercial, comparative or nuanced intent. When someone searches for something like "best WordPress hosting for multiple sites", an Overview cannot settle the question on its own. It has to cite sources. Being one of those cited sources drives clicks that would not have arrived through a standard ten-blue-links result, because the Overview itself points directly to your page as a reference. Understanding how AI search tools handle citations differently helps you judge which type of content to prioritise. The practical question is which camp your content sits in. If it answers a closed question briefly, it is vulnerable. If it builds a case, compares options, or requires depth to be credible, it is a citation candidate. Absorbed vs. Cited Content The distinction matters more than most people realise. Definitions, factual summaries, and short explanatory passages tend to get absorbed straight into the Overview answer with no attribution at all. Google pulls the clearest version of a plain fact, paraphrases it, and the source disappears. If your page exists to define what a term means or summarise a well-known process in a few sentences, that content feeds the answer without sending a single visitor your way. Step-by-step how-to content sits in a grey area. A tightly structured guide with numbered steps can get partially absorbed, but if the process is involved enough, Google will sometimes cite the source because the full sequence adds value beyond what fits in a two-line summary. Product comparisons and opinion pieces behave differently. A comparison page with real specifics, genuine trade-offs, and a clear recommendation tends to earn a citation because Google cannot responsibly flatten that into a neutral overview. The same goes for first-person experience, strong editorial positions, and content that contradicts the obvious consensus. The pattern that emerges is that how AI Overviews affect your traffic depends almost entirely on the shape of your content, not its quality alone. Generic, evergreen explainers are the most at risk of being consumed without credit. Content with a clear point of view, real comparative detail, or a structured process deep enough to warrant its own page is far more likely to hold its ground as a named source. Reading Your Search Console Data Honestly Impressions vs. clicks The most useful thing you can do is pull your impressions alongside clicks over the same time window, then look at them separately. If impressions stay flat or grow while clicks fall, that pattern points squarely at something absorbing attention above your result, and AI Overviews are the obvious candidate for informational queries. If both impressions and clicks drop together, that is a ranking shift, not an Overview problem. Conflating the two is the most common mistake people make when they panic about a traffic dip. A site that drops from position three to position eight will lose clicks for an entirely different reason, and no amount of rewriting your content for AI will fix a link profile or a page authority issue. Breaking down by query type The query-type breakdown matters a lot here. Filter your Search Console queries by the ones triggering position-zero appearances, particularly question-format queries beginning with "how", "what" or "why". Those are the searches most likely to get an Overview generated above all organic results. Compare their click-through rate against transactional queries on the same site. You will almost always find the informational ones have suffered more. Understanding what AI Overviews actually do to individual query types helps you prioritise which pages to address first. Keep the two signals separate. Impressions versus clicks tells you about visibility absorption. Position movement tells you about ranking health. Mixing them produces the wrong diagnosis. How Different Site Types Are Affected Not every site takes the same hit. Where you land in that picture depends heavily on what your site does. Informational content sites feel the sharpest squeeze. If your traffic has always come from people asking questions, such as "how does X work" or "what is the difference between Y and Z", Google's AI Overview often answers that question before anyone clicks. The user gets a synthesised reply pulled from multiple sources, reads it, and moves on. Your page may well be cited in the sources panel, but citations don't pay the bills if click-through rates drop to near zero. Publishers built on ad revenue from high-volume how-to content are noticing this the most. It's also worth understanding how Bing's AI search is reshaping the same pattern, because both search engines are pulling in the same direction. Service-based businesses sit in a noticeably different position. Someone searching "emergency plumber near me" or "web designer for small business" is not looking for a synthesised answer, they want a person. Overviews rarely satisfy that intent, so the click still happens. Ecommerce sits somewhere between the two. Navigational queries like "buy blue running shoes size 9" tend to land on product listings rather than an Overview, but category-level research queries can get absorbed. If your pages exist to inform rather than to close, they are more exposed. If they exist to convert a buyer who already knows what they want, the risk is lower. Adjusting Your Content Without Chasing the Algorithm The sites that hold up well in an AI-heavy SERP tend to share one characteristic. They were already written for the reader, not for a ranking formula. Clear headings, direct answers near the top of each section, concrete examples that illustrate a point rather than pad a word count. None of that is new advice. What changes is that thin, hedged, vaguely-worded content has even less room to hide. If a page dances around an answer for four paragraphs before getting to it, Google's AI has no trouble extracting the eventual point and presenting it without ever sending the user your way. Structure has always mattered. It just has more immediate consequences now. One practical adjustment is checking whether your key answers appear close to the relevant heading. A buried answer, even a good one, is harder for any system to surface cleanly. If you want to understand how Google is evaluating and scoring your pages beyond content alone, that broader picture matters too. None of this requires a complete rethink. It requires honest editing. ------------------------------------------------------------ # WordPress Multisite vs Separate Sites: Which Works Better Source: https://yorkshiredesign.co.uk/wordpress-multisite-vs-separate-sites-which-works-better/ Published: 2026-07-30 > Most people assume Multisite is the obvious choice the moment they need more than one WordPress site. One dashboard, one set of plugins, one place to log in. It sounds tidy. But the architecture underneath is a different matter, and choosing it for the wrong reasons causes real headaches months down the line. This guide lays out what each approach actually involves, where each one earns its place, and the signals that tell you which way to go. What Multisite Is Under the Hood Most people think of Multisite as a way to manage several WordPress sites from one login. That part is true, but it only describes the surface. Underneath, every site in a Multisite network shares a single WordPress core installation, a single wp-content directory, and one database. That last point matters most. Rather than separate databases per site, Multisite creates a set of tables for each sub-site, prefixed to keep them apart, all sitting inside the same database instance. So a site at network.com/shop and a site at network.com/blog are not independent. They share the same WordPress files, the same plugin directory, and the same database connection. Plugins are installed once at the network level, and a super admin decides which sites can activate them. Individual site admins cannot install plugins of their own. That is a significant constraint people often discover after the fact, not before. The practical consequence is that a badly-behaved plugin, a database query gone wrong, or a PHP memory spike on one site can drag the entire network down with it. There is no real blast radius separation. If the database server slows under load from one high-traffic sub-site, every other site on the network feels it. Understanding that shared infrastructure is the thing to get straight before you commit, because unpicking a Multisite setup later is considerably more involved than setting one up. Where Separate Installs Win The clearest case for separate installs is when the sites have nothing in common. Unrelated clients, incompatible server requirements, update tolerances that pull in opposite directions. Running an agency that manages sites for ten unrelated businesses? A single Multisite network ties their fates together. One plugin update that breaks site three also breaks sites one through ten. With isolated installs, you patch them individually, on your own schedule, and a problem on one never touches the others. That independence is not a minor convenience. When a client rings on a Monday morning because their checkout page is down, the last thing you want is to discover the cause was an update you rolled out across a shared network the night before. SEO and domain authority SEO separation is another reason to stay isolated. Search engines treat subdomains and subdirectories, which are the two common Multisite structures, differently to root domains. If you need each site to build its own domain authority and internal linking structure independently, a separate install on its own domain gives you a cleaner start and fewer inherited signals to unpick later. Server requirements For sites with markedly different server needs, separate hosting also makes more sense. A high-traffic WooCommerce store and a small brochure site belong on different infrastructure, and Multisite makes that separation awkward at best. The Real Case for Multisite Multisite earns its complexity in a narrow set of situations, and they all share one thing, a single team controlling multiple sites that need to stay in sync. A regional news publisher running city editions is the clearest example. The masthead, the theme, the ad placements, the plugin set, all identical across every edition, with content differing by geography. Managing that as ten separate WordPress installs means ten sets of plugin updates, ten places where a theme tweak needs applying, ten chances for something to drift out of line. Under Multisite, one update propagates everywhere. That is not a convenience, it is a real operational saving. Franchise networks fit the same pattern. A brand with forty locations wants consistent design and controlled branding, but each franchisee needs their own content area. Multisite handles that cleanly from a single dashboard. School and university networks School networks are another case where the architecture pays off. A university managing faculty sites, or a multi-academy trust running individual school pages under one umbrella domain, often needs central IT to control core settings while letting department staff publish freely within defined boundaries. Multisite's user role model, where a network admin sits above individual site admins, maps to that organisational structure in a way that separate WordPress installs simply cannot replicate without significant custom tooling. The complexity is real, but so is the payoff when the use case is right. How the Two Options Compare on SEO The structural choice in Multisite has a direct bearing on how Google treats each site. A subdirectory setup (yournetwork.com/siteA, yournetwork.com/siteB) pools all authority under one root domain, which sounds appealing until you realise Google sees the whole network as one entity. Individual sites within the network struggle to build independent trust signals, and a penalty or crawl issue on one subdirectory can drag the others down with it. Subdomain configurations (siteA.yournetwork.com) give slightly more separation, but Google has historically been cautious about passing authority across subdomains, so you can end up with the worst of both worlds. A mapped domain on Multisite gets closer to true separation, but the shared codebase and server environment still create hidden dependencies that an independent install does not have. Separate installs sidestep all of this. Each site owns its crawl budget, its own robots.txt, its own XML sitemap, and its link equity flows without any ambiguity. If you need Google to treat five sites as five distinct businesses, that clean separation is hard to replicate inside Multisite. There is also the internal linking question. Getting site architecture and link structure right matters regardless of which route you take, but Multisite adds a layer of complexity that is easy to get wrong and notice late. Performance, Plugins, and Shared Risk Multisite's plugin table is its biggest structural weakness. Every site on the network shares the same set of installed plugins, and one bad update can bring all of them down at once. Picture a network of eight sites running the same caching plugin. A rushed update ships with a conflict, and before you have had a chance to test it on a staging environment, all eight sites throw a white screen. With separate installs you would update one, catch the problem, and roll it back before touching the others. That containment is genuinely valuable when you are managing sites for different clients or different business units that cannot afford any shared downtime. Caching adds another layer of complexity in Multisite, because object caching and page caching both need to account for subdomain or subdirectory routing, and getting that configuration right takes considerably more time than most people budget for. Some popular caching plugins handle Multisite adequately, but you are almost always working around limitations rather than with them. Separate installs carry their own overhead, particularly around hosting costs and keeping each WordPress core installation current. But the blast radius of any problem stays local. That alone is often enough to tip the decision for anyone running sites where reliability matters more than administrative convenience. Which Setup Should You Build? The honest answer comes down to four questions. Are the sites related, sharing a brand, a purpose, or a team? Will the same handful of people manage all of them? Do they need identical plugins and a consistent WordPress version across every property? And is your hosting capable of running a network without choking under combined traffic? If you answered yes to most of those, Multisite is a reasonable fit. One dashboard, one update cycle, one server bill. That makes sense when you are running, say, twelve regional versions of the same membership platform and a single developer is keeping the lights on. Where it falls apart is when each site has meaningfully different requirements, different owners, or different growth trajectories. Bolt a WooCommerce shop and a brochure site together in one network and you will spend more time managing plugin conflicts than you saved on admin. Separate installs give each property its own breathing room, its own staging environment, and the freedom to update on its own schedule without touching the others. The tradeoff is the overhead of maintaining them individually, which automation tools can reduce significantly once you have the right workflow in place. If you are still unsure after working through those questions, default to separate sites. You can always consolidate later. Migrating out of a Multisite network is a far messier job than going in the other direction. ------------------------------------------------------------ # How Long Does SEO Actually Take? The Honest Answer Source: https://yorkshiredesign.co.uk/how-long-does-seo-actually-take-the-honest-answer/ Published: 2026-07-30 > Ask ten people how long SEO takes and you'll get ten different answers. Most are either wildly optimistic or deliberately vague. The real answer depends on where your site is starting from, how competitive your market is, and how much of the foundational work has actually been done properly. This is a straight look at the timeline, what moves first, what takes longer, and why rushing any of it tends to set things back rather than forward. The Starting Point Changes Everything Before any timeline makes sense, you need to know where you're starting from. That baseline shapes everything that follows. A brand-new domain is the most straightforward case, even though it often feels the slowest. Google has no history with it, no links pointing to it, and no reason yet to trust it. That trust builds page by page, link by link, over months. A neglected old site is a different animal. The domain might have real age behind it, some backlinks, maybe even decent content buried under years of drift. There's something to work with, but it still needs a proper audit before you can judge how far back the clock has been wound. Thin pages, stale metadata, and a content strategy that stalled around five years ago all drag on recovery time. The third scenario, a technically broken site, is where things get unpredictable. Crawl errors, pages accidentally blocked in robots.txt, slow load times pushing Core Web Vitals into the red. Google can see a site like that and choose not to index large chunks of it. Fixing the technical layer first isn't optional. It's the only place to start. Generic SEO timelines ignore all of this. Quoting "six to twelve months" without knowing which of these three situations a site is in is like quoting a repair time without lifting the bonnet. The real answer always starts with a proper look at what's already there, because the technical condition of the site often determines the first three months of work before any content or links even come into the picture. What Typically Moves in the First Three Months The first three months rarely produce a flood of new enquiries, and that is fine. What you are doing in this period is clearing the path so Google can understand the site. Broken internal links, pages blocked from crawling by a misconfigured robots.txt, missing canonical tags on duplicate content, slow load times tanking Core Web Vitals scores. These are the things that suppress a site before a single keyword has even been targeted. Fix them, and you give everything that comes after a fighting chance. In practice, the earliest signals you tend to see are pages getting indexed faster, crawl errors dropping off in Google Search Console, and a small lift in impressions for terms the site was already ranking for but not quite reaching. That last one is easy to miss if you are only watching for position-one rankings. On-page groundwork fits into this window too. Title tags rewritten to reflect what someone is searching for, heading structures tidied up, thin pages either strengthened or consolidated. None of it is glamorous work, but it is the kind of attention that compounds. If you want to understand more about what this covers in practice, the technical side of WordPress SEO goes into the detail. Three months in, the honest expectation is better foundations, not a transformed rankings position. The signal-building takes longer than that. Why Months Three to Six Is the Real Test The first couple of months are mostly groundwork, fixing technical issues, tidying site structure, building out properly targeted content. Search engines notice the changes, but rankings barely shift. Month three is where things start moving, and also where patience tends to run out. How Google weighs new content Google is beginning to weigh the content you've published against the queries it might answer. That process takes time because authority is not assigned quickly. A page that goes live today might spend two or three months being crawled, compared against competing pages, and gradually positioned before it earns a consistent spot. What's happening underneath matters enormously here. Thin, poorly targeted content can unravel months of solid technical work. We've seen it with a local company whose site we originally built, where a later SEO provider published hundreds of badly aimed pages in a short period. Rankings for their main terms collapsed, and the site looked amateurish. The lesson is not to rush volume. Discipline over shortcuts The sites that come out of this middle stretch in a stronger position are the ones that published fewer, better pages and let them settle. Months three to six reward that discipline and punish the shortcut. When Do Rankings Stick? Six to twelve months is the window where sustained first-page positions tend to solidify for most competitive search terms, and the reason is compounding. Search authority does not accumulate in a straight line. A site that has been publishing well-structured, properly linked content for eight months carries considerably more weight than one that published the same volume in eight weeks. Google is watching patterns. How consistently the site earns links, how regularly it publishes, whether users stick around or bounce straight back to the results page. Each positive signal reinforces the last, which is why rankings that arrive in month seven tend to hold far better than an early spike that fades by week three. Picture a local solicitor's site that ranks on page two for a moderately competitive term at month four, then climbs to position five by month nine without any single dramatic change. No viral link, no press coverage. Just consistent on-page work and the slow accumulation of trust the algorithm responds to over time. That compounding effect is also why gaps in activity hurt disproportionately. Pause the work at month five and you often lose more ground than the pause would suggest. If you want to understand what sits underneath that authority curve, the detail on why SEO takes the time it does is worth reading alongside this. The Things That Make It Take Longer Some sites are slower to rank not because SEO doesn't work, but because there's a queue of problems to work through before any progress sticks. Technical and content problems A slow-loading site is one of the most common culprits. Google measures page experience as part of how it evaluates a site, and if your Core Web Vitals are failing, you're asking the algorithm to reward pages that it can see aren't serving users well. Thin content is another drag on timelines. A site with fifty pages that each say almost nothing gives Google very little to work with, and publishing one new post a month when a competitor is publishing four means you're covering less ground. You can read more about the technical fixes that tend to move rankings if you want to understand what clearing that groundwork involves. Link history and crawl frequency A history of spammy or low-quality links can set things back by months, because that kind of baggage has to be identified and addressed before clean work gains any real traction. Publishing infrequently compounds all of it. Search engines revisit sites based on how active they are. A site that barely changes gives crawlers less reason to come back often, which slows down how quickly any new or improved content gets noticed in the first place. What You Should Be Watching Rankings and clicks are the headline numbers, but they're also the slowest to move. In the weeks before a page climbs to a position worth celebrating, there are earlier signals that tell you whether the work is pointing in the right direction. Crawl coverage is one of them. If Google is finding and indexing your pages more thoroughly than it was a month ago, that's a meaningful sign the technical groundwork is solid. Impressions in Google Search Console tend to lift before clicks do, because a page can start appearing in search results it wasn't appearing in before, even at low positions. Watching that impression count grow over four to six weeks tells you Google is beginning to associate your content with the right queries. Time on page and bounce rate matter too. A page that ranks but loses visitors in eight seconds doesn't hold a position for long. That combination of crawl health, impressions, and engagement gives you a real read on progress before the rankings fully catch up. None of this means you need a spreadsheet for every metric going. Pick four or five that connect to what you're trying to achieve, and check them on a consistent cadence rather than daily. The metrics that move the needle are rarely the ones dashboard tools put front and centre. Patience here isn't passive. It's knowing what to look at while the bigger results build. ------------------------------------------------------------ # SEO for Service Businesses: Why It Works Differently to Ecommerce Source: https://yorkshiredesign.co.uk/seo-for-service-businesses-why-it-works-differently-to-ecommerce/ Published: 2026-07-30 > A plumber who ranks for 'emergency boiler repair' at 11pm on a Monday is worth ten times more than a kitchen retailer ranking for 'best cookware set'. The intent is urgent, the margin is high, and there is no basket to abandon. Service business SEO is a different game entirely, and treating it like ecommerce is where most people quietly go wrong from the first month. The Moment a Customer Decides to Call Someone's boiler stops working at 7am. They're not browsing, not comparing features, not reading reviews of twelve different options. They pick up the phone within minutes of the first search. That single moment is where almost all service business revenue is won or lost, and it behaves nothing like an ecommerce transaction. A product buyer might visit a site four or five times over two weeks before adding to a basket. A service buyer, especially one with an urgent need, makes a trust decision in seconds. They're scanning for signals that tell them the business is local, credible, and available right now. A phone number that's easy to find, a handful of genuine reviews, a page that loads fast on a phone with one thumb on it. If any of those signals are missing or buried, they're gone to the next result before the page has finished loading. That changes what SEO has to do. For an ecommerce site, the job is largely about getting product pages in front of people with buying intent and keeping them on the site long enough to convert. For a service business, the entire funnel collapses into one moment. There's no basket, no checkout flow, no email sequence to recover an abandoned session. SEO for service businesses has to earn trust before the click, and then the page has to close the gap in the first few seconds. Keywords That Signal Intent, Not Browsing Product keyword research is built around nouns. Someone types "blue running shoes size 9" and the intent is obvious, the search volume is measurable, and dozens of retailers compete for the same phrase. Service businesses work in a completely different register. The person who types "why does my boiler keep losing pressure" is not browsing, they are describing a problem they need someone to fix today. That problem-framed query might attract a few hundred searches a month rather than a few thousand, but the person behind it is already halfway to picking up the phone. High search volume is a vanity metric for services if the people searching are just curious rather than ready to act. Transactional intent in service searches tends to show up in specific phrases. "Emergency electrician not turning up" or "accountant for sole trader first year" are low-volume, highly specific, and they convert because they match exactly where the searcher is in their thinking. Trying to rank for "accountant" instead is a long, expensive fight against national directories and large firms, and the traffic you'd win is largely unqualified anyway. The smaller, more targeted phrases that move enquiries are the ones to build pages around. The phrase that brings ten visitors and five enquiries outperforms the phrase that brings five hundred visitors and none. What a Service Page Needs to Rank Clarity about what you actually offer The first thing a service page has to do is be unambiguous. Not a vague "we help businesses grow" line, but a plain description of the specific service, who it suits, and what the outcome looks like. Google reads that clarity as a relevance signal. A plumber's page titled "Boiler Repair in Manchester" with a proper description of the work, the types of boilers covered, and a rough idea of response times will consistently outperform a generic "our services" page that tries to cover everything at once. Location context matters here too, not just in the title tag but woven naturally into the copy, so the page reads as written for a real place rather than bolted on for rankings. Trust markers most pages skip Accreditations, trade body memberships, a handful of specific testimonials that mention the actual job done, and any named guarantees all contribute. These aren't decorative. They reduce the friction a visitor feels before picking up the phone. Once those signals are in place, the page needs a single, clear call to action, not three competing buttons pointing in different directions. One ask, stated plainly, repeated in a logical spot near the top and again at the bottom. If you want to see how this connects to the broader discipline of building pages that convert and rank, the thinking behind a structured SEO process applies directly to how individual service pages are built and ordered. Why Content Strategy Looks Different for Services A product business fills pages with specs, sizes, and category filters. A service business has none of that to work with, which sounds like a disadvantage until you realise it forces a smarter approach. The content that builds ranking power for a service business comes from answering the questions customers are typing into Google before they pick up the phone. A plumber writing about why boiler pressure drops overnight, a solicitor explaining what happens if you miss a court deadline, a landscaper walking through the real cost of a garden redesign. These pages earn trust and topical authority in ways that a product listing never could. Google reads that body of content and starts to understand that this site covers the subject properly, not just the service name. That breadth takes time to accumulate. Each piece of well-considered content adds a small amount of weight to the overall picture, and the effect compounds across months rather than weeks. Service content also tends to attract readers who are close to making a decision. Someone searching "how much does a loft conversion cost" is not idly browsing. Getting that kind of content right is where service SEO does its most effective work. Local SEO and the Service Area Problem Ranking in multiple towns without a physical address in any of them is one of the harder problems in local SEO. Why thin location pages backfire The temptation is to build a page for every location you cover, stuff it with the town name, swap a few words, and hope Google treats each one as a genuine local result. It rarely does. What Google sees is a cluster of near-identical pages with no real substance behind them, and thin doorway pages like that tend to drag a site's overall quality signal down rather than lift individual rankings. A plumber covering twelve towns does not need twelve pages saying "emergency plumber in " with the same three paragraphs rearranged. One well-built page that honestly describes the service area, paired with a strong Google Business Profile, will outperform that stack every time. For a fuller breakdown of which local signals shift the needle, the piece on what moves rankings for small local businesses is worth reading alongside this. When location pages do make sense Build them when each one can carry something real, a specific project in that area, a local landmark reference, or genuinely different service detail. Without that substance, you're creating crawl overhead and diluting the pages that do have weight behind them. Metrics That Tell You If It's Working Traffic numbers can feel reassuring, but for a service business they tell you very little on their own. A site pulling 800 visits a month with a strong contact form conversion rate will generate more actual work than one pulling 5,000 visits from people who were never going to pick up the phone. The figures to watch are tied to real enquiry activity, form submissions, click-to-call events, calls tracked through a forwarding number, and the pages people visit immediately before they contact you. A modest but well-targeted site, built around the right search intent and a clear service area, can outperform a far busier one because every visitor arriving has a genuine reason to be there. Click-to-call rate is one that often gets ignored. On mobile, it is one of the clearest signals you have that someone is ready to act. If that number is low, the problem is usually a buried phone number or a page that hasn't earned enough trust by the time someone scrolls to it. For a fuller picture of which SEO signals connect to real revenue and which are just noise, rankings and traffic are a starting point. Enquiries are the result. ------------------------------------------------------------ # WordPress vs Headless CMS: What Growing Businesses Miss Source: https://yorkshiredesign.co.uk/wordpress-vs-headless-cms-what-growing-businesses-miss/ Published: 2026-07-30 > Headless CMS has become the answer a certain type of developer reaches for the moment a WordPress site shows any strain. The pitch sounds clean, decouple the back end, serve content anywhere, hit better performance scores. But the gap between what headless promises and what a growing business actually needs is wider than most people expect before they commit to the switch. What 'headless' means in practice Strip away the conference-talk framing and the concept is straightforward. A headless CMS stores and manages your content, but has no opinion about how that content gets displayed. The "head" (the front-end that renders pages in a browser) is removed and rebuilt separately, usually with a JavaScript framework like Next.js or Nuxt. In a traditional WordPress setup, the two halves are coupled together. WordPress handles your content, your templates, your menus, your theme, and the actual HTML that a visitor's browser receives. Everything lives in one place, which is why a non-technical editor can log in, make a change, and see it live within seconds. A headless setup splits that into two distinct systems talking to each other over an API. Your content sits in one place. A separate application fetches it and decides how to render it. That separation gives developers real flexibility, particularly when you need the same content to appear across a website, a mobile app, and a digital signage screen at the same time. That is a genuine architectural advantage in that specific scenario. What it is not is a universal upgrade. For most growing businesses publishing pages, blog posts, and product listings, the coupled architecture of WordPress is not a limitation. It is a different set of trade-offs, ones that become clearer once you know what you are comparing. Where WordPress still holds its ground For most growing businesses, WordPress is not the bottleneck. It is a mature platform with over two decades of active development behind it, a plugin ecosystem that covers almost every requirement out of the box, and a contributor base large enough that real security issues get patched fast. A business that needs a new landing page, a contact form, a booking widget, or a membership area can usually have it running the same week, without touching a line of code. The content editing experience is familiar enough that a non-technical team member can publish and update pages without any training overhead, which matters enormously when the person doing the work is also running the business. Pair it with a solid hosting setup and proper caching, and you have a stack that handles a serious volume of traffic without costing a fortune. The real strength is the support layer around it. Themes, plugins, developers, documentation, community forums. If you hit a problem, someone has already solved it and written about it publicly. Where WordPress does struggle is at genuine architectural scale, very high-frequency content updates, tightly controlled multi-channel publishing, or teams working across several front-ends at once. Those are real situations. But they apply to a small fraction of the businesses that think they need to escape WordPress to grow. The real cost of going headless Build cost and developer dependency The pricing conversation around headless CMS tends to focus on the platform itself, and that is where businesses get caught out. The platform fee is often the smallest part. What comes alongside it is a front-end build from scratch, a developer (or a team) who knows the specific framework being used, and a deployment pipeline that someone has to own and maintain. A mid-sized business moving from WordPress to a headless setup can expect months of build time before a single page goes live, and that clock is running at developer day-rate the whole time. If the original developer leaves, that knowledge walks out with them. What editors lose Content editors feel it too. The clean, familiar interface disappears. What replaces it is often a structured content model that made sense to the developer who built it, not the person writing Tuesday's blog post. Ongoing maintenance The longer-term overhead is where the real surprise lands. With WordPress, the hosting and maintenance ecosystem is mature, competitive, and broadly understood. With a headless setup, every layer, the API, the front-end host, the build process, the CDN configuration, is something a developer has to tend. There is no off-the-shelf answer when something breaks at 11pm on a Friday. That dependency is the cost that never appears on the initial proposal. Which sites headless suits Headless earns its complexity in a fairly narrow set of circumstances. The clearest case is a business publishing the same content across genuinely different surfaces at once. A main website, a mobile app, and an in-store kiosk all pulling from a single content API. A second strong fit is high-traffic editorial or e-commerce at serious scale, where a React or Next.js front-end can be statically generated and served from a CDN, shaving response times that a traditional server-rendered CMS would struggle to match. Development teams already working in JavaScript frameworks day-to-day will feel far less friction here than a company hiring its first developer and expecting them to navigate the whole stack alone. If your roadmap includes multi-channel delivery or a custom checkout experience that outgrows any off-the-shelf plugin, headless is worth the overhead. Knowing how each architecture scales under pressure makes that decision considerably easier. Outside those scenarios, most growing businesses are not quite there yet. A regional services company with a contact form, a blog, and a handful of landing pages does not have a multi-channel content problem. Neither does a growing e-commerce store on WooCommerce with a few hundred products. The complexity headless introduces, separate deployments, API maintenance, content preview quirks, serves those businesses poorly and adds cost without a matching return. What the SEO picture looks like for each Where headless looks good on paper Core Web Vitals scores are where headless builds look most tempting. Strip a site of its plugin stack, serve pre-rendered HTML from a CDN, and the Lighthouse numbers can look impressive. Raw performance scores, though, are only part of what determines how a site ranks. The SEO gap nobody budgets for A headless setup hands the content team a problem almost immediately. Every piece of metadata, every structured data block, every canonical tag has to be wired up manually through whatever framework is running the front-end. There is no Yoast panel, no default sitemap generation, no automatic Open Graph fallback. Teams that underestimate this tend to ship fast pages with thin or broken SEO output underneath, and Google notices before anyone on the project does. WordPress, done properly, rarely has that gap. The SEO tooling is baked in, the schema plugins are mature, and the image handling settings that affect both page speed and crawl efficiency have been refined over years of real-world use. WordPress SEO problems and how fixable they are Where WordPress creates technical SEO problems is almost always at the plugin layer. Duplicate meta output, conflicting sitemaps, bloated scripts slowing Time to First Byte. Those are fixable issues, not structural ones. A headless CMS introduces complexity that lives in the architecture itself, which makes it harder to audit, harder to hand off, and harder to recover when something quietly breaks in production. How to decide without overcomplicating it Start with your team, not your ambitions. If the people updating your site are marketers or business owners rather than developers, WordPress is almost certainly the right call. The block editor is approachable, the plugin ecosystem covers most content requirements, and you can get a well-built, fast site without putting a developer on standby every time someone needs to change a headline. A headless setup shifts that dependency permanently onto your technical team. If that team is thin or non-existent, you will feel it on every small update. Budget matters here too. A headless architecture with a separate front-end framework, a hosting layer for each environment, and the developer hours to wire it all together typically costs two to four times more to build and maintain than a comparable WordPress site. That gap is hard to justify unless your content is being published to multiple platforms simultaneously, like a website, an app, and an in-store display all pulling from the same source. Growth trajectory is where people tie themselves in knots. The fear that WordPress will not scale tends to arrive before there is any real evidence it is struggling. Sites serving millions of monthly visits run on well-configured WordPress hosting without architectural surgery. If you are on the fence, start with WordPress. You can always migrate specific parts of the stack later once you have a concrete reason to, and a concrete budget to match. ------------------------------------------------------------ # Schema Markup Without the Headache: What It Does and Why It Matters Source: https://yorkshiredesign.co.uk/schema-markup-without-the-headache-what-it-does-and-why-it-matters/ Published: 2026-07-30 > Picture two identical shops on the same street. One has a clear sign, opening hours on the door, and a menu in the window. The other has nothing. Search engines face that same problem every day. Schema markup is how you put the sign up. It tells Google precisely what your page contains, in a language machines actually understand, without you needing to know a single line of code to grasp why it matters. What Schema Markup Is Think about a recipe page. You see a headline, a list of ingredients, a cooking time, and a star rating left by someone who made it last Tuesday. You know exactly what each of those things is because your brain has years of context to draw on. A search engine crawling that same page sees text and HTML tags. It can make reasonable assumptions, but it is guessing that "45 minutes" refers to cooking time rather than, say, the author's age. Schema markup puts an end to the guesswork. It is a set of invisible labels, written in a standardised vocabulary called Schema.org, that sit inside the page's code and tell the search engine precisely what each piece of information means. Not "here is some text that might be a duration", but "this is the cooking time, and it is 45 minutes". The labels never appear on screen. A visitor reads the page exactly as you designed it. The markup works underneath, purely for machines, closing the gap between what a page says and what a search engine can confidently confirm it means. Why Google Cares About It Search engines process hundreds of millions of pages every day without a single person reading them. Everything Google knows about your page comes from automated crawlers that parse text, follow links, and make educated guesses about what the content means. The word "Mercury" on a page could mean a planet, a car brand, a chemical element, or a Roman god. Without additional context, Google picks the most probable interpretation and hopes for the best. Schema markup removes that guesswork entirely. You are telling the crawler, in a structured format it was built to read, exactly what each piece of information represents. A number next to a pound sign becomes a confirmed product price. A string of digits becomes an event date. Five stars become a verified review score tied to a specific business or product. That precision is what powers rich results. When you see star ratings, FAQ dropdowns, recipe cook times, or event details appearing directly inside search listings, schema is almost always the reason. A proper technical audit will often flag missing schema as a quick win, because those enriched listings stand out on a results page crowded with plain blue links. Google does not guarantee a rich result just because the markup is there. But without it, you are not even in the running. What a Rich Result Looks Like Picture two listings sitting side by side in a search results page. The first is a plain blue link with a grey URL underneath and maybe a two-line description pulled from the page. The second shows five gold stars, 143 reviews, a price range, and opening hours, all before anyone has clicked a single thing. Both sites could be selling the same product at the same price with the same quality of service. The difference in how they appear comes down entirely to whether one of them has schema markup in place. The click-through rate gap between a plain link and a rich result is not small. Google's own research has shown that rich results meaningfully outperform standard listings, and if you think about it from a user's perspective, that is hardly surprising. Someone searching for a local restaurant or a trades service is going to click the result that already answers their questions, not the one that makes them guess. A star rating signals trust. A review count signals popularity. Visible opening hours remove a reason to hesitate. None of that information lives in the title tag or the meta description. It only appears in the search listing when structured data tells Google it is there, in a format Google can read without ambiguity. Understanding which schema properties move the needle is where the real work begins. The Main Schema Types The ones most sites need Most websites only need a handful of schema types, and understanding what each one tells Google makes choosing between them straightforward. LocalBusiness schema is the obvious starting point for any physical or service-area business. It passes your address, phone number, opening hours, and business category directly to Google in a format it can read and verify. Article schema works alongside blog posts and news content, helping Google understand the publish date, the author, and the headline, which can improve how a post appears in search results over time. For most small business sites, LocalBusiness plus Article covers the majority of the ground. The ones that need more care FAQ schema can pull question-and-answer pairs directly into the search result, giving your listing more visual space. But it is also the type that gets misused most often. Adding it to a page where the questions feel manufactured just to trigger a rich result misses the point, and Google's own structured data guidance is clear that the content should represent real questions a user would ask. You can layer FAQ in as the content warrants it, not before. Product schema applies to anything you are selling, letting you surface price, availability, and condition directly in search. Review schema, or more precisely ReviewAggregator, lets you show star ratings in results, though it only applies when the reviews are collected on your own site rather than pulled from a third-party platform. How Schema Gets Added to a Site Schema is a small block of structured code, usually written in a format called JSON-LD, that sits inside a page's HTML without touching anything the visitor sees. On WordPress, you rarely need to write a single line of it yourself. A plugin handles the whole thing, reading your page content and generating the correct markup automatically behind the scenes. Plugins like Yoast SEO or Rank Math do a reasonable job for most standard types, covering articles, local businesses, products, and FAQ sections. You configure the details through a settings panel, the plugin writes the code, and it gets dropped into the page head where search engines can find it. For anyone who has spent time improving WordPress without editing template files, this will feel like familiar territory. Where it goes wrong is when the schema says one thing and the page says another. If your markup claims a five-star rating but there are no visible reviews on the page, Google will ignore it or, worse, discount your site's credibility across the board. The same applies to opening hours, prices, and addresses. Schema that contradicts the actual content is not a minor formatting issue. It signals to search engines that something is off, and that is a harder problem to fix than having no schema at all. What to Skip and What to Test Where schema goes wrong Not every schema type is worth your time, and adding the wrong one can create more problems than having none at all. Product schema works well on a page that shows a clear price, availability status, and a genuine way to buy. Add it to a service page or a catalogue listing with no price, and Google's guidelines flag it as incomplete, which can suppress a rich result rather than trigger one. The same trap catches a lot of sites with FAQ schema. The questions need to appear visibly on the page itself, not just exist in hidden markup. If a visitor cannot read the question by scrolling down, the schema does not belong there, and Google is increasingly good at spotting the mismatch. Stacking FAQ markup onto a page with two throwaway questions buried at the bottom is unlikely to earn a featured snippet and may earn a manual review instead. Event schema without real dates, Review schema on a page with no reviews, and Breadcrumb markup that does not match your site's real navigation all fall into the same category. Technically valid, practically useless. How to check your work The fastest way to check whether any markup is doing what you expect is Google's Rich Results Test. Paste the URL in and it tells you which rich results your page qualifies for and flags anything broken. Run it before and after any schema change, and you will know immediately whether the work has landed. ------------------------------------------------------------ # Five Things Clients Get Wrong About SEO Timelines Source: https://yorkshiredesign.co.uk/five-things-clients-get-wrong-about-seo-timelines/ Published: 2026-07-30 > Ask almost anyone who has hired someone to do their SEO why they cancelled after three months, and the answer is usually some version of 'nothing happened.' That frustration is understandable. It is also, nine times out of ten, rooted in a mismatch between what SEO actually does and how fast people expect to see it. These five misconceptions come up constantly, and clearing them up early saves a lot of grief on both sides. Ranking on Page One Is Not the Starting Line Most people picture SEO as a race to the top of Google. The trouble is, that race cannot even begin until Google knows your site exists and understands what it is saying. Before any ranking signal counts, Google's crawler needs to find your pages, read them cleanly, and add them to its index. That process is not instant. For a newer site, or one that has been patched together over the years with orphaned pages, blocked URLs, or thin content, it can take several weeks before the index even reflects the current state of the site. Think of it the way a good builder approaches a renovation. You do not pick up a paintbrush on day one. You check the floor joists first, look at what is holding the structure up, and make sure nothing is wrong underneath before touching the surface. Skipping that stage does not save time. It just means the problems surface later, when they are harder to unpick. A thorough technical audit at the outset catches exactly these issues, things like crawl errors, duplicate content, and missing canonical tags, before they stall progress for months. Fixing them is unglamorous, and clients rarely see it happening, but it is the groundwork that makes everything else stick. Why Month One Looks Like Nothing Is Happening The first four to eight weeks of an SEO engagement are where most of the foundational work lands, and almost none of it shows up in rankings. The technical backlog A technical audit comes first. That means crawling the site to find broken internal links, duplicate content, missing canonical tags, pages blocked from indexing that should not be, and redirect chains that waste crawl budget. On a WordPress site of any real age, there is usually a backlog of these issues that has built up over years of plugin updates and content changes. Fixing them does not move a ranking needle overnight. What it does is stop Google from actively discounting the site, which matters far more in the long run than chasing a quick position change. Mapping the content gaps Identifying which pages are thinly written, which search intents are completely unaddressed, and where the site's structure is fighting itself is not a half-hour job. A thorough technical SEO audit across an established site can take the better part of a week before a single change is made. The complaint that "nothing has changed" at week four is understandable, but it mistakes visible output for real progress. The work is real. It just lives under the surface for a while. Search Engines Need Time to Process Changes Fixing a technical issue on your website does not mean Google sees it straight away. Crawlers visit pages on their own schedule, and for most sites that schedule is irregular. A page on a small or mid-sized site might get recrawled every few days, or it might sit untouched for two to three weeks. The delay is not a fault in the system. It is how crawling and indexing work at scale, and it catches a lot of people off guard when they expect a fix to show results within hours of going live. Not all changes move at the same speed The type of change you make affects how long that delay feels. New content needs to be discovered, crawled, and then indexed before it can rank for anything at all. A redirect chain you have just cleaned up still needs Google to revisit every URL in that chain to register the change. A structural overhaul, such as reorganising your site navigation or flattening a deep folder hierarchy, can take even longer because it touches multiple signals at once. Each of these has its own re-indexing timeline, and they do not run in parallel just because you made all the changes on the same afternoon. The technical groundwork that precedes link building covers a lot of this territory in more depth. Patience here is not passive. It is the only realistic option. Competition Is the Variable Nobody Accounts For SEO timelines do not exist in a vacuum. When a site has spent five or six years building out detailed content, earning links from respected sources, and accumulating genuine user engagement signals, that history does not evaporate because a newer competitor starts doing the right things. The sites already ranking at the top have a head start measured in years, and the gap between them and a fresh campaign is not closed by effort alone. A thorough technical overhaul, well-researched content, and a clean link profile all matter, but they work against a backdrop that includes every established player in the space. If you are entering a competitive market where the top three results have domain histories stretching back a decade, your technical groundwork is the price of entry, not the finishing line. The realistic pace is set by the competition, not by how hard anyone works on your side. A niche with weak, thin, rarely updated sites at the top can shift in a few months. One dominated by authoritative publishers with thousands of indexed pages and years of consistent output will not. Understanding who you are up against before setting any expectation is the part most people skip entirely. It should be the first conversation, not an afterthought once timelines get pushed. Quick Wins Are Real, But They Are Not the Whole Story Some improvements do show up early. Fix a crawl error that was blocking a key page and Google can re-index it within days. Publish a piece of content that fills a clear gap in your niche and you might see a ranking within a few weeks. Those are real signals, and they matter. The danger is treating them as proof the work is finished. What tends to happen is this. A client sees a jump in impressions or a handful of new page-one positions, feels the momentum, and decides the budget could be better spent elsewhere. A few months later, rankings drift back down because the underlying work, the technical groundwork, the internal structure, the content depth, was never fully bedded in. The quick win was real, but it was a foundation stone, not the whole building. Early results and long-term rankings are connected, but they operate on different timescales. One good month tells you the direction is right. It does not tell you the job is done. Stopping at that point is a bit like pulling scaffolding down because the first floor looks solid, before the upper floors have been built at all. What a Realistic SEO Timeline Actually Looks Like Months one and two This is mostly groundwork. Google needs to crawl and index the changes, your content needs time to settle, and if there are technical problems to sort out first, that work has to happen before rankings can shift in any meaningful way. What you are watching for at this stage is not positions but signals, pages getting indexed, crawl errors disappearing, Core Web Vitals scores stabilising. A thorough technical audit done early can shorten this phase considerably, because you are not spending month three fixing things that should have been caught at the start. Months three to five This is where genuine momentum tends to build. You will start to see impressions climbing in Search Console before rankings fully reflect that, which is a healthy sign. Pages that were sitting on page two begin nudging upward. This is also when the quality of the site's underlying structure starts to matter. A clean, well-organised site with logical internal linking tends to move faster here than one carrying years of accumulated technical debt, orphaned pages, or bloated plugins that slow every response down. Month six onward Results become readable as a trend rather than noise. The compounding effect of the earlier structural and content work starts to show in ways you can actually point to. Patience at the earlier stages is what makes this phase feel worthwhile. ------------------------------------------------------------ # AI Writing Tools Reviewed: What They Get Right and Where They Fail Source: https://yorkshiredesign.co.uk/ai-writing-tools-reviewed-what-they-get-right-and-where-they-fail/ Published: 2026-07-30 > Roughly a third of marketers now use AI tools to produce written content, yet the complaints from editors and site owners sound remarkably consistent, the output reads fine until you look closely, and then it doesn't. That gap between 'looks plausible' and 'actually useful' is where the real differences between tools show up. This is a plain comparison of what the leading options do well, where they cut corners, and which type of work each one is actually suited to. What These Tools Do Under the Hood Every AI writing tool on the market, regardless of the branding or the pricing tier, is built on the same basic idea. They predict the next word. That sounds reductive, but it matters for how you judge them. These tools are large language models trained on enormous amounts of text. When you type a prompt, the model produces a statistically likely continuation of that input based on patterns it saw during training. It has no understanding of your business, your audience, or whether the claim it just wrote is accurate. It does not fact-check. It does not hold an opinion. What it does, often impressively, is produce fluent-sounding prose at speed. Tools like ChatGPT, Claude, Gemini, Jasper and similar products all sit on this same foundation, even if the underlying model, the fine-tuning, and the surrounding interface differ. Some are better at following a detailed brief. Some handle long-form structure more cleanly. Some stay on topic without drifting. Those differences are examined below. The honest starting point is this, judging any of these tools on whether they write like a human misses the point. The right question is whether they produce content you can use after editing, fact-checking, and applying your own judgement to every claim they make. ChatGPT for Content Writing ChatGPT is fast, and that speed is its biggest selling point. Feed it a brief and it returns a coherent structure in seconds, which is useful when you need to map out a long article or work through a content angle you haven't fully formed yet. It handles tone shifts reasonably well, can write in first person or third, formal or conversational, and rarely produces something completely unusable as a first draft. For service pages, outlines, and brainstorming session notes, it earns its place. The problem surfaces the moment you need specifics. Ask it about, say, Google's crawl budget behaviour on a large e-commerce site, and it will produce something that reads confident and well-organised but skips past the detail that would make the content useful. That confident vagueness is the pattern to watch for. It will also repeat itself across a long piece, circling the same point in slightly different wording without adding anything, which tends to go unnoticed until you read the draft back at pace. It suits early-stage drafting and ideation far better than it suits finished copy. Anyone publishing AI-generated content directly to their site without a proper edit pass will likely end up with pages that feel thin, even if they look structured at a glance. Use it to move fast on structure. Then treat everything it produces as raw material, not a finished article. Claude and Long-Form Writing Where it outperforms the competition Claude handles extended writing tasks better than most tools in this space. Give it a 1,500-word article with a specific structure and a clear argument to build, and it generally holds the thread from start to finish without losing the tone or repeating itself. That consistency over long passages is something GPT-4 and Gemini both struggle with more noticeably. Claude also tends to produce writing that sounds less like a template, which matters when you are trying to make content that feels like it came from a person who actually knows the subject. For anything that needs sustained reasoning, a considered point of view, or a consistent register across multiple sections, it is probably the strongest of the current generation of tools. Where it falls down The problem shows up the moment your brief gets specific. If you ask Claude to write in a particular format, stick to a fixed word count, or mirror a defined house style, it has a habit of deciding it knows better. Not dramatically, but enough that you spend time re-prompting. You might ask for four short paragraphs and get two long ones that cover the same ground differently. You might specify a plain, direct tone and get something a shade too polished. For anyone producing SEO content that needs to hit structural requirements precisely, that drift adds editing time. Claude earns its place on longer, less prescriptive work. For tight briefs with exact parameters, build in time to push back. Jasper, Copy.ai and the Specialised Marketing Tools The template advantage Tools like Jasper and Copy.ai are built around templates, and that structure is precisely what makes them useful for a specific kind of task. A non-writer who needs a Facebook ad headline, a product description, or a cold email opener can drop their inputs into a template and get something usable in under a minute. The format does a lot of the heavy lifting. It keeps the output short, purposeful, and aimed at a clear commercial goal. For someone who goes blank in front of a cursor, that scaffolding is helpful, and the quality of short-form copy from these tools has improved considerably as the underlying models have matured. The ceiling Push beyond that short-form comfort zone and things fall apart quickly. Ask Jasper to write a 1,500-word article on a technical subject and the template structure starts to crack. The tool produces something that looks like an article but reads like five disconnected ad prompts stitched together. There is no argument being built, no evidence, no real point of view. As the section on AI content writing for SEO covers in more depth, that kind of thin, assembled text tends to underperform in search regardless of how polished it looks on the surface. These tools earn their place for short, repeatable copy tasks. They were never designed to replace a writer who thinks. Where Every AI Tool Fails on SEO Content Factual drift Every AI writing tool shares the same blind spot. It generates text that sounds credible without knowing whether it is. Ask an AI to write about a technical subject and it will produce confident, fluent sentences that are sometimes wrong in the details that matter most. For SEO content, that creates a specific trap. Google's quality systems have grown good at identifying pages that sit on the surface of a topic without ever going deeper. A 1,200-word article that covers the same five obvious sub-points as the other ten pages ranking for that term is not going to move anything. AI tools are structurally biased toward that kind of surface-level output because they are trained to produce statistically normal text, and statistically normal text on any given subject tends to look exactly like everything else written on it. Generic phrasing at scale The same filler phrases, the same transitional sentences, the same conclusion structure appear across thousands of AI-generated pages. Sites publishing AI content at scale often end up with a thin-content problem before they have noticed it. Each individual page might reach the minimum word count, but when Google crawls the whole domain and sees hundreds of pages sharing the same shallow treatment of related topics, the signal it reads is a low-quality site, not a productive one. Publishing faster does not fix that. It accelerates it. How to Pick the Right Tool for the Job Matching task to tool For ideation and brainstorming, ChatGPT or Claude are hard to beat. They will generate a dozen angles on a topic in seconds, and that is useful when you are staring at a blank brief. For research summaries, Perplexity is worth reaching for because it pulls from live sources and cites them, which at least gives you a thread to pull on and verify yourself. First drafts of long-form content are where tools like Jasper or ChatGPT with a good system prompt can compress the grunt work, though what comes back almost always needs a proper structural edit before it resembles something a real person would read. Short-form copy, ad headlines or meta descriptions, is where AI performs most consistently. The output is short enough to sense-check in seconds and the format is constrained enough that the model does not drift. Where a human has to be in the loop Anywhere a claim matters, human editing is non-negotiable. AI tools will confidently state things that are wrong, and a quick read-through will not always catch it. If your content involves pricing, specifications, or any kind of professional advice, a person needs to check every sentence against reality. For a sharper look at where these tools start to undermine the content they are supposed to help with, the breakdown on how AI writing tools can damage content quality is a good companion read. ------------------------------------------------------------ # How Many WordPress Plugins Are Too Many (And How to Tell) Source: https://yorkshiredesign.co.uk/how-many-wordpress-plugins-are-too-many-and-how-to-tell/ Published: 2026-07-29 > There is no magic number. Thirty plugins on a tight, well-coded site can run faster and cleaner than ten poorly chosen ones on another. The question was never the count, it was always the quality of what you are running and whether each plugin is actually earning its place. This checklist walks through exactly how to tell the difference, so you can make that call with confidence rather than guesswork. Start With a Full Inventory Pull up the plugins screen before you do anything else. Count everything, active or not. Most people guess at what they have installed, and that guess is almost always wrong. Inactive plugins sit in your file system just as their active counterparts do, taking up server space and ageing without updates. A plugin you deactivated two years ago and forgot about can carry PHP functions with known security holes that nobody has patched, because nobody thought to check. The plugin screen won't flash a warning. Nothing will. You'll only find out when something goes wrong. Work through the full list methodically. Note what each one does, and be honest about whether that function is still needed. A contact form plugin from a page you deleted six months ago has no business being there, active or not. A plain text document or a spreadsheet is fine for this. Name, status, what it does, when it was last updated. That last column matters more than people expect. A plugin that hasn't seen an update in eighteen months is a question mark, not an asset. Ask One Question Per Plugin The fastest way through a bloated plugin list is to stop asking "do I need this?" and start asking "what breaks if I turn this off?" It sounds like a small shift, but it changes everything. The first question invites vagueness. You can always convince yourself something might be useful one day. The second question demands a concrete answer. Either something breaks or it doesn't. Deactivate the plugin on a staging copy or in a low-traffic window, then click through the pages most likely to depend on it. Check forms, checkout flows, any custom shortcodes, and the front-end layout. If nothing looks wrong after five minutes of honest testing, that plugin is not pulling its weight. Where this gets interesting is with plugins that seem invisible until something downstream breaks. A caching layer, an image compression tool, a redirect manager. These often have no obvious front-end output, so people assume they are essential. Test them the same way. The answer is still either yes or no. Do this once per plugin, log the result, and the list gets shorter fast. No gut feelings, no guesswork. Spot the Slowest Offenders First The raw plugin count tells you almost nothing on its own. A site running twenty lean, well-coded plugins can load faster than one carrying eight bloated ones. What you need is actual measurement. Install Query Monitor and reload a few representative pages while watching the database query count and server response time shift as you toggle plugins off one by one. Better still, spin up a staging duplicate first so you can deactivate things without touching the live site. You're looking for the plugin that adds 300ms to every page load, not the one that runs two tidy queries on a single admin screen. One badly written plugin can cost you more than half a dozen lightweight ones combined. That's not an exaggeration, it's just what poor code does to a shared environment. What to look for The usual culprits are plugins that fire on every page regardless of whether they're needed there, ones that load a full JavaScript library for a feature used on a single contact form, and anything that runs unindexed database queries at scale. A slider plugin that loads its assets site-wide even on pages with no slider is the classic version of this. Once you've found your heavy hitter, the fix is usually straightforward. Swap it for something leaner, or remove it entirely if the feature isn't earning its place. Check for Overlap and Redundancy The most common form of plugin bloat isn't a dozen questionable tools. It's two or three plugins doing the same job. Caching is the classic example. A site gets set up with WP Super Cache, someone later installs W3 Total Cache because load times were sluggish, and nobody removes the original. Both are now active, both are writing cache files, and they are conflicting with each other. The same pattern shows up in SEO plugins (Yoast and Rank Math running side by side), contact form plugins (Contact Form 7 and WPForms both installed, each with one active form), and security plugins (Wordfence and iThemes Security overlapping on login protection and file scanning). In every case, the site is carrying double the overhead for a single function. Go through your plugin list and group by category. If you have two entries under the same job, decide which one you use and remove the other. Deactivating isn't enough. An inactive plugin that loads database queries on activation checks still costs you something. Redundancy tends to creep in after a site redesign or a theme switch. The original installer is long gone, nobody has a full picture of what's there, and the duplicates just sit. A quick audit takes twenty minutes and often turns up two or three obvious cuts straight away. Update History Matters More Than Reviews A five-star rating tells you people liked a plugin. It tells you nothing about whether the developer still cares about it. The changelog in the WordPress repository is the honest signal. Look at two things. The date of the last update, and how often updates have shipped historically. A plugin sitting untouched for eighteen months has almost certainly missed security patches, PHP compatibility fixes, and changes to WordPress core that have introduced conflicts beneath the surface. What the repository actually tells you The repository also shows which WordPress version the plugin was tested up to. If that number is several major releases behind where you are now, the plugin is running on borrowed time. One abandoned plugin in a stack of fifteen is not a small problem. Every plugin shares the same execution environment, so a vulnerability in one is a door into all of them, and a PHP incompatibility in a single ignored dependency can throw fatal errors that bring the whole site down. If you want a methodical way to evaluate what you have installed before making changes, a thorough pre-change audit covers exactly this ground. Reviews age badly. Update history does not. The Consolidation Step Once you have a clear picture of what each plugin does, you will almost always spot overlap. A form plugin handling redirects when your SEO plugin already does that. A separate widget for social sharing when your theme has one baked in. A dedicated shortcode plugin doing something a native block handles now. Consolidation is not about stripping the site back to a bare minimum. It's about making sure each function has one owner and one owner only. Start by listing the duplicate jobs, then pick which tool handles each one best, whether that's the multipurpose plugin already installed, a theme feature you've never bothered to turn on, or a block editor equivalent that needs no plugin at all. Doing this methodically means you rarely lose anything in the process. How to remove safely Deactivation order matters more than most people expect. Always deactivate before you uninstall, and remove one plugin at a time rather than clearing several at once. That way, if something breaks, you know exactly which removal caused it. If you want a structured way to approach this before touching anything, a thorough pre-change audit saves a lot of debugging afterwards. Take a full backup before you start. Non-negotiable. Set a Review Cadence and Stick to It Plugin sprawl rarely arrives all at once. A testing plugin gets installed during a site tweak and never removed. A feature gets replaced by a better option, but the old plugin stays active out of habit. Six months pass, and suddenly there are thirty plugins doing the work of twenty, with the extras adding weight to every page load. Scheduling a proper review once a quarter keeps that drift in check before it compounds into something that needs real work. Go through each plugin and ask one question, if this were deleted tomorrow, would anyone notice? When to run a lighter check Every WordPress major release is also a natural trigger point. New core features sometimes replace what a plugin was doing, and compatibility issues can surface without any obvious warning signs. A practical rhythm is a thorough quarterly review, then a lighter pass after each major WordPress update. During the quarterly review, cross-reference active plugins against your site's current feature set, not what you needed a year ago. If you want a structured starting point for that, a performance audit before any changes gives you a clean baseline to work from. The list should reflect the site you have now, not the one you built. ------------------------------------------------------------ # Content Strategy for Small Businesses: Where to Start Source: https://yorkshiredesign.co.uk/content-strategy-for-small-businesses-where-to-start/ Published: 2026-07-29 > Most small business websites have plenty of pages but no real thread connecting them. A services page here, a blog post from three years ago there, an about page that reads like a CV. Visitors land, skim, and leave without understanding what you do or why they should care. That is not a writing problem. It is a structure problem, and sorting it out does not require an agency or a six-month plan. It requires a clear idea of who you are talking to and what you want each page to do. The myth that more content always helps A common assumption is that publishing more pages will bring in more traffic. So businesses churn out blog posts on loosely related topics, add FAQ pages that duplicate service copy, and end up with fifty pages that each say roughly the same thing in slightly different words. Search engines are not impressed by volume. They look at whether a page answers a specific question clearly and whether the site as a whole has coherent topical depth. Ten focused, well-written pages will consistently outperform fifty thin ones. The first job of a content strategy is deciding what to cut or consolidate, not what to add. Start with what your visitors are asking Before writing a single word, spend an hour listing every question a potential customer might ask before hiring you or buying from you. Not the questions you want them to ask. The ones they type into Google at 10pm when they are not sure who to trust. For a plumber, that might be "how much does a boiler service cost" or "signs my boiler needs replacing". For a solicitor, it might be "what happens if I miss a tax deadline". These are not glamorous topics. They are the questions that build trust before a person ever contacts you, and they are the backbone of a small business content plan that moves the needle on local visibility. Map questions to pages, not posts Not every question belongs in a blog post. Some belong on your services page, some on a dedicated FAQ section, and some warrant their own standalone page. A question like "do you offer emergency callouts" should be answered on your services page, prominently, not buried in a post from two years ago. Think of it as a simple map. High-intent questions sit on your commercial pages. Informational questions that help people make decisions sit in blog posts or guides. Keep them separate and each page stays focused on doing one job well. Check what Google already shows for your topic Before you write anything, search the phrase yourself. Look at what type of content ranks. If all the top results are listicles, writing a 3,000-word essay is probably the wrong approach. If they are all short answers, do not pad your page with filler. Google is telling you what format its users prefer for that particular query. Match it, then add something the existing results do not have. Structure your site before you start writing Content strategy and site structure are inseparable. A page can be beautifully written and still rank poorly because it has no clear relationship to the rest of the site. Search engines piece together what a site is about by looking at how pages connect to each other, and by reading the anchor text of internal links. A sensible structure for most small businesses looks something like this. A homepage that states clearly what you do and who you do it for Individual service pages for each main offering, each targeting a specific phrase A blog or resources section for informational content that supports the service pages An about page that gives people a reason to trust you over a faceless competitor A contact page with clear next steps That is not a template. It is a starting point. Every page needs a purpose and a logical connection to related pages. When you write a blog post about boiler maintenance, it should link back to your boiler servicing page. That internal connection tells search engines the two pages are related and passes relevance between them. If you are unsure how to put this into practice, the guide on ranking without an agency covers the writing side in more depth. Writing for people first, search engines second There is a version of SEO content that reads like it was assembled from a keyword list. Every other sentence contains the exact phrase you are targeting, the headings are awkward, and the whole thing sounds like a legal document translated from another language. Nobody reads it. Nobody links to it. It does not rank well, either, because search engines have become very good at recognising when a page is written for a bot rather than a person. Good content answers the question the visitor arrived with, then gives them a reason to stay. It uses the language your customers use, not the internal jargon your industry prefers. And it makes the next step obvious, whether that is contacting you, reading another page, or booking something. One idea per page The most common structural mistake is trying to cover too much on a single page. A page about "office cleaning services in the East Midlands" should not also try to rank for "domestic cleaning tips" and "how to clean a carpet". Those are different audiences with different intentions. Mixing them produces a page that half-answers multiple questions instead of fully answering one. Once a page has a clear single focus, the writing becomes easier. You know exactly what question you are answering, who you are writing for, and what you want them to do at the end. How often should you publish? Consistency matters more than frequency. One well-researched post per month, published reliably, will do more for your site than four rushed posts one week and then nothing for four months. Search engines pay attention to whether a site is maintained over time. So do visitors. A monthly cadence is achievable for most small businesses without it becoming a burden. Pick topics that answer real customer questions, write them properly, and make sure each one links to at least one relevant page elsewhere on your site. That compounds over time in a way that a single burst of activity followed by silence never does. In our experience, businesses that spend two hours mapping out six months of content topics in advance produce far more useful material than those who think of something the night before they publish. A little planning upfront changes the quality of everything that follows. The hosting question people overlook Content strategy only pays off if the pages you create load quickly. A slow site undermines everything else. Visitors leave before reading, and Google deprioritises pages with poor performance scores. For WordPress sites, hosting choice is a bigger factor than most people realise. Hostinger consistently outperforms hosts that charge significantly more, particularly when you pay upfront for a longer term and take advantage of their LiteSpeed cache stack. The renewal price is steeper than the signup price, so extending the initial period as far as your budget allows is a sensible move. Fast hosting is the unglamorous foundation that makes your content strategy work properly, and it is one of the things that tends to get skipped when people focus entirely on writing. If you want to understand more about how site speed ties into your content's visibility, the post covering what service business content gets read gets into the specifics of what keeps people on a page once they arrive. Where to go from here A website content strategy does not need to be complicated. List the questions your customers ask. Map those questions to the right pages. Structure the site so related content connects. Write one clear idea per page. Publish something useful every month and keep doing it. The results take time to show. But the businesses that get ahead on organic search are rarely the ones who did something spectacular once. They are the ones who built something sensible, kept at it, and did not stop when nothing happened in the first six weeks. The groundwork you lay now is what your site's visibility is built on six months from now. ------------------------------------------------------------ # WordPress Media Library: How to Stop It Becoming a Mess Source: https://yorkshiredesign.co.uk/wordpress-media-library-how-to-stop-it-becoming-a-mess/ Published: 2026-07-29 > Most WordPress sites reach a point where the media library is basically a skip. Hundreds of uncompressed images with names like 'IMG_4827.jpg', duplicate uploads nobody deleted, and files attached to pages that no longer exist. It rarely causes a crisis on its own, but it does slow things down quietly and makes any maintenance job harder than it should be. These are the checks worth doing now, before it gets worse. Name files before you upload, not after The filename a photo has when it hits WordPress is the filename it keeps forever. Get it wrong and you're stuck with it. WordPress does let you rename attachments after upload, but it only renames the display title, not the actual file sitting on your server. The original URL stays the same. So if you spent twenty minutes last Tuesday uploading IMG_4892.jpg, then edited the attachment title to something sensible, every page and post referencing that image is still pointing to IMG_4892.jpg on disk. Rename the physical file and those links break. That's the trap. The only clean answer is to sort the filename out before anything touches the media library. Something like black-leather-sofa-three-seater.jpg costs you about four seconds to type and pays back in search visibility, screen-reader clarity, and a library you can actually scan without squinting. Build the habit at the source. Before any batch of images leaves your phone, your camera, or your designer's Dropbox folder, rename them. Lowercase letters, words separated by hyphens, no spaces, no underscores, no brackets. Descriptive enough that someone reading the filename alone could picture the content. Once that becomes routine, the media library stays manageable almost on its own. The mess rarely starts inside WordPress. It starts with the files you bring to it. Folders make the difference at scale WordPress organises uploaded files by year and month, and that is it. No native folder structure beyond those two levels. A site that has been running for three or four years with regular image uploads ends up with thousands of files sorted by nothing more useful than when they arrived. For smaller sites, say under two or three hundred images, the date-based structure is honestly fine. The built-in search finds files quickly enough, and adding a folder plugin just introduces another moving part. Once you push past that threshold though, finding a specific product shot or a past campaign graphic starts to feel like archaeology. Which plugin to use FileBird is the lighter of the two main options. Drag-and-drop folders, a clean interface, and a free tier that covers most small to medium sites. Real Media Library goes deeper, supporting nested folders and bulk-move tools that matter when you are sorting through a backlog of two thousand files. Neither plugin physically moves files on the server. They layer a virtual folder structure on top of the existing uploads directory, which keeps things safe if you ever uninstall. The right choice depends entirely on volume and how many people upload content. One person managing a clean site probably never needs folders at all. Track down and remove unused files The quickest way to find orphaned media is a plugin like Media Cleaner, which scans your library and flags any file that isn't attached to a post, page, or widget. It cross-references every item in your uploads folder against the database, so images uploaded during a draft and then replaced, or files left behind after a theme switch, all surface in one list. Running a scan on a site that hasn't been audited in a few years can easily turn up hundreds of files sitting completely untouched. Before you delete anything, check the flagged items manually. Some plugins mark files as unused even when they're referenced directly in a page builder's custom field or hardcoded into a template. A quick search through your theme files and any custom CSS for the filename takes two minutes and can save a nasty surprise. Back up first, every time Take a full backup before you run the clean-up. This is not a precaution you skip to save time. Media Cleaner has a built-in trash system that holds deleted files temporarily, which gives you a short window to recover something if you made a mistake, but that window closes. A proper off-site backup, taken fresh the same day, means you can restore a specific image weeks later if a client comes back asking why a product photo has gone missing. The clean-up itself is straightforward. It's what happens the day after that catches people out. Duplicates are more common than you'd expect The most common way duplicates creep in is through re-uploads. A client downloads an image from the live site, tweaks it slightly, and uploads it again under a different filename. Multiply that across a few years and a handful of contributors, and the same product photo exists in four or five variations. Theme switches make it worse. When you swap themes, WordPress often regenerates size variants to match the new layout's dimensions, and some plugins create entirely new copies rather than updating the originals. Regenerating with a tool like Regenerate Thumbnails does the same thing if the settings aren't reviewed first. None of this shows up as an obvious problem until you're hunting for a specific image and find six near-identical versions with names like banner-final-v2-EDIT-web.jpg sitting in the same folder. A manual check inside the uploads folder via FTP or your host's file manager can be revealing. Sorting files by size and scanning for matching file sizes is a surprisingly reliable first pass. If you want to go further, a basic regex search in the uploads directory for patterns like -+x+.jpg will surface WordPress-generated size variants that have been uploaded as originals by mistake. Plugins like Imagify or Media Deduper can cross-reference file hashes to flag true duplicates. Before deleting anything, check whether a post or page references that file. Good image management practice starts before the file ever hits the library, but cleaning up what's already there is often the more pressing job. Set a compression rule and stick to it Every image that lands in your media library should earn its place. If it hasn't been compressed before upload, it's already a problem. A product photo shot on a modern phone can sit at 6MB or more straight out of the camera. Serve that uncompressed and you've handed Google a signal that your page is slow, which feeds directly into your Core Web Vitals scores. Largest Contentful Paint takes a hit the moment a heavy image is the biggest visible element on the page. The fix is a consistent rule. Set a maximum file size you'll tolerate, say 150KB for a standard content image, and treat anything above that as something to compress before it goes anywhere near the library. Tools like ShortPixel or Imagify can handle this on upload automatically, but the setting only works if you've switched it on and understood what each quality level means for your output. The image optimisation settings that genuinely shift the needle are fewer than most people expect, but they need configuring once, properly, rather than left at defaults. WebP conversion is the other half of that rule. Serving a PNG where a WebP would do the same job at a third of the file size is a straightforward win most sites still leave on the table. Prevent the mess from coming back Most libraries fall apart again within a few months because the habits that caused the original chaos never changed. Before anything gets uploaded, run through a short mental checklist. Does the file have a descriptive name that means something without context? Has it been sized to the largest it will ever display on the site? Is there already something identical sitting in the library? That last question catches more duplicates than anything else. Pair that discipline with automatic compression on ingest so every image that lands in WordPress gets optimised without anyone having to remember. Plugins like ShortPixel or Imagify handle this at the point of upload, which means the work happens once and you never end up with a folder full of 4MB originals that nobody noticed. If you want to understand what actually happens to an image once WordPress touches it, the settings that genuinely affect image quality and file size are worth working through before you configure anything. Lock down upload permissions Role restrictions do quiet but meaningful work here. By default, contributors and authors can upload media freely, and on a site with several editors that adds up fast. Limiting upload permissions to editors and above, or using a plugin to enforce stricter controls, removes the biggest source of unchecked growth. It's a five-minute change that most sites never make. ------------------------------------------------------------ # AI Automation for Local Businesses: Where to Start Source: https://yorkshiredesign.co.uk/ai-automation-for-local-businesses-where-to-start/ Published: 2026-07-28 > A lot of local businesses approach AI automation backwards. They spend weeks evaluating tools, read a dozen comparisons, then end up automating something that barely needed doing in the first place. The tasks that genuinely free up time are usually the unglamorous ones nobody notices until they stop happening. Getting that order right matters more than picking the fanciest platform. The myth that automation means replacing people When most people hear "AI automation," they picture redundancies. That's not what this is about. Think about the people you already rely on, a receptionist, a bookkeeper, the person who handles your social media between other jobs. A meaningful chunk of their day disappears into tasks that follow an identical pattern every single time. Chasing invoice payments. Sending appointment reminders. Copying enquiry details from an email into a spreadsheet. Posting the same type of content on a Tuesday afternoon. None of that needs human judgement. It just needs someone to be there and do it. Automation takes that repetitive overhead off their plate so they can spend time on the work only a person can do, talking to customers, solving unexpected problems, building the relationships that keep a business running. For a local business, that shift matters more than it might for a large company, because every hour of skilled attention is harder to replace. The honest framing is this. Getting started with AI workflow automation is less about shrinking your team and more about making the team you have considerably less stretched. The goal is to stop burning good people on the predictable and let them focus on the parts of the job where their experience, empathy and common sense are the whole point. Customer enquiries and the follow-up problem Most local businesses lose leads not because they lack interest, but because the reply takes too long. Someone fills in a contact form on a Tuesday evening, gets no response until Thursday morning, and by then they've already booked with someone else. It happens constantly, and the business usually has no idea it happened at all. A simple automated response, triggered the moment that form is submitted, changes the dynamic immediately. It confirms receipt, sets an expectation for when they'll hear back, and keeps the conversation alive long enough for a human to follow up properly. That gap between enquiry and first response is where a lot of weekly leads disappear. Taking it further with CRM triggers CRM triggers build on this. If a lead hasn't been contacted within a set window, the system can flag it, nudge the relevant person, or send a gentle follow-up message automatically. Nothing about that needs to feel robotic if the message is written well. The concern most owners raise is that automation will make their business feel impersonal. That's a fair worry if you're picturing generic corporate emails. But a well-crafted automated message, written in the same tone you'd use on the phone, reads exactly like you wrote it. If you want a clearer picture of where automated responses save time without stripping out the human feel, that's a good place to start. Appointment booking and reminder sequences No-shows are expensive in a way that's easy to underestimate. A therapist, a dog groomer, a mobile mechanic, any service business where time is the product knows the feeling, a slot blocked out, a client who doesn't turn up, no way to recover that hour. Manual booking compounds the problem. Someone has to answer the phone, check the diary, send a confirmation, and then remember to chase a reminder the day before. For a one-person operation, that admin can eat up 30 to 45 minutes a day, and it's time that earns nothing. A simple automation chain removes most of that. When a client books online, a confirmation goes out instantly, a 24-hour reminder follows automatically, and a follow-up for rebooking fires a few days after the appointment. No one has to remember to send any of it. Tools that don't need a developer Calendly, Acuity and even a well-configured Google Business booking link can feed into reminder sequences through platforms like Make or Zapier without needing a developer to set them up. The first time you see a no-show rate drop from one in five appointments to one in ten, the setup time pays itself back within a week. If you're weighing up where AI workflow automation fits into your business, booking and reminders is almost always the right place to begin. Repetitive content, social posts, review requests and emails The tasks that eat the most time for local businesses are rarely complicated. They are just relentless. Writing a Facebook post about this week's offer. Chasing a happy customer for a Google review. Sending a follow-up email after a job is done. Each one takes maybe ten minutes. Across a week, across a year, that adds up to a serious chunk of time that could go elsewhere. These are exactly the tasks where AI handles the repetition without breaking a sweat, because the structure of each task barely changes from one week to the next. The safe starting points are review request emails, post-appointment follow-ups, and templated social posts built around a real prompt you supply. The key is giving the AI enough context, your tone, your service, a specific detail, so the output reads like you wrote it on a busy Tuesday rather than something generated by a machine at 3am. The check that makes the difference Where people go wrong is treating the AI output as finished copy. Read it. Tweak the one phrase that sounds too formal. Add the customer's name properly. That thirty-second check is what keeps your communications feeling personal, and it costs far less time than writing from scratch every time. What not to automate yet Some tasks look like automation candidates on paper. In practice, handing them to a tool too early makes things worse, not just slower. Complaint handling is the obvious one. When a customer is unhappy, what they want is to feel heard by a real person who has the authority to do something about it. An automated response that acknowledges their frustration and promises a follow-up within 48 hours reads as indifference dressed up as process. The same goes for any conversation where the outcome depends on reading tone, building trust, or exercising some discretion on pricing. A returning client asking if you can flex on a quote deserves a considered reply, not a templated "thanks for your enquiry" that clearly came from a tool. For local businesses where reputation travels by word of mouth, these moments carry real weight, and the relationship you build locally is part of what search visibility ultimately rests on too. Creative briefs, bespoke proposals and anything that needs real context about a client's situation are also worth keeping human for now. The tools are improving fast, but they still flatten nuance. An automated proposal that gets the wrong tone, misreads the scope, or just feels generic can cost you a job you'd otherwise have won easily. Choosing a starting point that sticks The businesses that make real progress with automation tend to share one habit. They pick something small and boring rather than something ambitious and interesting. Think about the tasks that eat 20 or 30 minutes every single day without producing anything your customers see. Appointment confirmation emails. New enquiry acknowledgements. Social media reposts of existing content. Review request follow-ups after a job is done. These are the right starting points because they are repetitive, low-stakes, and easy to unpick if something goes wrong. If you automate a client-facing invoice reminder and the wording is slightly off, you can fix the template in ten minutes and nobody notices. That reversibility matters far more than most people give it credit for, especially when you are new to this and still building confidence in the tools. How to score your candidate tasks Score your candidate tasks against two things, how many times a week it happens, and what it would cost you if the automation misfired. High frequency, low consequence is the sweet spot every time. The planning stage is where most local businesses stall. They draw up a list of 15 processes they could automate, then spend three months debating the order. Pick one task from your list, set it running without overhauling your whole workflow, and review it after two weeks. That single completed cycle teaches you more than any amount of research beforehand. ------------------------------------------------------------ # What Actually Happens During a Full Website Redesign Source: https://yorkshiredesign.co.uk/what-actually-happens-during-a-full-website-redesign/ Published: 2026-07-28 > Most clients hand over their old site and expect a shiny new one back within a fortnight. The reality is that the visible work, the new pages and the fresh layout, only accounts for a fraction of what a redesign actually involves. The stuff that takes longest is mostly invisible, crawling the existing site for problems, mapping content, untangling years of plugin debt, and making sure nothing that ranked before quietly disappears on launch day. The Audit That Happens Before a Single Page Is Touched Before any wireframe gets sketched or a colour palette gets chosen, the work starts somewhere far less visible. The first thing to look at is what the existing site is doing, technically speaking. That means pulling a full crawl and going through redirect chains, 404 errors, and any pages that are indexing when they shouldn't be. It means running Core Web Vitals baselines through PageSpeed Insights so there's a real before-and-after to measure against, not a vague sense that the new build "feels faster". It means checking the canonical tags, the sitemap, the robots.txt, and whether any pages that rank well have accumulated backlinks that would vanish if their URLs changed without proper handling. A redesign that wipes out six years of link equity because nobody mapped the old URLs to the new ones is a painful thing to unpick afterwards. Analytics come next. Which pages bring in traffic? Which ones convert? Redesigns have a habit of deprioritising pages that look unimportant on the surface but do a lot of quiet work in search. Spotting those before the build starts means they get carried across properly, not rebuilt from scratch or, worse, dropped entirely. The audit isn't glamorous work, but skipping it is almost always what turns a straightforward redesign into a six-month recovery job. Why Content Takes Longer Than the Design The design is rarely what slows a website redesign down. Nine times out of ten, it's the content. Before a single template gets chosen or a colour palette agreed, somebody needs to decide which pages are staying, which ones get cut, and what the surviving pages are meant to say. That sounds straightforward until you sit down and look at a site that's been patched together over several years, where product descriptions were written by a supplier, half the team pages are out of date, and there are blog posts from years ago that nobody can remember writing. Sorting that out takes longer than most people budget for, and it can't be rushed. A template built around placeholder text rarely survives contact with the real copy in one piece. Images cause their own delays. Stock photos can be sourced quickly, but anything that needs to reflect the actual business, a real team, a real product, a real location, has to be photographed or commissioned. That alone can push a project back by weeks if it isn't planned early. The practical fix is to treat content as the first task, not something that follows the design. Map every page, decide its purpose, and have the copy drafted before templates are even mocked up. If you're putting together a brief for the project, a well-structured brief is the right place to capture those content decisions before any design work starts. Structure, URLs and the SEO You Cannot Afford to Break A URL change without a redirect plan is one of the fastest ways a redesign wipes out years of organic ranking. Search engines have indexed your old pages, other websites link to them, and users have bookmarked them. The moment those URLs disappear and return a 404, every one of those signals vanishes. A product page that has sat on page one for three years does not recover overnight. If the new site launches on a reworked URL structure and nobody has mapped the old paths to the new ones, that traffic is gone the day the site goes live. This is why the redirect audit happens before a single page template gets built, not after. Every existing URL gets crawled and logged, then matched one-for-one against its new destination. Where the content is moving to a different path, a 301 redirect carries the ranking history across. Where a page is being removed entirely, the nearest equivalent gets found rather than leaving a dead end. It sounds methodical because it is, and it takes considerably longer than most clients expect. The mapping work for a site with several hundred pages can run to a full day or more, but skipping it to save time is a shortcut that shows up immediately in Search Console as a spike in crawl errors. If you want to understand more about what proper SEO work involves, the detail is there. What the Build Phase Looks Like Week by Week Working in staging Once the design is signed off, the work moves into a staging environment, a private copy of the site that sits completely separate from the live version. This is where plugin selection starts to matter. A contact form plugin, a caching layer, an SEO framework, sometimes a page builder, each one needs to be chosen carefully because they interact with each other in ways that only become obvious once content is loaded and real performance tests are run. A staging build that looks fine on a blank page can start dragging the moment you add real images, real fonts, and a handful of third-party scripts. That's the point where the less visible decisions about WordPress configuration tend to have the biggest impact on how the finished site performs. Where timelines actually slip Feedback rounds are where most timelines slip, and it's not because revisions are difficult. It's because every change to a layout or a colour scheme needs retesting across screen sizes and browsers before it can be called done. One tweak to a header can break the mobile menu. A font swap can shift spacing across six page templates. There's no shortcut through that process. Each round takes the time it takes to do properly. Pre-Launch Checks That Most People Skip Going live is not the end of the project. It's where a new round of checking begins. Most people tick off a short list before hitting publish, does the homepage load, do the buttons work, does it look right on their laptop. What gets missed is the unglamorous layer underneath. Every form needs testing end to end, not just a visual inspection. A contact form that appears fine but silently fails on submission is invisible until a real enquiry disappears into nothing. Mobile rendering needs checking across actual device sizes, not just a browser resize. Schema markup needs validating so search engines read the structured data correctly. Pagespeed scores on the live server can differ from a staging environment, sometimes meaningfully, because server configuration, caching rules, and image delivery all behave differently once real traffic is involved. Broken internal links and unresolved 404s from old URLs are easy to miss too, especially on a site that has been restructured. A run through what a proper SEO audit covers shows how many of these signals feed directly into how a site ranks after launch. Treat the first two weeks post-launch as an active checking window, not a wind-down. Crawl the site again, recheck scores, watch for any redirect chains that crept in. The build was careful work. The launch deserves the same attention. After Launch, the Work Is Not Over What to watch in Search Console The weeks after a redesign goes live are where a lot of projects unravel, and most clients never see it happening. Google needs time to recrawl the site, process any URL changes, and reassess what the pages are about. During that window, fluctuations in rankings are normal. Ignoring them is not. Search Console should be checked regularly for crawl errors, soft 404s, and any pages that have dropped out of the index unexpectedly. A common failure here is a redirected URL that resolves correctly in a browser but returns the wrong status code to Googlebot, meaning the old page equity never gets passed through. You have to look at the raw data, not just assume the redirects are working because the site loads. Index coverage and post-launch review Index coverage reports often surface problems that the build process missed entirely. A noindex tag left on from the staging environment, or a robots.txt rule that is slightly too broad, can block whole sections of the site from being crawled without anyone noticing for weeks. If you are spending time and budget on a solid SEO foundation before launch, a proper post-launch review is how you protect that investment. Most clients plan carefully for the build. Very few plan for what comes after it. That post-launch period is where the redesign either holds its ground in search or slowly loses what it spent months trying to earn. ------------------------------------------------------------ # The Hidden Technical SEO Issues That Kill Your Crawl Budget Source: https://yorkshiredesign.co.uk/the-hidden-technical-seo-issues-that-kill-your-crawl-budget/ Published: 2026-07-28 > Google doesn't crawl every page on your site every day. It works with a budget, a rough limit on how many requests Googlebot will make before moving on. Most sites haemorrhage that budget on pages that should never be crawled in the first place. The fixes are not glamorous, and the results don't arrive overnight. But sorting this out is the kind of unglamorous groundwork that separates sites that rank from those that stall. What crawl budget means in practice Googlebot doesn't stay on your site indefinitely. It visits for a fixed period, follows a limited number of URLs, then moves on. That allocation of time and crawl capacity is what people mean by crawl budget, and for most small sites it's a non-issue. The problems start when a site grows, often without anyone noticing, and Googlebot ends up spending its quota on pages that were never meant to be indexed in the first place. A typical WordPress site generating URLs from tag archives, author pages, date-based archives, session parameters and half-finished draft pages can balloon from 200 useful URLs to several thousand. Googlebot crawls the bloat, runs out of budget, and never reaches the pages that matter to your rankings. The product pages, the service pages, the blog posts you spent real time on. That's the practical consequence, not a penalty. Your best content sits unvisited until the next crawl cycle, and on a sprawling site with thin technical foundations, that cycle can stretch for weeks. Duplicate and Near-Duplicate URLs Session IDs and tracking parameters Session IDs are one of the oldest offenders, and WordPress sites still fall into this trap more than you'd expect. When your server appends a unique session identifier to every URL, Googlebot sees each visit as a brand new page. The same product or post gets crawled dozens of times under different addresses, and your crawl budget drains on pages that are, in effect, identical. Tracking parameters from UTM tags work the same way. A URL with ?utm_source=email looks different to a crawler even though the content underneath hasn't changed at all. WooCommerce faceted navigation Faceted navigation is a particularly messy generator of URL sprawl. Filtering by colour, size, price range and availability can produce thousands of parameter combinations pointing at near-identical product listings. Add print-friendly page variants (the kind some themes and plugins create automatically without flagging it) and you can easily end up with a long tail of near-duplicate addresses that Google keeps revisiting at the expense of your real pages. Understanding the full picture of what Googlebot is crawling, and why, sits at the heart of why larger sites lose rankings over crawl budget alone. The fix generally starts with a proper canonicalisation strategy and tightening up which parameters are declared in Google Search Console. Redirect Chains and Soft 404s A redirect chain is exactly what it sounds like. Googlebot requests URL A, gets sent to URL B, which sends it on to URL C, and so on. Every hop in that chain costs crawl budget, yet at the end of it Google credits the final destination, not the intermediate stops. The bot has done real work for a result it could have reached in one step. If you have dozens of old URLs still pointing through two or three redirects, that wasted capacity adds up fast, and Googlebot may simply stop crawling before it reaches pages you want indexed. Soft 404s are less obvious but just as damaging. A soft 404 is a page that returns a 200 OK status code while displaying a "no results found" or "product unavailable" message, so Google's crawler treats it as a live, valid page and keeps spending budget on it. The correct response for a missing page is a 410 or 404 status, which tells Googlebot to stop revisiting and drop it from the queue. Without that signal, the crawler loops back repeatedly, burning time on empty pages. This is the kind of thing that rarely shows up in a surface-level site review, but a proper technical audit surfaces both issues clearly and gives you a clean fix list to work through. What Your robots.txt and noindex Directives Are Doing The crawling vs indexing distinction These two controls get confused with each other constantly, and the distinction matters more than most people realise. Blocking a URL in robots.txt tells Googlebot not to crawl it, but it does not remove the page from the index. Google can still discover that URL through an external link, list it in search results with no title or description, and acknowledge its existence without ever reading its content. A site that blocks its staging subdomain or a pile of filtered category pages in robots.txt might still see those URLs surfacing in Search Console, because crawling and indexing are separate operations entirely. Where noindex goes wrong at scale A noindex directive works the other way. Googlebot crawls the page, reads the tag, and agrees not to index it, which is fine for thin or duplicate content you want kept out of results. The problem is that every one of those crawls still costs you crawl budget. If you have hundreds of paginated archive pages or parameter-driven URLs carrying a noindex tag, the crawler dutifully visits each one and walks away empty-handed. Neither tool is wrong on its own. Applying them without understanding what each one controls is how budget gets drained on pages that were never worth crawling. Internal linking patterns that trap Googlebot in low-value corners The internal link structure of a site acts like a map for Googlebot, and a badly drawn map sends crawl budget to the wrong places. Tag archives with thirty overlapping entries, author profile pages that list nothing but post titles, paginated index pages reaching back years. These all sit in the link graph just as prominently as your service pages if the template is built carelessly. Googlebot follows links, it does not guess intent. So if your footer links to every tag ever created and your sidebar lists recent posts across a hundred categories, that is where a significant share of crawl requests goes. The pages you want indexed and ranked are often buried deeper, receiving fewer crawl visits as a result. The fix is less about adding links and more about auditing where your existing links point. A common pattern on WordPress sites is a theme that auto-generates navigation for every taxonomy term, pulling Googlebot into thin filtered views that carry no real content. Checking this is straightforward with a crawl tool like Screaming Frog, where you can trace link depth and see which templates are consuming the most internal equity. If you want to go deeper on the structural side, the principles behind why crawl budget gets wasted on large sites explain exactly how that link graph shapes Googlebot's behaviour over time. Diagnosing the Leaks Before You Fix Anything Search Console crawl stats Search Console's crawl stats report is the first place to look. You want to see a crawl pattern that stays broadly consistent, with Googlebot visiting pages at a steady, predictable rate. What you don't want is a chart that spikes wildly after a site update, then flatlines. That usually means Googlebot burned through a chunk of budget on something it shouldn't have and then backed off. Pay close attention to the "by response" breakdown. A high proportion of 301 redirects or 404s tells you straightaway that crawl budget is being spent on dead ends rather than content that matters. If you're seeing Googlebot repeatedly visiting the same redirect chains, that's a clear signal the structural problems run deeper than a missing page or two. Log file analysis Log file analysis takes that picture further because Search Console only shows you a sample. A raw server log shows every single request Googlebot made, at what time, to which URL, and what status code it got back. Look for clusters of bot requests hitting URLs with parameters, session IDs, or filtered facets that generate near-identical pages. That's the pattern that drains budget fastest on larger sites. A healthy crawl log looks almost boring, consistent bot visits spread across your important URLs, minimal wasted requests, no repeated hammering of the same path. Where to Start if Your Site Has Never Had a Crawl Audit If no one has ever looked at this properly before, spend your time first on URL parameter handling. Faceted navigation, session IDs, and sorting filters can multiply your indexable page count many times over without adding a single page of real content. Search Console's URL Parameters tool gives you a starting point, and checking your crawl stats there will quickly show whether Googlebot is burning time on near-duplicate parameter variants. Fixing this alone can free up a significant chunk of crawl capacity without touching your site structure at all. It's also the kind of problem that's embarrassingly common on sites that have been through monthly SEO retainers with nothing to show for the spend. Once parameter chaos is under control, the next job is finding orphaned noindex pages that Googlebot is still reaching through internal links or sitemaps. These are pages that sit in a grey zone, excluded from the index but still consuming crawl budget because Googlebot has no signal telling it to stop visiting. A full crawl using Screaming Frog will surface them quickly. The structural work that follows, consolidating thin pages and flattening navigation depth, takes considerably longer. But that compounding effect on crawl efficiency is exactly what the quicker wins are building towards. ------------------------------------------------------------ # The Page Speed Metrics Google Actually Scores You On Source: https://yorkshiredesign.co.uk/the-page-speed-metrics-google-actually-scores-you-on/ Published: 2026-07-28 > Most people trying to speed up their site are watching the wrong numbers. They screenshot a 94 from GTmetrix and call it done, while Google's actual scoring sits in a completely different set of metrics underneath. The three core web vitals metrics Google measures are specific, named, and each tied to a real moment in how a visitor experiences your page. Getting them wrong isn't just a score problem. It affects where you rank. Why Your Overall Speed Score Is Not What Google Measures A 92 in Lighthouse feels like a pass. An 87 in GTmetrix feels close. Neither of those numbers has any direct bearing on how Google ranks your page. PageSpeed Insights and similar tools are diagnostic instruments, built to help you find problems and prioritise fixes. They are not ranking signals. Google does not take your composite score, hand it to a ranking algorithm, and reward the sites with the highest number. Treating it as though it does leads people to chase the wrong target entirely. The signals that feed into search ranking come from the core web vitals metrics specifically. Largest Contentful Paint measures how quickly the main content loads for a real user. Interaction to Next Paint captures how fast the page responds after someone taps or clicks. Cumulative Layout Shift tracks whether the page visually jumps around while it settles. These three are measured from real Chrome user data collected in the field, not from a lab simulation run on a tool. A site can score 95 in Lighthouse and still carry poor field data on all three vitals, which is the version of performance that matters to Google. LCP: The Metric That Times Your Biggest Element Largest Contentful Paint measures how long it takes for the biggest visible element on the page to fully render in the viewport. That element is usually a hero image, a large H1 heading block, or occasionally a video thumbnail sitting above the fold. Google draws a clear line here, under 2.5 seconds is good, anything above 4 seconds is poor, and the gap between those thresholds is where most sites bleed ranking potential. The score is tied to real user experience data, not just a lab test, so it reflects what your actual visitors see on their devices. The things that hold LCP back most often are unoptimised images served at far too large a file size, render-blocking scripts that sit in the <head> and delay paint, and slow initial server response times. A common pattern is a 3MB hero image that loads last because three third-party scripts are queuing ahead of it. Fix the image format first. Switch to WebP, and set a proper fetchpriority="high" attribute on that element so the browser knows to load it before anything else. If you want to see how these individual fixes stack up against each other in practice, the pattern of what shifts the score is often different from what people expect. INP Replaced FID. What Changed? First Input Delay measured only the delay before a browser began processing your first click or tap. It ignored everything that happened next, which made it relatively easy to pass without your site feeling responsive to users. Google retired FID and replaced it with Interaction to Next Paint, which measures the full round trip from interaction to the moment the page visually updates. That broader scope makes it a far more honest signal of how a site behaves under real use, and it is considerably harder to game with a quick fix. Poor INP scores on WordPress sites almost always trace back to heavy JavaScript running on the main thread. Page builders like Elementor or WPBakery load substantial script bundles that keep the browser occupied, so when a visitor clicks a menu or submits a form, the response stalls while those scripts finish what they were doing. Google's threshold for a passing INP score is under 200 milliseconds, and bloated builder output regularly pushes sites well past that. If you are working through WordPress performance fixes, auditing and deferring non-critical JavaScript is usually the most productive place to start. CLS and the Invisible Shift What the metric is measuring Cumulative Layout Shift measures how much your page jumps around while it loads. It is the metric that catches people out most often because the problem rarely shows up clearly in an audit report. The score is calculated by tracking unexpected movement of visible elements, weighted by how much of the viewport shifts and by how far things move. A score above 0.1 is considered poor by Google. The causes are usually mundane. An image without explicit width and height attributes. A font that swaps in late and nudges surrounding text. An ad slot that appears above the fold after the initial paint, shoving everything below it downward. Why it's hard to diagnose What makes CLS frustrating is that the shift often only happens on a slow connection or on a device that loads resources in a different order than your development machine does. You can sit there on a fast desktop watching the page look perfectly stable, while a visitor on a mid-range phone sees the "Contact Us" button jump just as they tap it. Field data from real users tends to surface these problems far more reliably than a lab test ever will, because it captures the full range of conditions your actual audience is browsing in. Field Data vs Lab Data What the lab score actually tells you Running a PageSpeed Insights test and watching the score tick up feels productive, but that number is not what Google feeds into its ranking signals. The score you see in the lab simulation is generated by a single headless browser under controlled conditions, with a fixed connection speed and no browser cache. It is useful for spotting problems, but it is a snapshot of one synthetic visit, not a picture of how your real audience experiences the page. Google's ranking signal comes from the Chrome User Experience Report, which collects Core Web Vitals measurements from genuine Chrome users visiting your site over a 28-day rolling window. When field data tells a different story A site can score 90 in PageSpeed Insights and still sit in the "needs improvement" band in field data, because real visitors on slow mobile connections or older hardware pull the numbers down. The opposite happens too. A site with a middling lab score can pass field thresholds if its actual audience mostly visits on fast broadband. There is also a quieter problem for smaller sites. If you do not have enough eligible Chrome users visiting within that 28-day window, Google simply will not have sufficient field data to generate a Core Web Vitals assessment at all, which means your real-world performance goes unscored rather than measured. Which Pages Get Scored and Which Don't Google measures core web vitals metrics at the individual URL level, not across your domain as a whole. A fast, well-optimised homepage tells Google nothing about your contact page, your service pages, or your checkout. Each URL collects its own real-world performance data from actual visitors, and each one gets its own pass or fail against the thresholds. That means you can have a genuinely tight homepage sitting right next to a checkout page that has never been looked at properly, and Google treats them as completely separate cases. The pages that tend to get overlooked are the ones that feel secondary until you check the data. A WooCommerce checkout loaded with tracking scripts. A bloated contact page with a third-party form embed. A service landing page with an uncompressed hero image nobody noticed because the designer only ever tested on a fast office connection. These pages still get scored. If they fail, they pull down the site-wide signal Google uses to assess your overall Core Web Vitals status in Search Console. Fixing the homepage and calling it done is a common mistake, and one that takes time and careful page-by-page auditing to properly address. Where to Find Your Actual Core Web Vitals Data Start with Search Console, not PageSpeed Google Search Console is where your real Core Web Vitals data lives, and it should be your first stop. The Core Web Vitals report inside Search Console groups your URLs into three bands: Poor, Needs Improvement, and Good. These groupings are based on field data collected from real visitors using Chrome, which means they reflect what people on actual devices and connections are experiencing. That distinction matters enormously when you're trying to understand whether a problem is widespread or confined to a specific page type. Why the report is always the last thing to turn green Fixing something in your code does not immediately shift those groupings. Google needs to collect enough fresh field data before it reclassifies your URLs, and that process takes weeks. On all the websites we have worked through from failing to passing Core Web Vitals, the Search Console report was always the last thing to turn green, long after the underlying page speed fixes were in place. Set a reminder to check back after four to six weeks rather than refreshing the report daily looking for instant confirmation. ------------------------------------------------------------ # Bing SEO UK: Why Ignoring It Is Costing You Traffic Source: https://yorkshiredesign.co.uk/bing-seo-uk-why-ignoring-it-is-costing-you-traffic/ Published: 2026-07-28 > Most UK site owners optimise for Google and never give Bing a second thought. That made sense for years. It makes less sense now. Bing's share of UK desktop search sits somewhere between 12 and 15 percent, and with Microsoft pushing Copilot hard into Windows, Edge and Office, that number is quietly climbing. Ranking well on Bing is not a consolation prize. For certain audiences and devices, it is the only game that matters. Who Is Searching on Bing The raw market share figure undersells who is on the other end of those searches. Bing's audience skews older, more desktop-heavy, and more corporate than Google's. That matters considerably if you sell B2B services, financial products, legal advice, or anything with a higher price point. A significant portion of those users arrive on Bing because they opened Edge on a work laptop and never changed the default. Corporate IT departments lock those settings down, so the switch-to-Google moment never happens. That is not an accidental audience. These are people with purchasing authority and real budgets. Then there is Copilot. Microsoft's AI assistant pulls its answers directly from Bing's index, and usage across business environments has grown steadily as Microsoft has pushed it into Windows and Microsoft 365. When someone asks Copilot a question about a local solicitor, a B2B supplier, or a specific service in their area, Bing's index determines what surfaces. If your site is not indexed cleanly and your content does not answer questions in a structured, readable way, you are invisible to that query too. The audience feeding through AI-assisted search on Bing is more intentional than a casual Google browse, and that makes the traffic worth competing for. What Bing Weighs Differently to Google On-page signals and keyword placement Bing's ranking signals follow a noticeably different set of priorities, and the gap matters more than most site owners realise. Exact-match domains still carry weight with Bing in a way Google largely moved past years ago, so a domain that closely mirrors a target phrase can get a real lift in Bing's results without any additional work. On-page keyword placement is also more literal. Bing responds well to the focus term appearing early in the title, in the first paragraph, and in at least one subheading, rather than relying on semantic context to piece together the topic. Social signals, particularly shares and engagement on platforms like Facebook and LinkedIn, feed into Bing's authority signals too, which makes the technical structure underpinning a page only part of the picture. Crawl cadence and what it means for publishing The crawl cadence is where Bing diverges from Google in a way that catches people out. Bing crawls less frequently, which means a content freshness strategy built around Google's near-daily indexing will not translate cleanly. A new page can sit unindexed on Bing for several weeks, and updates to existing content take longer to be picked up and re-evaluated. That slower cycle rewards a more deliberate publishing approach. Fewer, more thoroughly built pages tend to hold their positions better than a high-volume, thin-content strategy that might get traction on Google before Bing has even finished processing the original version. Bing Webmaster Tools: A Free Audit Most People Skip Most site owners set up Google Search Console on day one and never give Bing Webmaster Tools a second thought. That is a mistake worth fixing. The platform is free, setup takes under ten minutes, and it surfaces data that Google does not hand over. The backlink explorer shows referring domains at a level of detail that Search Console has stripped back over the years. Pair that with the built-in keyword research tool, which pulls search volume data directly from Bing's own index, and you have a second data set to cross-reference against whatever you are already seeing in Google's tools. Two independent sources are more useful than one. The SEO Analyser is where Bing Webmaster Tools earns its place in a regular audit routine. Point it at any URL and it returns a structured report covering missing meta descriptions, slow-loading resources, thin content signals, and crawl issues. These are the kind of technical SEO problems that compound quietly over time if nobody is looking. You also get crawl control settings, so you can tell Bingbot how aggressively to index your site without burning through server resources. If you have not claimed your site yet, verify ownership via XML sitemap or a meta tag, submit your sitemap, and then spend twenty minutes in the analyser before you do anything else. The issues it flags first are almost always the ones worth fixing first. Schema and Structured Data Why Bing rewards markup faster than Google Bing has been more vocal than Google about what structured data it wants and where it makes a difference. For local service businesses, that transparency is worth paying attention to. LocalBusiness schema, with accurate NAP details, trading hours, and service area, tends to surface faster in Bing's local results than the equivalent effort yields on Google. Product schema, Review markup, and FAQ schema are all processed visibly in Bing's SERPs, often appearing as rich snippets within weeks of implementation rather than the months of patience Google sometimes demands. If you have already added schema to your site and seen little movement on Google, Bing may be where that groundwork pays off first. The schema types worth prioritising for UK service businesses For UK service businesses, the schema types worth prioritising are LocalBusiness, Service, and BreadcrumbList. These give Bing the clearest picture of what you do, where you do it, and how your site is structured. A plumber in Leeds who marks up their homepage with correct LocalBusiness schema, lists each service with a Service type, and adds a clean breadcrumb trail is handing Bing exactly the signals it asks for. The common mistake is treating schema as a one-time checkbox rather than something to maintain as services change or new pages are added. Getting that technical foundation right matters more than people assume, and Bing tends to reward it more obviously than Google does. The Honest Trade-Off With Bing Optimisation Bing should sit alongside your Google work, not compete with it for time. The places where effort pays off quickly are Bing Webmaster Tools, structured data markup, and tight meta descriptions. Bing reads meta descriptions more attentively than Google does, so a well-written, keyword-precise description can have a more direct effect on your click-through rate than the same change would on Google. Submitting your sitemap through Webmaster Tools and checking the crawl diagnostics takes an afternoon, and it closes off a category of problems that could otherwise sit quietly undetected for months. If you want to understand what else underpins that kind of technical groundwork, the principles carry across both engines. Where the trade-off gets less favourable is link-building aimed specifically at Bing. Bing does value authoritative backlinks, but running a separate outreach campaign to boost Bing rankings alone rarely makes sense. The sites worth earning links from are the same ones Google respects, so your existing link-building work already does the job on both fronts. A few deliberate hours spent on Bing's own toolset and your structured data will move the needle more than any Bing-specific campaign would. Treat it as a configuration job rather than a second marketing channel, and you will get solid returns without pulling effort away from where the bigger audience still sits. Copilot, AI Overviews and What Comes Next How Copilot changes what "ranking on Bing" means Microsoft has wired Copilot directly into Bing's index, which changes what ranking on Bing actually means. When someone asks Copilot a question, it pulls structured content from Bing's crawl to build its answer. That puts your site's schema, heading structure and crawlability right at the centre of whether you appear in an AI-generated response, not just a traditional blue-link result. It is the same shift Google made with AI Overviews. Search engines are increasingly summarising the web rather than listing it, so being indexed clearly matters more than ever. The double penalty for weak technical foundations The practical implication for UK businesses is that thin pages, poor markup and crawl errors now carry a double penalty. A page Google's AI Overview ignores might also be a page Copilot skips entirely. Getting your technical foundations right across both engines is no longer groundwork you can defer. Content that answers a specific question clearly, structured so a machine can parse it without guessing, is what feeds both AI systems. Bing SEO in the UK used to mean a small secondary audience. Now it means a second AI pipeline that can surface your business to people who may never see a traditional search results page at all. ------------------------------------------------------------ # On-Page SEO Checklist: What to Check Before You Publish Source: https://yorkshiredesign.co.uk/on-page-seo-checklist-what-to-check-before-you-publish/ Published: 2026-07-27 > Publishing a page without checking it first is like sending a letter without reading it back. Small oversights, a missing title tag, a heading that skips a level, a meta description left blank, quietly cost you rankings before the page even gets a fair chance. This checklist covers the essentials to work through on every page before you hit publish. None of it is complicated, but the number of live pages missing at least two of these items is higher than most people would expect. Title tag, write it for the search result, not the page Your title tag is what appears as the blue link in Google. It needs the focus keyword, and it needs to sit naturally within roughly 55 to 60 characters. Beyond that length, Google truncates it, and a truncated title looks unfinished. Avoid vague titles like "About Us" or "Services Page". Every page should have a title that tells a stranger exactly what they'll find there. If two pages on your site could share the same title, at least one of them has a problem. Meta description, earn the click, don't just describe A meta description does not directly affect rankings, but it does affect whether someone clicks. Think of it as a two-line pitch. Keep it under 155 characters, include the keyword where it reads naturally, and end on something that gives the reader a reason to choose your result over the one above or below it. Leaving the meta description blank means Google writes one for you, pulling a random sentence from the page. That random sentence is rarely the right one. Heading structure, one H1, then a clear hierarchy Every page gets one H1, and that H1 should contain or closely reflect the focus keyword. Below that, H2s and H3s should create a readable outline, not random formatting choices. A common mistake is using heading tags purely to make text bigger, which breaks the logical structure Google uses to understand the page. A useful test is to read just the headings in order. If they tell a clear story of what the page covers, the structure is working. If they read like a random list of bold sentences, it needs rethinking. You can also check this during a technical SEO audit to catch heading issues across the whole site at once. Body copy, keyword placement and readability The focus keyword should appear in the first paragraph, ideally within the first hundred words. After that, use it naturally a handful of times and let related terms fill in the gaps. Forcing exact-match repetition reads badly and serves no purpose. Paragraph length matters too. Short blocks are easier to scan. Long, unbroken paragraphs push people away, particularly on mobile. A page that earns a proper ranking tends to be one that's actually pleasant to read, not just technically complete. One genuine trade-off worth knowing. Writing purely for keyword frequency often makes copy worse. Readability and ranking are not in competition. They tend to move together. Image alt text, descriptive, not decorative Every meaningful image needs an alt attribute that describes what is in the image. This matters for accessibility first, and for image search second. Alt text should be specific. "Plumber fixing a copper pipe joint" beats "plumber" every time. Decorative images, things that are purely visual, should carry an empty alt attribute rather than a description. Screen readers skip them, which is the correct behaviour. Internal links, connect the page to the rest of the site A page with no internal links pointing to it is effectively invisible inside your own site. Before publishing, check that at least one or two existing pages link through to the new one, and that the new page links out to relevant content elsewhere on the site. In our experience, taking over sites from previous agencies often reveals pages that have sat completely isolated for months. No internal links in, no internal links out, and understandably no traffic. It is one of those things that is easy to miss when a site is managed by someone not paying close attention to the whole picture. URL, short, readable, and keyword-led The URL slug should reflect the page topic in plain English. Drop stop words where they add nothing, avoid dates unless the content is genuinely time-specific, and never leave auto-generated slugs like ?p=287 in place. Good: /on-page-seo-checklist/ Avoid: /blog/2024/march/on-page-seo-what-to-check-before-you-publish-a-new-page-on-your-site/ A clean URL is readable in a search result, easy to share, and gives Google a clear signal about the page topic before it has even crawled the content. Page speed, check before you publish, not after A page that loads slowly will not rank as well as one that is fast, regardless of how well the on-page elements are set up. Run the page through Google's PageSpeed Insights before it goes live. Large uncompressed images, render-blocking scripts, and a bloated database are the most common culprits. Fixing them after a page has been indexed is slower work than catching them first. ------------------------------------------------------------ # WordPress Image Optimisation: Settings That Actually Matter Source: https://yorkshiredesign.co.uk/wordpress-image-optimisation-settings-that-actually-matter/ Published: 2026-07-27 > Most WordPress sites carry more image weight than they need to. Not because nobody tried to fix it, but because the settings people adjust are often the wrong ones. Compress a JPEG to 80% quality and congratulate yourself, meanwhile the file is still the wrong format, the wrong dimensions, and loading before the browser even needs it. These are the settings that actually shift the numbers. Set a Maximum Upload Width and Stick to It WordPress lets you upload any size image, and most people do exactly that. A 4,000-pixel-wide photo from a phone gets uploaded, stored, and served, even when the content column it sits in is 800 pixels wide. The file stays enormous in the media library, and every visitor pays for it. Go to Settings, then Media, and set a hard maximum for large images. WordPress will scale down on upload. For most sites, 1,600 pixels wide is generous. Blog images rarely need more than 1,200. Set it once and every future upload is handled automatically. This is one of those quiet adjustments that pays off for the life of the site. Convert to WebP, Not Just Compress JPEG compression is not the answer it was five years ago. WebP serves roughly the same visual quality at 25-35% smaller file sizes, and browser support is now essentially universal. If your images are still being served as JPEGs or PNGs, you are carrying unnecessary weight on every page load. Most reputable image plugins handle WebP conversion on upload, but check the setting is actually switched on. Some plugins default to converting only when a WebP-capable browser is detected, then serve the original otherwise. That split logic adds complexity and can slow things down. A cleaner approach is to convert everything to WebP at upload and serve that file to everyone. We'd argue WordPress is the most flexible content platform ever built, powering well over 40% of the internet, which is exactly why getting these defaults right matters so much across so many sites. For a detailed look at where plugins do and don't handle this reliably, the post on what image plugins commonly miss covers the gaps worth knowing about. Lazy Load Below-the-Fold Images WordPress has had native lazy loading since version 5.5. For images that appear below the fold, the browser waits until the user scrolls near them before fetching the file. That means the initial page load is faster, and users who never scroll don't download images they never see. The setting is automatic for most images, but check your theme and any page builder you're using. Some override the native behaviour, or add loading="eager" to images that should be lazy. One place you do NOT want lazy loading is the hero image or any image visible without scrolling. Google's Largest Contentful Paint measurement is often that top image, and lazy loading it will hurt your LCP score directly. Only Generate the Thumbnail Sizes You Actually Use By default, WordPress generates multiple thumbnail sizes every time you upload an image. Large, medium, medium-large, thumbnail, plus whatever your theme registers on top of that. A single upload can create six or seven files. Most of them are never used. Unused image sizes waste storage and slow down uploads. More importantly, they clutter the media library and make it harder to see what is actually being served. You can disable unneeded sizes via functions.php or a lightweight plugin. First, audit what sizes your theme genuinely calls. Then remove everything else. It is a small job but one that compounds across hundreds of uploads. Use Responsive Images Properly The srcset attribute tells the browser which version of an image to load based on screen size. WordPress generates this automatically, but only if the right intermediate sizes exist in the first place. If you have stripped out too many thumbnail sizes, or uploaded images that are too small to begin with, the srcset will be thin or missing entirely. A mobile visitor on a 390-pixel-wide screen should not be downloading the same file as someone on a 27-inch monitor. Check your images in the browser's developer tools. Look at the Network tab, filter by images, and see what size is actually being fetched. If a 1,400-pixel image is loading on a phone, the srcset is not doing its job. For a more thorough walkthrough of file size, format and lazy load decisions together, the guide on WordPress image file size, format and lazy load goes into the detail. One Setting People Overlook: Image Quality on Resize When WordPress scales an image down, it applies a default quality setting of 82 for JPEG output. That is actually reasonable. Some plugins drop this to 60 or lower in the name of compression, and the results show, particularly on product photos or anything with fine detail. Higher compression is not always better. A blurry image that loads fast still looks cheap. Set quality at 80-85 and let format choice do the heavy lifting instead. WebP at 82 quality will outperform a JPEG at 60 on both file size and appearance. ------------------------------------------------------------ # Google Search Console for Beginners: What Each Report Tells You Source: https://yorkshiredesign.co.uk/google-search-console-for-beginners-what-each-report-tells-you/ Published: 2026-07-27 > Google Search Console is free, it connects directly to Google's own data, and most small business owners never look at it. That's a genuine shame, because it shows you exactly how Google sees your site, which pages are being found, which ones are being ignored, and where things are going quietly wrong. You don't need to be technical to get value from it. You just need to know which report does what. Start Here: The Performance Report This is the one most people open first, and for good reason. The Performance report shows how your site appears in Google Search over time. Four numbers sit at the top, total clicks, total impressions, average click-through rate, and average position. Clicks are the people who actually visited your site from a search result. Impressions are how many times your pages appeared in results, whether anyone clicked or not. A page can rack up thousands of impressions and almost no clicks, which usually means it's ranking but the title or description isn't convincing enough to earn the tap. Scroll down and you'll see the queries people searched before finding your site. This is genuinely useful. You'll often spot searches you never consciously targeted, which can shape what you write about next. You can also switch the view to 'Pages' to see which specific pages are doing the heavy lifting. URL Inspection: What Google Actually Sees Paste any URL from your site into the search bar at the top and hit Enter. Search Console fetches Google's most recent cached version of that page and tells you whether it's been indexed, when it was last crawled, and whether anything blocked it. This is the first thing worth checking when a page isn't showing up in search results. Nine times out of ten, the answer is either a noindex tag left on by accident, a crawling block in the site's robots.txt file, or a canonical tag pointing Google at a different page entirely. URL Inspection surfaces all of that in one place without you needing to dig through code. Coverage: Which Pages Google Has (and Hasn't) Indexed The Coverage report, now folded into the broader 'Indexing' section in the current interface, lists every URL Google has tried to process. Pages fall into four buckets, error, valid with warnings, valid, and excluded. The errors are the urgent ones. A 'submitted URL not found' means you've asked Google to index a page that returns a 404. A 'server error' means Google couldn't reach the page at all when it tried to crawl it. Neither of those pages will rank. The excluded list is worth a look too. Pages marked 'crawled but not indexed' sit in a grey zone where Google visited the page but decided not to include it. That happens often because the content is too thin or too similar to something else on the site. It's a signal worth acting on rather than ignoring. Core Web Vitals: Speed From Google's Point of View The Core Web Vitals report shows how real visitors experience your pages on both mobile and desktop. It groups URLs into three buckets, good, needs improvement, and poor. The scores come from real Chrome users visiting your site, not a lab test, so they reflect actual conditions. A common source of 'poor' scores is Largest Contentful Paint, which measures how long it takes the main content of a page to appear. Heavy images, slow server response times, and render-blocking scripts all push that number up. If you want to dig into what's causing the drag, Google's own PageSpeed Insights tool runs against any URL and breaks down exactly what's holding it back. For a plain-English explanation of what these metrics actually measure, the PageSpeed by Google breakdown on this site covers each one without the jargon. Sitemaps: Telling Google Where to Look A sitemap is a file that lists every page you want Google to know about. Submitting one through Search Console doesn't guarantee indexing, but it does make sure Google isn't missing pages simply because nothing links to them. Most WordPress sites generate a sitemap automatically. Once you've submitted it, the Sitemaps report shows how many URLs were submitted and how many Google actually discovered. A large gap between those two numbers usually points to a coverage problem worth investigating. One Thing People Consistently Get Wrong Search Console shows historical data, not live data. There's typically a delay of a few days before fresh information appears in the reports. So if you fix a technical error and open the console the next morning expecting the red bar to have disappeared, it probably won't have. That's not a fault. It's just how the system works, and patience genuinely matters here. Getting the console connected properly is the first step. If you haven't done that yet, the setup guide for small business sites walks through the verification process from scratch. ------------------------------------------------------------ # AI Tools for Small Businesses: What Actually Saves Time Source: https://yorkshiredesign.co.uk/ai-tools-for-small-businesses-what-actually-saves-time/ Published: 2026-07-27 > The AI tools market is noisy right now. Every platform promises to save you hours a week, and most of them say it with the same breathless language. The honest truth is that some of these tools genuinely do cut out repetitive work, and some are just a new layer of faff sitting on top of the old faff. This post looks at where AI automation tools for small business actually earn their keep, and where the hype outruns the reality. Start with the task, not the tool The biggest mistake is picking a tool first and then hunting for something to do with it. That approach wastes money and creates busy-work dressed up as productivity. Start with the tasks in your week that are repetitive, predictable, and dull. Those are the ones worth automating. Think about chasing invoices, responding to the same enquiry emails, reformatting content for different platforms, or scheduling posts. None of these require human judgement. That is exactly where automation earns its place. Customer enquiries and inbox management For most small businesses, the inbox is the single biggest time drain. AI tools like Zapier, Make (formerly Integromat), and even a well-configured Gmail filter chain with an AI layer can triage, tag, and draft responses to common queries in seconds. The realistic expectation here is not a fully hands-off inbox. It is a sorted, pre-answered inbox that cuts your active processing time by a meaningful chunk each day. If you get twenty similar enquiries a week, a template-driven AI response system handles the first draft. You review and send. That alone saves serious time over a month. Content drafting versus content thinking AI writing tools are genuinely useful for the mechanical parts of content production. Turning a set of bullet points into a readable paragraph, expanding a short brief into a longer draft, or repurposing a blog post into social captions are all tasks where tools like Claude or ChatGPT perform well. Where people go wrong is expecting the tool to do the thinking. It cannot tell you what angle to take, what your customers actually care about, or whether a claim is accurate for your specific business. That part still needs you. Use AI to handle the typing, not the strategy. For a comparison of where AI writing helps versus where it quietly makes content worse, there are practical use cases broken down by task type worth reading before you commit to a tool. The LLMs.txt myth A common issue we see is small businesses being charged a premium for "AI optimisation" that amounts to little more than adding an LLMs.txt file to their site. The truth is straightforward, if your SEO is already solid and your content is decent, flipping on LLMs.txt takes minutes. It is not complicated, it is not proprietary, and it should not cost you hundreds of pounds. The value is in the underlying SEO work, not the file. Automation stacks worth considering Not every business needs the same setup. A rough way to think about it by business type and volume: Freelancers and sole traders: Zapier free tier plus an AI writing tool covers most needs. Focus on automating appointment reminders, invoice follow-ups, and social scheduling. Service businesses with regular client contact: A CRM with built-in AI (HubSpot's free tier, for example) plus an email automation sequence removes most of the manual chasing. E-commerce or product businesses: Inventory update emails, order confirmation sequences, and review request triggers are all low-effort automations with a clear return. If you are weighing up where to put your first hour of setup time, this guide on getting started without wasting budget gives a sensible starting sequence. What is genuinely not worth your time AI image generation tools are seductive but slow to get right for business use. Getting a consistent, on-brand output requires significant prompt engineering and iteration. For most small businesses, buying stock photography or hiring a designer for key visuals is still faster. Chatbots on small business websites also tend to underperform unless the training data is deep and the maintenance is ongoing. A poorly configured chatbot frustrates visitors more than it helps them. If you cannot commit to maintaining it properly, a well-written contact form and a clear phone number do the job better. The search demand around AI marketing automation has risen sharply, which means more vendors are selling AI-flavoured products that are really just old software with a new label. If the tool cannot explain in plain English exactly what it automates and how, skip it. The measure of a useful tool A good AI automation tool for a small business should pass one simple test, does it remove a task you were doing manually, or does it add a new task to manage the tool itself? If it is the latter, the maths rarely works out. The best tools sit quietly in the background and only surface when something needs your attention. Getting that right takes a bit of setup time upfront. But once it is running properly, the payoff compounds. That is the kind of work worth doing slowly and carefully rather than rushing for a quick result. ------------------------------------------------------------ # AI Tools That Actually Help Content Writers Produce Better Work Source: https://yorkshiredesign.co.uk/ai-tools-that-actually-help-content-writers-produce-better-work/ Published: 2026-07-27 > Most writers come to AI tools with either too much hope or too much suspicion. The reality sits somewhere in the middle. The right tools can genuinely speed up the boring parts of the job, sharpen your research, and help you get a cleaner first draft onto the page faster. The wrong ones will homogenise your voice and hand you something that reads like every other article on the internet. This post walks through where AI actually earns its place in a writing workflow, and where it quietly makes things worse. What AI tools for content writers actually do At their core, AI writing tools do one of four things. They generate text from a prompt, suggest edits to text you have already written, summarise longer source material, or help you map out a structure before you start. Each of those has a genuinely useful application. None of them replaces the thinking, the judgement, or the experience that makes a piece worth reading. That distinction matters more than most people admit. A tool that generates a 1,000-word blog post in 30 seconds has not done the hard work. It has shuffled together patterns from other people's writing and handed them back to you. The writer's job is knowing what to keep, what to cut, and what to add from real knowledge of the subject. Research and ideation, where AI genuinely saves time The most honest use for AI in a content workflow is early-stage research. Feeding a tool a broad topic and asking it to surface related angles, common questions, or gaps you might have missed takes minutes. Doing the same manually across forums, search results, and competitor articles can take hours. Tools like ChatGPT or Claude are particularly good at synthesising a subject you are not deeply familiar with into a starting-point summary. That summary is not publishable, but it gives you enough grounding to ask better questions and spot where your own knowledge adds something the AI simply cannot. For ideation, AI is useful for generating a list of ten angles on a topic, then helping you pick the two that are actually distinct and worth writing about. The quality of that brief still depends on the human steering it. Drafting, use it as a scaffold, not a finished wall AI-generated first drafts are almost always flat. They cover the obvious points, they hedge constantly, and they lack the specific, lived detail that makes readers trust what they are reading. Used as a scaffold, though, they are genuinely helpful. Paste in a rough outline, generate a skeleton, then rewrite every sentence with your own voice and real examples. The writers who get the most out of AI drafting are the ones who treat it like a rough sketch on a whiteboard, not a wall they are about to paint. They know their subject well enough to spot where the AI has gone vague or wrong, and they replace those parts rather than publishing them. This is also where the risk sits. Publish the scaffold unchanged and you get content that sounds like everyone else's content. We would argue that making content in bulk this way is usually counterproductive. Pages start competing with each other, keywords cannibalise, and the overall site ends up weaker for it. A smaller number of carefully considered pieces, built around what you genuinely know, tends to serve a site far better. Editing and refinement, often the strongest use case For many writers, AI editing tools are more useful than AI drafting tools. Grammarly, Hemingway, and similar apps flag passive voice, sentence complexity, and readability issues in seconds. That kind of structural feedback, done manually, takes a second read and a lot of coffee. You can also paste a completed draft into a conversational AI and ask it specific questions. Ask it to find any paragraph where the argument goes circular. Ask it to flag claims that need a source. Ask it to suggest a tighter way to open the piece. These are genuine editing tasks, and AI handles them with a consistency that is hard to match when you have been staring at the same 800 words for two hours. Where AI tools make content worse, not better There is a specific failure mode worth naming. Writers who rely on AI for the actual thinking, not just the process, end up producing pieces that say nothing new. The AI draws from existing content, so a piece built entirely on its output is, at best, a slightly worse version of what already ranks. Readers notice this, even if they cannot name it. There is a particular flatness to AI-led content, a sense that the writer never actually had a view. For a more detailed look at where this goes wrong, the specific traps AI writing tools set are worth understanding before you build them into your process. Also worth noting: AI tools are not fact-checkers. They produce confident-sounding text regardless of whether the underlying claim is accurate. Every statistic, quote, and specific claim needs a human to verify it. Fitting AI tools into a realistic content workflow A sensible workflow looks roughly like this. Use AI to surface topic angles and related questions during research. Write your own outline based on what you actually know and what the reader genuinely needs. Use AI to generate a rough scaffold if you are stuck, then rewrite it substantially. Use an editing tool to tighten the final draft for readability and structure. Fact-check everything independently before publishing. If you are curious about which tools fit which part of that process, this breakdown of AI tools by workflow stage is a practical starting point. The tools are good. But the quality of the thinking you bring to them is still what determines whether the finished piece is worth reading. ------------------------------------------------------------ # The Quiet Death of Keyword Stuffing and What Replaced It Source: https://yorkshiredesign.co.uk/the-quiet-death-of-keyword-stuffing-and-what-replaced-it/ Published: 2026-07-27 > Most people who stumble onto SEO advice for the first time still hear the same suggestion, use your keyword as often as possible. Repeat it in the title, the headings, the first paragraph, the last paragraph. It sounds logical. More mentions equals more relevance, right? That was roughly true in the early 2000s. Google's understanding of language has moved so far beyond that thinking now that obsessing over keyword density can actually hurt a page more than it helps. Where the Myth Came FromEarly search engines were unsophisticated. They matched keywords against pages in a fairly mechanical way, so stuffing a page with a phrase worked. Webmasters exploited it hard, hiding white text on white backgrounds, cramming footers with hundreds of keyword variants. Google noticed. A long sequence of algorithm updates, beginning with Panda and continuing through to BERT and beyond, gradually dismantled the whole approach.That word 'gradually' is doing real work. It did not happen overnight, and a lot of outdated SEO advice still circulates as though it never happened at all.Myth: Keyword Density Has a Magic NumberYou will still find articles claiming you need a keyword density of exactly 1% or 2% to rank. There is no credible basis for a fixed target. Google does not publish a density threshold, and its own guidance has consistently pointed away from that kind of mechanical thinking for years.What matters is whether the page reads naturally and covers the topic with genuine depth. A page that mentions a phrase seven times in three paragraphs because someone is chasing a percentage will read awkwardly, and readers notice. Bounce rates climb. Dwell time drops. Those behavioural signals feed back into how a page performs.What Google Actually Looks at NowGoogle's systems, particularly its understanding of natural language through models like BERT, parse the meaning of a page rather than counting words. A page about replacing a car tyre does not need the phrase 'replace car tyre' twenty times. It needs to cover the subject thoroughly, the tools required, the safety steps, the common mistakes, what to do if a wheel nut is seized. That semantic depth is what signals relevance now.There is also the question of topical authority. A site that publishes a handful of thinly-written pages around one keyword is less likely to rank than a site that covers a subject from multiple angles over time. Breadth and depth together build the kind of authority that persists through algorithm updates. For anyone trying to understand what signals genuinely move rankings, our breakdown of the SEO metrics worth paying attention to is a good place to start cutting through the noise.Myth: Exact Match is Still KingPeople still build pages targeting a single exact phrase and write every sentence around cramming that phrase in. Google has understood synonyms and related terms for a long time. 'Best walking boots' and 'top hiking footwear' are the same query in any sensible reading. Writing content that covers the topic naturally will pick up variations automatically, without you needing to manufacture them.Forcing exact match into headings and anchor text where it sounds unnatural is one of the clearest signals of old-fashioned SEO thinking. Real editorial copy does not read like that. Google has got very good at telling the difference.What to Do InsteadThe approach that actually works is less exciting to explain, which is probably why it gets ignored in favour of tricks. Write a page that answers the question better than any competing page does. Cover the subject from every reasonable angle a reader might care about. Use clear headings, make the structure logical, and get to the point fast.Research what questions people actually ask around a topic, not just which phrases have search volume.Look at the pages already ranking and identify what they are missing, then cover that ground.Write for a reader who is slightly impatient. If the answer to their question takes three paragraphs to reach, they will leave before they get there.Build internal links between related content so Google can map the breadth of your subject matter across the site.Voice search has pushed this further. Conversational queries are now a significant share of search traffic, and they rarely match the keyword-dense patterns that stuffing was built around. A page optimised for how voice search phrases questions will read nothing like a stuffed page from fifteen years ago.The One Thing People Still Get WrongEven among people who know keyword stuffing is out, there is a tendency to over-engineer the focus keyword into every heading. The H1, then a couple of H2s, then the meta description, all using the exact same phrase. It ends up reading like a template rather than an article.Headings should describe what a section actually contains. If the focus keyword fits naturally, use it. If a variation reads better, use that instead.Google is not counting how many times your target phrase appears in heading tags. It is trying to understand whether your page genuinely answers what someone searched for. Those are very different things, and confusing them is still one of the most common mistakes a solid page can make.Good SEO content starts with a clear understanding of what search engines are actually rewarding, not a checklist of boxes to tick. The fundamentals have not changed. The tactics that used to chase them have. ------------------------------------------------------------ # Core Web Vitals Explained Without the Technical Jargon Source: https://yorkshiredesign.co.uk/core-web-vitals-explained-without-the-technical-jargon/ Published: 2026-07-27 > If you've ever seen the phrase 'Core Web Vitals' in Google Search Console and quietly closed the tab, you're not alone. The name sounds like something out of a hospital, and most explanations don't help. But the idea behind it is genuinely simple. Google measures how your website feels to use, not just whether it loads. Three specific signals do that measuring, and together they tell Google whether your site is worth sending people to. What Google Is Actually Measuring Core Web Vitals are three real-world performance signals that Google uses to judge the experience of visiting a page. They're not about code quality in the abstract. They're about what a visitor feels in those first few seconds, does the page show up quickly, does it respond when they tap something, does the layout stay still while it loads? Google has been open about using these signals as a ranking factor. A page that performs badly on all three is at a disadvantage, even if its content is strong. It's not the only ranking factor, but it's one you can actually measure and fix. The First Signal: LCP (Largest Contentful Paint) LCP measures how long it takes for the biggest visible element on your page to fully appear. That's usually a hero image, a large heading, or a banner photo near the top of the page. Think of it this way. You click a link and the page starts loading. LCP is the moment the main thing you came to see actually shows up. Google's benchmark is under 2.5 seconds. Above 4 seconds is considered poor. A slow LCP is often caused by a large, unoptimised image, a slow server, or render-blocking code that holds everything up while it runs in the background. The fix isn't always obvious from the surface. That's why a proper look under the bonnet matters far more than running a quick speed test and calling it done. The Second Signal: INP (Interaction to Next Paint) INP replaced an older metric called FID in early 2024. Where FID only measured the very first time a user clicked something, INP watches the whole visit. It tracks how quickly the page responds to every tap, click, or keypress throughout the session. If a visitor clicks a button on your contact form and nothing happens for half a second, that registers. If they tap a menu item and the page freezes briefly, that registers too. A good INP score is under 200 milliseconds. Above 500 milliseconds is a problem. INP issues usually point to too much JavaScript running on the main thread, which is the part of the browser doing all the visible work. Heavy plugins, tracking scripts, and bloated page builders are the common culprits here. The Third Signal: CLS (Cumulative Layout Shift) CLS measures how much the page jumps around while it loads. You've probably experienced this without knowing the name for it. You go to tap a link, the page shifts as an image loads above it, and you accidentally tap something else entirely. Google scores CLS on a scale where 0 is perfect and anything above 0.1 starts to hurt you. Common causes include images without defined dimensions, fonts swapping in late, and ads or banners that appear after the rest of the page has already settled. This one is worth getting right for user experience alone, before you even think about rankings. A page that keeps shifting is genuinely annoying to use, and visitors leave. Why All Three Matter Together Each signal catches a different failure mode. LCP catches slow loading. INP catches a sluggish, unresponsive page. CLS catches visual instability. A site can pass two and still have a rough score overall because of the third. The practical guide to how LCP, INP and CLS interact with rankings goes deeper on each metric, but the short version is that Google wants to be confident the page it sends someone to won't frustrate them within the first few seconds. What a Bad Score Actually Looks Like in Practice Picture a small business site built on a cheap shared host, running a page builder with twenty active plugins. The homepage loads slowly because the server is under-resourced. A large uncompressed banner image pushes the LCP past four seconds. Three different analytics and chat scripts fight for the main thread, dragging the INP up. And because no image dimensions were set in the theme, the whole layout jumps twice before it settles. That site can have genuinely good content and still rank below a competitor with a cleaner, faster setup. The work to fix it happens at the server level, in the theme code, and in the image pipeline. None of it is visible to the visitor once it's done, but the difference in feel is immediate. A site like Bedford House Clearance is a good example of how a simple, well-built site can recover top Google rankings for multiple keywords, without doing anything flashy. Where to Start If Your Scores Are Poor Google's PageSpeed Insights tool gives you a free read of all three signals for any public URL. It shows real-world field data where available, not just a lab simulation. Start there. Look at which signal is failing, then trace back to the likely cause. If you want a more thorough look at what's actually dragging your scores down, the kind of technical audit that covers performance issues will usually surface the culprits much faster than trial and error. The specific WordPress fixes that move Core Web Vitals scores are often more targeted than people expect. Good scores don't happen overnight. But once you know what each signal is actually measuring, at least you know what you're working toward. ------------------------------------------------------------ # 7 Ways Heavy Fonts Are Quietly Killing Your Page Speed Source: https://yorkshiredesign.co.uk/7-ways-heavy-fonts-are-quietly-killing-your-page-speed/ Published: 2026-07-27 > Most site owners hunt for speed problems in the obvious places, images, plugins, hosting. Fonts rarely make the list. But a poorly configured typeface can block rendering, trigger layout shifts, and add several hundred kilobytes before a single word appears on screen. The connection between fonts and load speed is tighter than most people realise, and the fixes are often straightforward once you know what to look for. 1. You're loading every weight and style, not just the ones you use Google Fonts and most font services let you request a whole family in one go. The problem is that "one go" often pulls in Regular, Bold, Italic, Bold Italic, Light, and more, even if your site only ever renders two of them. Each weight is a separate file. Load six when you need two and you've tripled the font payload for no reason. Check your font embed code and strip it back to only the weights your CSS actually calls. On WordPress, most themes let you control this in the customiser or through a lightweight plugin, though adding more plugins to solve a plugin problem is rarely the cleanest answer. 2. Render-blocking font requests are stalling your Largest Contentful Paint By default, a browser that hits a font request in the <head> has to fetch that file before it can paint text to the screen. That wait inflates your Largest Contentful Paint score directly. Google's own Core Web Vitals guidance flags LCP as one of the three signals that carry real weight in search ranking. The fix is preloading your critical font files with a <link rel="preload"> tag. This tells the browser to fetch the font early, in parallel with everything else, rather than waiting for the CSS to discover it. Small change, measurable payoff. 3. FOUT and CLS are symptoms of missing font-display settings Flash of Unstyled Text happens when a browser renders a page using a fallback system font, then swaps it out once the web font loads. That swap causes a layout shift, which shows up in your Cumulative Layout Shift score. A common issue we see is sites failing Core Web Vitals almost entirely because of font swaps moving content around mid-load. Setting font-display, swap in your CSS tells the browser to show the fallback immediately and swap it when ready, keeping content visible without a blank flash. It's part of the CSS font spec and costs nothing to implement. 4. Self-hosted fonts often outperform Google Fonts on TTFB Google Fonts is convenient, but every request goes to Google's servers first. That's a separate DNS lookup, a separate TCP connection, and a separate SSL handshake before the font data even starts moving. On a fast connection it's barely noticeable. On a slower mobile network it adds up fast. Self-hosting your fonts removes that round trip entirely. Tools like Google Webfonts Helper make it straightforward to download the files and write the CSS yourself. The first-connection overhead disappears, and your own server response time governs delivery rather than a third-party CDN you have no control over. 5. Variable fonts can cut file size significantly A variable font is a single file containing multiple weights and styles. Instead of requesting four separate files for Regular, Medium, Bold, and Light, you load one. Browser support is now solid across modern devices, and the size saving compared to loading four static weights is often substantial. This isn't always the right call. If you genuinely only need one weight, a standard static font file will likely be smaller than a variable one. But for sites using three or more weights, variable fonts are worth a close look. 6. Unicode subsetting stops you loading characters you'll never display Most fonts ship with support for dozens of languages and hundreds of special characters. If your site is written entirely in English, you're probably loading Cyrillic, Greek, and extended Latin characters that will never appear on the page. That's dead weight. Google Fonts handles subsetting automatically when you use their text= parameter or load via their standard URL. For self-hosted fonts, removing Google Fonts from WordPress entirely and switching to a single optimised subset file is often the cleaner route. Either way, only serve the characters your content actually needs. 7. Too many typefaces compounds every problem above Each additional font family multiplies the requests, the file sizes, the render-blocking potential, and the layout shift risk. Two families is generally the sensible ceiling for most sites. Three is where you start paying a real speed penalty. Four is where pages start feeling sluggish even before images load. This is one of those trade-offs worth being honest about. A beautifully art-directed site might genuinely need three carefully chosen typefaces. Most business sites, though, use extra fonts out of habit rather than design necessity. A second look at your font stack with a speed audit tool like PageSpeed Insights will usually show exactly what each additional family is costing you in load time. Common font performance issues by impact on load time Loading unused weights , highest impact Missing preload on critical fonts , very high Third-party font DNS overhead , high No font-display swap , medium to high No unicode subsetting , medium ------------------------------------------------------------ # Write a Brief That Actually Gets You a Better Website Source: https://yorkshiredesign.co.uk/write-a-brief-that-actually-gets-you-a-better-website/ Published: 2026-07-27 > Most website projects go sideways before a single line of code gets written. Not because the designer is bad, or the client is difficult, but because the brief was vague. 'Something clean and modern' tells a developer almost nothing. A good brief cuts revision rounds, keeps costs predictable, and means the site you get actually matches what you pictured. Here is how to write one that does all three. Start With the Outcome, Not the Design The single biggest mistake in a website brief is describing how you want the site to look before explaining what it needs to do. A developer can suggest colours and layouts. What they cannot guess is your business goal. So open your brief with a plain sentence about the outcome. 'We want visitors to book a free consultation' is a brief. 'We want a nice homepage' is not. Every decision that follows, from navigation to page structure to call-to-action placement, flows from that one clear objective. Describe Your Audience With Specifics Saying your audience is 'everyone' is the second most common brief problem. It forces a designer to make assumptions, and assumptions cost you revision time later. Think about who actually buys from you. Are they browsing on a phone during a lunch break, or sitting at a desktop comparing suppliers? Do they arrive already knowing what they want, or do they need convincing first? Even a rough sketch of that person, their situation, their question, their hesitation, shapes a better site than a mood board ever will. If you serve more than one type of visitor, name them separately. A designer can build navigation paths that serve both. They cannot do that if both are bundled into one vague description. List Your Pages and What Each One Must Do A sitemap does not need to be a polished document. A numbered list in a plain text email works fine. What matters is that it exists. For each page, write one sentence about its job. The About page builds trust. The Services page explains the offer. The Contact page removes every reason not to get in touch. When a developer knows the purpose of a page, they can structure it to serve that purpose rather than guessing from the title alone. One thing worth flagging here, if you have existing content, say so. If you need content written, say that too. Content is often the single biggest delay in a web project, and a brief that ignores it will run over time almost every time. You can find more on this when thinking about how copy and page structure interact at the ranking level. Include Reference Sites, and Say Why You Like Them Three to five websites you admire are worth more than a paragraph of adjectives. But a link alone is not quite enough. Note what you actually like about each one. Is it the speed? The layout? The way the navigation is organised? 'I like how this one loads instantly and the menu stays out of the way' tells a developer something real. 'I like this one' tells them nothing except that you have seen it. The same logic applies to sites you dislike. If there is a style you actively want to avoid, say so. Designers are not mind readers, and ruling out a direction early is far cheaper than reversing it after build. Be Honest About Budget and Timeline Many clients hold back on budget because they worry it anchors the price upward. In practice, the opposite is more common. A developer who does not know the budget either scopes something too large and shocks you with the quote, or scopes something too small and leaves you disappointed with what arrives. If you want to know what a realistic budget actually covers, our UK website cost breakdown is a useful starting point before you write the brief. On timeline, be realistic. A properly built, well-optimised site takes time. Anyone promising a full site in 48 hours is either templating heavily or cutting corners you will notice later. Give a rough launch window and flag any hard deadlines, such as a product launch or an event. That context helps a developer plan the build in a way that actually hits the date. The One Thing Most Briefs Forget Technical requirements. These are almost always missing, and they matter more than most clients realise. Do you need the site to connect to a booking system, a CRM, or a payment processor? Do you need multilingual support? Will you be updating the content yourself, or does someone else manage that? Are there accessibility standards you need to meet? These questions change the build significantly. A site that needs to talk to an external system is a different project to one that does not. The sooner a developer knows, the more accurately they can scope the work, and the fewer surprises appear mid-build. For anything involving automation or integrations, it is worth understanding what sits underneath the surface before you commit to a spec. Keep It Short and Send It Early A good brief does not need to be long. Two pages of clear, specific information beats a ten-page document full of padding. The goal is to give a developer enough context to ask the right follow-up questions, not to pre-answer every possible one. Send it before the first call if you can. Developers who arrive at a discovery meeting having already read a clear brief ask sharper questions, and you both leave the call with a much clearer shared picture of what gets built. ------------------------------------------------------------ # WordPress Plugins That Quietly Slow Your Site Down Source: https://yorkshiredesign.co.uk/wordpress-plugins-that-quietly-slow-your-site-down/ Published: 2026-07-26 > Not every slow site has an obvious culprit. Sometimes you've done the basics right , decent hosting, a lightweight theme, compressed images , and the site still drags. Nine times out of ten, the answer is sitting in the plugins list. A few poorly built plugins can quietly undo everything else you've done right, and the frustrating part is they rarely announce themselves. No error message. No warning. Just a site that feels heavier than it should. Page Builders That Load Everything, Every Time Page builders are the most common offender. Tools like Elementor or Divi load their full asset stack on every single page, even pages that were built with plain text and a basic layout. A simple contact page ends up carrying the CSS and JavaScript for sliders, accordions, and animation libraries it never actually uses. The fix is rarely "uninstall the builder". It's more nuanced than that. What you're looking for is whether the builder supports asset loading on a per-page basis, and whether your hosting stack can cache those assets aggressively enough to soften the blow. If neither is true, you're carrying dead weight on every request. Social Sharing and Feed Plugins Social plugins are deceptively heavy. A Facebook feed widget or a Twitter timeline doesn't just show a few posts. It loads a third-party JavaScript file from an external server, then waits for that server to respond before your page finishes rendering. If that external server is slow or briefly unavailable, your page hangs with it. The same applies to social sharing buttons. Most sharing plugins load a script for every network they support, whether those networks are relevant to your audience or not. A performance audit on your plugin list will often show these as the largest contributors to render-blocking time. Static sharing buttons built into your theme, with no external scripts, almost always perform better. Sliders and Carousels Sliders had their moment, but the performance cost has never been worth it. Most slider plugins load a JavaScript library, a CSS file, and several large images on page load, even if the slider is buried halfway down the page and most visitors never scroll to it. Google's own guidance on Core Web Vitals flags this kind of above-the-fold image loading as a direct contributor to poor Largest Contentful Paint scores. A static hero image, properly sized and served in a modern format like WebP, will outperform a five-slide carousel on every metric that matters for ranking and user experience. Backup Plugins Running During Peak Hours Backup plugins are essential. The performance problem isn't the plugin itself. It's when it runs. A full-site backup during your busiest traffic window puts real strain on the server, because database reads, file compression, and storage writes all compete with live page requests at exactly the wrong moment. Check your backup schedule. Most plugins default to whatever time they were first activated, which is often midday. Move it to somewhere between 2am and 4am, and make sure incremental backups are turned on if your plugin supports them. That alone can remove a noticeable spike from your server load. Contact Form Plugins That Pull In Too Much Contact form plugins are a good example of where reputation doesn't guarantee efficiency. Some of the most widely used ones load their scripts and styles globally, on every page of the site, even pages with no form on them at all. A product page, a blog post, a homepage, all carrying form assets they'll never render. The honest fix is either switching to a lighter alternative or using a plugin that supports conditional loading. Gravity Forms and Fluent Forms both handle this reasonably well. If you're using a caching or optimisation setup already, you can sometimes exclude those scripts from non-form pages manually, but it takes a bit of digging to get right. How to Actually Spot the Problem Run your URL through Google PageSpeed Insights and look at the "Reduce unused JavaScript" and "Eliminate render-blocking resources" recommendations. Both will usually name the scripts involved. Cross-reference those filenames against your plugin list. Most have recognisable folder names in their paths. A faster method is a selective deactivation test. Disable plugins in small groups, clear cache after each batch, and rerun the speed test. It's methodical work, but it's the most reliable way to find a poorly behaved plugin without guessing. In our experience with WordPress hosting setups, the worst offenders are almost never the ones you'd suspect first. Worth keeping in mind too, removing a plugin isn't always the right answer. Sometimes the better move is configuring it properly, loading it conditionally, or replacing it with a lighter alternative that does the same job. A fast site isn't about having fewer plugins. It's about making sure every plugin on the list is earning its place. ------------------------------------------------------------ # Managed WordPress Hosting UK: What You Actually Pay For Source: https://yorkshiredesign.co.uk/managed-wordpress-hosting-uk-what-you-actually-pay-for/ Published: 2026-07-26 > Most people assume managed WordPress hosting is just shared hosting with a fancier label. It isn't. The price difference is real, and so is what sits behind it. But the gap between a genuinely managed environment and one that just calls itself managed is wider than most site owners realise. Before you commit to a monthly plan, it's worth understanding what you're actually buying, because not every provider gives you the same thing for the same price. The myth that all managed hosting is the same Look at any comparison page and the plans all sound identical. Server-level caching. Daily backups. Automatic updates. Staging environments. The marketing language is practically interchangeable. What differs is how well any of it actually works under load, and whether the infrastructure has been tuned for WordPress specifically or just bolted onto a generic cloud setup. A true managed WordPress host runs PHP-FPM configured for WordPress, object caching at the server level with something like Redis, and a CDN that doesn't rely entirely on you configuring it correctly. A hosting company that ticks boxes on a features list may have none of that wired up properly. The only way to tell them apart is to dig into the technical spec, not the marketing copy. What the price actually covers Managed WordPress hosting in the UK typically runs from around £20 a month at the entry level to well over £100 for higher-traffic or multi-site plans. That price is paying for several things that cheap shared hosting simply doesn't include. Server environments built specifically around how WordPress handles PHP, database queries and static assets Automatic core and plugin updates with rollback capability if something breaks Isolated containers so one compromised site on the same server doesn't affect yours Support teams who actually know WordPress, not generic ticketing staff reading from a script The last point matters more than people give it credit for. When something breaks at 11pm on a Friday, having someone who can spot a plugin conflict versus a server configuration issue is worth a significant amount on its own. That kind of specialist knowledge doesn't come with a £3-a-month shared plan. What most people overlook when comparing plans The spec sheet rarely tells the whole story. One thing worth checking before anything else is whether the server cache gets cleared after any maintenance or update work. This sounds minor. It isn't. In our experience, one of the most common problems we've seen is a site that looks perfectly fine after an update, but only because the old cached version is still being served. The developer, the host, and the client all sign off thinking everything is good. Then the cache expires naturally, days or weeks later, and the real state of the site becomes visible. Broken layouts, missing fonts, a checkout that no longer works. You paid for work on a site that was never properly checked in its live state. Always make sure the server cache has been fully cleared and flushed before anyone signs off on a job. The PageSpeed score trap A number of providers market their managed hosting on the back of PageSpeed Insights scores. High scores, fast sites, job done. This is a misleading way to sell hosting, and it's worth being direct about why. Google does not use the PageSpeed Insights score as a ranking signal. It is a diagnostic tool, written for developers, designed to surface opportunities for improvement. Chasing a number in that tool, rather than measuring real-world performance through the metrics that actually affect how fast a site feels to a visitor, is a shortcut that often backfires. A host that leads with PageSpeed scores in its marketing is telling you something about its priorities. Core Web Vitals, measured in the field via Chrome User Experience Report data, are what Google actually looks at. Time to First Byte, Largest Contentful Paint, Interaction to Next Paint. These reflect real users on real connections, not a lab test run in ideal conditions. When managed hosting is genuinely worth it For a simple brochure site with modest traffic, a well-configured shared or semi-managed plan can absolutely do the job. Spending £80 a month on a site that gets 200 visitors a week is hard to justify on performance grounds alone. Where managed hosting earns its cost is with sites that carry real business weight. E-commerce, membership platforms, booking systems, anything where downtime has a direct financial cost. For those, the isolation, the specialist support, and the infrastructure designed around WordPress rather than adapted for it are not extras. They're the point. You can see a closer look at how managed and shared hosting compare on measurable performance factors to get a clearer sense of where the differences show up. What to actually check before you sign up Skip the feature list comparisons and ask the provider these specific questions instead. What PHP version is running and how quickly do you move to new versions after release? Is object caching enabled at the server level, or do I need to configure a plugin for it? How is the staging environment connected, and does a push to live clear all cache layers automatically? What happens when a plugin update breaks the site, and how fast can you roll it back? How clearly and confidently they answer these four questions tells you far more than any comparison table. Vague answers usually mean the infrastructure is more generic than the marketing suggests. ------------------------------------------------------------ # The Real Cost of Cheap Web Hosting Over Three Years Source: https://yorkshiredesign.co.uk/the-real-cost-of-cheap-web-hosting-over-three-years/ Published: 2026-07-26 > That £1.99-a-month hosting deal looks almost too good to ignore. And for the first few weeks, it probably feels fine. The site loads, the emails arrive, nothing obviously breaks. The real cost shows up later, quietly, across dozens of small failures that each chip away at your traffic, your rankings, and your visitors' patience. Spread that over three years and the cheap plan stops looking cheap at all. 1. Downtime You Don't Notice Until It's Too LateBudget hosts cram thousands of sites onto a single shared server. When one site spikes in traffic, everyone else on that box slows down or drops off entirely. Most small business owners never see it happen because they're not watching at 2 a.m. on a Tuesday.Search engines do notice, though. Googlebot crawls on its own schedule. If your site returns a 503 error during a crawl, that page may be marked as unavailable. Do that enough times and rankings slip. A customer who clicks through from a search result to find a blank screen rarely comes back.2. Speed That Quietly Kills Your Search VisibilityGoogle's Core Web Vitals are a real ranking factor. Largest Contentful Paint, Interaction to Next Paint, Cumulative Layout Shift , these aren't abstract scores. They measure what your visitors actually feel.Cheap shared servers typically have slow Time to First Byte, often well above 600ms. That one number drags every other performance metric with it. No amount of image compression fixes a server that simply takes too long to respond. If you want to understand how slow loading affects real visitors, the gap between a fast host and a budget one is usually the single biggest factor.3. The Hidden Renewal Pricing TrapMost cheap hosting promotions are introductory rates. Year one might cost £24. Year two, the plan renews at the full rate, often £10 to £14 a month. By year three, you've spent three or four times what you budgeted for.That's before you add the upsells. Daily backups, an SSL certificate, a CDN, malware scanning , these are often sold as extras on budget plans. On a properly specced host, they're included. Do the actual maths across 36 months before assuming the cheap option saves money. Approximate 3-year cost comparison (typical UK plans, illustrative ranges only) Budget shared , ~£90 Budget shared (full renewal rate) , ~£250 Quality managed hosting (inc. extras) , ~£420 Budget plans with add-ons can close the gap considerably. The headline price rarely reflects actual spend. 4. Security Gaps That Cost Real Money to FixShared hosting environments mean you're sitting next to hundreds of other sites, some of which will be badly maintained. A compromised neighbour can affect your server. Cheap plans often skip automatic malware scanning, and when something goes wrong, the fix isn't covered.A hacked WordPress site typically takes several hours of technical work to clean properly. That's assuming the host even helps at all. Some budget providers will simply suspend your account and send you a form. Pay someone to recover the site and the total quickly exceeds what a decent host would have cost across the whole three years.5. Support That Vanishes When You Actually Need ItBudget hosts manage support volume by making it hard to reach anyone useful. Ticket response times of 48 to 72 hours are common. Live chat often connects to a script-reader who can't touch the server configuration.If your site goes down before an event, a product launch, or a busy trading period, you're on your own. That's not a technical problem , it's a business problem, and it's one that proper hosting avoids almost entirely.6. What Simple, Well-Hosted Sites Actually AchieveThe case for keeping things clean and well-hosted isn't theoretical. A customer once came to us wanting a straightforward set of websites to improve their local visibility. Nothing fancy, just well-structured, properly hosted pages that loaded quickly and gave Google nothing to complain about. They regained number one positions for multiple local keywords. The hosting environment was a non-negotiable part of that , a slow or unreliable server would have undone the rest of the work immediately.Simple sites on solid infrastructure genuinely outperform complex sites on budget servers. That's a pattern that repeats consistently.7. The Honest Trade-Off Worth KnowingNot every site needs premium managed hosting. A personal blog with low traffic and no commercial stakes can probably live on a budget plan without serious consequences. But the moment a site is tied to revenue, reputation, or search rankings, the calculation changes.The question isn't whether quality hosting costs more per month. It does. The question is whether the gap in cost is smaller than the gap in what you lose. For most small business sites, the rankings you sacrifice to cheap hosting are worth far more than the monthly saving.Three years is a long time to find that out the hard way. ------------------------------------------------------------ # How Voice Search Is Quietly Reshaping Keyword Strategy Source: https://yorkshiredesign.co.uk/how-voice-search-is-quietly-reshaping-keyword-strategy/ Published: 2026-07-26 > Most keyword strategies are still built around how people type. Short, clipped phrases, no connecting words, no full sentences. Voice search breaks that habit completely. People speak the way they think, and that means longer, more conversational queries that traditional keyword tools often miss entirely. Adjust for that shift now and your content stays relevant. Ignore it, and pages optimised for typed search quietly lose ground to sites that answer questions the way a real person would ask them. The Difference Between Typed and Spoken Queries Someone typing into Google might search "best running shoes flat feet". The same person using a voice assistant will say "what are the best running shoes if you have flat feet?" That is not a minor variation. It is a fundamentally different sentence structure, and it demands a different kind of answer. Typed queries are compressed. Spoken queries are natural, often include filler words, and almost always contain a question word. "What", "how", "where" and "which" dominate. Content that addresses those question shapes directly tends to perform better in voice results, because the search engine can lift a clean, direct answer straight from the page. Why Long-Tail Keywords Matter More Now Voice queries are almost always long-tail by nature. A user asking their phone a question rarely uses two words. They use ten. That specificity is actually an opportunity, because long-tail phrases carry clearer intent and face less competition than broad head terms. The trap most sites fall into is chasing high-volume, short keywords and leaving the specific conversational phrases unaddressed. Those longer queries often come from someone closer to making a decision, not just browsing. If your page answers the exact question they asked, you are already ahead of the sites that wrote only for the typed version. For a practical breakdown of how to structure keyword research before writing, the step-by-step SEO process here covers where conversational intent fits into planning content that actually earns traffic. How to Write Content That Voice Search Picks Up There is no mysterious trick here. Voice search favours pages that answer questions directly, in plain language, near the top of a section. A few things that consistently help are listed below. Use the actual question as a subheading, then answer it in two or three plain sentences underneath. Keep your most direct answer in the first sentence of a paragraph, not buried in the third. Write at a reading level that feels natural spoken aloud. If the sentence sounds strange said out loud, rewrite it. Structure FAQ sections around real questions people ask, not polished marketing phrases. Google's featured snippet system rewards exactly this kind of structure. A concise, confident answer sitting directly below a matching question heading is the format search engines pull from most often. Page Speed Is Not Separate From This Conversation Voice results are almost always served through mobile devices. A page that loads slowly on mobile is a page that rarely gets chosen as a voice answer, regardless of how well the content is written. Hosting choices play a bigger role in load time than most people expect, and a site sitting on an underpowered server will struggle to compete even with strong content. Core Web Vitals matter here specifically because Google's ranking signals tie page experience to how likely a page is to appear in rich results. You cannot separate the technical layer from the content layer when optimising for voice. What Most People Get Wrong About Voice SEO The most common mistake is treating voice search as a separate strategy rather than a natural extension of writing clearly. Sites stuff in question phrases without actually answering them well, or they optimise a single FAQ page and leave the rest of the site untouched. In our experience, the sites that do this best are not running any special voice SEO campaign. They just write clearly, answer questions fully, and keep their pages fast. The voice results follow. There is also a genuine trade-off worth naming. Ranking for a voice answer does not always mean more clicks. If someone gets the answer read aloud by their device, they may never visit the page. For brand awareness that is still useful, but for e-commerce pages where the click matters, voice visibility is less directly valuable than it first appears. It is worth knowing that before investing heavily in voice-specific content. The Shift in How Metrics Tell the Story Traditional SEO metrics like click-through rate become harder to read when voice is involved. Impressions may rise while clicks stay flat, because the answer was delivered without a visit. The numbers will look strange if you are only watching clicks, which is why understanding which metrics actually reflect real performance matters more as voice search grows. The direction things are heading is clear. Searches are getting more conversational, AI-driven answers are pulling from well-structured content, and the sites that have already written for real human questions will have a head start that keyword-stuffed pages simply cannot catch up to quickly. ------------------------------------------------------------ # What Really Happens to Your Site When Hosting Goes Down Source: https://yorkshiredesign.co.uk/what-really-happens-to-your-site-when-hosting-goes-down/ Published: 2026-07-26 > Most site owners only discover their hosting is down when a customer messages them about it. By that point, the damage is already spreading quietly in a few directions at once. Visitors land on an error page and leave. Crawlers hit a dead end and note it. Forms stop working. And none of this shows up in your analytics because the tracking script never even loads. Downtime is never just a brief inconvenience. It has a habit of leaving traces well after the server comes back online. What a visitor actually sees The most common error during a hosting outage is a 503 Service Unavailable response. Some hosts serve a branded error page; others return nothing at all. Either way, the visitor's browser has nothing useful to show them. First-time visitors almost never come back. Someone who finds you through a search or a shared link and hits an error page will simply try the next result. There is no loyalty at that stage. Even returning visitors who know your site will often give up after a single failed attempt rather than refreshing repeatedly. And the quieter problem is that none of this shows up in your usual reporting. Sessions that bounce off a server error are typically invisible to analytics, so you can go days without realising the scale of what you lost. What Google's crawlers do with a downed site Google's crawlers behave differently depending on how long your site is unreachable. A brief outage, say under an hour or two, usually triggers no lasting consequence. Googlebot hits the 503, notes the error, and moves on. It is designed to handle occasional hiccups. The risk grows with time. If your site stays down for several hours across multiple crawl attempts, Google may begin to reduce its crawl frequency. Extended outages, particularly anything pushing 24 hours or more, can lead to pages being dropped from the index temporarily. Google's own guidance is clear on this point. A 503 tells its systems the downtime is temporary, which is the correct signal to serve. A 500 or 404 is far more damaging because it implies the content is permanently gone. The good news is that a short, correctly-signalled outage rarely leaves a permanent mark on rankings. The bad news is that most site owners have no idea what status code their server is returning when it struggles. The knock-on effects people rarely think about Beyond visitors and crawlers, a few other things break quietly during downtime. Contact forms and enquiry flows stop dead. Any lead who fills in a form while the server is down loses their message entirely. E-commerce checkouts fail, often mid-transaction, which is one of the hardest trust signals to recover from. Third-party services that ping your site, such as uptime monitors, payment webhooks, or API callbacks, start logging failures. Scheduled tasks on WordPress, like automated backups or publishing queued posts, miss their window and may not catch up cleanly. None of these failures announce themselves. You have to go looking for them once the site is back up. What to check the moment your site comes back Restoring the server is step one. What comes next matters just as much. Start with your server logs. Check what status codes were returned during the outage window and for how long. If your host was serving 500 errors rather than 503s, flag that with them. It is worth knowing whether the problem was at the server level, the database, or a specific plugin causing fatal errors under load. Then check your technical SEO health in Search Console. Look for a spike in crawl errors around the outage window. If you see pages flagged as unavailable, request indexing again on the key ones. Google usually re-crawls quickly once it sees the site is stable. Check your forms manually by submitting a test entry. Review any WooCommerce or booking logs for failed transactions. If your site uses caching, purge it fully so visitors are not served stale error states from before the recovery. The hosting decision that makes this happen less often Cheap shared hosting puts many sites on a single server. When that server struggles, everyone on it feels it. The sites that weather outages best tend to be on hosting with genuine redundancy, proper resource isolation, and a clear SLA that includes uptime guarantees backed by credits if they are missed. Back in 2004, working alongside large directory services including Infoserve and Thomson Directories on one of the UK's first Google AdSense partner installations, the lesson that stuck was how quickly a server-level problem compounds across everything sitting above it. The technology has changed completely. The physics of a failing server have not. If you want a practical look at what separates hosting tiers before you commit, this breakdown for small UK businesses covers what the specs actually mean in real use. One thing worth doing before the next outage Set up an uptime monitor. There are free services that ping your site every minute and alert you by email or SMS the second it goes down. Most site owners find out about downtime from a customer. An uptime monitor means you find out first, which gives you a fighting chance of limiting the damage before anyone else notices. Hosting reliability is one of those things that feels invisible when it is working. It only becomes real when it stops. ------------------------------------------------------------ # Why Your Website Feels Slow Even After Optimisation Source: https://yorkshiredesign.co.uk/why-your-website-feels-slow-even-after-optimisation/ Published: 2026-07-26 > You compress the images, install a caching plugin, maybe switch to a faster host. The PageSpeed score nudges up, you breathe a sigh of relief, and then three weeks later someone tells you the site still feels sluggish. This is one of the most frustrating places to be with a website. The fixes looked right on paper. So why is nothing actually changing for the person sitting in front of the browser? The Score and the Experience Are Not the Same Thing PageSpeed Insights gives you a number. That number measures specific technical signals, but it does not perfectly capture what a real visitor feels when they land on a page and wait for it to become usable. A site can score 80 or 90 in the lab and still feel sticky in the field. The reason is that lab tests run under controlled conditions. They use a simulated device, a fixed connection speed, and no browser history. Your actual visitors arrive on a three-year-old Android phone, on a patchy 4G signal, with seventeen tabs already open. Real-world field data consistently tells a different story to the lab score, and that gap is where people get confused. Caching That Only Helps Half the Time Caching is the most commonly misunderstood fix in this space. Most WordPress caching plugins do a solid job for returning visitors because the browser already holds a local copy of the page assets. First-time visitors get none of that benefit. They hit an uncached page, and if your server is slow to generate it, that wait is entirely visible to them. There is also the question of cache lifespan. On sites that update frequently, posts being published, prices changing, forms being tweaked, the cache clears itself constantly. In practice, far more pages serve uncached than the site owner realises. Plugin settings often ship with short expiry times that nobody ever adjusts. Third-Party Scripts Are the Silent Culprit Chat widgets. Cookie banners. Facebook Pixel. Google Tag Manager firing five separate tags. Each one loads from an external server, and your site has no control over how fast that server responds on any given day. This is the thing people miss most often. You can optimise every byte of your own code and still have a slow page because a third-party script is blocking the browser from rendering. You will not see this in a basic audit. You need to look at the waterfall chart in a tool like WebPageTest, find which requests are holding everything else up, and trace them back to a specific tag or widget. A common pattern worth watching for, a site has a live chat plugin installed that the business stopped using months ago. Nobody removed it. It still loads on every page, calls an external server, and adds a second or more to the render time. Nobody notices because it is invisible to the end user except as a delay. The Host Is Still the Bottleneck A shared hosting account on an oversubscribed server will fight all the optimisation work you throw at it. Time to First Byte, the measurement of how long the server takes to respond at all, is something no amount of image compression or minification can fix. It happens before the browser has even started loading your page. Switching from a slow host to a properly provisioned one is often the single biggest improvement available. It is not glamorous, and it is not free, but it addresses the problem at the source rather than working around it. What the Tests Are Actually Measuring Google's Core Web Vitals focus on three things. How quickly the largest visible element loads, how stable the layout is as it loads, and how fast the page responds to a user's first tap or click. A common issue is that optimisation work addresses general speed without targeting any of these specific signals. You can make a page lighter overall and still have a poor Largest Contentful Paint score because the hero image loads last. The ordering of how assets load matters as much as their size. When working on sites that were failing Core Web Vitals, a common issue is a correctly compressed image that still loads too late in the sequence because no one set it to preload. Moving that one instruction can shift the LCP score significantly. Plugins Quietly Undoing the Work WordPress plugins can conflict with each other in ways that are genuinely hard to track. A page builder might inject render-blocking scripts even when you have told your performance plugin to defer them. A backup plugin might run a scheduled task mid-morning that hammers the server. An SEO plugin might add schema markup that calls an external endpoint on every page load. None of this shows up in a basic speed audit because audits test the site as it stands at one moment. The real performance can vary hour by hour depending on what is running in the background. The Honest Trade-Off There is no single fix that covers all of this. Real performance work is methodical. You test, you isolate, you change one thing at a time, and you test again. That process takes longer than running a plugin and hoping, but it is the only way to understand what is actually causing the slowdown rather than guessing. If your scores have improved but the experience has not, the answer is almost always that something specific was not looked at closely enough. The waterfall, the server response time, the third-party requests, the asset load order. The surface was cleaned without anyone looking underneath. ------------------------------------------------------------ # Kinsta Hosting Reviewed: Is It Worth the Price for UK Sites Source: https://yorkshiredesign.co.uk/kinsta-hosting-reviewed-is-it-worth-the-price-for-uk-sites/ Published: 2026-07-25 > Kinsta sits at the premium end of managed WordPress hosting. The pricing reflects that, and plenty of UK site owners look at the monthly cost and wonder whether it is genuinely justified or whether they are paying for a brand name. This review works through what Kinsta actually gives you, where it earns its keep, and the one thing that stops it being the right call for every site. What Kinsta actually is (and what it is not) Kinsta is a managed WordPress host built on Google Cloud's premium tier infrastructure. Every site runs in its own isolated container, which means one site's traffic spike cannot drag yours down. That is meaningfully different from shared hosting, where you genuinely share resources with whoever happens to be on the same server. What it is not is a general-purpose host. If you run anything other than WordPress, Kinsta will not help you. That focused scope is part of why the platform performs well, but it is worth being clear-eyed about the trade-off upfront. Performance, where the price starts to make sense Google Cloud's premium tier routes traffic through Google's own network rather than the public internet. For UK visitors hitting a site hosted on the London data centre, that routing difference is real, not marketing copy. Time to First Byte tends to be low, and the platform's built-in Nginx page caching is fast out of the box. Core Web Vitals scores on Kinsta sites tend to be naturally higher than on shared or entry-level VPS hosts, simply because the infrastructure is not fighting itself. That said, Kinsta does not fix a badly built site. If your theme is loading fifteen render-blocking scripts, a better server only does so much. The platform gives you a clean foundation. What you build on it still matters. For sites that care about performance tooling on top of their host, Kinsta's own caching layer often reduces the need for a separate plugin, though it depends on the site's complexity. The control panel: MyKinsta MyKinsta is one of the cleaner hosting dashboards available. Staging environments, one-click deploys, PHP version switching, redirect rules, and database access are all in one place. There is no cPanel, which puts some people off initially, but MyKinsta is generally easier to navigate once you are used to it. The built-in APM tool is genuinely useful. When a site slows down, you can see which queries or plugins are responsible without reaching for a separate profiler. For developers who spend time diagnosing performance issues, that alone saves a fair amount of back and forth. Support, fast, but weighted toward developers Kinsta offers 24/7 live chat support and the response times are quick. The support team knows WordPress well, which separates them from generic hosts where you often get generic answers. However, the support is clearly geared toward developers and technically confident users. If you need someone to walk you through a theme conflict from scratch, you may find the answers a touch brief. For anyone managing multiple client sites, that developer-first approach is a feature. For a sole trader running their first WordPress site, it can feel a little hands-off. The pricing, what you are actually buying Kinsta's entry plan covers a single WordPress install with a fixed monthly visitor allowance. As you scale up installs or traffic, the cost rises in meaningful steps. Compared with shared hosting, the difference is substantial. Compared with a self-managed VPS where you are spending your own time on server maintenance, the gap narrows considerably once you factor in that time. The honest framing is this. Kinsta charges for a managed service, not just server space. If managing a server, keeping PHP updated, monitoring uptime, and diagnosing infrastructure issues is not how you want to spend your week, that management overhead has a real cost whether you pay Kinsta for it or absorb it yourself. If you want a side-by-side look at how Kinsta compares to another managed option, the Kinsta vs Cloudways breakdown covers the key differences in detail. Where Kinsta is not the right fit A simple brochure site with low traffic does not need Kinsta. The infrastructure is wasted on a five-page site getting a few hundred visitors a month, and the money is genuinely better spent elsewhere. There are solid hosts at a fraction of the cost that will serve that use case perfectly well, and what cheaper hosting actually delivers is worth understanding before you commit either way. Kinsta earns its price on sites where speed has a direct commercial consequence, where downtime is costly, or where a developer needs reliable tooling and fast support. E-commerce sites, membership platforms, and high-traffic content sites sit squarely in that category. The verdict Kinsta is a well-built, well-supported managed host on solid infrastructure. It is not overpriced for what it provides, but it is only worth the cost if the site genuinely demands what it offers. Know your traffic, know your requirements, and match the host to the actual workload rather than the aspiration. ------------------------------------------------------------ # SEO Copywriting Tips That Help Pages Rank and People Read Source: https://yorkshiredesign.co.uk/seo-copywriting-tips-that-help-pages-rank-and-people-read/ Published: 2026-07-25 > Picture this. A business owner spends weeks writing a service page. It reads well, sounds professional, and covers everything a customer might want to know. Three months later, it sits on page four of Google and gets almost no clicks. The copy is fine. But 'fine' is not the same as 'built to rank'. Writing for search and writing for people are not two separate jobs. Done properly, they are exactly the same job, and the pages that get both right are the ones that hold their ground long after the competition has swapped agencies. Start With What People Are Actually Searching For Before a single word goes on the page, spend time in Google's own search results. Type in the phrase you want to rank for and look at what already sits on page one. Those results are Google's opinion of what people want when they search that term. If every top result is a how-to guide and you're writing a product page, that mismatch will cost you before anyone reads a word. Your focus keyword should appear in the page title, the first paragraph, at least one subheading, and the meta description. Not because Google is counting, but because clear, consistent language tells both the algorithm and the reader exactly what the page is about. Stuffing a keyword in every other sentence does the opposite. It reads badly, and Google knows it. Write the Opening Paragraph Like It Has to Earn the Next Click Most people make a decision about a page within a few seconds of landing on it. Your opening paragraph is doing two things at once, it tells Google what the page covers, and it convinces the reader to stay. Front-load the value. Tell them what they will get from reading, not what the page is 'about' in the abstract. A weak opener sounds like this: "In this article we will explore the many factors involved in choosing a web designer." A strong one sounds like this: "Most web designers charge for things you'll never see. Here's how to spot the difference before you sign anything." Same topic. Completely different pull. Structure the Page So It Answers the Question in Layers Search engines read structure. Clear H2 and H3 headings help Google understand which part of your page answers which question, and they help real readers find what they came for without wading through paragraphs they don't need. Think of a well-structured page like a good explanation from a knowledgeable friend. They give you the short answer first, then the context, then the detail. They don't bury the key point in paragraph six. If your page makes someone scroll for two minutes before finding the one thing they searched for, they'll leave, and Google notices that too. Where it genuinely helps, a short bullet list can break up a dense section. Use them sparingly though. A page that is mostly bullets is usually a page that hasn't been properly thought through. Real depth lives in sentences. Match the Language Your Reader Actually Uses One of the most common traps in writing for search is using industry language when your audience uses everyday language. A plumber might describe their service as "thermostatic mixer valve installation". Their customers search for "how to fix a shower that keeps going cold". Both describe the same job. Only one matches what gets typed into Google. Read your own page aloud. If it sounds like a brochure, rewrite it so it sounds like someone who actually does this work talking to someone who needs it done. That register, plain and direct, is what people trust and what search engines reward. What Most People Get Wrong About Keyword Density The idea that hitting a keyword a certain number of times will push a page up the rankings is outdated. What matters now is topical depth, not repetition. Google wants to see that your page genuinely covers a subject, not that you've mentioned a phrase eight times in 600 words. In practice, that means covering related terms naturally. A page about SEO copywriting tips might mention search intent, meta descriptions, readability, and on-page structure without any of those being the focus keyword. That breadth is what tells Google the page has real substance. It's also, not coincidentally, what makes the page actually useful to read. In our experience, the sites that come to us after paying for months of SEO work often have pages crammed with repeated phrases and nothing else. The keyword is there. The depth isn't. That kind of content rarely ranks well and almost never converts. Write a Meta Description Worth Clicking The meta description does not directly affect your ranking, but it affects whether someone clicks your result over the one above or below it. Think of it as a seven-second pitch. It should say what the page delivers, use plain language, and give the reader a reason to choose your result over the others on the page. Keep it under 160 characters, include the focus keyword naturally, and lead with the benefit. If you want a solid grounding in how on-page signals fit into a wider SEO process, that detail is worth understanding before you start optimising at scale. Good copy and good SEO are not in competition. A page that reads well, answers a real question, and is structured clearly will do more for your rankings than any amount of keyword manipulation. Write for the person first, and the technical side tends to follow. ------------------------------------------------------------ # WordPress Caching Explained: What Each Layer Actually Does Source: https://yorkshiredesign.co.uk/wordpress-caching-explained-what-each-layer-actually-does/ Published: 2026-07-25 > Most people switch on a caching plugin, tick a few boxes, and assume the job is done. Sometimes that is enough. More often, it is just the surface layer of a much deeper system, and the layers underneath are either misconfigured or missing entirely. Understanding what caching actually does at each level makes the difference between a site that feels fast and one that is fast, measurably, every time a real visitor lands on it. Why Caching Exists at All WordPress is a dynamic system. Without caching, every page request triggers a chain of events: PHP runs, queries hit the database, the result gets assembled, and the HTML is sent to the browser. On a quiet site with a small database, that might take 300 milliseconds. On a busier site, or one with a bloated theme and thirty active plugins, you can be looking at over two seconds per request before the browser has even started loading anything. Caching breaks that chain by storing the finished result and serving it directly on the next request. The principle is simple. The implementation has several distinct layers, and each one solves a different part of the problem. Browser Caching: The Layer Closest to the Visitor When someone visits your site, their browser downloads assets, images, stylesheets, scripts, fonts. Browser caching tells the browser how long to keep those files before requesting fresh copies. This is controlled through HTTP headers, specifically Cache-Control and Expires. A well-configured server sets long cache lifetimes on assets that rarely change, such as a logo or a font file, and shorter lifetimes on things that update frequently. Get this wrong and visitors re-download the same 200kb image on every page load. Get it right and returning visitors experience near-instant load times because most of the page is already sitting on their device. This layer is free to implement and has a direct effect on Core Web Vitals scores, particularly Largest Contentful Paint for returning visitors. It is also one of the first things Google's PageSpeed Insights flags when it is missing. Page Caching: Where Most Plugins Start Page caching is what most WordPress caching plugins actually provide. The first time a page is requested, WordPress builds the full HTML output. The plugin saves that HTML to disk or memory. Every subsequent request gets the saved copy, skipping PHP and the database entirely. This is the biggest single performance win available to a typical WordPress site. A page that previously took 900ms to generate can serve in under 50ms from a warm cache. The difference is that dramatic. There is a caveat worth knowing. Page caching and dynamic content do not always mix well. Cart pages, checkout flows, and anything personalised per user cannot be cached generically. A good caching setup excludes those URLs explicitly. Miss that step and you end up with customers seeing each other's session data, which is a serious problem beyond just performance. Object Caching: Saving Database Work Between Requests WordPress has a built-in object cache, but by default it only lasts for the duration of a single request. Once the page is delivered, everything it stored is discarded. A persistent object cache changes that. Tools like Redis or Memcached keep frequently used database query results in memory across requests. This matters most on sites where page caching cannot cover everything. A membership site, a WooCommerce store with complex filtering, or a site running lots of shortcodes that hit the database on every load, all of these benefit from object caching in a way that page caching alone cannot address. Most small business sites never need it. Larger, data-heavy ones often cannot perform well without it. We'd argue WordPress is the most flexible website creation system ever built, powering well over 40% of the internet, and object caching is one of the features that makes serious WordPress deployments genuinely competitive with bespoke-coded alternatives. Opcode Caching: PHP Doing Less Work Every time PHP runs, it compiles your code from plain text into something the server can execute. Opcode caching stores that compiled version in memory so it does not need to be recompiled on the next request. OPcache, which ships with PHP itself, handles this automatically on most modern hosting. You rarely configure this yourself. What you can check is whether it is actually enabled. A quick look at your server's PHP info page will confirm it. If it is off, or if the allocated memory is too low, PHP is doing unnecessary work on every single request. CDN Caching: Putting Static Files Closer to the Visitor A content delivery network stores copies of your static assets across servers in multiple locations around the world. A visitor in Sydney pulling a file from a server in London adds latency. The same file pulled from a Sydney CDN node does not. CDN caching works alongside your other cache layers, not instead of them. It is not a replacement for proper page caching or object caching. Think of it as the final step that reduces physical distance from file to browser. For sites with an audience across multiple countries, it is worth doing. For a purely local audience, it is a lower priority than getting the other layers right first. If you want to understand how managed hosting stacks these layers for you automatically, that is a separate conversation worth having before you choose a host. Getting the Stack Right The most common mistake is treating caching as a single checkbox. Switch on a plugin, ignore the server, skip CDN setup, leave OPcache unverified. Each layer you miss is a performance gap that stays open. Browser cache headers should be set at the server level, not left to defaults Page cache exclusions need to cover every dynamic or personalised URL Object cache is worth adding when your site does heavy database work OPcache should be confirmed as active, not just assumed CDN is the last layer to add, once the others are solid Done in that order, caching is not complicated. It is methodical. And a site with every layer properly configured feels genuinely different to one that just has a plugin installed and forgotten about. ------------------------------------------------------------ # What a Content Audit Reveals That Analytics Never Shows Source: https://yorkshiredesign.co.uk/what-a-content-audit-reveals-that-analytics-never-shows/ Published: 2026-07-25 > Your analytics dashboard can tell you how many people visited a page last month. What it cannot tell you is why half your blog posts sit on page four of Google, why a page that gets traffic converts nobody, or which articles are actually pulling your rankings down. That gap between what the numbers show and what is really happening across your content is exactly where a content audit does its work. What a content audit actually is Think of it less like an accounting exercise and more like lifting the bonnet on a car that seems to be running fine. The engine might be ticking over, but something underneath is wearing out. A content audit is a systematic review of every published page on your site, looking at what it covers, how well it covers it, whether Google can make sense of it, and whether it is helping or hindering your overall search presence. Analytics tells you what happened. A content audit tells you why, and what to do about it. The pages your analytics will never flag Most site owners focus on their top ten performing pages because those are the ones with numbers worth celebrating. The trouble is that the pages doing the quiet damage rarely have enough traffic to show up as a problem. They just sit there, indexed, occasionally crawled, pulling your domain's overall quality signal in the wrong direction. A content audit finds these. Specifically, it surfaces pages that are too thin to rank for anything useful, old posts that contradict newer, better content on the same site, and pages where the topic you intended to cover bears almost no relation to the search intent behind the queries landing on it. None of those failure modes produce a spike in your bounce rate report. They just silently exist. Keyword cannibalisation, the problem hiding in plain sight Keyword cannibalisation is what happens when two or more of your pages compete for the same search term. Google has to pick one to rank. Often it picks neither confidently, and both pages underperform as a result. This is one of the most common things a content audit uncovers on sites that have been publishing for a few years without a clear structure. You might have a service page targeting "WordPress speed optimisation" and three blog posts that have drifted onto the same territory. Analytics will show you that all four pages get some traffic. It will not show you that consolidating them into one authoritative piece would likely outrank all four combined. That judgement call requires a human eye on the content, not a dashboard. Content that ranks but does the wrong job Here is a pattern worth knowing about. A page ranks on page one for a search term, pulls in a reasonable number of visitors each month, and yet converts almost no one. Analytics might flag the low conversion rate, but it will not explain it. A content audit looks at the mismatch between what the page promises and what the reader actually wanted when they searched. Someone typing "how much does a website cost" wants a ballpark and a breakdown, not a sales pitch for a discovery call. Getting that match right, between the search intent and what the page delivers, is something you can only assess by reading the content alongside the query data. No automated report does that for you. If you want to understand what actually gets read on a service site, the answer almost always comes back to intent alignment, not word count. Outdated content and the trust it quietly erodes A post from three or four years ago that still ranks but contains outdated advice is a quiet liability. Readers who arrive, notice the information is stale, and leave immediately are giving Google a clear signal. That signal compounds over time. A content audit flags these pages so you can make a call, update them, redirect them to something more current, or remove them entirely. In our experience, sites running on shared or bargain hosting, particularly GoDaddy, compound this problem because slow load times mean readers bounce before even getting to the content, making the trust erosion worse before you have a chance to fix it. What to do with what you find The output of a good audit is a prioritised action list, not a spreadsheet of problems. Pages typically fall into four buckets. Keep and improve, solid content that ranks but could be stronger with a refresh or a better internal link structure. Consolidate, two or more thin pages covering the same ground, better merged into one authoritative piece. Redirect, pages with no realistic search value but with inbound links worth preserving. Remove, thin, duplicated or entirely off-topic pages that are doing more harm than good. Getting the right brief together before you start improving any of this content makes the actual writing far easier. A clear structure matters more than most people realise, and a well-built content brief is what separates a page that ranks from one that just fills a slot. One honest caveat A content audit takes time. Anyone who offers to run one in a few hours is skimming the surface. Reading pages individually, mapping them against search intent, checking internal link structures and identifying cannibalisation patterns is detailed, methodical work. The sites that see real gains from it are the ones willing to let the process take as long as it needs to. ------------------------------------------------------------ # When AI Writing Tools Make Your Content Worse, Not Better Source: https://yorkshiredesign.co.uk/when-ai-writing-tools-make-your-content-worse-not-better/ Published: 2026-07-25 > Most people assume the problem with AI-generated content is obvious. Bad grammar. Nonsense sentences. Stuff that clearly reads like a machine wrote it. But the content that actually damages sites is nothing like that. It reads fine. It passes a quick skim. It ticks the word count. And it quietly hollows out a page's ability to rank or convert, because it sounds informed without actually being so. That gap between readable and useful is where AI writing tools do their worst work. The myth that fluency equals quality AI writing tools are genuinely good at producing fluent prose. Sentences connect, paragraphs flow, the structure looks reasonable. The problem is that fluency and substance are completely separate things, and most tools optimise hard for the first while leaving the second entirely up to you. A page about boiler servicing that uses all the right terminology but never explains what actually happens during a service, what a homeowner should watch out for, or how often a specific boiler type needs attention, is thin content dressed in a decent coat. Google's quality raters are trained to spot exactly this. The signals that make a page worth ranking are about depth and accuracy, not sentence construction. When volume becomes the enemy One of the fastest ways to damage a site is to publish a lot of AI content in a short time. It feels productive. The content calendar fills up. But search engines assess a site's overall quality signal, not just individual pages. Picture a services site that publishes thirty blog posts in a month, all AI-generated, all hitting roughly 800 words, all covering broadly similar angles on the same topic. Each post is technically readable. But the site now has thirty pages competing with each other for the same queries, none of them saying anything the others don't, and no single page strong enough to stand out. That's a crawl budget problem, a cannibalisation problem, and a trust problem wrapped into one. Publishing less, but putting genuine thought into each piece, consistently outperforms volume chasing. The 'sounds right but isn't' problem This is the one that trips people up most. AI tools are trained on enormous amounts of text, which means they are very good at producing content that sounds authoritative on a topic, even when the specific claim is wrong, outdated, or simply made up. For anything that touches real-world accuracy, whether that's legal, medical, financial, or technical subject matter, this is a serious risk. A plausible-sounding wrong answer does more damage than no answer at all. Readers who catch it leave and don't come back. Google's guidance around experience, expertise, authoritativeness and trustworthiness (E-E-A-T) exists precisely because this problem is widespread, and it penalises pages that get it wrong at scale. The fix is straightforward but unglamorous. A human who actually knows the subject has to read every output and correct it. That takes time. Skipping that step is where the damage starts. What AI tools handle well (and what they don't) To be fair about it, there are genuine uses for AI in a content workflow. Drafting a structure, generating a first outline, rephrasing a clunky sentence, pulling together a summary of a brief, all of these save real time without creating much risk. Where AI consistently underperforms is anywhere a piece needs a specific, first-hand perspective. An account of what actually went wrong on a project. A genuine comparison based on real testing. An opinion that carries weight because someone with experience formed it. That's the kind of content that human writers consistently outperform AI on, and it's exactly the content that earns links, shares and long dwell times. In our experience, the sites that use AI most effectively treat it as a capable research assistant, not a writer. The thinking, the judgement and the voice stay human. The homogenisation problem nobody talks about There is a subtler issue that compounds over time. When a lot of sites in the same industry use the same AI tools with similar prompts, the content starts to converge. The same structure. The same angles. Even similar phrasing. For the reader, this means every competitor's blog sounds interchangeable. For search engines, it means no individual page has a clear reason to be ranked above the others. Differentiation, which used to come from a business's genuine experience and personality, disappears. That's a slow erosion rather than a sudden drop, but it's real. Content that reflects what a business has actually done, seen and learned is not something a generalist AI can replicate. That specificity is what makes a page memorable, and what makes it useful to someone trying to make a real decision. Writing that sounds like everyone else rarely converts. If you want to see how AI content affects SEO in practice, the honest answer is that it depends entirely on how much human judgement goes into the process before publish. The check worth doing before you hit publish Before any AI-assisted page goes live, run through these four questions honestly. Does this page say something a competitor couldn't copy and paste onto their own site? Is every factual claim in here something you can personally verify? Would someone who knows this topic well find anything genuinely useful here? Does the page sound like a real person with real experience wrote it? If the answer to any of those is no, the page isn't ready. That's not a criticism of the tool. It's a reminder that the tool only goes so far, and the rest is still your job. ------------------------------------------------------------ # Google AI Overviews: What They Actually Do to Your Traffic Source: https://yorkshiredesign.co.uk/google-ai-overviews-what-they-actually-do-to-your-traffic/ Published: 2026-07-25 > Google's AI Overviews sit above everything else on the search results page. Before a single organic listing, before any ads, the answer is already there. For a lot of searches, that changes who gets the click and who gets nothing. If your SEO strategy is built around ranking on page one and waiting for traffic to flow, it is worth understanding exactly how these summaries work and what they are actually doing to the numbers beneath them. 1. What an AI Overview Actually Is An AI Overview is a generated summary that Google places at the top of certain search results. It pulls from multiple sources and presents a combined answer directly on the page. The user gets what they need without ever clicking through. These appear most often on informational queries. How-to questions, definitions, comparisons, anything where Google is confident a summary covers it. Transactional searches, local results, and brand-specific queries are less likely to trigger one. But the informational space is enormous, and that is where most content marketing lives. 2. Click-Through Rates Are Taking a Hit The honest picture is this, when an AI Overview appears, organic click-through rates on the same page drop. Google itself has not published a specific figure, but the pattern is consistent across the SEO community. If the answer is already on screen, fewer people scroll down. How much the rate drops depends on the query. Something like "what is anchor text" is almost entirely absorbed by the overview. Something like "best WordPress hosting for small business" still drives clicks, because the user wants opinions and comparisons, not a paragraph summary. Position one used to be the goal. Now position one with an AI Overview above it is a different thing entirely. You can rank first and still see impressions outpace clicks by a wide margin. 3. Being Cited in the Overview Is Not the Same as Ranking Google sometimes lists the sources it drew from inside the overview panel. Appearing there is worth something, but it is not a reliable traffic driver on its own. Many users read the summary and stop. The citation is visibility, not necessarily a visit. That said, pages that do get cited tend to share common traits. They are specific, they are structured clearly, and they answer one question well before moving on. Thin pages that cover ten topics loosely rarely appear. The overview rewards depth on a narrow point. If you want to explore how Google evaluates the pages it surfaces, what Google actually looks at when ranking pages covers the signals that matter most. 4. Not All Traffic Is Equally Affected Commercial and navigational queries hold up better. Someone searching for a specific business, a product to buy, or a service in their area is not going to be satisfied by a generated paragraph. They want a real page, a real price, or a real phone number. The content most at risk is purely informational. Think glossary pages, explainer posts, FAQ-style articles written to capture long-tail searches. These have always been a solid way to build topical authority, but they are now competing directly with a summary that Google built from your own content and your competitors'. Meanwhile, searches driven by AI assistants are also shifting how people phrase their queries. Tools like ChatGPT and Bing's AI chat handle a growing share of the "explain this to me" type searches before the user even opens Google. The informational space is being squeezed from more than one direction. 5. What to Do About It (and What Not to Bother With) Chasing AI Overview citations as a strategy is largely a distraction. You cannot optimise directly for them in any reliable way, and obsessing over a metric you cannot control is a poor use of time. What you can do is build the kind of content that holds up regardless. Write pages that go beyond the summary. If your article tells someone what something is, then also tells them how to use it, what goes wrong, and what to do next, a paragraph overview cannot replace it. Focus on topics where intent is commercial or comparative, because those are harder for a generated summary to satisfy. And build genuine authority on a specific subject area rather than spreading thin across hundreds of loosely related keywords. In our experience, the sites that feel the least impact are the ones that were never purely chasing traffic volume. They were building something a reader actually wanted to spend time on. An AI Overview can answer the question. It cannot replace the experience of reading something well made. 6. Keep an Eye on Search Console The clearest way to see what is happening to your own traffic is to watch impressions versus clicks in Google Search Console. If impressions are holding steady or growing but clicks are falling, that is the AI Overview effect showing up in your own data. Filter by query type. You may find that certain topic clusters are losing clicks while others are not. That tells you where to focus your effort and where to reconsider the content strategy. If you are not already using Search Console properly, understanding what Search Console actually does is the place to start. The traffic landscape is shifting. The sites that adapt are the ones that give people a reason to click even when Google has already given them a reason not to. ------------------------------------------------------------ # Still Slow? Hidden Reasons Optimisation Isn’t Working Source: https://yorkshiredesign.co.uk/still-slow-hidden-reasons-optimisation-isnt-working/ Published: 2026-07-25 > You've installed a caching plugin, compressed your images, maybe even run a CDN. The Google PageSpeed score ticked up a little. Yet visitors are still waiting, and bounce rates haven't budged. This is one of the more frustrating problems in web development because the obvious fixes are already done. What's left tends to be quieter, harder to spot, and almost never mentioned in the standard optimisation guides. Here's where to look next. Your Hosting Is the Ceiling Everything Else Hits No amount of caching compensates for a server that's genuinely slow to respond. Time to First Byte (TTFB) is the metric to watch here. If the server takes longer than roughly 200ms to start sending a response, every other optimisation you've done is fighting upstream. Shared hosting is the usual suspect. When your site shares physical resources with hundreds of others, your response time isn't entirely in your control. A plugin or CDN can mask some of that latency, but it can't eliminate it. If TTFB is your problem, the real fix is a better hosting environment, not another layer of optimisation stacked on top of the existing one. Render-Blocking Resources You Haven't Touched Yet Caching plugins handle a lot, but they rarely deal with render-blocking JavaScript and CSS automatically, or they do it badly. These are the files the browser has to download and process before it can paint anything on screen. The tell-tale sign is a high Largest Contentful Paint (LCP) score alongside a fast TTFB. The server is responding quickly, but something is holding the browser up. Check which scripts load in the <head> and whether they're deferred or loaded asynchronously. Third-party scripts are often the real culprit, especially chat widgets, fonts pulled from an external server, or tag manager containers stuffed with extras. Each one adds a round trip the browser has to complete before anything meaningful appears. Too Many Plugins Doing Overlapping Jobs WordPress sites accumulate plugins over time. An SEO plugin, a schema plugin, a redirection plugin, a forms plugin, a social sharing plugin. Each one is usually harmless alone. Together, they can generate a surprising number of database queries, extra HTTP requests, and script loads on every single page view. The problem isn't any individual plugin. It's the combined weight of plugins that each add a little, and nobody has ever audited the total. Deactivate anything that isn't actively earning its place. If two plugins do roughly the same thing, pick one. A leaner setup nearly always performs better than a feature-heavy one with everything switched on. We'd argue that most WordPress sites carry at least three or four plugins they no longer need. That dead weight has a real cost, even if no single plugin looks heavy in isolation. Images That Look Compressed but Aren't Properly Served You compressed the JPEGs. Good. But are they being served in a next-generation format like WebP? And are they sized correctly for the device requesting them, or is a mobile visitor downloading a 1,400-pixel-wide image to display it at 400 pixels? Responsive images, the srcset attribute, and WebP conversion are separate steps from basic compression. Many sites do one but not the others. Getting the technical fundamentals right means covering all three, not just the most visible one. A site that scores well on desktop PageSpeed but serves oversized images to mobile users is only half-optimised, and mobile is where most of your traffic is coming from. The Database Is Working Too Hard WordPress stores everything in a database, posts, settings, transients, revisions, session data. Over time, that database accumulates a lot of junk. Thousands of post revisions for pages nobody edits anymore. Expired transients that never got cleaned. Autoloaded options that grow with every plugin install and removal. A bloated database slows down query times. Not dramatically on any single query, but the effect compounds across every page load. Running a regular database optimisation, removing post revisions beyond a sensible limit, and auditing autoloaded data are the kinds of tasks that don't show up in a PageSpeed report but absolutely affect how snappy a site feels under real traffic conditions. What the Score Doesn't Tell You A PageSpeed Insights score is a lab measurement taken under ideal conditions with a single simulated request. Real users don't behave that way. They arrive on different devices, from different locations, with warm or cold caches, alongside other users hitting the same server. Field data from Google's Chrome User Experience Report often tells a very different story from the lab score. If your Core Web Vitals are green in the lab but amber or red in field data, the gap usually points to real-world server load, JavaScript execution on low-powered devices, or content that loads differently under actual conditions. That's the number worth fixing, because it's what Google uses for ranking. Chasing a high lab score while the field data stays poor is a common trap. A site that feels slow to real visitors costs you conversions regardless of what the tool says. The work that actually moves the needle happens well below the surface, and it takes patience to get right. ------------------------------------------------------------ # The Coolest WordPress Themes Worth Actually Building On Source: https://yorkshiredesign.co.uk/the-coolest-wordpress-themes-worth-actually-building-on/ Published: 2026-07-24 > A theme can look brilliant in a demo and fall apart the moment you actually try to build something real with it. Slow to load, tangled markup, page builders that fight you at every turn. The coolest WordPress themes are not just the ones with the best screenshots. They are the ones that hold up once the content goes in, the plugins stack up, and Google starts paying attention. Why Most 'Popular' Themes Are Not Worth Your Time ThemeForest bestseller lists are driven by sales volume, not quality. A theme with 40,000 sales might have got there on the back of a good-looking demo and a low price point. That says nothing about how the code behaves, how the Core Web Vitals score holds up under real content, or whether the developer is still actively maintaining it. The classic failure mode is a multi-purpose theme that ships with fifteen demo templates, four bundled page builders, and a plugin pack nobody asked for. It looks flexible. What it actually is, is heavy. Every page load carries the weight of features you are not using, and Google notices. What to look for instead is pretty straightforward. Clean output, a sensible DOM size, no JavaScript loading on pages where it serves no purpose, and a developer who patches security issues promptly. That is a shorter list than most theme review posts suggest, because most of what gets called a feature is actually overhead. Astra: Still the Benchmark for Lightweight Builds Astra has been the go-to for performance-focused builds for years, and it has earned that reputation. The base theme loads under 50KB without a page builder, which gives you a genuine head start on Core Web Vitals before you have touched a single setting. It works cleanly with Elementor, Bricks, and the block editor, and the starter templates are optional rather than baked in. That matters because a theme that makes you delete things before you can start building is already making more work for you. The free version covers most use cases. The pro tier adds header and footer builder functionality that would otherwise need a separate plugin. Whether that is worth the outlay depends entirely on the project. GeneratePress: The One Developers Actually Trust GeneratePress has a smaller public profile than Astra but a fierce following among developers who care about output quality. The HTML it produces is clean, semantic, and minimal. No bloat by default, and the modular premium licence means you only activate the components you need. It scores consistently well on Lighthouse without any additional caching or optimisation work, which is a meaningful baseline. Most themes need a caching plugin and image optimisation running just to hit acceptable performance scores. GeneratePress starts ahead of that conversation. If you are hand-building sites rather than using a visual drag-and-drop workflow, this is probably the most honest choice on the market. Bricks Builder: A Theme and Builder in One Bricks sits in a different category. It is both a theme and a front-end visual builder, and the distinction matters because the output it generates is genuinely leaner than most alternatives. Unlike Elementor, which wraps elements in multiple nested divs, Bricks writes closer to what you would produce by hand. The learning curve is real. Bricks rewards people who want to control the structure of a page rather than just fill in pre-made sections. For that kind of build, what the theme produces under the hood is exactly the right thing to be thinking about. One honest caveat worth naming. Bricks is a one-person or small-team project at its core, which means the roadmap moves at a different pace than a larger product. Not a dealbreaker, but worth knowing before you commit a client's long-term site to it. Kadence: The Practical Middle Ground Kadence sits between Astra and GeneratePress in terms of out-of-the-box functionality. It has a solid block theme built for the native WordPress editor, which makes it a sensible choice for anyone who wants to avoid a proprietary page builder entirely. The starter templates are well-structured and easy to strip back, the global colour and font controls work without a separate plugin, and for small business sites that do not need heavy customisation, it is often the most efficient path from brief to live. What the 'Cool Factor' Actually Costs You Some themes look genuinely spectacular. Full-screen video backgrounds, parallax effects, animated section transitions. The demos are impressive. The PageSpeed scores are not. A theme that ships with a video hero, a particle animation library, and custom cursor effects is almost certainly loading JavaScript that tanks your Largest Contentful Paint before your first paragraph renders. That is a direct ranking signal Google weights. Themes like Salient sit right in this territory, where the aesthetic appeal is real but the performance trade-off needs a clear-eyed look before you commit. The themes genuinely worth building on are the ones that look good because of the content you put in them, not despite the framework they run on. That requires a bit more design work upfront. The results tend to last a lot longer. ------------------------------------------------------------ # Website Copy That Converts: What Every Service Page Needs Source: https://yorkshiredesign.co.uk/website-copy-that-converts-what-every-service-page-needs/ Published: 2026-07-24 > Picture a service page that looks the part. Clean layout, decent photography, a contact form sitting at the bottom. And yet the phone stays quiet. The copy reads like it was written for a brochure nobody asked for, full of what the business does and almost nothing about why a visitor should care. That gap between a page that looks good and one that actually earns enquiries is almost always a writing problem, not a design one. Start With the Reader, Not Yourself Most service pages open with the company name, a short history, and a list of capabilities. The reader is already scanning for the exit. What stops them is finding something that sounds like their problem described back to them. Before a single word goes on the page, it's worth asking one question honestly, what is the visitor worried about right now? Not what you offer, but what they're trying to fix, avoid, or decide. That answer shapes every sentence that follows. A plumber's service page that opens with "we are a family-run business established in 2003" tells the reader nothing useful. The same page opening with "burst pipe at midnight" lands differently. Same trade. Completely different effect. The Headline Does Most of the Work Visitors spend roughly three seconds deciding whether to read further. The headline carries that entire decision. It needs to be specific, not clever. "Professional Web Design Services" could appear on ten thousand sites unchanged. "WordPress sites built to load fast and rank" gives the reader something to hold. Specificity signals that you understand what actually matters to them. A good test, cover the company name on the page and ask whether a competitor could publish it word for word. If the answer is yes, the headline is doing nothing. Build Proof Into the Copy, Not a Separate Section Testimonials tucked at the bottom of a page carry less weight than most people think. By the time a visitor reaches them, they've usually already decided. Proof lands harder when it's woven into the main copy, not filed away at the end. Instead of "we deliver fast results", try "clients typically see a measurable drop in bounce rate within the first month". Instead of "experienced team", name the experience: "over 200 WordPress sites built across a decade of hands-on development". Specifics do the convincing that vague adjectives never can. If you're writing product or service page copy and want to understand how search engines weigh what you write, writing copy that ranks covers how the two goals overlap more than most people expect. What Most Service Pages Get Wrong The single most common mistake is writing too much about process and too little about outcome. Visitors don't need a blow-by-blow of how you work. They need to feel confident that the problem goes away. Features tell. Benefits sell. "We use caching plugins" is a feature. "Your site loads in under two seconds on mobile" is a benefit. Passive voice drains energy. "Services are provided by our team" reads like a legal disclaimer. "We handle it" reads like a person. Long paragraphs kill momentum. If a block of text runs past four lines, most readers skip it entirely. Generic calls to action waste the close. "Contact us" asks for nothing specific. "Get a free quote this week" gives the reader a reason to act now. None of this is complicated in theory. In practice, it's genuinely difficult to write about your own business clearly, because you're too close to it. That's why so many service pages end up as inside-out documents, written for the business rather than for the person reading it. The Call to Action Deserves Its Own Thinking A call to action isn't just a button. It's the last thing standing between a visitor and an enquiry, so the wording matters more than most pages treat it. Think about what the visitor is nervous about. If they worry about being locked into something expensive, "book a free, no-obligation call" removes that friction directly. If they're comparing options, "see how we approach it differently" invites curiosity rather than demanding a commitment. One CTA per page works better than three competing ones. Give the visitor a clear single next step, and make sure it sits near the top of the page. Not just at the bottom after a scroll they may never take. Copy and Content Are Different Jobs A service page is not a blog post. Blog posts build trust over time and answer questions. Service pages convert. Mixing the two tends to produce pages that do neither job particularly well. In our experience, the pages that convert most reliably are short, direct, and completely focused on the reader's decision. They don't try to educate. They try to reassure. If a visitor leaves knowing exactly what to do next and feeling confident you can handle the job, the copy has done its work. For businesses that create written content regularly, understanding what goes into a solid content brief can prevent a lot of wasted effort before writing even starts. Good service page copy isn't about sounding impressive. It's about making the decision easy for the person reading it. ------------------------------------------------------------ # AI Workflow Automation for Marketing: No Tech Team Needed Source: https://yorkshiredesign.co.uk/ai-workflow-automation-for-marketing-no-tech-team-needed/ Published: 2026-07-24 > Most people assume AI workflow automation for marketing is something only companies with a developer on the payroll can do. That assumption costs them hours every single week. The truth is, the barrier is far lower than it looks, and the biggest mistake is not starting too soon, it is starting without a clear picture of what you actually want to hand off. Get that right first, and everything else becomes a lot less daunting. The myth that you need a tech team to automate anything This one is worth challenging straight away. A decade ago, building any kind of automated workflow meant writing code, managing servers, or hiring someone who could. That world has shifted considerably. Tools like Make (formerly Integromat), Zapier, and a growing number of WordPress-native plugins let non-technical people connect apps, schedule tasks, and trigger actions without writing a single line of code. That said, "no code needed" does not mean no thinking needed. The logic behind a good automation, knowing what triggers what, what data goes where, and what happens when something fails, still requires care. The tool handles the technical plumbing. You still have to design the system. Start with the task you dread most, not the flashiest use case The common trap is reaching for the most exciting automation first. AI-generated content pipelines, dynamic personalisation, multi-step nurture sequences. Those come later, and only if they genuinely suit your business. Start with the task you do every week that offers nothing back except the time it swallows. For most small marketing operations, that tends to be one of four things: Manually sharing new blog posts across social channels Copying enquiry form data into a spreadsheet or CRM Sending a follow-up email after someone downloads a resource Pulling performance data from multiple platforms into one report Pick one. Automate that. Get comfortable with how it feels before you add a second layer. Understand what "trigger, action, condition" actually means Every automation, regardless of the tool you use, follows the same basic logic. Something happens (the trigger), that causes something else to happen (the action), and sometimes a condition filters whether the action fires at all. A simple example, a new contact submits your enquiry form (trigger), their details get added to your CRM (action), and if they ticked "interested in SEO", they also get tagged in a specific list (condition). That is a real, useful workflow. It takes roughly twenty minutes to build in most no-code tools and runs without anyone touching it again. If you can describe your task in those three terms, you can automate it. If you cannot, the task probably needs simplifying before it can be handed off to a machine. Where AI actually adds value in a marketing workflow "AI automation" gets used loosely, so it is worth being specific. There are two distinct things here, rule-based automation (if this happens, do that) and genuine AI-assisted steps (where a language model writes, categorises, summarises, or makes a judgement call). For marketing without a tech team, the AI layer tends to earn its place in three areas. First, drafting first-pass content from a structured brief so a human can edit rather than write from scratch. Second, summarising long documents, transcripts, or reports into a usable format. Third, routing or tagging incoming enquiries based on what the person actually said, rather than a rigid dropdown they filled in. Search interest in AI marketing automation has risen sharply in recent months, and the tools have genuinely improved. But the ones worth using are the ones that reduce a specific task, not the ones promising to replace your entire marketing strategy. The mistake that wastes most of the budget Automating a broken process. If your weekly reporting takes three hours because the underlying data is inconsistent and unreliable, building an automation around it will not fix that. It will produce wrong outputs faster. In our experience, GoDaddy hosting creates a similar kind of problem when it comes to speed-dependent workflows. Sites hosted there tend to run slowly and carry a lot of unnecessary overhead, which means any automation that touches the website, form submissions, page-triggered events, webhook responses, hits delays that compound. The hosting itself becomes the bottleneck, not the automation logic. Fix the foundation before you build on top of it. That applies to your data, your processes, and your hosting. You can read more about avoiding wasted spend when you start with AI automation if you want a fuller picture of where budgets tend to leak. A realistic starting point for the first 30 days Week one, pick one repetitive marketing task and map it out using trigger, action, condition. Do not touch a tool yet. Just write it down. Week two, build it in a free tier of Make or Zapier. Test it with real data, not dummy entries. Week three and four, let it run. Watch what breaks or misfires. Adjust. Most automations need one or two small fixes before they settle. After 30 days, you will have one working automation, a much clearer sense of where the next opportunity is, and none of the regret that comes from buying a complicated platform on day one. The practical steps for starting without disrupting your workflow are worth reading alongside this if you want more detail on that first build. Good automation is quiet. It just handles the thing, every time, without being chased. ------------------------------------------------------------ # AI Workflow Automation for Small Businesses: Where to Start Source: https://yorkshiredesign.co.uk/ai-workflow-automation-for-small-businesses-where-to-start/ Published: 2026-07-24 > Most small business owners who try AI automation pick the wrong starting point. They reach for the flashiest tool, connect a few things together, and wonder why it saves them no time at all. The smarter move is to start with the work you already do on repeat, find the single most painful part, and fix that first. Everything else follows from there. This guide walks through where that starting point usually is, and how to approach it without burning budget on something that never gets used. Find the Repetition Before You Find the Tool The most common mistake is choosing a platform before identifying the problem. Someone reads about Zapier or Make, signs up, and then tries to retrofit it onto their business. That rarely works. The better approach is to spend a week writing down every task you do more than twice. Answering the same enquiry email. Copying order details into a spreadsheet. Posting the same type of content on a schedule. Those are your candidates. Once you have a short list, rank them by two things, how often the task happens, and how long it takes each time. The one at the top of both lists is where you start. Not the most technically interesting one. The most tedious one. What 'Automation' Actually Means at Small Business Scale There is a tendency to picture automation as a complex system with dozens of moving parts. For a small business, it almost never needs to be that. A single automated trigger that fires off a follow-up email after a form submission is automation. So is a scheduled post going out without anyone touching a keyboard. These are not glamorous, but they recover real time across a working week. The practical ceiling for most small businesses is three or four connected steps. Trigger, action, condition, output. Anything beyond that tends to break quietly, and you only notice when something has slipped through for a fortnight. Keep it simple enough that you can explain what it does in one sentence. The Tasks Where AI Adds the Most Pure automation handles triggers and actions. AI adds something different, it handles the variable stuff. Writing a first draft of a reply. Summarising a long email thread. Generating a product description from a set of bullet points. These are tasks where the input changes every time, so a simple if-this-then-that rule cannot help you. The practical sweet spot for small businesses is combining both. A form comes in, automation routes it to the right place, and an AI tool drafts the initial response for you to review and send. You are still in control. You are just not starting from a blank screen every time. For a detailed look at where this combination pays off most, these practical AI uses for small business are worth working through. Where Most People Get It Wrong The failure mode I see most often is automating something that did not need automating. Someone spends three hours building a workflow to save twenty minutes a month. The maths never adds up, and the system adds maintenance overhead on top. The other common trap is automating a broken process. If your current way of handling enquiries is chaotic, an automated version of chaos is still chaos, just faster. Sort the process manually until it works cleanly, then automate the clean version. That order matters more than people expect. Choosing the Right Starting Tool For most small businesses with no developer resource, the realistic options are Make, Zapier, or the automation features built into whatever CRM or email platform they already use. Start with what you have. If your email marketing tool has a basic automation builder, use that before paying for a separate platform. Zapier suits people who want something that connects quickly with minimal setup. Make suits people comfortable with a slightly steeper learning curve who want more control over logic and conditions. Neither is universally better. The right one is the one you will actually maintain when something breaks at 8pm on a Tuesday. If you are trying to get started without overcomplicating it, this guide to starting AI automation without breaking your workflow lays out a sensible order of operations. How Long Before It Pays Off A single well-chosen automation typically saves between thirty minutes and two hours a week once it is running reliably. That does not sound like much. Across a month it is four to eight hours back in your working day, and across a quarter it starts to feel significant. The key word is reliably. A fragile workflow that needs fixing every few weeks costs you time rather than saving it. Expect the setup and testing of your first real automation to take a full working day, sometimes two. That is not wasted time. It is what makes the difference between something that runs quietly in the background for two years and something that gets switched off after a fortnight because it kept misfiring. The budget-conscious approach to AI automation covers how to scope this without overspending on tools you outgrow in six months. Pick one task. Automate it properly. Let it run. Then look at what to do next. ------------------------------------------------------------ # What Is Technical SEO and Why Does It Matter for Your Site Source: https://yorkshiredesign.co.uk/what-is-technical-seo-and-why-does-it-matter-for-your-site/ Published: 2026-07-23 > Most people think SEO is about keywords and blog posts. That part matters, but Google also spends a lot of time looking at how your site is built. Technical SEO is everything that happens beneath the surface. The structure, the speed, the signals that tell search engines whether your pages are even worth crawling. Get it wrong and even good content struggles to rank. Get it right and everything else you do works harder. Think of It Like the Foundations of a House You can decorate a house beautifully, but if the foundations are cracked, the whole thing is unreliable. Technical SEO is the foundation work. It is the set of things that makes your site easy for search engines to find, read and trust. Google uses automated bots called crawlers to visit your pages. They follow links, read your code and decide what your site is about. If those bots hit errors, slow load times or confusing structures, they move on. Your content never gets a fair hearing. What Technical SEO Actually Covers It is not one single thing. Technical SEO is a collection of factors that all affect how search engines interact with your site. The most common ones are worth knowing by name, because they come up often. Crawlability , can Google's bots actually reach your pages? A misconfigured robots.txt file can accidentally block whole sections of your site. Indexability , even if Google can crawl a page, it needs permission to store it. A stray 'noindex' tag tells Google to ignore a page entirely. Site speed , slow pages frustrate users and signal poor quality. Google uses a set of speed metrics called Core Web Vitals to measure this. HTTPS , a secure connection is a basic ranking signal. An unencrypted site raises a red flag immediately. Structured data , small pieces of code that tell Google exactly what your content is (a product, a review, a recipe). It helps your listing stand out in search results. Mobile usability , Google now ranks the mobile version of your site first, not the desktop version. None of these things are visible to your visitors. That is exactly what makes them easy to overlook. Why It Matters More Than People Expect A common pattern we see is a business that has spent real money on content and still sees flat traffic. Often the culprit is something invisible. Duplicate pages confusing the crawler. Images that are three megabytes each, slowing every page load to a crawl. Internal links pointing to redirected URLs so Google is burning its crawl budget on dead ends. The fix is rarely glamorous. It is methodical. You run through the audit properly, find what is actually broken rather than what looks broken, and fix it in the right order. That process takes time. But it pays off more consistently than chasing algorithm updates. The Thing Most People Get Wrong There is a tendency to treat technical SEO as a one-off job. Fix it once, move on. The reality is that sites change constantly. New plugins get added. A theme update overwrites a canonical tag. A developer adds a redirect that creates a chain five hops long. Regular checks matter far more than a single deep clean. Not every week, but quarterly at a minimum. The issues that sneak in quietly are the ones that compound over months and do the most damage. The other misconception worth addressing is around AI search. Getting found by AI-powered search tools does not require a separate strategy. As long as your core SEO is solid, adding an LLMs.txt file is usually all it takes. A common issue we see with clients is that this gets sold as something complex and expensive. It really is not. If your content is decent and your technical foundations are clean, it works. How Technical SEO Fits Alongside Content and Links Technical SEO does not replace good content, and it does not replace earning links from reputable sites. The three work together. Think of content as what you are saying, links as who is vouching for you, and technical SEO as whether anyone can actually hear you in the first place. Get the technical side wrong and the other two efforts are partly wasted. A page that loads in six seconds and has crawl errors will not rank consistently, regardless of how well-written it is. Sorting out the technical fixes that actually move rankings is often the fastest way to see movement from work you have already done. Where to Start if You Are Not Sure Where You Stand Google Search Console is free and shows you real data about how Google sees your site. Look for crawl errors, pages excluded from the index, and any Core Web Vitals warnings. That alone gives you a working list to act on. If the results make little sense, a proper technical audit will map out what needs attention and in what order. There is no point fixing page speed if half your pages are accidentally set to noindex. Sequence matters as much as effort. ------------------------------------------------------------ # Local SEO for Small Businesses: What Actually Moves the Needle Source: https://yorkshiredesign.co.uk/local-seo-for-small-businesses-what-actually-moves-the-needle/ Published: 2026-07-23 > Most small businesses are told they need local SEO, then handed a list of forty things to do with no sense of which ones matter. The honest answer is that a handful of fundamentals do most of the work. Get those right first, and you will see movement. Chase everything at once and you will exhaust your budget on activities that barely shift a needle. This post walks through what genuinely counts, what is largely noise, and how to decide where to spend your time. Your Google Business Profile Carries More Weight Than Most People Realise For any local search, Google's map pack sits above the organic results. That map pack is powered almost entirely by your Google Business Profile, not your website. So before you touch a single on-page element, your profile needs to be complete, accurate and actively maintained. A complete profile means every field filled in. Business category, opening hours, service area, phone number, a real description that explains what you do. Photos matter too. Profiles with a reasonable number of genuine photos consistently appear more prominently than near-empty ones. The category you pick is especially important. Google reads your primary category as the strongest signal of what you do. A plumber who sets their category to 'Home Services' instead of 'Plumber' is making life harder for themselves from the start. Reviews Are a Ranking Factor, Not Just a Trust Signal Google uses review volume and recency as part of how it ranks local results. A business with fifty reviews from the past six months will generally outrank one with fifty reviews from three years ago, even if the star rating is similar. The mistake most businesses make is asking for reviews once and then stopping. Recency matters, so a steady trickle of new reviews over time is worth more than a burst followed by silence. Responding to reviews also counts. Google's own guidance states that responding to reviews shows you value customer feedback. That engagement is a small but real signal, and businesses that ignore their reviews leave an easy win on the table. NAP Consistency: The Unglamorous One Nobody Wants to Fix NAP stands for Name, Address, Phone. Google cross-references how your business details appear across the web, from your website to directories like Yell, Thomson Local, and Yelp. If those details are inconsistent, Google loses confidence in the accuracy of your listing. This sounds tedious because it is. Tracking down every old directory listing where your previous address or a misspelled business name still sits is not exciting work. But the unglamorous fixes are often the ones that have been holding a site back for months without the business ever knowing. Start with the big ones. Google, Bing Places, Apple Maps, Yell, and your own website footer. Get those consistent before worrying about the smaller directories. What On-Page SEO Actually Does for Local Rankings Your website still matters, but in a specific way for local SEO. Google needs to confirm that your site backs up what your Google Business Profile claims. If your profile says you are a solicitor in Manchester but your website never once mentions Manchester or legal services clearly, that mismatch creates uncertainty. A well-structured service page that names what you do and where you do it resolves that. It does not need to be long. It needs to be clear. A page for 'boiler installation in Sheffield' that actually discusses boiler installation, mentions Sheffield, and has a real address will outperform a generic services page every time. Beyond that, how Google reads and evaluates your pages comes down to basics that have not changed much. Clean structure, clear headings, pages that load quickly, content that answers a real question. The One Area Where Most Local SEO Budgets Get Wasted We have taken over sites where a business had been paying a monthly SEO retainer for a year or more. On inspection, nothing meaningful had been done. The Google Business Profile was incomplete, the NAP was inconsistent across directories, and the site had no location-specific content at all. The monthly reports showed keyword rankings for terms nobody was searching, which kept the client busy reading charts while the actual problems sat untouched. SEO is invisible work by nature. That makes it easy to invoice for without doing it properly. If you are paying for local SEO and cannot see changes to your Google Business Profile, new or updated location pages, or evidence that someone has audited your directory listings, those are fair questions to ask. What Is Not Worth Your Time Right Now A few things get talked about more than they deserve at the early stages of local SEO. Schema markup for a small local business is nice to have, but it will not rescue a profile with no reviews and inconsistent NAP. Chasing backlinks before your on-page basics are solid is putting the cart before the horse. Building out dozens of location pages for towns you barely serve, just to cover more ground, often creates thin content that Google ignores or downgrades. Fix the profile, earn the reviews, clean up the NAP, and write one genuinely useful page per real service area. That order of priority will take you further than any shortcut. Understanding what that kind of sustained work realistically costs makes it easier to judge whether what you are currently paying is going anywhere useful. ------------------------------------------------------------ # The WordPress Plugins Worth Paying For Source: https://yorkshiredesign.co.uk/the-wordpress-plugins-worth-paying-for/ Published: 2026-07-23 > The WordPress plugin market is enormous. There are free versions, pro upgrades, lifetime deals, and annual licences competing for your attention constantly. Most of them aren't worth it. A handful genuinely are. The difference usually comes down to whether the plugin does something technically difficult that would take you days to build yourself, or whether it just wraps a basic feature in a slick marketing page. This guide cuts through that noise and focuses on the plugins where the paid version actually changes the outcome. Why Most Free Plugins Are Fine Before spending anything, it's worth saying plainly, the majority of what a WordPress site needs is covered by free plugins. Contact forms, basic SEO meta fields, simple caching, cookie banners. You don't need to pay for those. The paid tier earns its place when the free version is genuinely hobbled, when support matters because the plugin touches critical infrastructure, or when the premium feature saves a significant amount of manual work every week. If none of those apply, keep your money. Caching and Performance: WP Rocket WP Rocket is the one premium plugin that comes up on almost every serious WordPress site. There's no free version, which puts some people off. But the reason it stays at the top of every honest performance list is that it works straight out of the box without needing to understand what page caching, lazy loading, or cache preloading actually mean. The configuration is sensible by default. For most sites, turning it on improves Core Web Vitals scores without touching a single advanced setting. For those who do want to dig deeper, the controls are there. It's one of those tools where you could spend an hour reading the documentation, or you could just install it and see the results in PageSpeed Insights within minutes. One caveat worth naming: WP Rocket and some aggressive theme frameworks can conflict, particularly around JavaScript deferral. If your site uses a lot of third-party scripts, test every change before assuming it's safe. A fast score on a broken page helps nobody. If you're trying to improve speed without just stacking more plugins, WP Rocket should be the last tool you reach for, not the first. Image Handling: Smush Pro or ShortPixel Images are quietly responsible for a large share of slow WordPress sites. Most people upload a 4MB JPEG from their phone, and it stays that size forever because nobody told WordPress to do anything about it. Free image plugins exist and do a reasonable job. The paid versions earn their cost when you have an existing library of several hundred unoptimised images. Smush Pro's bulk optimisation and ShortPixel's WebP conversion pipeline both handle that kind of backlog without you sitting there clicking one image at a time. ShortPixel's credit-based pricing is worth understanding before you commit. It suits sites where images are uploaded occasionally. For a busy e-commerce or photography site uploading constantly, a subscription model may work out better value. Choose based on your actual upload volume, not the headline price. For a more detailed look at how these tools compare in practice, the breakdown of WordPress image optimisation plugins covers exactly that. SEO: Rank Math Pro vs Yoast Premium The free tiers of both Rank Math and Yoast cover the basics. Meta titles, descriptions, XML sitemaps, robots controls. Honestly, for a small brochure site, that's usually enough. Rank Math Pro earns a closer look if you're managing multiple sites or need schema markup beyond what the free version offers. The breadcrumb schema, FAQ schema, and review markup all function cleanly without needing to hand-code anything. For a business running technical SEO improvements across their WordPress site, having that schema layer working properly matters more than most people realise. We'd argue Yoast Premium's main selling point, its redirect manager, is the feature most likely to justify the cost for an established site doing a redesign or URL restructure. Broken internal links after a migration are one of the most common and avoidable SEO problems out there. What's Not Worth Paying For A few honest saves before this wraps up. Premium page builder upgrades are rarely worth it unless you're building client sites at volume. Most of what they unlock is available elsewhere for free. Paid social sharing plugins do nothing for performance or rankings. Skip them entirely. Premium security plugins often overlap with what a good host already provides at the server level. Check your host's feature list before doubling up. The plugins that reliably earn their cost are the ones handling something technically heavy, caching, image processing, structured data. Anything that's mostly cosmetic or administrative can usually be handled free, or just left out altogether. WordPress powers a remarkable share of the web precisely because its plugin ecosystem is so capable. But that same ecosystem rewards the people who pick carefully, not the ones who install everything and hope for the best. ------------------------------------------------------------ # 7 Things Google Actually Looks at When Ranking Pages Source: https://yorkshiredesign.co.uk/7-things-google-actually-looks-at-when-ranking-pages/ Published: 2026-07-23 > Most conversations about how Google ranks pages jump straight to keywords and backlinks. Both matter, but they sit much further down the list than people expect. Before any of that counts, Google has to be able to find the page, read it properly, and decide it actually answers what the searcher wanted. Miss any one of those steps and the rest of your effort goes to waste. Here is what the algorithm is genuinely looking at, in the order it actually matters. Crawlability Comes Before Everything If Googlebot cannot reach a page cleanly, nothing else on this list matters. A misconfigured robots.txt rule, an accidental noindex tag left over from a staging migration, or render-blocking JavaScript that hides the main content until after the crawler times out , any of these silently removes a page from contention. This is the unglamorous end of SEO that most audits skip past too quickly. Worth checking first, every time. What the Page Is Actually About Google reads the whole document now, not just the title tag and H1. It looks at the supporting headings, the language used across the body, and whether the page builds a coherent picture of a single topic. Thin, vague pages tend to rank poorly regardless of how many times a target phrase appears. Keyword density is essentially a relic. What signals topical clarity is whether a reader could finish the page and feel they got a complete answer. Pages that circle a subject without landing on it rarely hold rankings for long. Page Experience Signals and Core Web Vitals Google has confirmed that Core Web Vitals are ranking inputs. The three that count are Largest Contentful Paint (how fast the main content loads), Interaction to Next Paint (how quickly the page responds to a tap or click), and Cumulative Layout Shift (how much the layout jumps around while loading). A common issue is that page owners see a ranking drop and never connect it to a slow or visually unstable experience. The penalty is quiet. There is no warning in Search Console that says "your LCP cost you position four." A common pattern across many sites is exactly this, failing Core Web Vitals, no obvious ranking cause found, and the fix sitting entirely in the performance layer. E-E-A-T and Why It Is Harder to Fake Than People Think Experience, expertise, authoritativeness, and trust are not a checklist you complete and move on. Google's quality rater guidelines use these as a filter, and the raters are real people applying judgement, not a script. Sites with no real author signals, no evidence of genuine experience, and nothing that distinguishes their take from a generic summary consistently underperform against thinner-looking competitors who clearly wrote from real knowledge. That gap tends to widen after each core update. The honest trade-off here is that building real authority takes time. There is no shortcut that holds up. Links Are Still a Signal, Not the Only One Backlinks remain relevant. A single mention from a genuinely authoritative source in your field carries more weight than fifty directory submissions. That has always been true, and Google's approach to link quality has only become more sophisticated. What has changed is that links alone no longer compensate for weak content, poor page experience, or intent mismatch. They amplify a good page. They do not rescue a bad one. Structured Data Helps Google Read the Page, Not Rank It Schema markup is widely misunderstood. Adding it does not push a page up the results. What it does is give Google clearer context about what the page contains, and where eligible, it can earn rich result features like star ratings, FAQs, or recipe cards in the search results. Those features improve click-through rate, which is worth having. But treating structured data as a ranking booster leads to wasted effort. Get the content right first. Schema is the finishing layer, not the foundation. Search Intent Alignment Is the One Most Sites Miss A page can pass every technical check, carry real authority, and load in under two seconds and still not rank. The most common reason is intent mismatch. The page answers a different version of the question than the searcher is actually asking. Google groups intent into broad categories. Informational queries want an explanation. Transactional queries want a path to an action. Navigational queries want a specific destination. Where people go wrong is writing a long-form guide for a query where Google clearly trusts short comparison pages, or building a product page for a term where the results page is full of how-to articles. Look at what Google already ranks for the query before writing a word. The format it trusts is visible right there in the results. Matching that format is not gaming the system , it is answering the question the way the searcher expects it to be answered. ------------------------------------------------------------ # NitroPack vs WP Rocket: Which One Speeds Up WordPress Source: https://yorkshiredesign.co.uk/nitropack-vs-wp-rocket-which-one-speeds-up-wordpress/ Published: 2026-07-23 > Both tools sit at the top of almost every WordPress speed plugin conversation. NitroPack does almost everything automatically; WP Rocket hands you more control and expects you to know what you're doing with it. Neither one is objectively better. The right choice depends on what your site needs, how comfortable you are in the WordPress engine room, and whether you want the work done for you or want to do it yourself. What Each Tool Is Actually Trying to Do NitroPack isn't really a plugin in the traditional sense. It's a cloud-based optimisation service that runs your site's assets through its own infrastructure, applying caching, image compression, code minification, and a CDN all in one go. You install the WordPress plugin, connect it to your NitroPack account, and the heavy lifting happens off your server. The idea is that most of the decisions are made for you, so you're not spending an afternoon tweaking settings and hoping you got it right. WP Rocket takes the opposite approach. It's a self-hosted caching plugin that sits on your server and gives you a structured set of controls, page caching, file optimisation, lazy loading, database cleanup, and so on. You decide what gets switched on and how aggressively. That hands-on model suits developers and site owners who want to understand exactly what's happening under the bonnet, but it also means the results depend heavily on how well you've configured it. The gap between a default WP Rocket install and a properly tuned one can be significant. The Features That Move the Needle on Core Web Vitals NitroPack handles Largest Contentful Paint almost entirely on its own. It automatically identifies your above-the-fold images, applies next-gen formats like WebP, sets correct dimensions to prevent layout shifts, and prioritises their loading without you touching a single setting. That automatic image dimension handling is particularly useful for CLS, because a missing width and height attribute on an image is one of the most common reasons a layout jumps around during load. WP Rocket doesn't touch image dimensions at all, so that particular fix falls to you or a separate plugin. For CSS, NitroPack generates critical CSS automatically on every page type, whereas WP Rocket's critical CSS generation requires manual triggering and can take a few attempts to get right on complex layouts. Where WP Rocket earns its place is on INP and anything that needs careful per-page control. Its delay JavaScript execution feature lets you pick exactly which scripts fire on interaction rather than on load, which can genuinely reduce input delay on content-heavy pages. NitroPack's equivalent is more of a blanket setting, and on complex or WooCommerce sites that can occasionally break functionality. If your site has unusual scripts or third-party integrations that need babysitting, that manual control matters more than automation. Where NitroPack Can Go Wrong NitroPack's automatic optimisation is its biggest selling point, but that same aggressiveness is also where things start to break. Because it rewrites CSS, defers JavaScript and restructures how assets load, it can interfere with dynamic content in ways that aren't immediately obvious. WooCommerce is a common sticking point. Cart fragments, checkout logic and mini-cart updates all rely on JavaScript firing in a specific order, and NitroPack occasionally mangles that sequence. You might not notice on a product page, but a customer at checkout suddenly finds the basket isn't updating. That's a conversion problem dressed up as a caching problem. If you want a deeper look at what's actually happening under the bonnet, this breakdown of NitroPack's internal processes is worth reading before you go near a live WooCommerce store. The cloud-dependency is the other trade-off most reviews gloss over. NitroPack doesn't just run on your server. It routes your assets through its own infrastructure to apply optimisations, which means your site's performance now has an external link in the chain. If NitroPack's service has downtime or latency, your site feels it. A plugin like WP Rocket processes everything locally, so you keep full control. That's not a reason to dismiss NitroPack outright, but it is something to factor in before committing, particularly on a production site where reliability matters more than squeezing out every last millisecond. Where WP Rocket Has Its Own Limits WP Rocket does a lot well, but it ships as a caching and performance plugin, not a complete optimisation suite. Image compression, CDN delivery and advanced CSS handling all sit outside its core feature set, which means you need to pair it with something like Imagify for images and a separate CDN service before you're anywhere close to a full stack. Most people install WP Rocket, tick a few boxes in the dashboard, and assume the job is done. What they've actually got is the caching layer working and not much else. That gap shows up immediately in Lighthouse scores when Google flags uncompressed images or layout shifts the plugin was never designed to catch. The misconfiguration risk is real too. WP Rocket's CSS delivery settings, particularly the option to remove render-blocking resources and delay unused CSS, can actively hurt your scores if the underlying theme or page builder generates styles in a way the plugin doesn't handle cleanly. A broken critical CSS file will cause a flash of unstyled content on every page load, which tanks your Cumulative Layout Shift metric. It's a legitimate tool, but the assumption that it covers everything is where most setups quietly fall short. The Hosting Factor Both Tools Depend On NitroPack and WP Rocket are both doing their work at the application layer, which means they are entirely at the mercy of whatever sits beneath them. If your server is slow to respond, no amount of caching, minification, or lazy-loading will fix that. A high Time to First Byte is a server-side problem. A caching plugin cannot solve a server-side problem. The classic version of this is a site where the cache is perfectly configured but the uncached requests, like form submissions or logged-in pages, still grind along at two or three seconds because the underlying infrastructure simply cannot keep up. This is the variable most people skip over entirely when comparing plugins, yet it shapes the results more than any feature difference between NitroPack and WP Rocket. A well-optimised WordPress install on a capable server will score well with either tool. The same install on shared hosting with an overloaded CPU will score poorly with both, regardless of how carefully the settings are tuned. If you have not already looked hard at what your host is actually giving you, the comparison on whether managed WordPress hosting genuinely improves speed is worth reading before you make any plugin decision. Cost vs Value: What You're Actually Paying For NitroPack's pricing is tied to your site's monthly pageviews, and that model works well at low traffic levels. The free plan covers 5,000 pageviews, which suits a small brochure site. But once you start pushing past that, the costs climb quickly. A site doing 50,000 pageviews a month sits in a tier that costs more annually than a lot of business owners expect, and if you run several WordPress installs, you're paying that per site. What you get in return is a genuinely automated optimisation stack, image conversion, CDN delivery, and caching all managed for you without touching a setting. WP Rocket charges a flat annual licence fee, starting at one site and scaling to unlimited. That predictability is worth something, especially if you manage multiple projects. What it doesn't include is the CDN layer or image compression out of the box. You're expected to pair it with other tools to match NitroPack's feature depth. The honest trade-off is this, if you want a single tool that handles everything with minimal configuration, NitroPack's premium tiers are genuinely earning their price. If you're comfortable understanding what each optimisation layer actually does and piecing a stack together yourself, WP Rocket's flat fee stretches further. Which One to Choose and When The honest split comes down to how comfortable you are inside WordPress settings. NitroPack is the right call when the person running the site has no interest in caching rules, exclusion lists or render-blocking resource flags, but still needs Core Web Vitals scores that hold up. You install it, connect it, and it makes sensible decisions for you. The trade-off is less granular control, and on complex sites with lots of dynamic content, that occasionally means something breaks and you need to whittle down which automated rule caused it. For straightforward business sites and blogs, that rarely happens. WP Rocket makes more sense if you or your developer understands what each toggle actually does, because the results can be tighter and more predictable when a real person is making those calls. It also tends to sit more cleanly inside a hosting stack that already includes server-level caching. If you want a deeper look at how these tools interact with the cache layer beneath them, managed hosting and what it actually changes is worth understanding first. Automated optimisation tooling is getting sharper quickly, and the gap between hands-off and hands-on approaches is narrowing, but for now that distinction still shapes which tool earns its keep on your site. ------------------------------------------------------------ # AI Content That Ranks vs AI Content That Just Fills a Page Source: https://yorkshiredesign.co.uk/ai-content-that-ranks-vs-ai-content-that-just-fills-a-page/ Published: 2026-07-22 > Using a content creator AI to scale output sounds like a straightforward win. Write more, rank more. Except that is not how Google works, and sites that treat AI as a publishing conveyor belt tend to find that out the hard way. The gap between AI content that earns rankings and AI content that quietly damages a site comes down to a handful of specific decisions, most of which happen before a single word is generated. Why AI Output Defaults to the Average AI language models are trained on enormous amounts of existing text. That is their strength, but it is also their structural problem. Because they learn by pattern-matching what has already been written, the output naturally gravitates toward the middle. Safe sentences. Common angles. The kind of copy that sounds plausible because it resembles everything else on the topic. Search engines do not reward average. A page that reads like a synthesis of everything Google already indexes adds nothing. There is no original judgement, no practitioner's angle, no detail that only someone who has actually done the work would know to include. For a search engine trying to assess genuine expertise, that absence is loud. What Google's Quality Signals Are Actually Measuring Google's quality guidelines focus on whether a page genuinely serves the person searching, not just whether it contains the right words. Depth relative to word count matters here. A 1,200-word page that circles a topic without landing anywhere specific will score worse than a tighter 600-word page that actually answers the query. Topical specificity is another real signal. A page about "how to fix slow WordPress load times" should cover specific causes, such as unoptimised images, render-blocking scripts, or a bloated database, not vague advice about "improving performance". Generic coverage tells Google the page is not written by someone who has spent real time on the problem. Author credibility markers, things like a named author, a clear point of view, and references to real experience, also factor in. A page written as if by nobody in particular, which describes most raw AI output, gives the algorithm very little to work with. The Prompting Problem Nobody Talks About Most poor AI content is a prompting failure, not a tool failure. Ask a content creator AI to "write a blog post about SEO tips" and you will get exactly what you deserve, a generic, forgettable list that every other site already has a version of. A tighter brief changes everything. A good prompt tells the model the specific reader it is writing for, the exact angle to take, what to leave out, and the single most important thing the page must make clear. For example, a prompt that says "write for a small business owner who has already tried basic SEO and seen no results, focus on why their page structure is the likely problem, skip anything about keywords or meta tags, and make clear that fixing internal linking is the one change most worth making" produces something far more useful than a blank instruction. The specificity you put in is roughly the specificity you get out. Where Human Judgement Has to Step In Even a well-prompted draft needs a practitioner's eye before it publishes. AI consistently misses a few things that matter. It tends to soften trade-offs, presenting options as roughly equal when one is clearly better in most situations. It makes claims without grounding them in anything real. And it rarely has a genuine point of view, which is the thing a reader actually remembers. We'd argue this editing step is where most people give up. It takes longer than expected, and the temptation is to publish the draft as-is. That decision is where filler content is born. Catching wrong emphasis, adding a real example, and inserting an honest caveat are not cosmetic fixes. They are what separates a page worth ranking from one that wastes the crawl. The Real Cost of Page-Filling Content Filler content is not a neutral choice. Picture a site that published 200 AI-generated posts over a few months with no editorial filter. Each post was thin, topically vague, and structurally similar. The crawl budget got spread across pages that offered nothing. The site's topical authority diluted as Google struggled to identify what the site actually knew. Then the stronger, older pages, the ones that had earned rankings, started slipping. That is a pattern worth taking seriously. As we'd argue when clients ask about volume, making content purely for the sake of it tends to cannibalise the pages that were already working. Minimal, carefully chosen content built around your actual expertise almost always outperforms a sprawl of thin pages in the long run. What AI-Assisted Content That Actually Ranks Looks Like The production model that works is not "prompt and publish". It is a split of responsibilities. The content creator AI handles structure, first draft, and variation at speed. The human provides the angle, the specific detail, the opinion, and the final edit. In practice, that means starting with a clear brief that defines the reader and the one thing the page must do. The AI drafts. A person then reads it as a sceptic, adding what is missing, cutting what is vague, and making sure the page has a real point of view rather than a rehearsal of common knowledge. If you want to understand what that looks like at a structural level, the difference between what search engines and readers actually need from a page is a useful place to start. That process takes more time than pressing publish on a raw draft. It also produces pages that hold their rankings rather than sliding after the first crawl. The shortcut is always available. It just rarely leads where people think it will. ------------------------------------------------------------ # WordPress Snippets and AI: How to Use Both Without Breaking Things Source: https://yorkshiredesign.co.uk/wordpress-snippets-and-ai-how-to-use-both-without-breaking-things/ Published: 2026-07-22 > AI can write a WordPress hook in seconds. That speed is genuinely useful, but it creates a false sense of confidence that gets sites broken. The sweet spot is treating AI as a fast first drafter, not a final authority. Before that pairing works well, though, you need to be clear about what a 'snippet' actually means here, because the scope matters before any code gets written. What 'WordPress Snippets' Actually Means Here A snippet, in this context, is a fragment of PHP dropped into your site to change how WordPress behaves. That could live in functions.php, inside a dedicated plugin like Code Snippets, or through WPCode. It is not a full plugin build, not a theme child override. It is a targeted, single-purpose piece of code that hooks into WordPress at a specific point. That distinction matters because the risk profile is different. Snippets tend to be short, so developers trust them quickly. But a 10-line function dropped into functions.php can bring down an entire admin panel just as effectively as a broken plugin can. Small does not mean safe. What AI Gets Right and Where It Starts to Guess AI handles boilerplate well. Standard hook patterns, common filter signatures, well-documented WP functions like add_action, remove_filter or wp_enqueue_scripts are written about extensively, so AI has plenty of material to draw from and usually gets the structure right. Where it starts to slip is context. AI has no idea which version of WordPress you are running, which theme you are using, or what the other 23 plugins on your site are doing. It also hallucinates deprecated functions with confidence. You might receive perfectly formatted code built around a function that was removed two major versions ago, and the output will look completely plausible until it fires a fatal error. The other gap is specificity. Ask AI to write a snippet that interacts with WooCommerce's checkout, and it will produce something that looks sensible in isolation. Whether it conflicts with your particular payment gateway or your custom order flow, it simply cannot know. The Staging Rule: Why You Never Test This Live A fatal error in functions.php does not produce a polite warning. It locks you out of the WordPress admin entirely. You are left with FTP access or a cPanel file manager trying to delete or edit a file you cannot even open properly in a browser. It is one of the more unpleasant ways to spend an afternoon. A staging environment prevents this completely. Test every AI-generated snippet there first, even if the code looks clean. Staging catches execution errors before they reach real visitors, and it gives you the space to check error logs without any pressure. Skipping this step to save time is the exact decision that creates an emergency at the worst possible moment. If you are managing WordPress sites regularly, the hosting environment you choose will determine how easily you can spin up staging. Not every host makes it straightforward. A Working Order for Writing, Reviewing and Deploying Snippets with AI Context is the most important thing you can give an AI when asking it to write WordPress code. A vague prompt produces vague output. A specific one produces something actually usable as a starting point. State your WordPress version and active theme at the start of the prompt. Name any plugin the snippet needs to interact with, including its version if you know it. Describe what the snippet needs to do, and what it must not affect. Review the output for deprecated functions before you copy anything. A quick check against the WordPress developer reference takes two minutes. Paste it into your staging environment via a snippet manager, never directly into a core or theme file. Check the PHP error log after activation, not just the front end. A snippet manager like WPCode is worth using here specifically because it catches fatal errors before they execute and lets you deactivate a snippet without needing file access. That safety net alone makes it the right deployment method. The One Thing Most Developers Miss When Using AI for Code Hook priority and execution order are almost never addressed in AI output. WordPress fires actions and filters in a specific sequence, and where your snippet sits in that sequence changes what it actually does. A snippet that works perfectly in isolation can produce completely silent breakage when another plugin runs the same hook at a lower priority number. We'd argue this is the most underestimated problem with using a wp snippets ai workflow. The code looks correct, the page loads, and the issue only surfaces two weeks later when a customer reports something odd in checkout. AI gives you a first draft. The execution order is your responsibility to check. When a Snippet Is the Wrong Tool Entirely Some problems that arrive looking like snippet jobs are actually theme architecture issues or missing plugin settings presenting as code gaps. AI will write you something regardless. It is not going to say "actually, you should check the plugin settings first." Before reaching for a snippet, ask whether a plugin that already handles this already exists. Ask whether the theme is the thing creating the problem. The judgement call of when not to add more code to a site is the part AI genuinely cannot make for you, and it is often where the real performance problems begin to stack up. More code is not always the answer. Sometimes the answer is removing something. ------------------------------------------------------------ # AI Automation That Saves Hours on Repetitive Marketing Tasks Source: https://yorkshiredesign.co.uk/ai-automation-that-saves-hours-on-repetitive-marketing-tasks/ Published: 2026-07-22 > Most marketing teams don't have a strategy problem. They have a time problem. Scheduling posts, reformatting copy for different channels, chasing up leads, pulling together reports nobody reads fully. These tasks aren't complicated. They're just relentless. AI automation doesn't replace the thinking behind your marketing. It handles the mechanical repetition so the hours you spend on it actually go somewhere worth going. Why Repetitive Marketing Tasks Are Costing More Than You Think The easy assumption is that small tasks are cheap because they take little time individually. Scheduling a social post takes five minutes. Pulling last week's email stats takes another ten. Resizing a batch of images, copying performance numbers into a spreadsheet, chasing a newsletter draft through three rounds of copy-and-paste. Each one feels trivial in isolation. But those tasks do not sit in a corner of your brain quietly waiting their turn. Each one demands a decision, a context switch, a moment of focus that takes real mental energy to recover from. Add them up across a working week and you are not looking at scattered minutes. You are looking at a full day, sometimes more, spent on work that produces no original thinking whatsoever. The sharper cost is what gets squeezed out. Marketing strategy, campaign ideas, testing new angles, writing something genuinely worth reading. These are the tasks that actually move a business forward, and they require uninterrupted headspace. When your morning is already fragmented by fifteen micro-tasks before 10am, that headspace is gone before the important work even starts. The pattern is predictable. A business owner sets aside Tuesday afternoon for planning, but the routine jobs have already taken the edge off the day. Nothing bold gets written. Nothing gets tested. That slow, steady drain on decision-making bandwidth is the real price of doing repetitive marketing by hand. What AI Can Actually Take Off Your Plate The tasks that eat the most time in marketing tend to be the ones that follow a fixed pattern every single time. Social post scheduling is a good example. The logic never changes, but someone still has to sit there queuing content, setting dates, picking platforms. AI handles that loop without a second thought, and once a schedule is in place it keeps running whether you're at your desk or not. The same goes for email follow-up sequences, where AI can watch for a trigger like a form submission or a purchase and send the right message at the right interval without anyone touching it manually. Content repurposing is where the time savings start to feel genuinely significant. Taking a blog post and producing a short social caption, a subject line for an email, and a meta description from it used to mean someone sitting down and rewriting the same ideas three different ways. AI does that in seconds, at scale, with reasonable consistency. Lead tagging works similarly, categorising incoming enquiries by topic or intent so your follow-up is actually relevant. If you want a clearer picture of how these kinds of automations sit inside day-to-day small business workflows, there are some grounded practical examples worth reading through. Where WordPress Fits Into the Automation Stack For most small businesses, WordPress is already doing the heavy lifting. It holds the content, handles the contact forms, runs the WooCommerce store. The good news is that you do not need to bolt on an entirely new system to start automating repetitive marketing work. WordPress has a built-in REST API that exposes your site's data to external tools, so platforms like Zapier, Make, or a custom script can read from it, write to it, and trigger actions based on what happens there. A new post goes live, and a webhook fires off an email to your list, queues a social post, and logs the entry in a spreadsheet, all without anyone touching a keyboard. That connection matters because it keeps your existing setup intact. You are not migrating to a new CMS or rebuilding your stack from scratch just to automate three tasks. If you want to see exactly how those triggers work at a technical level, using the REST API to automate site tasks covers the mechanics in plain terms. The practical upshot is that WordPress sits comfortably at the centre of an automation pipeline, passing data outward to the tools that handle email, social, and reporting, while you get on with the work that actually needs a human behind it. The Honest Limits: What AI Automation Gets Wrong AI handles volume and repetition well, but it has a genuine blind spot around tone. It can produce fifty product descriptions in the time it takes you to write one, yet ask it to handle a sensitive reply to a frustrated customer, or write something that captures a very specific brand voice, and the cracks show quickly. The output tends to drift toward whatever pattern the model was trained on. That's fine for generic copy, but it falls flat when the brief calls for character. If you have spent years building a distinct personality into your brand, automation alone will not protect it at the edges. The bigger risk is running automation without a human checkpoint. When a workflow runs unsupervised, small errors compound. A wrong tone slips past, a factual assumption gets baked into dozens of emails, and the noise builds quietly before anyone notices. The fix is not to avoid automation but to place the human review at the right stage, not as an afterthought. If you are curious how that plays out inside a real CMS, what automation actually does inside a WordPress site gives a clear picture of where the technology genuinely helps and where it still needs a hand. How to Build a Simple Automation Loop Without Breaking What Works The safest way to start is also the most obvious one. Pick a single task that crops up more than three times a week and write down exactly what triggers it, what information goes in, and what the finished output looks like. A newsletter that goes out every Monday is a good example. The trigger is a calendar event, the inputs are a blog post URL and a subject line, and the output is a sent email to a list. Once you can describe it that clearly on paper, you can describe it to an automation tool. That mapping step is where most people skip ahead too quickly, and it is usually why their first attempt breaks something they were not expecting. Choosing the right tool matters more than choosing a clever one. A straightforward task like scheduling social posts or routing a form submission into a spreadsheet does not need an AI model anywhere near it. Pure rule-based automation handles that perfectly well, and it is far easier to debug when something goes wrong. It is worth understanding where automation ends and AI genuinely begins before you build anything, because conflating the two usually means you add complexity you do not need. Test the loop on a small sample first, watch it run a handful of times, and only scale it once you are confident the outputs are what you actually wanted. The Tasks Worth Automating First (and the Ones to Leave Alone) The clearest place to start is anything high-volume and low-judgement. Scheduling social posts, resizing images for different platforms, sending follow-up emails after a form submission, pulling weekly traffic numbers into a report, generating first-draft meta descriptions from a page title. These jobs share a common trait. The output is predictable, the criteria are fixed, and getting it wrong doesn't embarrass anyone. If a task takes roughly the same steps every single time and rarely needs a human to weigh context, it's a strong candidate. That's where AI can quietly absorb hours of repetitive work without touching anything fragile. Where things go wrong is when businesses automate tasks that depend on reading a situation correctly. Responding to a negative review, drafting a proposal for a new client, writing copy that reflects a brand's actual personality rather than a generic approximation of it. These aren't slow jobs because people are inefficient. They're slow because real judgement is being applied. Handing them to automation without close human oversight is how you end up with replies that feel hollow or messaging that subtly misrepresents what you actually do. If a mistake would damage trust, keep a person in the loop. Automation should handle the volume so that humans have more time for the moments that genuinely matter. ------------------------------------------------------------ # 7 SEO Reporting Tasks You Can Actually Hand Off to AI Source: https://yorkshiredesign.co.uk/7-seo-reporting-tasks-you-can-actually-hand-off-to-ai/ Published: 2026-07-22 > SEO reporting is one of those jobs that eats time without anyone noticing. Pulling rankings, checking crawl errors, chasing down page speed dips, writing the same summary you wrote last month. Most of it is repetitive, and repetitive work is exactly what automation handles well. The question is knowing which parts you can safely hand off and which still need a human eye. Get that distinction right and you claw back hours every single week. 1. Rank tracking and weekly position exports Manually logging keyword positions is a genuine waste of time. Tools like Google Search Console, Ahrefs and SEMrush all expose APIs. An automation can pull position data on a schedule, dump it into a spreadsheet or dashboard, and flag anything that moves more than five places in either direction. You still need to decide what the movement means. But the gathering? Hand it off completely. 2. Core Web Vitals monitoring and alerts Core Web Vitals scores shift whenever a theme update lands, a plugin loads a new script, or a hosting environment hiccups. Checking PageSpeed Insights manually every week is not a sustainable habit. A simple automation can hit the PageSpeed or CrUX API on a schedule and send an alert the moment a score drops below a threshold you set. That way you only look when something actually breaks. No news is genuinely good news. 3. Crawl error summaries Google Search Console flags crawl errors, coverage issues and indexing problems continuously. The problem is nobody checks them continuously. An automation that pulls the Search Console API daily and emails a digest of new 404s, soft 404s or excluded pages means nothing sits unnoticed for three months. For WordPress sites this matters more than most people realise. Plugins create and delete pages, redirects break during updates, and a single misconfigured permalink structure can quietly orphan a stack of good content from the index. 4. Backlink change reports New backlinks and lost backlinks both matter, but neither is urgent enough to check every day by hand. An automated pull from your link data source, filtered to show only changes from the previous period, gives you a clean diff without the noise. What you're looking for is patterns. A sudden spike of low-quality links, or the loss of a cluster of links from one referring domain, is worth a second look. The automation surfaces those patterns. You make the call. 5. Competitor visibility snapshots Watching competitor rankings by hand is the kind of task that starts well and quietly gets abandoned. Automate a weekly pull of the same tracked terms across competitor domains and you have a running comparison without the manual effort. This is worth setting up even for a small keyword set. Seeing a competitor jump ten positions on a term you've been building content around is a signal worth catching early, not six weeks later. 6. The monthly summary report itself This is where a lot of people are surprised. A common issue we see is clients assuming that writing a monthly SEO summary has to be manual. It does not. Once the data flows into a structured format, an LLM can draft a plain-English summary of what moved, what stayed flat and what needs attention. It will not replace your judgement on what to do next. But it removes the blank-page problem and gets a first draft in front of you in seconds rather than an hour. Worth being honest though, the output is only as good as the data going in. Garbage metrics produce a confident-sounding summary of nothing useful. On a related note, there is a similar myth around AI and search visibility. Optimising for AI-powered search results gets sold as some complex undertaking. In practice, solid SEO plus an llms.txt file does the job. The hard work is the content quality underneath it. 7. Internal link opportunity flagging As a site grows, internal linking gets harder to manage manually. An automation can scan your published content, match phrases against your target keyword list and surface pages that mention a term but do not link to the most relevant destination. You still decide which suggestions are worth acting on. Some will be irrelevant or already covered by a redirect. But having a list to work from beats starting from memory. For sites with more than fifty pages, this kind of audit catches gaps that manual SEO audits routinely miss. What you should not hand off Strategy. The automation can tell you rankings dropped. It cannot tell you whether to refresh the page, build more links, consolidate thin content or leave it alone. That judgment comes from understanding the site, the niche and what the numbers actually mean together. Reporting automation works best when a human sets it up thoughtfully and reviews the output with a critical eye. It is not a shortcut to skip understanding SEO. It is a way to spend less time on the mechanics and more time on the thinking. ------------------------------------------------------------ # Server Response Times: The Fix Nobody Mentions Source: https://yorkshiredesign.co.uk/server-response-times-the-fix-nobody-mentions/ Published: 2026-07-22 > Most people chasing page speed go straight for image compression and caching plugins. Fair enough, those things matter. But there's a step that happens before any of that, one that quietly decides whether your site feels fast or sluggish regardless of everything else you've done. Server response time is where the race is already won or lost, and it's the fix that barely anyone talks about. What Server Response Time Actually Is When a browser requests your page, your server has to think before it responds. That thinking time is called Time to First Byte, or TTFB. It's the gap between the browser asking for the page and the first byte of data coming back. Google's own guidance suggests a good TTFB sits under 800 milliseconds, with under 200ms being the target for strong performance. Everything else, the images loading, the fonts rendering, the layout painting, all of it waits until that first byte arrives. A slow server response delays the entire chain. You can have the leanest HTML in the world and still feel slow to a visitor if the server takes two seconds just to say hello. The Real Causes Worth Knowing Shared hosting is the most common culprit. When your site sits on a server alongside hundreds of others, you're competing for the same resources. Peak traffic on a neighbour's site can slow yours down without you doing a single thing wrong. Unoptimised database queries are another big one, especially on WordPress. Every page load can fire dozens of database calls. If the database isn't indexed properly, or there are bloated tables from years of old post revisions and plugin data, those queries drag. A site that worked fine at launch can grow noticeably slower over two or three years for exactly this reason. PHP version matters too. Running an old PHP version on WordPress is like driving with the handbrake on. PHP 8.x processes requests meaningfully faster than PHP 7.x, yet plenty of live sites are still running older versions because nobody's checked. What People Get Wrong When They Try to Fix It The most dangerous version of this I've seen is when someone is paid to "optimise" a site, installs a caching plugin, compresses a few images, and calls it done. The PageSpeed Insights score goes up. The client is happy. The server response time hasn't changed at all. Google does not use PageSpeed Insights scores as a ranking signal. It is a developer tool, a guide to what could be improved, not a metric Google feeds into its algorithm. Chasing that number without fixing the underlying server configuration is cosmetic work. What actually matters is how fast the page loads for a real visitor on a real connection. There's also the cache problem. A caching plugin can mask a slow server by serving pre-built pages. But if the server cache isn't cleared before the client signs off the work, the slow response time hides underneath. The cache expires weeks later and suddenly the site feels sluggish again. We've seen this pattern more than once, where a client pays for work, everything looks fine, and then several weeks down the line the real picture emerges. How to Diagnose It Properly Start with a proper TTFB measurement using a tool like WebPageTest or GTmetrix, making sure the server cache is completely cleared first. You want the cold-start number, not the cached one. That's the honest figure. Then look at a few specific things in order: Which PHP version is the server running? Check in your hosting control panel. How large are the WordPress database tables? Autoloaded options bloat is a common offender. Is the hosting environment shared, VPS, or managed WordPress? Each has a different ceiling. Are there heavyweight plugins firing on every request, even pages where they do nothing? Fix the environment first. Then add caching on top of a fast server, not instead of one. When Hosting Is the Honest Answer Sometimes no amount of optimisation fixes a slow TTFB because the hosting plan simply isn't up to the job. A £3-a-month shared host will have a ceiling. A move to a proper managed WordPress host, or a VPS with object caching like Redis, can drop response times dramatically where nothing else will. That's an unglamorous answer, because it costs money. But if the hosting choice is quietly undermining everything else, no plugin in the world covers for it permanently. The work underneath always surfaces eventually. One Final Check Before You Trust the Numbers Always test with a cleared cache. Whether you're reviewing someone else's work or your own, flush the server cache, flush the CDN cache, and run the speed test cold. That's the number that tells the truth. Anything else is a best-case reading on a warm server, and real visitors don't get that version. ------------------------------------------------------------ # Content Writer vs Copywriter: Which Does Your Site Need? Source: https://yorkshiredesign.co.uk/content-writer-vs-copywriter-which-does-your-site-need/ Published: 2026-07-22 > Most people hire one when they needed the other. A blog post that reads like a sales pitch, or a homepage that sounds like a Wikipedia article, are both signs the wrong person was briefed. The difference between a content writer and a copywriter is not just a job title. It shapes the goal of every sentence on your site, and getting it wrong means your words work against you before a visitor has read past the first paragraph. Two Jobs, Two Different Outcomes A content writer builds articles, guides and posts designed to earn attention over time. Their job is to answer questions, explain a topic clearly and give readers a reason to stay on the page. Search engines reward this kind of writing because it matches what people are actually looking for. A copywriter writes words that make something happen. A homepage headline, a product description, a checkout button, an email subject line. Every word is working toward a specific action, usually a click, a sign-up or a purchase. The writing is shorter, sharper and built around a single outcome. Both are skilled jobs. They just pull in opposite directions. Where Content Writing Fits If your site needs to attract visitors from search, content writing is what earns those visits. Blog posts, how-to guides, comparison articles and FAQs all belong here. The goal is not to sell immediately but to show up when someone types a question into Google and give them a genuinely useful answer. Good content writing takes a well-chosen keyword, builds a piece around it and treats the reader as someone who came to learn something. That means depth, structure and enough substance that a person actually finishes reading. A 300-word post stuffed with the right phrase is not content writing. It is filler, and search engines have become very good at spotting the difference. We'd argue that making content en masse is normally a waste of time. It ends up cannibalising pages, muddying keyword focus and producing nothing a reader would bother bookmarking. A smaller set of carefully chosen pieces, written with a specific audience in mind, consistently outperforms a factory approach. That point is worth sitting with before commissioning fifty posts at once. If you want to understand how post length plays into this, the long-form versus short post debate is worth reading before you decide. Where Copywriting Fits Your homepage, your service pages, your call-to-action buttons. These are copywriting jobs. The reader already knows they might want something. The copy's job is to confirm they are in the right place and remove any reason to leave. Good copy is economical. It does not explain everything. It says the right thing, in the right order, to the right person, and then stops. A homepage that runs to eight hundred words of self-congratulation is not copy. It is a missed opportunity. Visitors scan, decide quickly and leave faster than most site owners want to believe. A copywriter will also think about tone. A solicitor's site should not sound like a fashion brand. A trades business should not sound like a tech startup. Getting the voice right is part of the job, and it is harder than it looks. The Area Where They Overlap SEO copywriting sits in the middle. A well-optimised service page needs a target keyword, a clear structure and persuasive language that moves someone toward a decision. That is content strategy and copywriting in the same document, which is why briefing the wrong person produces something lopsided. The balance between writing for search engines and writing for people is genuinely tricky to hold. A purely SEO-focused brief often produces writing that no human enjoys reading. A purely brand-focused brief can produce writing Google has no idea what to do with. The best pages manage both, and that usually requires someone who understands the tension rather than ignoring half of it. How to Decide What You Actually Need Start with the page's purpose. Trying to rank for a search term and educate a reader? That is a content writing job. Trying to convert a visitor who has already found you? That is a copywriting job. Building a service page that needs to rank AND persuade? You need someone who can do both, or two people working from the same brief. Budget matters too. A skilled copywriter who specialises in conversion work charges more than a general content writer. That is not a reason to pick the cheaper option if conversion is what you need. It is a reason to be honest about what each page is supposed to do before you commission anything. What Most Briefs Get Wrong The brief itself is usually the problem. Asking for "some website content" tells a writer almost nothing. Which pages, which audience, what action, what tone, what keyword. Without those answers, even a good writer is guessing. The result is words that fill space but do not do a job. Before hiring either, write down what you want a visitor to do after reading each page. That one question will tell you which type of writer you need, and it will make the brief ten times easier to write. ------------------------------------------------------------ # What a Proper SEO Campaign Actually Costs (And Why) Source: https://yorkshiredesign.co.uk/what-a-proper-seo-campaign-actually-costs-and-why/ Published: 2026-07-22 > A local company came to us after spending twelve months and a fair chunk of money with an SEO provider. Rankings were down. Traffic had dropped. And when we dug into the site, we found hundreds of pages, all thin, all badly targeted, none of them doing anything useful. The SEO bill had been modest. The damage was not. That kind of experience is exactly why the question of what SEO actually costs deserves a straight answer, not a sales pitch. Why the Quotes Are All Over the Place Ask five SEO providers for a price and you'll get five completely different numbers. That's not because the work is mysterious. It's because the word 'SEO' covers everything from a few hours of keyword research to a full technical overhaul, ongoing content production, and months of link building. They're not the same thing, and the prices shouldn't be the same either. The cheap end of the market tends to mean automated reports, templated changes, and content produced in bulk. It looks like activity. It rarely moves anything meaningful. At the serious end, you're paying for someone who actually reads your site, understands what's broken, and builds a plan around your specific situation rather than a standard package. What You're Actually Paying For A proper SEO campaign has several layers, and each one takes real time. The technical groundwork alone, checking crawlability, fixing indexation problems, sorting out site speed, reviewing structured data, can take days before anything visible happens. That work is invisible to most clients but it's the foundation everything else sits on. Skip it, and the content work that follows has far less effect. After that comes the content side. Good keyword research isn't just finding high-volume terms. It's working out which phrases your audience actually uses when they're ready to do something, and matching those to pages that can realistically rank. Then each page has to be written, structured properly, and connected to the rest of the site in a way that makes sense to both Google and a real visitor. There's also the ongoing work, monitoring rankings, watching for algorithm shifts, adjusting what isn't working, and building the kind of authority that compounds over time. None of that fits into a one-off fee. If a quote implies otherwise, it's probably not describing what you think it is. The mechanics behind all this are laid out in more detail if you want to understand what actually happens inside a real SEO campaign, beyond the surface-level reporting. The Numbers: A Realistic Range For a small business in a competitive niche, a credible monthly retainer in the UK typically sits somewhere between £400 and £1,500 per month, depending on how competitive the market is and how much ground needs to be covered. Project-based work for a technical audit plus initial optimisation can range from £600 to £2,500 as a one-off. Anything significantly below those figures should prompt a question about what's actually being done. That doesn't mean expensive is always better. It means the price needs to match the scope. A site with 20 pages in a niche local market needs far less than a growing e-commerce store targeting national search terms. The honest conversation is about what your site needs, not what a standard package includes. What Cheap SEO Actually Costs You This is where it gets uncomfortable. Poorly executed SEO doesn't just fail to work. It can actively cause damage that takes longer to undo than the original problem would have taken to fix. Google's quality guidelines are explicit about thin content, manipulative link schemes, and keyword stuffing. Crossing those lines, even accidentally through a bad provider, leaves a mark that a good campaign then has to clean up first before making any forward progress. The scenario at the top of this post is not unusual. Mass-produced content with no real targeting destroys topical clarity, confuses crawlers, and dilutes the authority of pages that were actually working. Recovering from it means auditing every page, removing or consolidating what doesn't pull its weight, and rebuilding trust with Google slowly. That takes time and money that the client wouldn't have spent if the first campaign had been done properly. If you're weighing up providers, the reasons behind what good SEO costs are worth reading before you commit. The One Honest Caveat SEO takes time regardless of how good the work is. Even a technically sound, well-structured campaign with strong content rarely shows meaningful ranking movement in under three months. For competitive terms, six to nine months is a more realistic expectation. Anyone promising results in thirty days is either targeting terms nobody searches for or making promises they can't keep. That patience is built into the price. You're not paying for a quick win. You're paying for something that holds up and keeps building. The metrics worth tracking while you wait are explained in our piece on which SEO signals actually matter, rather than the vanity numbers that look impressive but tell you very little. Spend less, get less. Spend appropriately, and give it time. That's the honest shape of it. ------------------------------------------------------------ # SEO Metrics That Actually Matter (Cut the Noise) Source: https://yorkshiredesign.co.uk/seo-metrics-that-actually-matter-cut-the-noise/ Published: 2026-07-21 > Most SEO dashboards are full of numbers. Impressions, domain authority, keyword density, crawl budget. Some of those numbers matter. Most are noise. The problem is that too many businesses spend real time watching the wrong ones, then wonder why their rankings don't shift. This post cuts through that. It's a straight comparison of which metrics are genuinely worth tracking, which are vanity figures, and how to tell the difference. Organic Traffic vs Keyword Position: Which Comes First?Ranking number one for a keyword feels like the obvious win. But a top position for a phrase nobody searches does nothing for your business. Organic traffic, the actual count of people arriving from search, is the more honest measure of whether your SEO is working.Position tracking still has its place. It shows whether specific pages are moving in the right direction. But watching rankings without checking whether those pages actually get clicked means you're reading half the story. Both numbers together are useful. Either one alone misleads.Click-Through Rate: The Metric Most People IgnoreGoogle Search Console gives you click-through rate (CTR) for every page and query. It's one of the most underused numbers in SEO. A page sitting at position four with a 12% CTR is delivering more real traffic than a page at position two with a 3% CTR.A low CTR on a well-ranked page usually points to a weak title tag or a meta description that doesn't earn the click. That's a quick fix with a measurable result. It's the kind of detail worth spending time on, rather than chasing a ranking position one place higher.Impressions: Useful Context, Dangerous ObsessionImpressions tell you how often your pages appeared in search results. That's worth knowing. What they don't tell you is whether anyone engaged, clicked, or found what they were looking for.A site can rack up 50,000 impressions a month and generate almost no business if those impressions come from irrelevant queries. Chasing impression volume by producing content at scale is one of the more damaging habits in SEO. We built a site for a local company several years ago, and the owner later brought in an SEO firm that pushed out hundreds of poorly targeted pages. Impressions climbed. Rankings for the pages that actually mattered tanked. Bad content at volume is worse than no content at all.Treat impressions as context, not a goal. They tell you reach. They say nothing about relevance.Core Web Vitals: Technical Signals That Feed Real BehaviourCore Web Vitals measure how a page loads and responds for a real visitor. Google uses them as a ranking input, but their value runs deeper than that. A slow page loses people before they've read a word. A page that shifts layout as it loads frustrates visitors in a way that's hard to recover from.The three figures to watch are Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS). Google's own Web Vitals documentation sets the thresholds clearly. LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1. These aren't aspirational targets. They're the line between a page that works and one that quietly pushes visitors away.Domain Authority: Stop Treating It Like a Google MetricDomain Authority is a score created by Moz. Ahrefs has its own version called Domain Rating. Neither is a Google metric. Google does not use either figure when ranking your pages. They are third-party estimates of link profile strength, useful for benchmarking against competitors, but not worth treating as a primary goal.A smaller site with carefully earned links from genuinely relevant sources will outperform a site with a high DA score built on low-quality directories. What you want to track is the quality and relevance of the sites linking to you, not a composite score that smooths over all of that. If you're investing in the underlying technical work that supports a clean site, link quality follows more naturally over time.Conversions: The Number That Closes the LoopOrganic traffic is a means to an end. That end is enquiries, purchases, sign-ups, or whatever action your business actually needs. If your SEO reporting never reaches that point, you're measuring effort rather than outcome.Setting up goal tracking in Google Analytics 4 is not complicated, though it does take time to get right. Once it's in place, you can see which pages bring in traffic that converts and which bring in traffic that bounces straight off. That distinction shapes every content and optimisation decision that follows. Without it, the whole process is a bit like steering without a destination.The Honest Trade-OffNo metric works in isolation. Organic traffic without CTR data misses intent. Rankings without conversion data miss business impact. Core Web Vitals without content quality miss the full picture. The goal is a small, clear set of numbers that together show whether the site is moving in the right direction, not a dashboard stuffed with figures that feel productive to watch but never change a single decision.Pick fewer metrics. Understand each one properly. That's what actually pays off. ------------------------------------------------------------ # WordPress Hosting Migration: What Goes Wrong and How to Avoid It Source: https://yorkshiredesign.co.uk/wordpress-hosting-migration-what-goes-wrong-and-how-to-avoid-it/ Published: 2026-07-21 > Moving a WordPress site to a new host sounds straightforward. Copy the files, move the database, update a few settings. In practice, it's the kind of job that quietly breaks things you won't notice for days. A missing redirect, a corrupted database table, a caching layer that remembers the old server. This checklist covers the parts that actually go wrong, so you can go into a migration with your eyes open rather than fixing problems after the fact. Back Everything Up Before You Touch Anything This sounds obvious, but a full backup means files and database, not just a folder download. Many hosting control panels let you grab the public_html directory without touching the MySQL database, and that's where all your content lives. Use a plugin like UpdraftPlus or run a manual export via phpMyAdmin. Store the backup somewhere other than the current host, because if that server goes down mid-migration, you need a copy you can actually reach. Download a local copy. Don't rely on cloud storage you haven't tested restoring from. Choose a Host That Won't Slow You Down The migration itself is only half the job. Where you're moving to matters just as much as how you get there. From experience, Hostinger consistently offers the best value for running multiple WordPress sites, particularly when you pay up front for a longer term. Their LiteSpeed cache stack comes included rather than bolted on, and server response times hold up well against hosts that charge considerably more. GoDaddy is one we'd steer people away from. Across several servers over the years, the experience was the same, reliably slow, loaded with unnecessary add-ons, and expensive at renewal. The renewal cost trap catches a lot of people regardless of host, so extend your initial period as far as you can afford. That first-year price rarely survives into year two. If you're unsure how hosting choice affects real page performance, the detail on what managed hosting actually does to load times is worth reading before you commit. Transfer Files and Database Cleanly The two most common ways to move a WordPress site are a migration plugin such as All-in-One WP Migration or Migrate Guru, or a manual transfer using FTP and phpMyAdmin. Plugins are faster for straightforward sites. Manual transfer gives you more control when a site has a large database, unusual file permissions, or a custom server configuration. Whichever method you use, check that the wp-config.php file has the correct database credentials for the new host before you test anything. It's a five-second check that saves an hour of debugging a white screen. Set Up a Staging Environment to Test First Don't go live on the new host without testing the site first. Most decent hosts provide a temporary URL or let you add a subdomain specifically for this purpose. Point your local hosts file at the new server IP, browse the site thoroughly, and check forms, checkout flows, and anything that calls an external API. These are the things that quietly break and won't show up in a visual check. A common failure here is a WooCommerce store where the payment gateway stops working because the SSL certificate hasn't been issued on the new server yet. Test everything before you touch DNS. Don't Rush the DNS Change DNS propagation takes time. Typically a few hours, sometimes closer to 48. The mistake people make is lowering the TTL on their DNS records too late, or not at all, which means some visitors land on the old server while others hit the new one. Lower your TTL to 300 seconds (five minutes) at least 24 hours before you plan to switch. Once propagation is confirmed, you can set it back to normal. Keep the old hosting account active for at least a week after the switch. You'll want it there if something surfaces that needs cross-referencing. Check Redirects and Internal Links After the Move If your old site ran on HTTP and the new host has SSL configured, every HTTP URL that isn't redirected properly becomes a potential 404 or a mixed-content warning. Check your .htaccess file has the correct rewrite rules in place, then run the new site through a crawl tool like Screaming Frog to catch broken internal links before Google does. The way your site's internal structure holds together after a move is worth paying close attention to. A poorly migrated site can quietly lose the link equity it had built up, and that doesn't show up immediately. For context on why that structure matters, how WordPress sites typically get internal linking wrong covers the underlying logic. Clear Every Cache After Going Live Once the new host is live, clear everything. The WordPress cache plugin, any server-level cache such as LiteSpeed, Varnish or Nginx, Cloudflare if you use it, and your browser. A cached version of the old site can mask real problems for hours. Confirm you're seeing the live new server by checking the response headers or using a tool like whatsmydns.net to verify propagation has completed. A careful migration takes a few hours spread over a day or two. Rush it and you'll spend longer fixing it than you saved by hurrying. ------------------------------------------------------------ # How to Automate Content Publishing Without Breaking Your Workflow Source: https://yorkshiredesign.co.uk/how-to-automate-content-publishing-without-breaking-your-workflow/ Published: 2026-07-21 > A local trades company asked about automating their blog posts. They wanted content going out three times a week without thinking about it. Reasonable goal. But within a month of setting up a cheap automation tool, they had forty-seven published pages that said almost nothing, two of which shared the same target keyword, and their main service page had quietly slipped off the first page of Google. That is not an automation problem. That is a strategy problem that automation made worse, faster. Automation Does Not Fix a Weak Content Plan Most people miss this. AI automation for content publishing is genuinely useful, but it amplifies whatever you feed into it. Give it a clear structure, a proper keyword map, and sensible publishing rules, and it will save you hours every week. Give it a vague brief and an ambitious schedule, and it will produce volume without purpose. Creating content for content's sake is one of the most common and quietly damaging mistakes a small business can make. Pages start competing with each other. Keywords cannibalise. The site looks busy but the rankings go sideways. Minimal, well-targeted content almost always outperforms a high-volume scattergun approach. The businesses that get the most from automation are the ones that have already done the slower work first. Deciding what to write about, which keywords genuinely matter, and how each piece fits the wider site structure. Automation then handles the scheduling and publishing mechanics. It does not replace that thinking. What You Actually Need Before You Automate Anything Before touching a publishing tool, map out your content properly. That means knowing which pages are already live, what keywords they cover, and where the genuine gaps are. Without that groundwork, automated publishing will almost certainly create duplication and thin pages that do more harm than good. You also need a clear brief for each piece. A title, a focus keyword, a rough word count, and the specific angle you want to take. Automation can schedule and publish that content, but the brief still needs a human behind it. The moment you automate the thinking as well as the publishing, quality drops fast. Google's quality rater guidelines are clear that useful, accurate, people-first content carries real weight. No scheduling tool changes that. Writing content that actually ranks still comes down to whether it answers something real and does it better than what is already out there. How the Mechanics of Automated Publishing Work At its simplest, an automated content publishing workflow moves through a few clear stages. Content is drafted, reviewed, formatted, then queued for publication at a set time. WordPress's native scheduling handles the last step on its own. More involved setups might pull a draft from a Google Doc or a content management sheet, run it through a formatting step, and push it live on a schedule. A simple automated publishing flow Brief approved → Draft written → Human review → Scheduled in WordPress → Published automatically → Internal link check The human review step is not optional. That is where you catch keyword clashes, thin content, and anything that reads like it was written to fill a slot rather than answer a question. Skipping it is where most automated workflows begin quietly damaging a site. What Good AI Automation for Content Publishing Actually Looks Like Done properly, tools that genuinely speed up content workflows handle the repetitive parts. Pulling a draft into WordPress, applying the right category and tags, scheduling it for a sensible time, pinging the sitemap to search engines once it goes live. These are tasks that take five to ten minutes each time you do them manually. Across twenty posts a month, that adds up. What good automation does not do is write the strategy, pick the keywords, or decide whether a piece should be published at all. That judgement stays with the person who knows the business. The automation simply removes the mechanical steps around it. The Part Nobody Warns You About Bad content at scale is significantly worse than no content at all. We built a website for a local company some years ago, and the owner later hired an SEO firm that produced hundreds of poorly targeted pages at pace. The result was a site that looked amateurish, a main keyword that dropped out of the rankings, and a considerable amount of cleanup work needed to recover the position. That is not an edge case. It is a predictable outcome of treating volume as a proxy for quality. If you are considering bringing automation into your content process, start small. Automate the scheduling of content you have already approved. See how it performs. Then extend the workflow carefully, one step at a time. The businesses that get it right treat automation as a time-saver on top of a solid plan, not a replacement for having one. The Honest Trade-Off Automation saves real time. It also makes it easier to publish things you should not publish. The discipline required to run a good automated content workflow is, if anything, higher than doing everything manually, because the volume is higher and the errors compound faster. Go in with that understanding and it is a genuinely useful tool. Go in expecting it to do the thinking for you and it will create problems that take months to untangle. ------------------------------------------------------------ # WordPress Websites: What You’re Actually Getting Under the Hood Source: https://yorkshiredesign.co.uk/wordpress-websites-what-youre-actually-getting-under-the-hood/ Published: 2026-07-21 > Most WordPress websites look fine on the surface. Clean layout, a few pages, a contact form. But scratch beneath that and you'll often find a different story, bloated themes loading dozens of scripts nobody asked for, plugins fighting each other quietly, and a database that's never been touched since the site went live. Understanding what's actually running under a WordPress site is the difference between one that holds up over time and one that slowly falls apart without anyone noticing. WordPress Is a Framework, Not a Finished ProductA lot of people treat WordPress as if it's the website itself. It isn't. WordPress is the foundation, and what you build on top of it determines almost everything about how the site performs, ranks and behaves under pressure.The theme controls how every page is rendered. The plugins handle functionality. The hosting determines how fast those files reach a browser. Get any one of those layers wrong and the whole thing suffers, regardless of how good the design looks in a screenshot.Think of it like a car engine rather than the paintwork. You can have a beautiful exterior and still be running on something working twice as hard as it should for half the output.What Themes Are Actually Doing to Your SiteThemes are the single biggest source of unnecessary weight on most WordPress websites. A theme like Divi or Avada ships with its own page builder, its own CSS framework, its own JavaScript, and often its own font loading system. You're loading all of that whether you use those features or not.A leaner approach, using a minimal base theme or a well-coded block theme, can cut what the browser has to load by a significant margin. That matters directly for how themes behave at a code level, and it matters even more for Core Web Vitals scores that affect real search rankings.The honest trade-off is that leaner themes often demand more technical setup. You lose the drag-and-drop convenience. For some clients that's the right compromise. For others it isn't. There's no universal answer, but the cost of a heavy theme compounds over time as Google's patience for slow pages gets thinner.The Plugin Problem Nobody Talks About HonestlyPlugins are WordPress's greatest strength and its most common liability. A well-built plugin from a reputable developer, kept updated and used for a single clear purpose, is fine. The problem is that most WordPress websites accumulate plugins the way a garage accumulates junk. One at a time, each for a reason that made sense at the time.Twelve active plugins is normal. Twenty is common. Some of those will be loading scripts on every page of the site, even pages where they do nothing. Some will conflict with each other in ways that only show up under specific conditions. A few won't have received a meaningful update in two years.The test worth running is simple. Disable each plugin one by one and check whether the site still does what it needs to do. You'll be surprised how many can go.SEO and WordPress: Where It Actually Goes WrongWordPress is genuinely good for SEO when it's set up correctly. Clean URLs, a sensible heading structure, proper canonical tags, fast load times. All of that is achievable without specialist tools if the underlying build is solid.Where it goes wrong, repeatedly, is when SEO is treated as a plugin job rather than a structural one. Installing Yoast or Rank Math does not optimise a site. Those tools surface information. They don't fix technical problems. Duplicate content from tag archives, thin category pages generating hundreds of near-identical URLs, images without alt text at scale. These are structural decisions, not configuration settings.In our experience, taking over a site from a previous provider often reveals months of retainer payments with nothing concrete done. The SEO plugin is configured, the green lights are on, but the underlying technical issues are untouched. It's an uncomfortable conversation to have with a new client, but it's one that comes up more often than it should.Hosting: The Layer Most People Ignore Until Something BreaksShared hosting is where a lot of WordPress websites live, and it's where a lot of performance problems are born. A server that responds slowly to every request adds latency before a single byte of page content has loaded. No amount of caching fixes a slow server response.If your hosting migration to a faster provider ever goes sideways, it's usually because of database connection strings, SSL misconfiguration, or DNS propagation catching someone off guard. These are solvable problems, but they need someone who knows what to check at each stage rather than clicking through a wizard and hoping for the best.Keeping a WordPress Site in Good ShapeA WordPress website isn't finished when it goes live. Core updates, plugin updates, PHP version compatibility, database optimisation, log file checks. These are recurring jobs, not one-off tasks.Check PHP version compatibility whenever WordPress releases a major updateReview active plugins every few months and remove anything not actively usedRun a page speed audit after any significant plugin or theme updateMonitor for broken links, especially after content restructuringNone of that is glamorous work. But it's the kind of quiet maintenance that keeps a site running well for years rather than quietly degrading until something finally breaks visibly. ------------------------------------------------------------ # WP Rocket: A Beginner’s Guide to What It Actually Does Source: https://yorkshiredesign.co.uk/wp-rocket-a-beginners-guide-to-what-it-actually-does/ Published: 2026-07-21 > If someone has told you to install WP Rocket and you're not entirely sure what it does or whether it's worth the money, you're not alone. It's one of the most recommended WordPress plugins out there, but most explanations either assume you already know what caching is or try to sell you on it before explaining the basics. So here's a plain-English walkthrough of what WP Rocket actually is, what it changes on your site, and what you genuinely need to know before buying it. What WP Rocket Is (and What Problem It Solves) WP Rocket is a caching and performance plugin for WordPress. Its main job is to make your website load faster for visitors. It does that by storing a ready-made version of each page so WordPress doesn't have to rebuild it from scratch every time someone arrives. Think of it like a bakery that pre-bakes its most popular loaves in the morning. When a customer walks in, the bread is already on the shelf. Without caching, the bakery bakes every loaf to order, one at a time, which takes far longer. Your website works in almost exactly the same way. Beyond caching, WP Rocket also handles a handful of other speed-related tasks, combining CSS and JavaScript files, lazy-loading images, preloading pages, and cleaning up some of the bloat that WordPress tends to accumulate over time. Why Page Speed Actually Matters Page speed is one of those things that sounds technical but has a very direct impact on real visitors. A slow site loses people before they've even read a word. Google's own guidance confirms that page experience, including load speed, is a ranking factor, so a sluggish site can quietly cost you both visitors and search visibility. Core Web Vitals are the specific set of metrics Google uses to measure that experience. They include how fast your largest visible element loads, how quickly the page responds to a first click, and how much the layout shifts while loading. WP Rocket addresses several of these directly, which is part of why it's so widely recommended for improving those scores. If you want to understand what those scores actually mean before touching any plugin, there's a good overview of what PageSpeed Insights is measuring that's worth reading first. What WP Rocket Does Not Do This is where most beginners get caught out. WP Rocket is not a magic fix. It cannot compensate for a slow hosting server, a bloated theme with hundreds of scripts loading on every page, or enormous uncompressed images. A common pattern is this, someone buys WP Rocket, runs a speed test, and is disappointed that their score barely moved. Nine times out of ten, the bottleneck is the host, not the cache layer. No caching plugin can speed up a server that's already struggling. If your hosting is the weak link, the things that genuinely matter for WordPress hosting speed are worth working through before spending money on performance plugins. WP Rocket also won't fix a theme that loads fifteen different font files or a page builder that outputs three times the HTML it needs to. It can reduce the damage somewhat, but the underlying cause needs addressing separately. The Settings Worth Paying Attention To WP Rocket has a lot of options, and it's easy to enable everything and create new problems. Some JavaScript optimisations, for example, can break contact forms or sliders if applied without testing. The plugin warns you about this, but beginners often click past the warnings. The settings that tend to give the biggest benefit with the least risk are straightforward. Basic page caching, which is on by default and safe to leave alone. Lazy loading for images, which delays off-screen images from loading until the visitor scrolls to them. Database optimisation, which removes old post revisions and expired transients that quietly build up over months. Preloading, which tells WP Rocket to crawl your site and warm up the cache automatically. The JavaScript deferral and delay options are where most people run into trouble. They're worth exploring, but test carefully after enabling them, especially on forms and checkout pages. For a closer look at getting the most out of what you've paid for, this breakdown of WP Rocket settings in practice goes into the detail. Is It Worth the Price? WP Rocket isn't free. It costs around $59 per year for a single site licence, which puts some people off when free alternatives like W3 Total Cache exist. The honest answer is that the paid price buys you a much cleaner setup experience and settings that are generally safer out of the box. W3 Total Cache is powerful, but its interface is genuinely intimidating if you don't know what you're doing. One wrong setting can break a site. WP Rocket is designed to give sensible defaults from the moment you activate it, which counts for a lot when you'd rather focus on your business than debug a white screen. For a single WordPress site that handles moderate traffic, it's a reasonable spend. For multiple sites, the cost adds up, and that's where hosting with a built-in cache stack becomes worth exploring. In our experience, Hostinger's LiteSpeed cache stack, included with their hosting plans, can outperform WP Rocket on sites where the server itself is already fast, especially if you pay upfront for a longer initial term to lock in the lower price. Just watch the renewal cost, which jumps significantly after the first period. WP Rocket earns its place on most WordPress sites. Just go in with realistic expectations about what it can and can't fix on its own. ------------------------------------------------------------ # WordPress Themes: Is Salient Still Worth It? Source: https://yorkshiredesign.co.uk/wordpress-themes-is-salient-still-worth-it/ Published: 2026-07-21 > Salient has been around long enough to have a reputation, and for a while that reputation was well earned. It sold in enormous numbers on ThemeForest, and plenty of agencies defaulted to it because it looked impressive out of the box. The question now is whether it still holds up when you look past the demo. Because the web has moved on, and a theme that wowed people a few years ago can quietly become a drag on a site that needs to stay fast, clean and genuinely competitive. What Salient Actually Is Salient is a premium multipurpose WordPress theme built around its own page builder, WPBakery. It ships with a large library of pre-built demos, a custom header builder, and a set of bundled plugins including Revolution Slider. On paper, that sounds like everything you'd want in one package. In practice, that bundling is exactly where the problems start. The Performance Problem Is Real Multipurpose themes like Salient are built to do everything, which means they load assets for features you're not using. A contact page doesn't need portfolio scripts. A homepage doesn't need the WooCommerce helpers buried three directories deep. But they load anyway, because the theme has no way of knowing what you're not using. Revolution Slider is a particular offender. It's been a staple of themes like Salient for years, but it adds significant JavaScript weight even on pages with no slider at all. On a site where Core Web Vitals matter, that kind of passive bloat is quietly working against you before a single visitor lands. For context, Google's own documentation on Largest Contentful Paint makes clear that render-blocking scripts are one of the fastest ways to tank your LCP score. A theme that bundles several of them isn't a shortcut. It's a liability. WPBakery Is the Sticking Point Salient is tightly coupled to WPBakery, which predates the block editor by several years. It works, but it stores layout as raw shortcode inside post content, which means your design is baked into the database in a format only WPBakery can read. Switch themes, or try to move to a different builder, and you're left with pages full of unrendered shortcode strings. That's not a minor inconvenience. It's a migration headache that has caught out a lot of site owners who thought they were just choosing a design, not locking into an ecosystem. If you're considering a theme that holds up technically over the long run, the builder underneath matters just as much as how the demos look. Where Salient Still Has Genuine Strengths It would be unfair to write it off entirely. Salient has a genuinely active development team, and the theme does receive updates. The demo library is extensive, and for someone who needs a complex-looking site without commissioning a custom build, the variety on offer is hard to match at that price point. For smaller sites where page speed isn't a primary concern, where the owner is happy to stay within the WPBakery ecosystem, and where the visual output matters more than the technical detail underneath, Salient can still do the job. It's not a broken theme. It's just not a lean one. What the Alternatives Look Like The honest answer is that the WordPress theme market has matured considerably. Block-based themes built for the native editor are lighter, more future-proof, and play well with tools like Spectra or Kadence Blocks without the shortcode lock-in. Themes like Kadence or Astra start fast and let you build up complexity only where you need it, rather than loading everything by default. That said, switching from Salient to a block theme on an existing site isn't a small job. The rebuild cost is real, and if a site is performing well enough in its current state, the disruption may not be worth it right now. We've found that the decision almost always comes down to what the site needs to do next, not just what the theme is capable of today. The Optimisation Trap to Watch Out For One pattern worth flagging, a Salient site that's been "optimised" by someone who installed WP Rocket, ran an image compression pass, and called it done. The PageSpeed score might look respectable straight after, but that's often because the server cache is still serving the pre-optimisation version of the page. Clear that cache, run the tests again, and the picture can look very different. In our experience, clients have paid to have their WordPress site optimised and only discovered later, once the server cache expired naturally, that the underlying issues were never actually fixed. The score looked good. The site wasn't. Always test with the cache cleared and every plugin active, or you're not testing the real thing. The Verdict Salient isn't a bad theme. But if you're starting a new build today, there are lighter, more flexible options that won't put you on the back foot before you've written a word of content. If you're already running Salient on an existing site, the question isn't whether it's fashionable. It's whether it's slowing you down in ways you can measure. That's worth finding out before assuming everything is fine. ------------------------------------------------------------ # Web Hosting With WordPress: What Actually Matters for Speed Source: https://yorkshiredesign.co.uk/web-hosting-with-wordpress-what-actually-matters-for-speed/ Published: 2026-07-21 > Pick the wrong host and it does not matter how well your WordPress site is built. A slow server punishes every page, every visitor, every search ranking. The problem is that most hosting comparisons focus on storage and price, not on the things that actually determine how fast your site loads. Here is what to look at instead. Server response time comes before everything else Before a browser can render a single pixel, your server has to respond. Google measures this as Time to First Byte, and anything above 600ms is a red flag. A well-configured server on good infrastructure should respond in under 200ms for a cached page. If your server response time is slow, no amount of image compression or caching plugins will fully rescue you. You are patching a problem that starts one level deeper. Check your TTFB in Google's PageSpeed Insights before you touch anything else on the site. Shared hosting is a gamble you usually lose On shared hosting, your WordPress site sits alongside dozens or hundreds of other sites on the same physical server. When a neighbour gets a traffic spike or runs a heavy database query, your site slows down. You have no control over that. For low-traffic brochure sites, shared hosting is often fine. But the moment you add WooCommerce, a membership area, or any real volume of daily visitors, the limitations show quickly. A modest VPS or a quality managed WordPress host costs more, but the consistency is worth it. Predictable performance beats occasional fast, and your Google rankings reflect that over time. In our experience, GoDaddy shared hosting is persistently slow. The servers feel overloaded, and they come bolted with unnecessary add-ons that do not help performance. Renewal costs are also steep once the introductory period ends, which makes the total value poor. PHP version is not a minor detail WordPress runs on PHP. Older PHP versions are measurably slower and miss security patches that have been available for years. Running PHP 7.4 on a host that supports 8.2 is a choice that costs you on both fronts. Check your host's control panel. If PHP 8.1 or 8.2 is available and your theme and plugins support it, switch. The performance difference on database-heavy pages is real, not theoretical. Most decent hosts let you change this with a single dropdown. If yours does not, that tells you something about how current their infrastructure is. Object caching separates good setups from great ones WordPress makes a database call for almost everything it renders. Object caching stores the results of those calls in memory, so the same query does not have to run again for the next visitor. Redis and Memcached are the two common tools for this. Most shared hosts do not offer either. Quality managed WordPress hosts include Redis as standard. If your current host does not support object caching, a caching plugin alone is doing only part of the job. You can see the impact clearly on sites with dynamic content, like WooCommerce catalogues, where the difference between cached and uncached database calls is measured in whole seconds. For more on how managed hosting affects real-world speed, it is worth reading through the specifics before committing to a plan. Where your server physically sits still matters Latency increases with physical distance. A server in the United States adds measurable delay for a visitor in Manchester, even with a CDN in front of it. For UK-focused sites, a UK or European data centre is the right default. A CDN helps by serving static assets from edge nodes closer to the visitor, but it does not replace a geographically sensible origin server. The CDN fetches content from your origin at some point, and if that round trip is slow, you will still feel it. Get the origin right first, then layer a CDN on top. Storage type changes everything on disk reads NVMe and SSD storage are significantly faster than traditional spinning hard drives at retrieving files. WordPress reads theme files, plugin files and uploaded assets on every uncached request. If your host is still using HDD storage, that read speed becomes a bottleneck at scale. It sounds like a minor hardware detail. It is not. The gap between HDD and NVMe on WordPress file reads is substantial enough to affect your Largest Contentful Paint score, which is one of the three Core Web Vitals Google uses as a ranking signal. Fixing Core Web Vitals on WordPress is much harder when the server itself is the bottleneck. One honest caveat Upgrading your hosting will not fix a bloated theme, unoptimised images, or a plugin loading scripts on every page. Good infrastructure creates the right conditions for a fast site. It does not compensate for a poorly built one. Both matter, and getting the hosting right is where the process starts, not where it ends. Related: Web Hosting Explained: What Actually Matters for Your Site Related: Server Response Time and TTFB: The Page Speed Problem Most Sites Ignore Related: Web Hosting for Small UK Businesses: What Actually Matters ------------------------------------------------------------ # Google Insights PageSpeed: What the Scores Actually Mean Source: https://yorkshiredesign.co.uk/google-insights-pagespeed-what-the-scores-actually-mean/ Published: 2026-07-21 > You paste your URL into Google Insights PageSpeed, hit Analyse, and get back a number. Sometimes it's red. Sometimes it's amber. Occasionally it's a satisfying green. Most people stare at it for a moment, feel vaguely worried or vaguely relieved, and then close the tab. That's understandable, because the tool does not explain itself particularly well. These scores are not arbitrary, though. Each one points to something specific happening on your site, and understanding what they measure changes how you respond to them. One Tool, Two Very Different Tests The first thing worth knowing is that PageSpeed Insights runs two separate analyses. One simulates a mobile device on a slow 4G connection. The other tests desktop conditions. You get a score for each, and they often differ by 20 points or more. Mobile nearly always scores lower. That is not a flaw in the tool. Mobile users are genuinely on slower networks and less powerful hardware, so the test reflects real-world conditions rather than a best-case lab environment. If your mobile score is in the red and your desktop score is green, that is not balance, that is a problem half-hidden. What the Colour Bands Actually Represent PageSpeed Insights scores run from 0 to 100. Google groups them into three bands, and the thresholds are worth knowing precisely rather than roughly. 0 to 49 (red) , Poor. The page is likely causing real frustration for visitors. Slow load times at this level are directly linked to higher bounce rates. 50 to 89 (amber) , Needs improvement. Not catastrophic, but there is measurable room to speed things up, and some users will notice the delay. 90 to 100 (green) , Good. Most pages in this range pass Core Web Vitals and give visitors a reasonable experience. The number itself is a composite, though. It is not a direct reading of how fast your page loads in seconds. It is a weighted average of several underlying metrics, which is where most people's understanding stops. The Metrics Doing the Real Work Behind the headline score sit six individual metrics. Not all of them carry equal weight. Some metrics matter far more than others, and knowing which ones Google emphasises is the difference between fixing the right things and wasting a day on the wrong ones. Largest Contentful Paint (LCP) measures how long it takes for the biggest visible element on the page to load. That is often a hero image or a large heading. Total Blocking Time (TBT) captures how long the main thread is locked up by JavaScript, leaving the page technically loaded but unresponsive to taps and clicks. Cumulative Layout Shift (CLS) records whether elements jump around as the page settles, which is the experience of going to tap a button and having it move at the last second. These three carry the most weight in the final score. Improving them moves the needle. Chasing the others without addressing these is tidying around the edges. Lab Data vs Field Data PageSpeed Insights shows you two kinds of information side by side, and most people do not notice the distinction. Lab data is collected by running a controlled simulation every time you run the test. Field data, shown in the 'Discover what your real users are experiencing' section, comes from real Chrome users visiting your site over the previous 28 days. Field data is only available if your site has enough traffic for Google to have collected it. If you do not see it, the lab data is all you have. The two often disagree. A page can score 78 in the lab and still show red Core Web Vitals in field data if real-world conditions are harsher than the simulation assumes. For SEO purposes, field data is what Google actually uses in its ranking signals. The lab score is useful for diagnosis. The field data is the report card. Why the Score Changes Every Time You Run It This catches people out. You run the tool twice in a row and get 71 then 68. Nothing has changed on the site. The variation is real and normal. The simulation uses a throttled connection, and network conditions in Google's testing infrastructure fluctuate slightly. A swing of three to five points between runs is noise. A swing of fifteen points is worth investigating. A common issue we see across many sites is a score that looks reasonable on average but collapses under load or at certain times of day, which points to a server performance problem rather than a front-end one. A good host matters as much as a lean codebase. If you want a stable baseline, run the test three times and take the middle result. Then look at what the individual numbers are telling you rather than fixating on the composite score alone. What the Score Does Not Tell You A score of 90 does not mean your site is fast for every visitor. It means it performed well under a specific simulated condition. Shared hosting, a CDN without proper caching, or a theme loading four hundred kilobytes of unused CSS can all drag real-world performance below what the tool shows. The score is a starting point, not a finish line. Treat it as a prompt to look deeper, not a pass or fail certificate. ------------------------------------------------------------ # Content Writing for Service Businesses: What Gets Read Source: https://yorkshiredesign.co.uk/content-writing-for-service-businesses-what-gets-read/ Published: 2026-07-21 > Most service business websites have plenty of words on them. The problem is nobody reads them. Visitors land on a page, scan for about eight seconds, and leave if nothing snags their attention. That isn't a design failure. It's a content failure. The writing is either about the business instead of the reader, too vague to be useful, or buried under so much waffle that the actual point never arrives. Getting content right for a service business means understanding why people visit in the first place. People visit to solve a problem, not to read about you The single most common mistake in service business content is writing from the inside out. A plumber writes about how they started in 1987 and take pride in their work. A solicitor lists every qualification on their about page. A web designer explains their 'process' in four corporate steps. None of that is what the visitor came to read. They came because something is broken, confusing, or costing them money. Write toward that first, and your story earns its place later. A simple test, read your first paragraph and count how many times the word 'we' appears versus the word 'you'. If 'we' wins, rewrite it. The formats that actually get read Long, unbroken paragraphs are the fastest way to lose someone. That's not opinion, it's just how people read on screens. Short paragraphs, clear subheadings, and the occasional list give the eye somewhere to rest and the brain a reason to keep going. For small businesses trying to rank without a large content budget, this matters even more. You don't need a 3,000-word essay. You need a focused page that answers one question well, with the structure to prove it at a glance. Lead with the problem the reader has, not the service you offer. Use subheadings that mean something, not 'Our Approach' or 'What We Do'. One idea per paragraph. Split anything that covers two things. If you can say it in twelve words, don't use thirty. What the best service pages have in common The service pages that convert well share one trait, they're specific. Not 'professional plumbing services across the region', but 'emergency boiler repairs, usually same day'. Not 'tailored web design solutions', but 'WordPress sites built from scratch, no templates, no page builders'. Specificity does two things. It filters out the wrong enquiries, which saves everyone time. And it signals to the right visitor that you actually know what you're doing. Vague copy reads as a lack of confidence, even when it isn't meant that way. A well-written service page also handles the obvious objections before they come up. How long does it take? What does it cost roughly? What happens after I get in touch? Leaving those unanswered pushes people to Google your competitors instead. Where AI content helps and where it falls short AI can produce a serviceable first draft faster than most people can write a headline. That's genuinely useful for getting words on the page when you're staring at a blank screen. The problem is that AI content tends toward the general. It smooths out the edges that make a business sound like a real person wrote it. For service businesses, voice matters more than volume. A reader who feels like they're talking to a person is far more likely to pick up the phone than one who's just read a paragraph that could have appeared on any site in the same sector. The line between AI content that works and AI content that doesn't usually comes down to whether a human has shaped the output with real detail and genuine opinion. The honest trade-off with longer content There's a persistent idea that longer pages rank better. Sometimes that's true. A thorough how-to guide covering a topic properly can outperform a thin 300-word page with ease. But length without substance is worse than brevity. Google's quality raters are trained to assess whether content genuinely helps the reader, and a bloated 1,500-word page stuffed with filler will not fool anyone for long. The question to ask isn't 'is this long enough?' It's 'have I actually answered what someone searching this phrase needs to know?' That might take 400 words. It might take 900. The length follows the answer, not the other way around. A note on tone for service businesses specifically Corporate language is a habit, not a strategy. Phrases like 'bespoke solutions', 'client-centric approach', and 'passionate about delivery' appear on tens of thousands of service websites and mean nothing to anyone. They're filler that signals low effort. Write the way a competent person explains something to a friend. Direct, plain, and honest about what you do and don't do. That tone builds more trust than any amount of polished positioning language, and it takes considerably less effort to maintain across a whole site. If the copy on your service pages sounds like it could belong to a competitor with the name swapped out, it needs a rewrite. Good content for a service business isn't clever. It's clear, it's useful, and it gets out of the reader's way fast enough that they actually reach the end. ------------------------------------------------------------ # WordPress Performance Audit: What to Check Before You Touch a Plugin Source: https://yorkshiredesign.co.uk/wordpress-performance-audit-what-to-check-before-you-touch-a-plugin/ Published: 2026-07-21 > Most people's first instinct when a WordPress site feels slow is to start deactivating plugins. It's understandable, but it usually sends you down the wrong path. A proper WordPress performance audit works in a specific order, and plugins are rarely where the real problem lives. Get the sequence right and you'll spend less time guessing, find the actual bottleneck faster, and avoid breaking something that was working fine. Start With a Baseline Measurement Before touching anything, you need a fixed starting point. Run the site through Google's PageSpeed Insights and note the scores for both mobile and desktop. Write them down. Screenshots work well too. The numbers themselves matter less than having something to compare against later. Without a baseline, you genuinely cannot tell whether a change helped, hurt, or did nothing at all. It's the most skipped step, and it's the one that costs the most time. Run the test three times and average the results. A single PageSpeed run can vary by 10 or 15 points depending on server load at that moment. One bad reading will send you chasing a ghost. Check Your Hosting Before Anything Else Hosting is the floor everything else sits on. A slow server produces a slow site, full stop, and no amount of caching or image compression will fix that. Look at your Time to First Byte (TTFB). A reading above 600 milliseconds at the server level points directly at infrastructure, not your theme or your plugins. Shared hosting plans are the classic example of this trap. You might have a perfectly lean WordPress install, but if you're sharing a server with hundreds of other sites, your TTFB will drag regardless. A plugin audit won't touch that number. The fix here is often a hosting upgrade or a move to a provider with proper server-side caching. That's a bigger conversation, but it belongs at the start of the audit, not the end. Look at Your Theme's Actual Output Heavy page builders and bloated themes load a lot of CSS and JavaScript that your pages never actually use. Open Chrome DevTools, go to the Coverage tab, and load a page. You'll often see 70 to 80 percent of the CSS marked as unused. That's the theme loading styles for components you haven't built. This is worth knowing before you start blaming plugins, because a theme generating 400kb of render-blocking CSS is a much bigger problem than most plugins will ever be. If your theme doesn't give you control over what it loads, that's a structural issue to address separately. You can read more about what themes actually load under the hood in our post on Core Web Vitals fixes that hold up in practice. Audit Images Before You Audit Code Unoptimised images are responsible for more slowness than almost any other single factor, and they're often the easiest to fix. Look for images served at full resolution that are displayed at thumbnail size, PNGs where a WebP would do the job, and images with no lazy-loading attribute. A product or portfolio page that loads 20 uncompressed JPEGs will score poorly no matter how optimised everything else is. Sort this before you move on. Check that images have defined width and height attributes to prevent layout shift Confirm that WebP is being served where the browser supports it Make sure images below the fold are lazy-loaded Look for any images wider than 1400 pixels that don't need to be Now Look at Render-Blocking Resources Once hosting, theme output, and images are accounted for, render-blocking scripts and stylesheets are the next honest place to look. These are files that pause the browser from drawing the page until they've fully downloaded and processed. In PageSpeed Insights, the 'Eliminate render-blocking resources' diagnostic will list them. CSS loaded in the document head is the usual culprit, followed by JavaScript that hasn't been deferred or moved to load after the page. Disabling Google Fonts is one specific, measurable fix here. Our post on what happens to load time when you drop Google Fonts goes into that in more detail. Plugins Come Last, and Only Then Systematically After all of the above, plugins. Not before. We'd argue WordPress is probably the single most important website platform ever built, powering well over 40 percent of the web, and a big part of that is how well plugins extend it. But that flexibility means it's easy to accumulate 30 plugins when 12 would do the same job. The right way to audit plugins for performance is not to deactivate them randomly. Use a plugin like Query Monitor to see which plugins are adding database queries, and how many. Use the Network tab in DevTools to see which scripts are being loaded on each page. Then you have evidence, not guesses. A plugin that fires 40 database queries on every page load is worth investigating. A plugin that loads one small script is almost certainly not your problem. Check the technical SEO foundations while you're in there too, because slow pages and crawl budget are connected. The technical audit checklist here covers what to confirm before assuming performance is a content issue. The order of all this matters more than most guides admit. Get it right and the audit takes a few focused hours. Skip straight to plugins and you could spend days on something that was never the cause. Related: Page Speed Fixes That Actually Move Core Web Vitals ------------------------------------------------------------ # Content Briefs That Writers Actually Want to Work From Source: https://yorkshiredesign.co.uk/content-briefs-that-writers-actually-want-to-work-from/ Published: 2026-07-21 > Most people who write content briefs think the problem is too little detail. So they add more. More keywords, more headings, more competitor URLs to 'take inspiration from'. The brief gets longer. The output gets worse. A brief is not a script. It is a handshake between the person who knows the business and the person who knows how to write. When that handshake is confused, the writing that comes back will be too. The myth that more detail means better output A brief stuffed with forty keywords, six competitor articles and a 600-word brand summary is not helpful. It is noise. Writers are not robots processing every field in order. They read the brief once, build a mental picture of the piece, and write from that picture. If the brief is a mess, the writing will be too. You will get something that ticks every bullet point and reads like nothing at all. Short, focused briefs nearly always outperform exhaustive ones. Myth, the brief should specify every heading Pre-loading a brief with exact H2s and H3s feels organised. In practice, it traps the writer inside a structure before they have thought the piece through. The result is writing that fills containers rather than builds an argument. A better approach is to name the angle and the destination. What should the reader be able to do, decide, or understand by the final paragraph? That single question does more work than a full heading map. If you genuinely need a particular structure for technical reasons, flag it as a constraint, not a skeleton to flesh out. There is a related trap worth naming, specifying word counts per section. Good writers adjust length to the content, not the other way round. Asking someone to write 200 words on a point that only needs 80 guarantees padding. The one thing most briefs leave out entirely The reader. Not a demographic. A specific person, in a specific moment, with a specific problem. "Our audience is small business owners aged 25 to 50" tells a writer almost nothing. "This is for someone who just Googled 'why is my website slow' at 11pm because a client complained" tells them everything. The situation shapes the tone, the vocabulary, the assumed knowledge, and how much patience the reader brings to the page. Without it, writers guess. They usually guess wrong. Keyword stuffing the brief is not the same as SEO guidance Listing fifteen keyword variants does not help a piece rank. It makes the writer anxious and the prose clunky. A clean brief names one primary keyword and explains the intent behind it. Is this person trying to understand something, compare options, or make a decision? That matters far more than keyword density. If you are working with a writer who understands what search engines and readers both need from a page, you do not need to teach them SEO in the brief. You need to give them enough context to apply it well. Producing content in bulk from keyword lists is, more often than not, a waste of effort. Pages end up competing with each other, signals get diluted, and nothing ranks well for anything. A smaller number of carefully chosen topics, written properly, does more. Competitor links are not a brief "Here are three articles we want to beat" is not direction. It is an invitation to copy the structure of something that may not even be performing well. Many high-ranking pages rank despite their writing, not because of it. They have backlinks, domain authority, or age working in their favour. If you share competitor URLs, explain what you think they did right or wrong. "This article is thorough but buries the practical advice in section four" is useful. A URL with no comment is not. What a genuinely useful brief actually contains It is shorter than you think. The brief needs to answer four things clearly, and nothing else is required. Who is reading this, and what is their situation right now. What one thing should they walk away knowing or doing. The primary keyword and the intent behind it. Any hard constraints, tone, word count, topics to avoid, claims that need a source. That is it. A writer with those four answers can produce something worth publishing. A writer handed a forty-field template with no clear reader picture cannot, regardless of how much time they put in. The briefs that produce forgettable pages, covered in more detail when looking at why most briefs produce forgettable content, tend to share one flaw. They are written for the process rather than the reader. The brief becomes a checklist to complete rather than a conversation to have. Fix that, and the writing tends to fix itself. Related: AI Writing Tools vs Human Writers: Where Each One Wins ------------------------------------------------------------ # Technical SEO Audits Explained Without the Jargon Source: https://yorkshiredesign.co.uk/technical-seo-audits-explained-without-the-jargon/ Published: 2026-07-21 > Most people have been told they need a technical SEO audit without being told what one actually involves. The phrase sounds serious, and the reports that come back often look impressive, full of red flags and percentages. But what is actually being checked, and why does it matter? This is a plain-English walk through what a real audit covers, what the findings usually mean, and where the genuinely important problems tend to hide. Start With Crawlability Before anything else, an audit asks one basic question. Can search engines actually read the site? Googlebot and other crawlers follow links, request pages, and interpret the code they find. If something blocks that process, pages simply do not get indexed. Common blockers include a misconfigured robots.txt file, a noindex directive left on from a staging environment, or a sitemap that points to URLs the server returns as errors. These are not rare edge cases. They turn up regularly, and they are the kind of thing that looks fine on the surface while quietly doing real damage underneath. Index Coverage: What Google Has Actually Found An audit pulls the list of URLs Google has indexed and compares it to what the site actually contains. The gaps between those two things are where problems live. Duplicate content is a frequent culprit. A single product page might be reachable through four or five different URLs because of trailing slashes, URL parameters, or session IDs. Google picks one version and largely ignores the rest, which means link equity gets diluted and the wrong page can end up ranking. Canonical tags should handle this, but they are often missing, wrong, or pointing in circles. Thin pages are another pattern worth watching. Automatically generated tag archives, near-empty category pages, paginated results with no unique content. These pages consume crawl budget without contributing anything. In our experience, a site that has let this run unchecked for a year or two can end up with hundreds of indexed pages that nobody searched for and nobody benefits from. Site Structure and Internal Linking How a site links to itself tells search engines which pages matter. An audit maps the internal link structure to check whether the most important pages are actually being prioritised. Orphan pages are a common finding. These are pages with no internal links pointing to them, which means crawlers may never find them at all, regardless of how good the content is. At the other end, some sites funnel almost all their internal links through a single navigation menu and nowhere else, which is a missed opportunity to signal relevance through the body of the content itself. Depth also matters. A page buried six clicks from the homepage is being treated as low priority, whether that was the intention or not. An audit surfaces this so the structure can be adjusted deliberately rather than left as an accident of how the site grew. Page Speed and Core Web Vitals Speed is a ranking signal, but more importantly it affects whether visitors stay. Core Web Vitals measure three specific things, how fast the main content loads, how quickly the page responds to input, and how much the layout shifts during load. Google uses these as part of its broader assessment of page quality. An audit checks these scores against real-world data where available. Lab scores from tools like PageSpeed Insights give a useful directional read, but field data from the Chrome User Experience Report reflects what actual visitors experienced. The two can diverge significantly, especially on sites that serve a lot of returning visitors with cached assets. Render-blocking scripts, unoptimised images, third-party embeds that load before anything else. These are the usual causes of a slow Largest Contentful Paint, and they are all fixable once they are identified. On-Page Technical Signals This section of an audit tends to get conflated with content work, but there is a distinct technical layer here. Title tags and meta descriptions are checked for duplication, length problems, and missing values. Heading structure is reviewed to see whether it makes logical sense or whether H1 tags are scattered across the page by a theme that does not know better. Structured data is another area worth checking. Schema markup helps search engines understand what a page is about, whether it is a product, a review, a business listing, or a recipe. Errors in schema often go unnoticed for months. You can check for them directly in Google's Rich Results Test, and an audit should do exactly that. What a Real Audit Actually Turns Up The findings that matter most are rarely the ones that look dramatic in a report. A long list of missing alt attributes is easy to generate and easy to fix. The things that take more time to diagnose are the structural issues, a redirect chain built up over years of migrations, a canonical configuration that contradicts the sitemap, foundational problems that make link building pointless until they are resolved. One pattern that comes up more than it should is sites where the owner, after the original build, handed things over to a content agency that produced volume without strategy. Hundreds of pages targeting loosely related terms, no internal linking between them, thin word counts. It looks like activity but it dilutes the whole domain. Bad content does not cancel itself out over time. It accumulates. A thorough audit separates the noise from the things that are genuinely holding a site back. That is the point of it. Not a report full of amber warnings, but a clear picture of what needs fixing first and why. ------------------------------------------------------------ # 7 Reasons Proper SEO Costs What It Does Source: https://yorkshiredesign.co.uk/7-reasons-proper-seo-costs-what-it-does/ Published: 2026-07-21 > SEO quotes vary wildly. You'll see offers for £99 a month and proposals for £1,500 a month, and both claim to do the same thing. They don't. The real cost of a proper SEO campaign reflects the actual hours involved in technical auditing, content work, link building, and ongoing monitoring. This post breaks down where that money actually goes, so you can judge what's worth paying for and what isn't. 1. A Technical Audit Takes Longer Than Most People Expect Before any rankings move, someone needs to understand what's already broken. A proper technical audit covers crawl errors, duplicate content, page speed issues, structured data, internal linking gaps, and indexation problems. On a site with a few hundred pages, that work alone can take a full day or two. Cheap SEO skips this entirely, or runs an automated tool and calls it done. That's the equivalent of checking the tyres and ignoring the engine. 2. Content Research Isn't Just Finding Keywords Good keyword research is about understanding intent. What does someone actually want when they type that phrase? Are they comparing options, ready to buy, or just learning? Mapping that across a whole site, checking what competitors have covered, and identifying genuine gaps takes several hours of careful thinking. Generating a keyword list from a free tool in ten minutes isn't the same work. The list might look similar on paper, but the strategic decisions behind it are completely different. This is where a lot of budget-tier SEO quietly falls short, and clients often don't find out until months have passed with nothing to show. 3. On-Page Optimisation Is Repetitive, Granular Work Rewriting title tags and meta descriptions, improving heading structure, tightening internal links, and updating existing content to better match search intent. None of it is glamorous. All of it takes time. A site with fifty pages of under-optimised content could have forty or fifty individual tasks to work through. Shortcuts here tend to show. Titles that are stuffed with keywords, headings that don't match the page, thin paragraphs padded out to hit a word count. Google's quality raters are trained to spot exactly this kind of surface-level work. 4. Link Building Is Hard, Slow, and Often Thankless Earning a link from a relevant, authoritative site means finding the right contact, making a genuine case for why they should link to you, and then waiting. A lot of outreach leads nowhere. Getting even a handful of quality links in a month is a decent result. Cheap link building usually means directories, spammy guest posts on low-quality sites, or link farms. These can do more damage than nothing. Google's guidance on link spam policies is clear on what it penalises. Recovering from a bad link profile is a job in itself. 5. Reporting and Monitoring Isn't Optional Rankings shift. Traffic patterns change. A page that ranked well in one month can drop when a competitor updates their content or a site structure change accidentally orphans a key page. Proper SEO involves watching for those signals regularly and responding to them. This is part of what clients often don't see. The monitoring, the small adjustments, the checking that nothing has quietly broken. It runs in the background every week. In our experience, we've taken over sites where a previous provider had been charging a monthly retainer for months on end, and when we looked under the hood it was obvious nobody had touched a thing. No changes to the site, no new content, no link activity. Just a standing invoice. The problem is common because SEO is largely invisible to the client, which makes it easy to bill for work that hasn't happened. Knowing what to look for is part of what you're paying for. A good SEO company lays out exactly what metrics actually matter and reports against them honestly. 6. The Time Required Doesn't Compress Well SEO isn't a task you can rush. Google's algorithms take time to process changes, reward consistent signals, and build trust in a domain. A proper campaign needs at minimum four to six months before meaningful trends become visible, often longer in competitive niches. Anyone quoting you a fixed price for three months of SEO and promising page-one rankings is selling you something that doesn't exist. The work is ongoing and the results compound slowly. That's not a flaw in SEO, it's how it works. Understanding the full picture of what SEO actually involves makes it much easier to judge whether a proposal is realistic. 7. Expertise Is the Biggest Variable in the Price Two people can both call themselves an SEO specialist. One has spent years working through technical audits, diagnosing crawl problems, reading algorithm documentation, and testing what actually moves rankings. The other has done a short course and uses the same handful of tools for every client. The price difference between them often isn't as large as it should be, because the second person has lower costs and can undercut. But the outcomes are miles apart. When you're assessing what an SEO campaign should cost, the question worth asking isn't 'why is this expensive?' It's 'what happens to my site if I pick the wrong one?' The answer to that is often months of wasted time and a site that's harder to fix than if nothing had been done. ------------------------------------------------------------ # Using the WordPress REST API to Automate Repetitive Site Tasks Source: https://yorkshiredesign.co.uk/using-the-wordpress-rest-api-to-automate-repetitive-site-tasks/ Published: 2026-07-20 > Picture a site with 400 product pages. Every January, prices need updating, stock statuses change, and a handful of meta descriptions go stale. Doing that by hand through the WordPress dashboard takes days. Doing it through the REST API takes a script and a coffee break. That gap is exactly what WordPress REST API automation is about. Not magic, not a plugin shortcut. Just a clean, direct channel into your site's data that you control entirely. What the REST API Actually Is WordPress ships with a built-in REST API. It exposes your site's content as structured data, accessible via standard HTTP requests. Posts, pages, users, taxonomies, custom post types. They're all reachable through a predictable URL pattern ending in /wp-json/wp/v2/. The important part is that it works both ways. You can read data out of WordPress, and you can push data in. That second direction is where automation gets interesting. A Concrete Example: Bulk Meta Updates Say you've published 80 blog posts and realised the meta descriptions are either missing or too long. A manual fix means opening each post, scrolling to the SEO block, editing, saving. Repeat 80 times. With the REST API, you write a short script (PHP or Python both work cleanly here) that fetches every post, checks the relevant field, and patches the ones that need changing. The whole run takes seconds. The dashboard never opens once. This is the kind of task that gets quietly ignored because it feels too small to hire for and too large to do manually. The API removes that middle ground entirely. Authentication: The Part People Skip Too Fast Reading public post data needs no authentication at all. Writing data does. WordPress supports several methods: Application Passwords (built into core since version 5.6), OAuth, and JWT via a plugin. For most automation scripts running server-side, Application Passwords are the practical choice. You generate one from the user profile screen, store it somewhere safe (an environment variable, not hardcoded into the script), and pass it in the request header. The mistake people make is testing with their admin credentials embedded in the code, then forgetting to clean that up before the script goes anywhere near production. That's a real security hole, and it's an avoidable one. Treat the Application Password like you'd treat a database password. Same rules apply. Scheduled Tasks Without the Dashboard WordPress has its own cron system, but it only fires when someone visits the site. For low-traffic sites, that makes scheduled tasks unreliable. The REST API sidesteps this completely. You set up a proper server-side cron job (on your hosting environment or a separate task runner) that calls an API endpoint on a fixed schedule. The request triggers whatever update you need, rotating a featured post, clearing a transient cache, republishing a draft at a set time. The site doesn't need a visitor to make it happen. For sites where timing actually matters, this is a meaningful difference. A server cron fires when you tell it to. WordPress pseudo-cron fires when someone happens to load a page. Those are not the same thing. Custom Endpoints for Custom Logic The default endpoints cover the standard WordPress data structures. But you can register your own. The register_rest_route() function lets you define a custom URL and a PHP callback that does whatever you need. This is useful when the automation involves logic that doesn't map neatly onto a post or a term. For instance, you might need an endpoint that cross-references two custom post types and returns a merged dataset to a third-party tool. You build the endpoint, you define the logic, and the external system calls it on demand. We've seen this used to connect AI-driven content workflows directly to WordPress, pushing structured content into the right place without a human touching the queue. The API acts as the bridge between the external process and the site's database. One Trade-off Worth Naming The REST API is not always the fastest route to the database. Direct database queries (via $wpdb) are quicker for bulk operations. The API adds an HTTP layer and runs through WordPress's permission checks every time. For a script running a thousand updates in a loop, that overhead adds up. In that situation, a direct query inside a WP-CLI command is often the smarter call. The API earns its place when you need external access, cross-system communication, or you want the operation to respect WordPress's own permission model without writing that logic yourself. Knowing which tool fits the job is what separates a clean build from one that quietly adds overhead you'll spend months chasing out later. The API is genuinely useful. It's not always the right tool. Where to Start The simplest entry point is a GET request to yoursite.com/wp-json/wp/v2/posts in a browser or a tool like Postman. You'll see your posts returned as JSON. From there, add authentication, try a PATCH request on a single post, and watch it update live. That small test loop teaches you more about how the API behaves than any documentation will. The official WordPress REST API handbook is solid for reference, but hands-on is faster. Start small, automate one thing, then build from there. ------------------------------------------------------------ # What a Small Business Website Actually Costs in the UK Source: https://yorkshiredesign.co.uk/what-a-small-business-website-actually-costs-in-the-uk/ Published: 2026-07-20 > Most small business owners approach website costs the same way they approach a tradesperson's quote, they know they need one, they have no idea what's fair, and they're worried about being taken advantage of. The price range in the UK is genuinely wide. A five-page website might cost £400 or £4,000 depending on who builds it and what's actually involved. This post breaks down what sits behind those numbers, so you can judge whether a quote is reasonable before you commit. The Three Broad Price Bands UK web design quotes for small businesses tend to cluster into three ranges. Under £800 usually means a template dropped into a builder like Squarespace or a very lightly customised WordPress theme. It can work, but there are real limits, you get what's on the surface, and technical decisions like hosting configuration, Core Web Vitals or structured data rarely get any attention. The £800 to £2,500 range is where most small businesses land. At this level you should get a properly set-up WordPress site, a theme chosen and adjusted for your brand, decent on-page SEO, and someone who has actually thought about how a visitor moves through the site. Above £2,500 you are paying for more time, more bespoke development, or both. Custom post types, booking systems, WooCommerce, complex page structures. The higher figure isn't always better value, but there are genuine jobs that need it. What the Price Actually Pays For The visible part of a website, the design you can see and click around, is maybe a third of the real work. The rest is setup that nobody photographs, hosting configuration, caching, image compression, database optimisation, SSL, spam protection, redirects, and the initial SEO groundwork. Skip that groundwork and the site looks fine on launch day, then underperforms for the next three years. A common pattern is a business that paid a low price for what looked like a complete site, then wonders six months later why it isn't showing up in search. Nine times out of ten, nobody touched the technical layer. That is the real difference between a thorough build and a quick one. It is not always obvious from a screenshot. Template vs Custom: Does It Actually Matter? For most small businesses, a well-configured template is perfectly adequate. The template is not the problem. What matters is how it is set up, how the code is structured underneath, and whether anyone has looked at what loads when a visitor hits the page. A theme built on top of another theme, for example, often carries double the CSS and JavaScript it needs. That bloat slows load times and makes styling conflicts almost inevitable as the site grows. It is worth asking anyone who quotes you whether they build on a base theme or on a stacked framework. The answer tells you a lot about how they think. For a real example of what that kind of problem looks like once it compounds, the Dragonfly website rebuild involved stripping out exactly this kind of inherited theme layering, rebuilding cleanly on WordPress, and returning the site to the first page of Google for several competitive search terms. Ongoing Costs: What Gets Left Out of the Quote A one-off quote rarely covers what comes next. Hosting runs roughly £5 to £30 a month depending on the type and quality. A managed WordPress host with proper backups and server-level caching sits at the higher end, and it is usually worth it. You will also need to factor in maintenance. WordPress core, plugins and themes need updating, and not updating them is how sites get hacked or broken. Some designers charge a monthly retainer for this. Others hand it over and walk away. Know which one you are getting before you sign off. SEO is a separate conversation entirely. A website build can include good technical foundations and solid on-page SEO. Ongoing search visibility, content, link-building, and the month-by-month work of ranking takes more time and a different budget. You can read about why UK web design prices vary so dramatically if you want to understand the wider picture. What to Watch Out For in a Quote Be cautious of quotes that list a page count but nothing else. Five pages tells you the structure. It tells you nothing about whether anyone will look at load speed, set up Google Search Console, write proper meta descriptions, or check how the site performs on a mobile connection. Ask specifically what the quote includes for SEO setup. Ask who hosts the site and whether you own the hosting account. Ask what happens after launch if something breaks. These are not awkward questions. A good designer expects them. If you want a clearer sense of what the design process itself should look like, this breakdown of a proper web design process covers the stages that actually matter. The Honest Answer on Price There is no single right number. A straightforward five-page site for a local service business does not need a £5,000 build. But a £400 rush job with no technical thought behind it will cost more in the long run, either in lost enquiries or in paying someone to fix it later. Good value sits at the point where the price is fair and the work underneath is thorough. That combination is less common than it should be, but it is what you are actually looking for. ------------------------------------------------------------ # Page Speed Sins Most Agencies Leave Behind (And Why) Source: https://yorkshiredesign.co.uk/page-speed-sins-most-agencies-leave-behind-and-why/ Published: 2026-07-20 > A site can look quick on launch day and still be carrying a slow-motion disaster underneath. Most agencies hit publish, hand over the keys, and move on. The performance problems they leave behind are not always obvious , they do not throw errors, they do not break anything visibly. They just quietly eat into your load times, your Core Web Vitals scores, and eventually your rankings. These are the ones that get missed most often, and why they tend to stick around. Uncompressed Images That Nobody Went Back to Check Images are the single biggest culprit on most sites. An agency builds the pages, the client uploads their own photos later, and nobody ever reviews what gets added. A raw PNG from a camera can sit at four or five megabytes and serve at full resolution on a screen that only needs a fraction of that. It adds seconds to load time on mobile, and it compounds with every new page added. The fix is not glamorous. It is a proper compression step baked into the workflow, or a server-side conversion to WebP. What most agencies skip is setting this up so it happens automatically. Without that, it falls through the cracks the moment they stop being involved. Render-Blocking Scripts Left in the Wrong Place Every script that loads in the <head> of your page delays everything visible to the user. The browser hits that script, stops, downloads it, processes it, and only then carries on rendering what you can actually see. That pause is called render-blocking, and it directly affects your Largest Contentful Paint score. Agencies will often load analytics scripts, chat widgets, and third-party tools this way because it is the default and nobody has pushed back on it. Moving scripts to load asynchronously, or deferring them until after the main content is visible, is a straightforward change. But it requires someone to audit every script on the page, understand what each one does, and judge what can safely wait. That takes time agencies rarely bill for after handover. Object Cache That Creates More Problems Than It Solves Object caching sounds like a sensible thing. Cache the database queries, serve results faster, done. In practice, on a standard WordPress site without heavy repeated queries, it often works the other way. Cached requests can serve stale data in ways that are hard to spot, and the overhead of maintaining the cache layer can actually slow responses down rather than speed them up. In our experience, object cache tends to cause quiet, unseen issues on general WordPress sites. It is genuinely useful on WooCommerce stores running complex product queries, but on a brochure site or a blog it adds complexity for questionable gain. The problem is that agencies often install it as a blanket performance measure and never revisit it. If you have noticed odd caching behaviour or inconsistent page rendering, this is worth checking first. No Attention Paid to TTFB Time to First Byte is the gap between a browser requesting your page and the server beginning to respond. If that gap is over 600 milliseconds, everything downstream suffers regardless of how well-optimised your front end is. A slow server response is a bottleneck at the source. No amount of compression or script deferral makes up for a host that takes too long to wake up. Most agencies pick hosting based on price or familiarity, not on measured server response times. The result is sites sitting on shared hosting that crawls under load. If you want to understand what is actually happening at the server level, a slow TTFB is often the root cause that everything else gets blamed for. Third-Party Scripts Nobody Audited Every third-party embed adds a network request, often to a server you have no control over. A Facebook pixel, a live chat widget, a HubSpot tracking snippet, an embedded YouTube video. Each one adds latency. On a page with four or five of these, you can be looking at an additional two to three seconds of load time on a slow connection, and none of that shows up in a basic test. The honest truth is that some of these tools are genuinely needed. But a lot of them get installed during a campaign or a trial and then just stay there. An audit every few months of what is actually loading on your pages, and what is still earning its place, is the kind of practical maintenance that moves real Core Web Vitals scores rather than just surface-level ones. Why Agencies Leave These Problems Behind Agencies are not always cutting corners deliberately. A lot of this comes down to how the work is scoped. Performance is checked at launch, the scores look acceptable, and the project closes. What happens to the site over the next twelve months, as content grows and plugins accumulate, is outside the scope of what was agreed. Solo technical work tends to look at this differently. There is nobody to pass the awkward jobs to, so going underneath the surface rather than just checking what is visible at launch is simply how the work gets done. Choosing who builds and maintains your site matters more than most people realise. What to actually look for in a web design agency is worth reading before you commit to anyone. ------------------------------------------------------------ # WordPress vs Headless CMS: Which One Actually Scales? Source: https://yorkshiredesign.co.uk/wordpress-vs-headless-cms-which-one-actually-scales/ Published: 2026-07-20 > The headless CMS pitch sounds compelling. Decouple the content from the front end, gain total flexibility, ship faster. A lot of growing businesses hear that and start wondering if WordPress is holding them back. Most of the time, it isn't. The real question isn't which system is technically superior. It's which one fits what you actually need to run and grow a site without burning through your budget or your team's patience. The Myth: WordPress Can't Handle Real Scale This comes up constantly, and it's worth addressing head-on. WordPress powers roughly 40% of the entire web. That's not a figure that points to a system buckling under pressure. It includes major publishers, global e-commerce operations, and content-heavy platforms handling millions of visits a month. The idea that WordPress hits a ceiling quickly is, in most cases, simply wrong. Where scale problems do appear, they're almost never WordPress's fault. They're hosting decisions, bloated themes, plugins stacking on top of plugins, or databases that nobody has touched in years. We'd argue the system itself is rarely the bottleneck for any business under serious enterprise scale. What Headless CMS Actually Gets Right Headless isn't a gimmick. For the right use case, it genuinely solves real problems. If your content needs to feed multiple front ends simultaneously, say a website, a mobile app, a digital signage system, and a third-party platform, then a headless setup earns its complexity. The content lives in one place and gets pulled wherever it's needed via an API. It also gives front-end developers complete freedom over how pages are built. No theme constraints, no block editor fighting back. That freedom matters when your team is large, your design requirements are unusual, or you're running a genuinely custom product. So there are real advantages. But they come with real costs too, and that's where the myth-busting gets more important. The Hidden Cost Nobody Warns You About Going headless means your content editors lose a lot. No live preview that actually reflects the finished page. No simple drag-and-drop layout tools. Adding a new page type or content structure requires developer time every single time. For a business where non-technical staff manage the site day to day, this is a significant problem. The classic version of this is a small business that migrated to a headless setup because a developer recommended it, then found that updating a banner image or changing a CTA required raising a ticket and waiting. The agility they thought they were gaining disappeared almost immediately. That ongoing developer dependency is a real trade-off. You need to price it in honestly before deciding headless is the right move. Most growing businesses don't have that resource sitting idle. Where WordPress Genuinely Struggles Honesty matters here. WordPress isn't the right tool for every job. If you're building something that isn't really a website at all, a complex SaaS product, a heavily custom web application, a system where content structure needs to be deeply programmatic, then forcing it into WordPress creates friction you'll fight forever. Performance is also worth watching. An unoptimised WordPress installation can be slow. That's not a fundamental flaw, it's a maintenance problem, but it does require attention. Understanding which PageSpeed scores actually carry weight matters a lot here, because a poorly configured WordPress site will lose on Core Web Vitals in ways that genuinely affect search rankings. Theme choice compounds this. A heavy theme with a full page builder baked in is often the single biggest drag on performance, more so than WordPress itself. What sits under the hood of a WordPress theme tells you far more about long-term performance than the demo ever will. The Scaling Question You Should Actually Be Asking Scaling isn't just about traffic volume. It's about whether your site can grow without breaking your workflow, your budget, or your team. WordPress scales well when it's built properly from the start. Clean architecture, a sensible hosting environment, good image handling, and a technical SEO foundation that doesn't accumulate debt over time. Most businesses don't need to rebuild the system. They need someone who'll actually look underneath and fix what's causing the drag. Headless scales well when you have a dedicated development team, a genuine multi-channel content need, and the budget to support ongoing technical management. Those conditions are less common than the sales pitch implies. Which One Should You Choose? For most growing businesses, WordPress is still the right answer. Not because it's the easiest or the most fashionable, but because it gives non-technical teams real control, it has a deep ecosystem of well-tested tools, and when it's set up carefully, it performs well and holds up over time. Headless makes sense in a narrow set of cases. If you genuinely tick those boxes, it's worth exploring properly. If you're mainly chasing the idea of something more modern or more scalable without a specific problem to solve, you'll likely spend a lot of money to end up in roughly the same place. The right call nearly always comes down to what you actually need to run the business, not what sounds best in a technical conversation. Related: WordPress vs Headless CMS for Growing Businesses ------------------------------------------------------------ # AI Content That Ranks vs AI Content That Bores Source: https://yorkshiredesign.co.uk/ai-content-that-ranks-vs-ai-content-that-bores/ Published: 2026-07-20 > Most AI-generated content fails not because it is badly written, but because it has nothing to say. It fills space. It repeats what ten other pages already say, in slightly different words, with no point of view and no genuine detail. Google has seen it all before, and so has your reader. The gap between AI content that ranks and AI content that gets ignored is not about word count or even grammar. It is about whether the page gives someone a reason to stay. The Real Problem With Most AI Content The failure mode is almost always the same. Someone prompts an AI tool to write about a topic, accepts the output with minor edits, and publishes. The result is a page that covers the subject in the broadest possible terms, mentions everything vaguely, and commits to nothing specific. That kind of content used to slip through. It does not now. Google's quality evaluations look for genuine expertise, real depth, and pages that actually help a searcher complete a task or answer a question. A page that hedges every point and avoids any concrete detail struggles to pass that bar. The uncomfortable truth is that volume is the enemy here. We'd argue that making content en masse is normally a waste of time. Pages start cannibalising each other, competing for the same keywords, thinning out the whole site's authority rather than building it. Fewer, better pages nearly always outperform a flood of filler. What 'Thin' Actually Means in Practice Thin content is not about length. A 1,500-word page can be completely thin. Think of a site that auto-generates a page for every service variation, every town in the country, every combination of product attribute, and none of those pages say anything that the others don't. Google crawls thousands of near-identical pages, finds no meaningful difference between them, and either ignores most of them or penalises the whole domain. AI makes this trap easier to fall into because output is fast and cheap. The temptation to produce sixty pages in a week is real. But sixty pages of generic copy is not sixty chances to rank. It is sixty pages competing against each other for attention that none of them deserve. The fix is not a better prompt. It is a clearer brief, a stricter content strategy, and a willingness to publish far less than you think you need to. You can read more about what a solid brief actually contains in the structural ingredients every brief needs before a writer, human or AI, touches the keyboard. What Google Actually Rewards Google's own guidance on helpful content is consistent on one point. The page should be written for a person, not assembled to satisfy a crawler. That means it needs an angle, a specific point of view, or information that isn't already on the first page of results. Original insight is the hardest thing for AI to produce on its own, because AI has no experience. It synthesises what already exists. So the moment you use it without adding your own knowledge, opinion, or real-world detail, you are publishing a remix of content that is already ranking. Why would a search engine prefer yours? The pages that rank well tend to share a few qualities. They answer a specific question with specific detail, not a broad sweep. They include a genuine point of view, even a mild one. They do not pad. And they are clearly written for a human being who has a real problem to solve. How to Use AI Without Producing Filler AI is genuinely useful as a drafting tool and a structural aid. Where it goes wrong is when it replaces thinking rather than supporting it. The starting point should always be a clear brief that specifies the angle, the audience, the specific question being answered, and what makes this page different from everything already out there. Once a draft exists, the work is in what you add, not what you cut. Real examples. Specific numbers where you have them. A clear opinion on the thing. A sentence that no other site could publish unchanged because it comes from your experience. That is what separates a page that ranks from one that drifts. It also matters where and how keywords appear. Stuffing a phrase into every paragraph is a reliable way to make copy read like it was written by a machine. Search engines have been sophisticated enough to read naturally for years. Focus on covering the subject well, and what actually moves the needle in search tends to follow. The Minimum Viable Bar for Publishing Before any page goes live, it is worth asking one honest question. If a reader arrived at this page with a genuine need, would they leave with something useful that they could not have found just as easily on the first two results they already saw? If the answer is no, the page is not ready. That standard rules out a lot of AI output. It also rules out a lot of human-written content. The bar is not about the tool. It is about whether the page earns its place. Everything else, the word count, the format, the keyword density, is secondary to that. ------------------------------------------------------------ # 7 Ways Core Web Vitals Affect Real Visitors (Not Just Scores) Source: https://yorkshiredesign.co.uk/7-ways-core-web-vitals-affect-real-visitors-not-just-scores/ Published: 2026-07-20 > Most people treat Core Web Vitals as a Google ranking checkbox. Pass the audit, move on. But the three metrics , LCP, INP and CLS , exist because they measure things visitors actually feel. A slow load, a layout that jumps, a button that doesn't respond. These aren't abstract scores. They're the moments where someone decides whether to stay or leave. Here's what each one actually does to the people on your site. 1. LCP Tells Visitors Whether Your Page Is Broken Largest Contentful Paint measures how long it takes for the biggest visible element to appear. Usually that's a hero image or a headline. Visitors don't know what LCP is. What they feel is a blank white screen, and a blank screen reads as broken. Google's own guidance considers anything over 2.5 seconds a poor experience. Beyond that threshold, a meaningful share of visitors will reload or leave before the page even finishes loading. The damage happens before you've said anything to them. 2. INP Determines Whether Your Buttons Actually Feel Responsive Interaction to Next Paint replaced First Input Delay and it's the harder one to fix. INP measures the full delay between a user doing something , tapping a menu, clicking a form field, pressing a button , and the page visually responding. A score above 200 milliseconds starts to feel sluggish. Above 500ms it feels broken. On mobile, where people are tapping with a finger and expecting near-instant feedback, a slow INP is the kind of thing that makes someone assume your site has frozen. They tap again. Nothing. They leave. The usual cause is too much JavaScript running on the main thread. Page builders, tag managers stacked on top of each other, third-party chat widgets loading at the wrong moment. It all adds up quietly. 3. CLS Causes Visitors to Click the Wrong Thing Cumulative Layout Shift is the one that annoys people most visibly. It's what happens when content jumps around as the page loads , a button moves just as someone is about to tap it, or an advert loads and pushes the article text down. The frustration is real. Someone trying to read an article, accept a cookie notice or fill in a form gets interrupted by a sudden jump. At best it's irritating. At worst they click something they didn't mean to, or abandon the page entirely. A CLS score above 0.1 is considered poor, and you can often see it with your own eyes just by scrolling through the site on a phone. Unsized images are the most common culprit. If the browser doesn't know an image's dimensions before it loads, it can't reserve the space. The page collapses and reflows when the image arrives. 4. Poor Scores Compound on Mobile Connections Lab tests run on fast machines with a stable connection. Real visitors are often on a 4G signal that drops to 3G in a lift, or on an older Android phone with limited processing power. What scores 75 in a Lighthouse audit on a desktop can score 40 on a mid-range phone. This matters because the effect on real visitors is always worse than the lab suggests. Build for the lab and you're optimising for a test environment, not for your actual audience. 5. Slow Pages Quietly Erode Trust Before You've Made Your Case There's a difference between a visitor bouncing because your offer isn't right for them, and a visitor bouncing because your page took four seconds to load. The first is fine. The second is a waste of every pound you spent getting them there. A slow or unstable experience signals, unconsciously, that something is off. It's not a rational judgement. It's a feeling. And feelings about a site form in the first second or two, long before the copy has a chance to do any work. 6. Fixing the Right Things Makes a Measurable Difference Not every fix moves the needle equally. Compressing images helps LCP. Deferring non-critical JavaScript helps INP. Adding explicit width and height attributes to images fixes the majority of CLS issues. The fixes that actually shift Core Web Vitals are usually structural, not cosmetic. A simple, well-built site will almost always outperform a feature-heavy one. That's not a philosophical point, it's a technical one. Fewer things loading means fewer things blocking. We built a series of clean, straightforward local sites for a house clearance client and they regained number one rankings for multiple local keywords as a result. Simple done properly beats complex done carelessly. 7. The Score Is a Proxy , the Visitor Experience Is the Point It's easy to chase a green score in PageSpeed Insights and call it done. But the score is only useful as a proxy for what a real person encounters. Common misconceptions about Core Web Vitals often come from treating the audit as the goal rather than a diagnostic tool. A site that passes a lab test but uses a CDN-cached version to fake the score hasn't helped a single visitor. What matters is how the page performs on a real device, on a real connection, for someone who has never been to the site before. That's the only test that counts. Related: Core Web Vitals Explained: LCP, INP and CLS for Rankings ------------------------------------------------------------ # What a Good Web Design Process Actually Looks Like Source: https://yorkshiredesign.co.uk/what-a-good-web-design-process-actually-looks-like/ Published: 2026-07-19 > Most people who commission a website have never done it before. That's fine. But it does mean the process can feel opaque, like things are happening somewhere behind a curtain and you're just waiting for a link to appear in your inbox. A good web design process is nothing like that. It's methodical, it involves you at the right moments, and there's a clear reason for each step. Here's what it actually looks like when it's done properly. It Starts With Listening, Not Designing Before anything is built, a proper process begins with a conversation about your business. Not your colour preferences. Not your logo. What you do, who your customers are, what you want the website to actually achieve. A contact form? Online sales? Bookings? Each of those shapes the build in a completely different way. This is also the moment to talk about what you don't want. A site that looks slick but loads slowly. A theme that's been dressed up rather than built properly from the ground up. Getting clear on the brief here saves a lot of back-and-forth later. Research Before a Single Pixel Gets Placed Good designers look at your competitors before opening any design software. Not to copy them, but to understand what's already out there and where the gaps are. They'll also look at your industry's search landscape, which terms people actually type when they're looking for what you do, so the structure of the site supports search from day one. This is the unglamorous part of the work that most people never see. It takes time. But skipping it means you end up with a site that looks fine and does nothing. Structure Comes Before Style The next step is planning the architecture. How many pages? What goes where? How does a visitor move from landing on the homepage to taking the action you want them to take? This is called the sitemap and the user journey, and it's more important than any font choice. A common mistake is jumping straight to visuals. A site can look beautiful and still confuse visitors into leaving. Sorting the structure first means the design has a solid foundation to sit on, rather than the other way around. Think of it like a house, you don't pick the wallpaper before the walls are up. The Build Itself: What's Actually Happening For most small business sites, WordPress is the platform of choice, and for good reason. It's flexible, well-supported, and gives you control without needing a developer every time you want to update a page. But WordPress done badly is still bad. Themes stacked on top of other themes, bloated plugins doing jobs they were never designed for, scripts loading that nobody needs. The technical side of a proper build matters a lot. Page speed, clean code, images that are properly sized, a structure search engines can actually read. We rebuilt one site from scratch after the original had been developed on top of a poorly chosen theme causing custom post type conflicts and styling issues throughout. Once it was done properly, it returned to the first page of Google for several competitive search terms. The site itself hadn't changed in terms of what it offered. The build underneath it had. If you want to understand what separates a considered build from a rushed one, the difference between looking good and working well is worth reading before you commission anything. Branding Isn't Just a Logo Sometimes a client arrives with everything ready. A logo, brand colours, existing photography. Other times, they arrive with nothing but an idea. Both situations are fine, but the second one takes more thought. We've taken clients from no branding at all to a complete identity, logo, colour scheme usable both online and in print, domain name, the full picture. The lesson there is that your brand isn't just what goes on your website. It's what goes on your business cards, your email signature, your social profiles. A website built without a clear identity underneath it tends to look stitched together. Getting that foundation right first pays off everywhere. Testing Before Launch, Not After Before a site goes live, it should be tested properly. Not just "does it look right on my laptop". Mobile, tablet, different browsers, different screen sizes. Page speed. Links. Forms that actually send. Contact details that are correct. These things sound obvious, but they get missed more often than you'd think. For a broader look at what to expect from whoever builds your site, that's worth checking before you sign anything. After Launch Is Not the End A website isn't a finished product the day it goes live. It needs monitoring. Search rankings take time to build. Content gets updated. Things break quietly when plugins update or hosting changes. The sites that perform well a year after launch are the ones that are looked after consistently, not left to run on their own. That's not a sales pitch. It's just honest. Good results take time, and a site needs attention to stay in good shape. Related: What a Web Design Company Actually Does for Your Money ------------------------------------------------------------ # How to Disable Google Fonts in WordPress and Speed Up Your Site Source: https://yorkshiredesign.co.uk/how-to-disable-google-fonts-in-wordpress-and-speed-up-your-site/ Published: 2026-07-18 > Most WordPress themes load Google Fonts by default. It happens quietly, in the background, and most site owners never question it. The problem is each font family adds an extra HTTP request, sometimes more than one, before the page even starts to render. On a slow connection that delay is visible. This post walks through exactly how to stop WordPress loading Google Fonts, what to replace them with, and when it genuinely moves the numbers. Why Google Fonts Affect Load Time Every time a visitor lands on your site, the browser has to fetch those fonts from Google's servers before it can finish rendering the page. That is an external HTTP request, and it adds a round-trip to the load sequence that your hosting has no control over. On a fast connection it might only cost a few hundred milliseconds, but those milliseconds sit inside your Largest Contentful Paint timing, which is one of the signals Google uses to score your Core Web Vitals. The font request also has to resolve a DNS lookup, open a connection, and wait for a response before the browser can move on. The reason people assume this is fine is that Google's CDN has a reputation for being quick. And it often is. The problem is that the browser treats the font stylesheet as render-blocking by default, meaning it will pause page construction until the stylesheet has loaded and the font files are confirmed. Add a slow network, a cold DNS cache, or a user on mobile data, and that pause becomes noticeable. Local hosting removes the external dependency entirely. The font files live on the same server as everything else, the browser finds them without leaving your domain, and you cut one more variable out of the load chain. It is a small change, but small changes stack up. Check Whether Your Site Is Actually Loading Them Before you change anything, confirm the fonts are actually there. Open your site in Chrome, right-click anywhere on the page and choose Inspect, then go to the Network tab. Reload the page and filter by "Font" or just search for "fonts.googleapis.com" in the request list. If you see calls going out to Google's servers, the fonts are loading. If you don't, the job's already done and you can move on. It sounds basic, but skipping this step means you could install a plugin, change settings, and fix a problem that never existed. Google PageSpeed Insights gives you a second way to check without touching DevTools at all. Run your URL through it and look at the diagnostics section. A flag for "Eliminate render-blocking resources" that references fonts.googleapis.com tells you exactly what's happening and where the delay sits in your load sequence. That context matters because the fixes that actually shift your Core Web Vitals scores are rarely the obvious ones, and Google Fonts is one of the more straightforward wins once you know it's genuinely present. Start with evidence, not assumptions. The Plugin Route: Disable Without Touching Code If you'd rather not open a functions.php file, there are a handful of plugins that handle this cleanly. OMGF (Optimise My Google Fonts) is the one worth reaching for first. It scans your site, identifies every Google Fonts request, and lets you host those font files locally instead of pulling them from Google's servers on each page load. That single change removes an external HTTP request and can shave a noticeable amount off your Largest Contentful Paint score. Asset CleanUp is another option, and it gives you granular control over which scripts and styles load on which pages, so you're not disabling fonts site-wide if you only have a problem on specific templates. The caveat worth knowing is that not every "speed" plugin does this job well. Some popular all-in-one optimisation plugins include a Google Fonts setting buried inside a larger bundle, and the overhead of the plugin itself costs more than the font request it saves. It's worth being honest about that trade-off. If you only need to deal with fonts, a focused plugin like OMGF is tidier than installing something with forty features you'll never use. More plugins almost always means more moving parts, and more moving parts means more to go wrong when WordPress updates. The Code Route: Remove Google Fonts Properly via functions.php If you're comfortable working in a child theme, dequeuing Google Fonts directly in functions.php is the cleanest approach. Open your child theme's functions.php file and add a function hooked to wp_enqueue_scripts with a priority of 100 or higher, which ensures it fires after your theme and plugins have registered their own font handles. Inside that function, call wp_dequeue_style() and wp_deregister_style() for each font handle you want to remove. A typical Twenty Twenty-style theme registers its fonts under a handle like twentytwenty-google-fonts, so that's the string you'd pass in. Check the exact handle name by loading the page source and searching for fonts.googleapis.com to find what your theme actually registered. One thing worth noting is that plugins can register their own separate Google Fonts calls independently of the theme, so removing the theme handle alone won't always clear every request. You'll often find Contact Form 7, WooCommerce add-ons, or page builder plugins quietly loading their own font stylesheets. Add a separate wp_dequeue_style() line for each offending handle, confirmed by inspecting the page source each time. A tool like a TTFB audit can then confirm whether those external requests have actually dropped from the waterfall, which is the only real proof that the dequeue worked. What to Use Instead of Google Fonts System fonts are the straightforward answer. Fonts like Georgia, Arial, and the newer system-ui stack are already on the visitor's device, so the browser renders them instantly with no external request at all. A system font stack can look surprisingly clean on a modern site, and on most screens the difference between a system serif and a popular Google Font is genuinely hard to spot. For sites where readability and speed matter more than a distinctive typographic identity, that is usually the better trade-off. Self-hosting is the right call when a specific typeface genuinely matters to the design. You download the font files, serve them from your own server, and remove the third-party dependency entirely. Performance-wise, a well-configured server with a low TTFB will deliver a self-hosted font quickly enough that the page speed penalty becomes very small. The honest caveat is that self-hosting takes a bit more setup, and if you skip the correct font-display settings in your CSS, you can still end up with layout shift or invisible text on slow connections. Do it properly or the gain is minimal. How Much Difference Does It Actually Make Disabling Google Fonts is a genuine improvement, but it sits in the middle of a much longer list of work. On its own, it might shave a few hundred milliseconds off your load time and remove one or two render-blocking requests that PageSpeed Insights flags. You will likely see small gains in First Contentful Paint and possibly Largest Contentful Paint, but the needle rarely moves far from this single change alone. Think of it as tidying one room in a house that still has damp walls and a leaking roof. Where it does count is in a proper Core Web Vitals audit, where every marginal gain adds up. The sites that go from failing to passing Core Web Vitals almost always get there through a handful of these smaller fixes stacked together, not one dramatic intervention. If you are working through page speed fixes methodically, fonts are worth sorting early because they are quick to address and they clear the path for the heavier optimisation work ahead. Skip them and they will still be sitting in your report, nagging away, while you try to diagnose something more complicated further down the line. Related: How Disabling Google Fonts Improves WordPress Load Time ------------------------------------------------------------ # WooCommerce SEO Setup: The Structural Decisions That Matter Source: https://yorkshiredesign.co.uk/woocommerce-seo-setup-the-structural-decisions-that-matter/ Published: 2026-07-18 > Most WooCommerce stores get the surface stuff right. A plugin installed, a sitemap submitted, a title tag or two updated. Then they wonder why rankings stay flat. The real problems tend to sit one level deeper, in the structural choices made when the site was first built. URL paths, category architecture, duplicate content between product variations, canonical handling. These are the decisions that shape whether Google can read your store properly, and they're far harder to fix later than they are to get right at the start. Your URL structure is a decision, not a default WooCommerce gives you a URL structure out of the box, but that does not mean it's the right one for your store. By default, product URLs sit under /product/product-name/ and categories under /product-category/category-name/. That's fine for small shops. For anything with real depth, though, how you organise those paths matters. The question worth asking early is whether you want category names inside product URLs or not. Including them (/shoes/running/product-name/) reinforces topical depth. Leaving them out keeps URLs shorter and avoids the headache of URLs breaking if you ever restructure categories. Neither is universally right. The mistake is not choosing deliberately and sticking with it, because changing URL structure on a live store costs you whatever authority the old URLs had built. Category pages are where most stores leave ranking power on the table Product pages matter, but category pages are often where the real search volume sits. Someone searching "waterproof hiking boots" is not necessarily looking for a specific product yet. They want options. A well-built category page can rank for that term and funnel people toward individual products. The problem is that most WooCommerce category pages ship with almost no content. A heading, a grid of products, a pagination bar. There's nothing for Google to assess topically. Adding even a short, genuinely useful description above or below the product grid, one that actually explains what the category covers and who it's for, gives the page something to rank on beyond product titles and schema markup. For a store we rebuilt from the ground up on WordPress, moving category pages from near-empty grids to properly structured pages with real content was one of the faster wins. The site returned to the first page for several competitive terms without any change to the product pages themselves. Product variations create duplicate content if you're not careful Variable products are standard in WooCommerce. A t-shirt in five colours and three sizes is one product. But depending on how your theme and plugins handle attribute URLs, each variation can end up with its own indexable URL. That means Google might find ten versions of the same page with almost identical content. The fix is canonical tags. Every variation URL should point its canonical back to the parent product URL. Most SEO plugins handle this automatically, but it's worth checking, especially if you've migrated from another platform or switched plugins partway through the site's life. Screaming Frog or a quick crawl will show you quickly whether variations are being indexed separately. Filtered navigation is one of the quietest sources of crawl waste If your store uses layered navigation or filter widgets, which most do, every combination of filters can generate a unique URL. Colour, size, price range, brand, the combinations multiply fast. Left unchecked, this produces thousands of thin, near-identical pages that drain crawl budget and dilute your cleaner category and product URLs. The standard approach is to noindex filtered URLs and block them via robots.txt where appropriate. WooCommerce SEO plugins like Yoast or Rank Math have settings for this, but the defaults aren't always correct for every store configuration. Check what's actually being indexed with Google Search Console's URL inspection tool before assuming the plugin has handled it. Schema markup on product pages is worth doing properly Google's product structured data guidelines are specific about what's needed for rich results, price, availability, reviews where you have them, and ideally a merchant listing. WooCommerce plugins output basic product schema automatically, but the quality varies. Missing or malformed markup means no rich results in search, which on product searches is a real visibility gap. Worth checking in Google's Rich Results Test. It takes two minutes and tells you exactly what's missing or broken. A lot of stores have schema output that looks complete until you test it. The content temptation that can do real damage There's a version of ecommerce SEO that involves producing large volumes of thin, loosely related content in the hope that some of it sticks. In our experience, this can actively hurt a site. We've seen a local company's rankings tank after an SEO firm produced hundreds of poorly targeted pages. The content made the site look unfocused, diluted the authority of the pages that actually mattered, and left a mark that took time to unpick. Bad content isn't neutral. It drags things down. For ecommerce WordPress SEO setup, fewer well-structured pages almost always outperform a sprawl of thin ones. Build the structural foundations first, then add content where it genuinely serves a search intent. Internal linking between products and categories is often ignored How products link to each other, and how categories link downward into products and upward to broader topics, shapes how Google distributes authority across the store. Most WooCommerce themes handle this loosely at best. Related products are shown, but the logic behind which products appear is often random or based on category overlap alone. A more deliberate approach, linking from product descriptions to genuinely related products or to a parent category page where it makes sense, builds a structure Google can follow. It's the kind of internal linking work that doesn't look dramatic but compounds over time. Most of the meaningful SEO work in a WooCommerce store is exactly like that, unglamorous, thorough, and slow to show results. That's not a warning, it's just how it works. ------------------------------------------------------------ # Cheap Web Hosting: What You Actually Get for the Price Source: https://yorkshiredesign.co.uk/cheap-web-hosting-what-you-actually-get-for-the-price/ Published: 2026-07-18 > Cheap web hosting is everywhere. A few pounds a month, unlimited everything, free domain for a year. It sounds straightforward. But the price you see upfront is rarely the whole story. Before you commit to a plan because it looks affordable, it's worth understanding what you're actually trading away, and at what point that trade starts costing you more than it saves. The Shared Hosting Model and Why It Matters Most cheap hosting runs on shared servers. Your site sits alongside hundreds, sometimes thousands, of others on the same machine. When one site on that server gets a spike in traffic, everyone else slows down. You have no control over who your neighbours are or how much they consume. This is fine for a site that gets almost no traffic. For a business that depends on people actually landing, reading, and enquiring, it introduces a variable you can't manage. Speed becomes inconsistent, and inconsistent speed is worse for conversions than slow-but-steady. What Cheap Usually Means for Core Web Vitals Google measures page experience through how your server responds as much as how your code is written. Time to First Byte, the gap between a visitor's browser sending a request and your server replying, is directly tied to hosting quality. A budget server under load can push that number well past 600ms. Good hosting keeps it under 200ms. That gap matters. Core Web Vitals scores are partly a server problem, not just a plugin or image problem. You can spend hours optimising WordPress and still underperform because the foundation underneath is doing the heavy lifting too slowly. Uptime Promises vs. Reality Every host advertises 99.9% uptime. That sounds reliable. In practice it allows for around eight hours of downtime per year, and the cheap providers often fall short of even that. More importantly, "uptime" doesn't account for the stretches where your site is technically live but responding so slowly it may as well be down. Monitoring your own uptime is the only way to know what you're actually getting. Free tools like UptimeRobot check your site every few minutes and log outages. Run it for a month on a cheap plan and the pattern usually becomes obvious. The Renewal Trap Budget hosts almost always lead with an introductory price. Sign up for two or three years upfront, and the monthly figure looks tiny. Renew at standard rate and it can triple or quadruple overnight. The total cost of ownership over two to three years often lands closer to a mid-range host than the headline suggested. This is where people get caught. The switch-over cost, pointing domains, migrating files and databases, testing everything works, puts people off moving. So they renew, pay more than they planned, and stay on infrastructure that isn't really serving them. Support: When You Need It Most Cheap hosting support tends to fall into two camps. Either it's a chatbot that redirects you to a knowledge base, or it's a queue that takes hours to answer a simple question. If your site goes down on a Friday evening before a busy weekend, that difference is felt immediately. For a solo business or a site handling real enquiries, having someone who can actually diagnose a server-level problem quickly is not a luxury. It's the kind of thing you only value when it's absent. When Budget Hosting Is Actually Fine Here's the honest part. If you're running a low-traffic site, a portfolio, a testing environment, or something where downtime costs you nothing, cheap hosting does the job. Not everything needs premium infrastructure. A brochure site that gets a handful of visitors a week is not going to suffer meaningfully from shared hosting. The problem is assuming that's still the right call when the site grows, when you start investing in SEO, or when the site becomes the main route through which customers find you. The hosting decision that made sense at the start doesn't automatically stay correct. We rebuilt a WordPress site from scratch recently, a client whose original build had been stacked on top of another theme, causing persistent custom post type and styling conflicts. Sorting the codebase got them back onto the first page for several competitive terms. But had the hosting underneath been the bottleneck, none of that work would have landed as well as it did. The two things are connected. What to Actually Compare Before You Choose Price per month after the introductory period, not the sign-up rate. Actual renewal costs in year two and three. Server location relative to your audience. Whether PHP and database versions are current. What the support channel looks like at 9pm on a Sunday. If you can find independent uptime reports or reviews that cover a full twelve months, those are worth more than anything on the host's own marketing pages. If the hidden costs of budget hosting are already showing up in your rankings, it is usually cheaper to move sooner rather than later. Related: Web Hosting Uptime: What It Means and How to Check Yours ------------------------------------------------------------ # WordPress Multisite and SEO: The Problems You Hit Early Source: https://yorkshiredesign.co.uk/wordpress-multisite-and-seo-the-problems-you-hit-early/ Published: 2026-07-18 > WordPress Multisite looks like a sensible idea on paper. One installation, multiple sites, everything managed from a single dashboard. But the SEO problems show up quickly, and they are not always obvious until you are already committed to the setup. Most of them come down to how search engines see each sub-site, how content is shared across the network, and how little control you actually have over things that matter to rankings. This is worth understanding before you build, not after. What Multisite Actually Does to Your Site Structure A standard WordPress install gives you one domain, one site, one set of signals for Google to read. Multisite splits that into a network. Each sub-site can run on a subdomain (shop.yourdomain.com) or a subdirectory (yourdomain.com/shop), and that distinction matters more than most people realise. Subdirectory networks generally perform better in search. Google sees the content as part of the root domain, so any authority the main domain has built up extends to the sub-sites. Subdomain networks are treated more like separate sites. That means each one starts from scratch in terms of trust, backlinks and crawl budget. For a new network with thin sub-sites, that is a serious disadvantage. Duplicate Content Is the First Real Danger Shared themes, shared plugins, shared content templates. All of it can produce near-identical pages across multiple sub-sites with no meaningful differentiation. Google does not penalise duplicate content in the dramatic way some people suggest, but it does struggle to decide which version to rank. Often it picks none of them. The issue gets worse when plugins auto-generate archive pages, tag pages, or category indexes that sit across several sub-sites at once. Without proper canonical tags in place, the network starts competing against itself. That is a problem you cannot fix with a plugin toggle after the fact. It needs to be designed out from the beginning. Mass content without purpose does not help. It hurts. The same principle applies across a Multisite network at scale. Crawl Budget Gets Eaten Faster Than You Expect Googlebot has a limited amount of time it will spend crawling any given domain or network. On a single site, that budget usually covers everything important. On a Multisite network, the crawler has to work through every sub-site, every shared template page, every auto-generated URL. If the network grows to twenty or thirty sub-sites, the important pages on the strongest sites can end up crawled less frequently. For e-commerce networks or sites with regular content updates, this is a genuine problem. The fix involves tightening your robots.txt and crawl directives across each sub-site individually, which is more involved than it sounds on a shared installation. Internal Linking Across the Network Is a Structural Trap Internal links are one of the cleaner signals you can control. They tell search engines how pages relate to each other and where the important content sits. On a standard WordPress site, this is straightforward to manage. On Multisite, the network complicates it. Links between sub-sites count as external links, not internal ones. That changes the way authority passes between pages. A link from your main site to a sub-site does not carry the same weight as an internal link between two pages on the same domain. If your content strategy relies on sub-sites referencing each other to reinforce topic clusters, you are working against the way search engines actually read those signals. There is a fuller explanation of how site structure affects link equity worth reading before committing to a network setup. Plugin and Theme Conflicts Slow Everything Down SEO plugins are not always built with Multisite in mind. Some generate sitemaps only at the network level. Others create settings that apply globally when you need them sub-site by sub-site. A few simply do not work correctly in a network environment and produce errors that are surprisingly hard to trace. Theme performance is the same story. A slow theme drags down every sub-site in the network simultaneously. Because all sub-sites share server resources, a spike in traffic on one can affect load times across all of them. For anyone already watching Core Web Vitals scores, that shared resource model is worth taking seriously before you go live. When Multisite Is and Is Not the Right Call Multisite makes sense for large organisations managing genuinely separate audiences under one brand, or for agencies hosting client sites under controlled conditions. It is not the right tool for a small business trying to build SEO across several niche topics. In that case, separate installs with a clear linking strategy between them will nearly always outperform a network setup. The honest answer is that Multisite adds complexity without adding SEO advantage. The gains are operational. The costs are technical. If your primary goal is organic search performance, that trade-off is rarely worth making unless you have the time and resource to manage it properly from day one. ------------------------------------------------------------ # 7 Ways Businesses Brief Web Projects Completely Wrong Source: https://yorkshiredesign.co.uk/7-ways-businesses-brief-web-projects-completely-wrong/ Published: 2026-07-18 > A bad brief costs more than a bad developer. Most web projects that run over budget, miss the mark, or need rebuilding after six months share one thing in common, the brief was vague, rushed, or built around the wrong questions. The problem usually starts before anyone opens a design tool. Getting this part right is not complicated, but it does require slowing down and being specific about what you actually need. 1. Describing how it should look instead of what it should do "I want something clean and modern" tells a designer almost nothing useful. What you actually need to answer is, what do visitors do on this site, and what should they do next? A homepage that converts enquiries needs a completely different structure to one that builds brand awareness. Looks follow function. If the brief skips the functional goal entirely, the design is just decoration. 2. No clear primary action for the visitor Every page needs one primary thing it asks the visitor to do. Call, buy, book, read, subscribe. Pick one per page. Briefs that list five or six goals for a single page produce cluttered pages that push visitors toward nothing. The brief should name the single most important action for each key page, and the rest of the design should support it. 3. Sending competitor URLs without saying why "I like this site" is a starting point, not a brief. Without context, a developer cannot tell whether you like the colour palette, the layout, the speed, or the content structure. Useful competitor references come with specific notes. "I like how this navigation stays fixed on scroll" or "their product page keeps the buy button visible at all times" gives someone something to actually work with. 4. Leaving content as an afterthought Pages need words, images, and sometimes video before they can be designed properly. A brief that says "content to follow" delays the whole build and often means the final design gets retrofitted around content it was never built for. This is one of the most common ways a clean initial design ends up looking cramped and disjointed by launch. Rough content, even placeholder headings and real photo references, should be in the brief from the start. A brief should also flag who is writing the copy. If the answer is "we'll sort that ourselves", agree a deadline before the project kicks off, not after. Late content is the single biggest reason web projects stall mid-build. It is worth treating the content side as its own separate brief with its own structure and deadlines. 5. No mention of existing technical constraints A brief that ignores the technical environment causes problems later. What platform is the site on? Are there integrations with booking systems, CRMs, or payment processors? Does the hosting have any limitations? These are not optional details. Discovering mid-build that a required plugin conflicts with the server setup, or that a third-party booking system needs a specific PHP version, eats time and budget fast. Understanding what your hosting environment actually supports before writing a brief saves a lot of backtracking. It is the kind of technical groundwork that gets skipped because it feels dull, but it is exactly the sort of thing that trips a project up two-thirds of the way through. 6. Mistaking brand preferences for brand guidelines "We like blue" is not a brand guideline. A working brief needs hex codes, font names, logo files in the correct formats, and any existing assets the site must match. Without these, a designer makes decisions by guesswork, and those decisions usually need undoing. One project that comes to mind involved rebuilding an entire WordPress site from scratch because it had been built on top of an incompatible theme, causing styling conflicts that ran right through the front end. None of that would have surfaced in a brief that said "match our current look." 7. Skipping the audience entirely A brief that does not describe the actual visitor is a brief built around the client's preferences rather than the end user's needs. Who is landing on this site? What do they already know? What do they need to trust before they act? A site for first-time buyers needs different language, layout, and reassurance signals than one aimed at repeat trade customers. If the brief does not answer who the site is for, the design cannot answer it either. This matters even more when the business is starting from nothing. A client once came with no branding, no online presence, and no website. Building the right brief meant starting with identity, who they were, who they were speaking to, what the brand needed to communicate both online and in print. The domain name, the colour scheme, the copy tone all followed from that. A vague brief at that stage would have produced a site with no coherent direction at all. If you are about to brief a new site and want to know what it should actually cost, understanding why web design prices vary so much is a useful starting point before any conversations begin. ------------------------------------------------------------ # Your Website Looks Great. So Why Isn’t It Converting? Source: https://yorkshiredesign.co.uk/your-website-looks-great-so-why-isnt-it-converting/ Published: 2026-07-18 > A small furniture maker spent four months building a website they were genuinely proud of. Good photography, a clean layout, clear branding. Traffic was coming in. Enquiries weren't. They assumed the problem was SEO, then the product, then the price. It was none of those things. The site looked right but worked badly, and the gap between the two is where most enquiries quietly disappear. A beautiful website and an effective one are not the same thing. Looking good is easy. Working well is harder. Design tools have made it straightforward to build something that looks polished. Stock photography, clean fonts, a hero image that fills the screen. None of that costs much time or money now. But visual polish doesn't tell a visitor what to do next, doesn't load fast enough to hold them, and doesn't answer the question they actually arrived with. The furniture maker's site had large, beautiful product images. They were also uncompressed, pulling in over 4MB per page. On a mobile connection, the page took seven seconds to feel usable. Most visitors had already left by then. The design was fine. The delivery wasn't. Speed is where most good-looking sites fall apart Slow pages lose visitors before the page is even visible. That's not an opinion, it's a pattern that shows up consistently in analytics. A visitor who bounces in the first two seconds never saw your offer, never read your headline, never got the chance to convert. High-resolution images are the most common cause, but they're not the only one. Unused CSS loaded in from a theme, render-blocking scripts, fonts pulling in from an external server, a shared hosting plan that's genuinely too slow for the traffic, these things compound. Each one costs a fraction of a second. Together they cost you the visitor. If you haven't looked at your hosting setup recently, that's often worth checking before anything else. A slow server makes every other fix harder to see. The page answers the wrong question This is the one people miss most often. A visitor arrives on your site with a specific question. Usually something like, can you do what I need, how much does it cost, and can I trust you? Most beautiful websites answer none of these directly. Instead they lead with the brand story, or a rotating hero banner with three messages that change before the visitor finishes reading the first one, or a vague headline like "We build beautiful things for discerning clients." That tells the visitor nothing useful. So they leave to find a site that does. The fix is blunt but it works. Put the most important information where someone looks first. What you do, who it's for, what happens next. Make the next step obvious. A contact form buried on page four isn't a conversion tool, it's an obstacle. Trust signals are missing or unconvincing People buy from businesses they feel confident about. A beautiful design helps, but it doesn't replace the things that actually build confidence. Real testimonials with names and context. Photos of the work, not just lifestyle imagery. A clear explanation of how the process works. A phone number that looks like someone answers it. Generic stock photos of people shaking hands do the opposite of building trust. Visitors have seen them a thousand times and they register as filler. Real photos of real work, even if the photography is imperfect, consistently outperform polished but hollow imagery. There's a related issue worth being honest about. Some sites look so designed that they feel corporate and distant. If you're a small business, leaning into that can work against you. People often prefer a site that feels like a real person runs it. Mobile experience gets treated as an afterthought Roughly half of all web traffic comes from mobile devices now, and a site that looks excellent on a desktop can be genuinely frustrating on a phone. Text that's too small to read without zooming, buttons too close together to tap accurately, a navigation menu that takes three attempts to open. The gap between looking clean and working cleanly is widest on mobile. A designer who checks their work only on a large monitor will miss it every time. Testing on an actual phone, with an actual thumb, on an actual mobile connection, catches things no desktop preview will show you. What to check before assuming it's a traffic problem Before spending more on ads or SEO, spend an hour on these. Open your site on your phone on mobile data, not wifi. Time how long it takes to feel usable. Read your homepage headline and ask whether it tells a first-time visitor exactly what you do. Find your contact form and count how many clicks it takes to get there. If your site is getting visits but not enquiries, that's a conversion problem, not a traffic one. More traffic through a broken funnel just means more people leave without buying. The site needs fixing first. Good design and good performance aren't opposites. But it takes more than picking a nice theme and uploading photos. The detail underneath matters, and that's exactly where most attractive-but-ineffective websites fall short. ------------------------------------------------------------ # Content Writing for SEO: What Search Engines and People Both Want Source: https://yorkshiredesign.co.uk/content-writing-for-seo-what-search-engines-and-people-both-want/ Published: 2026-07-17 > Most pages fail not because they lack keywords, but because they have nothing to say. Google has spent years building systems to spot the difference between a page that holds a reader's attention and one that just repeats a phrase until it ranks. The gap between those two things is where most content goes wrong. Getting this right is not about writing tricks or density targets. It is about understanding what a page actually needs to do before you place a single keyword. Why Writing for Algorithms Alone Stopped Working Google can see what happens after someone clicks your page. If they land, glance, and hit the back button within a few seconds, that tells the algorithm something. Do it enough times and the page drops, regardless of how many times you used the right phrase. Engagement signals matter now in a way they simply did not a decade ago. Pages that hold attention, prompt scrolling, and lead to follow-on clicks carry more weight than pages built around keyword repetition. The algorithm has shifted toward asking whether a page is genuinely useful, not just whether it mentions the right words. That shift is uncomfortable for anyone who built their content strategy around hitting a keyword count. The work is harder now. But good writing actually gets rewarded for it. The One Thing a Page Needs Before Any Keyword A specific point of view. That is it. Without something clear and particular to say, a page becomes a collection of sentences orbiting a topic without ever landing on it. Google's quality raters, who help shape how the algorithm is trained, are explicitly looking for what makes a page worth ranking: real expertise, a clear purpose, and content that could not have been written by someone who has never thought about the subject. A page about 'what to look for in a web designer' written from a genuine opinion, naming real things to check, will almost always outrank a page that lists the same generic five points every other site lists. The opinion is the differentiator. Without it, keyword placement is just rearranging furniture in an empty room. How to Use Keywords Without Sounding Like a List The focus keyword belongs in the title, the opening paragraph, one or two subheadings where it fits naturally, and then scattered through the body wherever it comes up organically. That is about all the instruction you need. What hurts a page is forcing the phrase into sentences where it does not belong. 'Content writing for SEO is something content writing for SEO professionals use for content writing for SEO purposes' is an extreme example, but the same problem appears in subtler form all the time. Readers notice it immediately. So does Google. Write the page for a person asking a specific question. Use the keyword where it comes up naturally in answering that question. Stop treating it as something to insert, and start treating it as a signal of what the page is about. Structure That Works for Scanners and Crawlers Most people scan before they read. They check the headings, skim the first line of each paragraph, and decide whether to commit. Structure your page knowing that, and you serve both the reader and the crawler at the same time. Clear H2 headings that describe what each section covers help a reader navigate and help a search engine map the page's topic. Short paragraphs, two to four sentences as a rule, give the eye somewhere to rest. One idea per paragraph keeps the logic clean. These are not stylistic preferences. They are the difference between a page that gets read and one that gets abandoned. One thing worth being deliberate about is the first hundred words. That opening section often decides whether someone keeps reading. Lead with the point, not the preamble. The Trade-off Nobody Warns You About Depth helps rankings. But length kills readers. That tension is real, and most content advice ignores it. Google tends to reward pages that cover a topic thoroughly. But 'thoroughly' does not mean 'at length'. A 600-word page that answers one question completely will outperform a 2,000-word page that answers it slowly. The problem is not depth versus brevity. It is specificity versus padding. Padding is what happens when a writer hits a word count target instead of a reader's actual need. The practical fix is to pick one question per page and answer it properly. If there is more to say, that is another page. This is also why most sites need more pages, not longer ones, if they want to build real search visibility without an agency budget. What Good Content Writing Actually Looks Like in Practice Consider two pages targeting the same phrase. One is 1,400 words long, covers ten subtopics, and repeats the keyword 22 times. The other is 700 words, answers one specific question, uses plain language, and is structured so a reader can get the answer in under two minutes. Nine times out of ten, the shorter, focused page wins. Not because it is short, but because it is clear. The reader gets what they came for. They do not bounce. The dwell time is longer relative to the page length. And because the writing is specific rather than generic, it earns more trust, more shares, and more links than the padded version. That is what content writing for SEO actually means in practice. Not keyword density. Not word count targets. A real answer to a real question, written plainly, structured so people can actually use it. The rest is detail. Contact Us Related: Long-Form Content vs Short Posts: Which Earns More Traffic Related: Content Writing for SEO: Why Most Briefs Produce Forgettable Pages ------------------------------------------------------------ # Video Production Websites: What They Need to Actually Work Source: https://yorkshiredesign.co.uk/video-production-websites-what-they-need-to-actually-work/ Published: 2026-07-17 > Video production websites are some of the most demanding builds to get right. The content is heavy, the visitors are visual, and the temptation to load every page with autoplay reels is strong. But what impresses a client in a meeting does not always translate to a website that loads quickly, ranks in search, or actually converts. The gap between a site that looks impressive and one that quietly does its job is wider here than almost anywhere else. Why Video Websites Break Faster Than Most A standard business site serves text, a few images, and maybe a contact form. A video production site is a completely different animal. You are dealing with large file sizes, autoplay triggers, embedded players from third-party platforms, and galleries that pile element on element before the page has even finished loading. That weight shows up immediately in Core Web Vitals. Largest Contentful Paint (LCP) suffers when the biggest thing on screen is a video thumbnail or a player that has to call out to an external server before it renders. Cumulative Layout Shift (CLS) spikes when embedded players load asynchronously and shunt everything else down the page. Generic site builds ignore all of this because they are not built around what media-heavy pages actually do to a browser. Hosting matters too. Shared hosting that handles a small business website comfortably will buckle under the bandwidth and concurrent requests that a portfolio-heavy video site demands. That is not a maybe. It is a certainty. Self-Hosting Video vs Embedding: The Real Trade-Off This is the decision that shapes everything else. Self-hosting means the video file lives on your server. Embedding means it lives on YouTube or Vimeo, and your page just pulls in a player. Self-hosting gives you full control. No third-party branding, no suggested videos at the end pulling your visitor somewhere else, no algorithm deciding what plays next. But it burns through bandwidth fast, it requires a host capable of streaming reliably, and the file sizes involved are not trivial. A five-minute showreel at broadcast quality is not something shared hosting handles gracefully. Embedding from Vimeo or YouTube solves the bandwidth problem immediately. The video is served from infrastructure built for exactly this purpose. Load times improve because the heavy lifting moves off your server. The trade-off is that you hand over some control, and on YouTube in particular, what plays after your video is out of your hands entirely. For most video production businesses, a hybrid approach makes sense. Embed the public-facing showreel on YouTube or Vimeo, self-host or use a private video platform for client work shown behind a login. That keeps the front end fast and the client experience clean. You can read more about how this connects to broader on-site SEO decisions in our separate breakdown. What Search Engines Actually See on a Video Site Google cannot watch your showreel. It reads text, structured data, and metadata. A homepage that is ninety percent video and ten percent words gives search engines almost nothing to work with. Autoplay reels rank for nothing on their own. What does help is VideoObject schema, a small piece of structured data you add to the page that tells Google the video's title, description, duration, and thumbnail URL. Google's own guidance confirms this is how video results get surfaced in search. Without it, even well-produced video content is largely invisible to the index. Each video should sit on its own page with a proper title, a written description, and a transcript where possible. That text is what earns the ranking. The video is what earns the enquiry once the visitor arrives. The Pages That Win Enquiries (and the Ones That Don't) Portfolio dumps rarely convert. A grid of thumbnails with no context tells a visitor nothing about what it would be like to work with you, what the process looks like, or what they should expect to spend. It looks impressive, but it does not move anyone to pick up the phone. The pages that do convert are specific. A service page that explains what you actually produce, who it suits, roughly what is involved, and what happens next will outperform a portfolio grid every time. Visitors need to see enough to feel confident, not just impressed. One site we rebuilt from the ground up had been layered on top of an existing theme, which caused styling and custom post type issues throughout. Once that was resolved and proper service pages were built out, it returned to the first page of Google for several competitive terms. The portfolio was still there. It just stopped being the whole site. Page Speed on a Media-Rich Site: What to Prioritise LCP and CLS are the two metrics that cause the most trouble on video production websites. LCP is slow because the largest element on the page is usually a video thumbnail or an embedded player. CLS is high because players load after the initial render and shift the layout. The practical fixes are fairly consistent. Lazy-load anything below the fold. Use a poster image instead of autoloading the player on arrival. Set explicit dimensions on every embedded element so the browser reserves space before it loads. For sites where page speed is a persistent problem, a common issue we see across many builds is that the player is firing on load when it should only fire on interaction. That single change moves LCP noticeably. The goal is not a stripped-back site with no video. It is a site where the first visible content loads fast, and the rest follows sensibly behind it. WordPress for Video Production: Solid Choice or Overkill? WordPress handles video production websites well in most respects. The CMS is flexible, the plugin ecosystem covers VideoObject schema, lazy loading, and player controls, and it is straightforward for a client to update their own portfolio without developer help. Where you need to be careful is theme bloat. Page builders that load scripts and styles across every page regardless of whether that page uses them add weight that a media-heavy site cannot afford. A theme built for a generic business site often carries assumptions that work fine in that context and cause real problems in this one. If you want a sense of how page builders and themes affect the underlying performance picture, this post on sites that look good but don't convert covers the same tension from a different angle. WordPress is a solid choice for this site type. But it needs to be built carefully, not just installed and themed. ------------------------------------------------------------ # WordPress Image Optimisation Plugins: Which Ones Are Worth It Source: https://yorkshiredesign.co.uk/wordpress-image-optimisation-plugins-which-ones-are-worth-it/ Published: 2026-07-17 > Images are almost always the heaviest thing on a WordPress page. Get them wrong and your site loads slowly regardless of what else you've done right. There are dozens of plugins claiming to fix this, and most of them overlap badly. Some genuinely help. Others just add weight to the admin side without doing much to the actual files. This is a plain look at which wordpress image optimisation plugins are worth installing, and where the real work actually sits. Why Plugins Alone Won't Solve It A plugin can automate compression and convert formats. What it cannot do is fix an image uploaded at four times the size it actually needs to be. Drop a 4,000-pixel-wide photo onto a page where it displays at 800 pixels and no plugin fully recovers that. The best results come from getting the source file close to right before any plugin touches it. That said, a solid plugin handles the tedious work automatically, and for most sites it makes a real difference. The question is which one, not whether. ShortPixel: Still the Most Consistent ShortPixel has been around long enough to earn genuine trust. It compresses on upload, converts to WebP, and lets you bulk-process your existing media library. The free tier covers 100 images a month, which is fine for a small site. Beyond that you buy credits rather than paying a monthly subscription, which suits smaller operations who don't want recurring costs for what is mostly a one-off task. The lossy compression is good. Aggressive, but rarely noticeable on photographs at normal display sizes. For logos and flat graphics, switch to lossless and leave it there. One setting that's easy to miss, make sure it's processing your thumbnails, not just the full-size original. WordPress generates several versions of every image, and they all need compressing. If you want to understand what the plugin is actually doing to your files under the surface, there's more detail on what these tools tend to overlook that's worth reading alongside this. Imagify: Clean Interface, Good WebP Handling Imagify is built by the same team behind WP Rocket, so it integrates cleanly if you're already using that for caching. The free plan gives you 25MB of optimisation per month, which runs out quickly on an active site. Paid plans are subscription-based, so the cost adds up over time. Where it earns its place is WebP delivery. It serves WebP to browsers that support it and falls back to the original for those that don't, all without any manual configuration. For sites that haven't touched their image formats yet, that alone tends to cut file sizes noticeably. Smush: Popular, but Worth Knowing Its Limits Smush is one of the most installed image plugins in the WordPress directory. It's free, well-supported, and it works. The free version doesn't convert to WebP, though, and it doesn't use the most aggressive compression available. You get decent results on JPEGs but you're not squeezing everything out of the files. The pro version adds WebP and lazy loading, but at that price point you're competing with ShortPixel credits, which go further for most sites. Smush is fine if you want something free and hands-off. Just know it's not the strongest tool available. Lazy Loading: Built Into WordPress Now WordPress has had native lazy loading since version 5.5. For most sites, that means you don't need a plugin for this specific feature. Images below the fold load only when a visitor scrolls toward them, cutting the initial page weight significantly. Where a plugin still helps is in making sure lazy loading applies consistently, including on images added through page builders or custom blocks that sometimes bypass the default behaviour. Check your site with the browser's network tab open and filter by images. If everything loads at once on a long page, something is overriding the default. That's worth digging into rather than assuming the plugin handled it. For a broader look at file size, format choices and lazy load working together, that covers the full picture. The One Plugin Combination Worth Considering Running two image plugins at once is usually a mistake. They compress the same files twice, conflict on WebP generation, and make problems harder to diagnose. Pick one compression tool and stick with it. If speed is a priority across the whole site, pairing a compression plugin with a caching plugin that handles critical CSS and deferred scripts does more than stacking multiple image tools. Images matter, but they're one part of a larger picture. A site that's getting faster without adding yet more plugins is usually doing the right things at the server and code level, not just in the media library. What's Not Worth Bothering With Any plugin that promises to optimise images entirely on your server, without an external API, is worth treating with caution. Local compression is slower, uses your hosting resources, and typically doesn't achieve the same file size reductions as a dedicated image processing service. The good plugins send files to an external API, compress them properly, and return the result. That's not a concern, it's how the better tools work. Also skip anything that bundles image optimisation as a side feature inside a bloated multi-purpose plugin. You end up carrying a lot of overhead for one feature you actually needed. ------------------------------------------------------------ # What a Web Design Company Actually Does for Your Money Source: https://yorkshiredesign.co.uk/what-a-web-design-company-actually-does-for-your-money/ Published: 2026-07-17 > Most people assume a web design company is basically a graphic designer with a keyboard. You pick some colours, upload a logo, and a site appears. The reality is almost the opposite. The visible part, what you see on screen, is often the quickest bit. The work that actually determines whether a site ranks, loads fast, and holds together over time happens somewhere most clients never look. Myth: You're Just Paying for a Pretty Design A screenshot tells you almost nothing useful about a website. It tells you what colours were chosen and whether the layout looks tidy. It says nothing about how the page loads, how the code is structured underneath, or whether the architecture makes sense for search engines. The real work in a proper build is structural. Page hierarchy, how content is ordered in the HTML, whether render-blocking scripts are held back until they're needed, how images are served. None of that shows up in a mockup. A site can look polished and still fail every Core Web Vitals check. That gap, between how something looks and how it actually performs, is exactly where a thorough build earns its cost. Myth: Any Developer Can Build the Same Thing Template work and a properly built site are not the same thing, even when they look identical in the browser. A lot of websites get built on top of existing themes, stacking plugins and page builders until the thing technically functions. The problem is what's running underneath. We've rebuilt sites that were originally developed on top of a third-party theme, with custom post types and styling crammed on top. The surface looked fine. Underneath, there were conflicts causing CPT issues, slow query loads, and structural problems that were quietly dragging the site down. After rebuilding from the ground up on WordPress, the site returned to the first page of Google for several competitive terms. The design barely changed. The code did. Someone who looks under the bonnet, rather than just at the dashboard, catches that kind of thing before it costs you later. You can read more about what separates surface-level work from a proper technical approach in our piece on what to look for in a web design agency. Myth: SEO Is Something You Add On Afterwards This is one of the most expensive beliefs in web design. SEO is not a layer you apply after launch. It is baked into how the site is built, or it isn't there at all. Heading hierarchy, URL structure, internal linking logic, page speed, how content is grouped and how crawlers move through the site. These decisions get made during the build. Fixing them after the fact means reopening work that should have been done properly the first time, and paying for it twice. A web design company that understands search builds with these things in mind from day one, not as an afterthought. Myth: A Faster Build Means a Better Deal Speed is not efficiency here. A site built in three days has almost certainly skipped something. The technical detail that makes a site hold up, device testing, script loading order, image compression strategy, database query efficiency, takes real time. There are no shortcuts that don't eventually show up somewhere. Usually in Core Web Vitals scores, or in rankings that quietly slip three months after launch. A common issue we see is page speed that passes on launch day and degrades steadily as plugins update and conflict with each other. That doesn't happen on a site where someone has paid attention to what's actually loaded on every page. It happens when the build was rushed and nobody looked closely at the underlying performance. Our Core Web Vitals fixes guide covers several of these patterns in detail. Myth: Once It's Live, the Work Is Done A live site is not a finished product. It's a maintained one, or it isn't maintained and it slowly deteriorates. WordPress core updates, plugin conflicts, PHP version changes, speed degradation as content grows. These things accumulate. A site left completely alone for twelve months rarely performs the same as it did on launch day. Security vulnerabilities appear. Plugins fall out of sync. Page weight creeps up. Ongoing attention is part of what you're paying for with a proper web design company. Not because anything is broken, but because the web doesn't stand still. What the Money Actually Goes On A proper build involves a technical audit before a single page is designed, architecture decisions about how content is grouped and linked, speed work that often takes longer than the design itself, and testing across real devices rather than just a desktop browser. Content structure takes time too. Heading levels, meta information, how copy is formatted so both readers and search engines get what they need from it. That's before any visual design work starts. There's no padding in that list. It's just what a careful build actually involves. The money goes on hours nobody sees, on decisions that quietly determine whether the site performs or sits there looking nice and doing nothing. If you want a clearer sense of what these builds cost and why prices vary so much, our guide to UK web design costs lays it out plainly. Related: What a Good Web Design Process Actually Looks Like ------------------------------------------------------------ # Does Managed WordPress Hosting Actually Make Your Site Faster? Source: https://yorkshiredesign.co.uk/does-managed-wordpress-hosting-actually-make-your-site-faster/ Published: 2026-07-17 > Managed WordPress hosting is sold on speed. The marketing is confident, faster servers, built-in caching, optimised environments. But the reality is a bit more complicated than that. Some sites do get meaningfully quicker after switching. Others move across and see almost no difference. What actually determines the outcome is less about the host and more about what's already going on inside the site itself. What Managed Hosting Actually Gives You Standard shared hosting puts your site on a server alongside hundreds of others. Resources are pooled, and when a neighbouring site spikes in traffic, yours can slow down. Managed WordPress hosting changes that. You get a server environment tuned specifically for WordPress, usually with faster storage, server-level caching, and fewer competing tenants. Most managed hosts also handle software updates, daily backups and security monitoring. That's less admin for you, which is genuinely useful. But none of that directly puts kilobytes of markup on a faster connection. The hosting environment is one part of the speed picture, not the whole thing. Where the Speed Gains Are Real Time to First Byte, which Google uses as a signal in its Core Web Vitals assessment, measures how quickly a server starts responding. This is where managed hosting tends to win clearly. A well-configured managed server on fast NVMe storage can cut that initial response time significantly compared with a congested shared environment. Server-level caching also makes a real difference for mostly static pages. When a managed host serves a cached HTML file directly, it skips PHP execution and database queries entirely. For content-heavy sites with high traffic, that shortcut adds up. For a small site with ten visitors a day, the benefit is harder to notice in practice. What the Host Cannot Fix This is where most people run into disappointment. A faster server cannot compensate for a WordPress install that is carrying too much weight. Slow Core Web Vitals scores usually come from oversized images, render-blocking scripts, poorly coded themes or plugins stacking up requests. The host delivers the files. It cannot decide which files get delivered. A common issue is that a site fails Core Web Vitals not because of server response time but because of how the page is built. Fixing that requires looking at what is actually inside the site, not just where it is hosted. We have seen this repeatedly when optimising page speed across different hosting setups, and moving to managed hosting alone was not enough to turn a failing score into a pass. If your theme is loading six font files and your homepage has uncompressed images at several megabytes each, you need to fix those first. No amount of server-level caching rescues a 4MB hero image. The Plugin Layer Still Matters Many managed hosts recommend against certain caching plugins because the host already handles caching at the server level. That makes sense on paper. But it also means you lose some of the granular control that a plugin like NitroPack or WP Rocket gives you over things like lazy loading, critical CSS and script deferral. If your performance plugin handles those front-end optimisations well, and the managed host handles server-side delivery, the combination can be genuinely strong. The mistake is assuming one replaces the other. Is the Price Worth It Managed WordPress hosting costs more. Sometimes considerably more. Whether that premium pays off depends on what you are comparing it against and what your site actually needs. For a high-traffic WooCommerce store or a membership site under constant load, the investment in a stable, fast environment usually makes sense. For a five-page brochure site that gets a few hundred visits a month, a well-configured shared or cloud host with a decent caching plugin will often perform just as well at a fraction of the cost. The question worth asking is not "is managed hosting faster?" but "is the current hosting actually the bottleneck?" If your site is slow and the server response time is the problem, switching will help. If the bottleneck is a bloated theme or unoptimised assets, addressing the front-end will move the needle far more than a hosting upgrade. What to Check Before You Switch Run your site through Google PageSpeed Insights and look at where the time is actually being lost. If Time to First Byte is the dominant issue, managed hosting is a reasonable answer. If the diagnostics are pointing at image sizes, unused CSS or third-party scripts, fix those first. Good hosting is worth paying for. But it is one piece, and it is rarely the most important one. Get the site itself in reasonable shape, then put it on a solid server. That order tends to produce better results than the other way around. ------------------------------------------------------------ # 7 Things Every Content Brief Needs to Rank in Search Source: https://yorkshiredesign.co.uk/7-things-every-content-brief-needs-to-rank-in-search/ Published: 2026-07-17 > Most content briefs are too thin to be useful. They hand a writer a keyword, a rough word count, and not much else. Then everyone wonders why the page never appears in search. The brief is where ranking actually starts. Get it wrong there and no amount of editing fixes it later. These seven things separate a brief that produces something worth reading from one that just fills a page. 1. A Single, Specific Search Intent Every page should answer one question for one type of person. Not three questions. Not a broad topic. One clear intent. Before you write a word of the brief, look at what already ranks for your target keyword. Are those pages how-to guides, product comparisons, or definitions? That tells you what Google thinks the searcher wants. Match it, and you start from the right place. Ignore it, and your page fights uphill from day one. 2. Real Competitor Analysis, Not Just a List of URLs Dropping five competitor URLs into a brief is not analysis. You need to note what those pages actually cover, what they skip, and where they fall short. Look for gaps. A competitor's page on "content briefs" might explain what they are but never explain how to write one. That gap is your opening. Brief the writer to fill it. That is how a page earns its position rather than simply repeating what already exists. This kind of close reading takes time. It is also, nine times out of ten, the step that most briefs skip entirely. 3. The Primary Keyword and a Handful of Supporting Terms One focus keyword, stated plainly. Then three to six related terms the writer should weave in naturally, not mechanically. These supporting terms are not padding. They reflect the language real searchers use around the topic. Google's own guidance on helpful content makes clear that pages should cover a subject thoroughly, not just repeat a single phrase. A brief on content brief SEO that never mentions search intent, headings, or user need is already incomplete. Keep the keyword list short. A brief crammed with forty terms overwhelms the writer and usually produces copy that reads like it came from a spreadsheet. 4. A Clear Angle or Point of View Generic content ranks poorly because it offers nothing a reader could not find anywhere else. The brief needs to tell the writer what position the page is taking. That might be a common mistake to address, a contrarian view on standard practice, or a process explained in a specific order that nobody else has bothered to lay out clearly. Whatever it is, it needs to be in the brief before the writer starts. You cannot retrofit an angle onto copy that was written without one. We have seen this problem up close. A local company built a decent website, then handed content production to an SEO firm who churned out hundreds of pages with no clear angle and no relevance to the actual business. The result was a rankings drop on the keywords that actually mattered. Bad content at volume is worse than no content. Do not rank number one for something that does not help your business. 5. Word Count Based on What Ranks, Not a Round Number Picking 1,500 words because it sounds thorough is not a strategy. Look at what the top three ranking pages for your keyword actually contain. If they are all between 800 and 1,000 words, write 900. If they are long-form guides at 2,500 words, you probably need to match that depth. Word count follows the topic. Some questions are answered in 600 words. Some need 2,000. The brief should reflect that, not impose a number that pads the copy or forces cuts where the reader needed more detail. If you want to see what matching depth to the topic looks like in practice, the thinking behind what makes a page worth ranking covers this well. 6. Specific Headings, Not Just Topics Telling a writer to "cover keyword research" is not a heading. "How to find supporting keywords without paid tools" is a heading. The difference is specificity. Draft at least the main H2 headings in the brief. They become the skeleton of the page. When they are specific, the writer knows exactly what each section needs to deliver. When they are vague, the writer guesses, and the page ends up covering things you did not want while missing things you did. Good headings also do quiet SEO work. They signal to search engines what a page covers, which supports the kind of thorough, structured content that tends to hold its position over time. 7. A Clear Internal Linking Plan The brief should name the pages you want to link from and to, with guidance on the anchor text. This is often the last thing anyone thinks about and the first thing forgotten once the copy goes live. Internal links pass relevance signals between pages. They keep readers on the site and help search engines understand how your content fits together. A brief that includes this from the start means the writer builds those links into the copy naturally, rather than bolting them on awkwardly after the fact. For a fuller look at how this connects to the wider reasons most briefs produce forgettable pages, that post covers the structural side in more depth. Related: 7 Ways Businesses Brief Web Projects Completely Wrong ------------------------------------------------------------ # Clean Website Design: Looking Good vs Working Well Source: https://yorkshiredesign.co.uk/clean-website-design-looking-good-vs-working-well/ Published: 2026-07-17 > A website can look immaculate and still be quietly failing. Slow to load, invisible to search engines, broken on a phone. The word 'clean' gets used constantly in design briefs, but it almost always refers to how something looks, not how it performs. Those are two very different things. This post works through what clean actually means in technical terms, and how you can tell the difference before you hand over the final payment. What 'Clean' Usually Gets Confused With Most people use 'clean' to mean minimal. White space, simple fonts, not too many colours. That is a style preference, not a technical quality. A site can be visually restrained and still carry three megabytes of uncompressed images, four conflicting page builder plugins, and render-blocking scripts stacked in the document head. A genuinely clean website is one where the code is tidy, the load is light and the structure makes sense to both users and search engines. What it looks like is almost secondary. The real question is what is happening underneath. The Hidden Weight of a Slow Page Open Google PageSpeed Insights on a site that looks great. You will often find a score that tells a different story. Unoptimised images are the most common culprit. A hero image exported at full resolution from a design tool can weigh two or three megabytes on its own. On mobile, that single file can delay the Largest Contentful Paint by several seconds. Render-blocking scripts are the other common issue. JavaScript that loads in the document head before the page has painted anything visible forces the browser to stop and wait. The user stares at a blank screen. They do not know why. They just leave. A common issue we see across many sites is that Core Web Vitals show as failing, even though the front end looks perfectly fine. Passing those metrics requires deliberate technical work, not just a good-looking layout. Code Underneath the Surface WordPress makes it easy to build something that looks polished. It also makes it easy to accumulate bloat. A theme that was built to do everything ships with CSS for layouts you are never going to use. A page builder adds its own stylesheet on top. Then a plugin adds another. By the time a page loads, the browser is processing hundreds of kilobytes of CSS that have nothing to do with what is on the screen. Plugin conflicts are a subtler problem. Two plugins touching the same element, or both trying to manage caching, can produce odd results that only show up on specific devices or browsers. The front end looks fine in a desktop preview. A real user on a mid-range Android phone sees something broken. This is the kind of thing that only surfaces when you look at the code, not the design mock-up. If you are curious about why a well-designed site still loses enquiries, this is usually where the answer sits. When Design Gets in the Way of the User A layout that looks striking on a large monitor can be a mess on a phone. Oversized hero sections, text that does not reflow, buttons that sit too close together for a thumb to tap accurately. These are not minor polish issues. They are the difference between someone calling you and someone pressing back. Navigation is another area where visual decisions hurt real outcomes. If a user needs three taps to find a phone number, most will not bother. Contact details should be one tap away on mobile, full stop. A designer who is focused on aesthetics may not be thinking about that. The person paying the invoice should be. What Google Actually Reads vs What You See Google does not see your font pairing. It reads your HTML. Heading structure matters. A page with five H1 tags, no H2s and image alt text left blank is difficult for a crawler to make sense of, regardless of how considered the visual design is. Schema markup, crawlability and internal link structure all influence how a page ranks. Most design briefs say nothing about any of them. Getting a page to rank depends on the stuff that never appears in a design preview. That work happens at the code level, and it takes time to do properly. How to Tell the Difference Before You Sign Off You do not need to read code to do a basic check. Run the URL through Google PageSpeed Insights. Look at the mobile score specifically. Anything below 70 on mobile is a problem worth raising before you accept the work. Open Google Search Console if the site has been live for a few weeks. The Core Web Vitals report shows real-user data, not just lab scores. If pages are flagged as failing, that is a concrete issue, not an opinion. Check mobile usability on your own phone. Try to find the contact page in under two taps. If you cannot, a real visitor probably will not either. These checks take ten minutes. They are worth doing before the final invoice is paid, not six months later when rankings have not moved. One honest caveat, a PageSpeed score of 100 does not automatically mean the site will rank well or convert visitors. It is one signal among many. But a score in the 30s on mobile is rarely a coincidence. It is usually a sign that the technical groundwork was skipped in favour of how things looked. Contact Us Related: Your Website Looks Great. So Why Isn't It Converting? ------------------------------------------------------------ # Web Hosting Uptime: What It Means and How to Check Yours Source: https://yorkshiredesign.co.uk/web-hosting-uptime-what-it-means-and-how-to-check-yours/ Published: 2026-07-17 > A 99.9% uptime guarantee sounds like your site is always on. Do the maths and it permits just under nine hours of downtime every year. That figure is on the host's terms, measured the way they choose, logged when they decide something counts as 'down'. Whether any of that downtime lands at 2am or right in the middle of your busiest trading hour is not covered. Here is what those numbers actually mean, and how to find out what your host is really delivering. What 99.9% Uptime Actually Adds Up To Run the maths and it becomes clear quickly. 99.9% uptime across a full year leaves 8 hours and 45 minutes unaccounted for. Step up to 99.99% and you are still looking at around 52 minutes a year where your site can legitimately go dark under the terms of the SLA. Neither figure is dishonest. The problem is that most people read the percentage and stop there. Fifty-two minutes spread across a year sounds trivial. One unannounced outage on a Friday afternoon during a product launch is a different matter entirely, and the SLA treats both the same way. Why the Percentage Is Only Half the Story Timing matters more than the total. A 15-minute outage at 2am barely registers. The same outage at noon on a Monday, when Googlebot is midway through a crawl or someone has just clicked a paid ad, costs you something real. Most hosting SLAs say nothing about when downtime tends to cluster. Maintenance windows, server migrations and resource spikes follow the host's schedule, not yours. Check your own traffic data in Google Analytics or Search Console. If your peak hours run from 10am to 2pm, that is the window you need solid uptime in, not just a good annual average. How Hosts Measure Uptime (And What They Leave Out) Host-reported uptime almost always measures one thing, whether the server responds to a ping. If the server sends back any response, it counts as up. That is not the same as your site actually working. A page can respond to a ping and still return a database timeout to every real visitor. Slow TTFB, PHP errors, a broken database connection, a failed CDN handoff, none of these necessarily trigger a host's own monitoring as a downtime event. Partial failures like these are invisible to most SLA calculations but very visible to your users and to search engine crawlers. This is why host-reported uptime figures almost always look better than independent monitoring shows. The host is measuring their infrastructure. You need to measure what visitors actually experience. How to Check Your Host's Uptime Yourself Two tools worth knowing are UptimeRobot and Better Uptime. Both offer free tiers that handle basic HTTP monitoring. Set them up to check your homepage URL, not just your domain, because that tests the full stack rather than a bare DNS response. Check every five minutes rather than every minute. One-minute polling on a free plan can generate noise from brief network blips that are not genuine outages. Five-minute intervals give you a clean picture without false positives. Run it for four to six weeks before drawing any conclusions, then compare the logged availability against what your host claims. A consistent gap between the two is worth questioning. For a closer look at how hosting affects real page load performance, the fixes that move Core Web Vitals scores cover TTFB and server response time in detail. What Downtime Does to Your SEO Google does not penalise a site for one isolated outage. Recurring short outages are a different matter. If Googlebot visits during a crawl window and repeatedly hits a 503 or a timeout, it scales back how often it returns. That wastes crawl budget and delays indexing for new or updated pages. The signal is quiet, which is what makes it easy to miss. You will not see a ranking drop you can point to directly. What you will see is pages taking longer than expected to appear in search results, or re-crawl rates falling off in Search Console. Reliability is a background quality signal. It does not shift rankings on its own, but consistent unreliability slowly erodes the conditions that good rankings depend on. When It's Time to Move Hosts Persistent outages during peak hours, a consistent gap between claimed and independently measured uptime, or repeated partial failures that never appear in any SLA report are all legitimate reasons to consider moving. The honest caveat is this. A poorly planned migration can cause more disruption than the original problem. DNS propagation, database transfer errors and misconfigured redirects can take a site offline for longer than any individual hosting outage. If you do decide to move, do it methodically. Test the new environment before switching DNS, understand what actually matters in a hosting setup before committing, and always keep a full backup you can restore from if something goes wrong during the transfer. A better host will not fix SEO problems on its own. But a reliable one stops your hosting from quietly working against everything else you are doing right. Contact Us Related: Cheap Web Hosting: What You Actually Get for the Price Related: Web Hosting Choices That Quietly Kill Your SEO ------------------------------------------------------------ # AI Automation Tools for SEO: How to Choose the Right One Source: https://yorkshiredesign.co.uk/ai-automation-tools-for-seo-how-to-choose-the-right-one/ Published: 2026-07-17 > There are dozens of AI tools promising to sort your SEO. Some do something genuinely useful. Others generate a lot of noise and not much movement. Choosing between them is less about features and more about understanding what kind of SEO problem you actually have. A tool that writes meta descriptions at scale is not the same as one that audits crawl structure. Getting clear on that difference before you spend money saves a lot of wasted time. Content Generation vs Technical Audit Tools Most AI SEO tools fall into two camps, ones that produce content, and ones that analyse your site's technical health. They are not interchangeable, and treating them as if they are is where most people go wrong. Content tools, things like AI writers and brief generators, can cut the time it takes to produce a first draft or map out a topic cluster. That is genuinely useful if your bottleneck is output. However, if your site has crawl errors, slow load times, or poorly structured internal linking, no amount of AI-written content will fix that. Google needs to be able to find and read your pages before it can rank them. Technical audit tools are a different category entirely. They crawl your site, flag issues with indexability, structured data, canonical tags, and page experience signals. Some now use AI to prioritise which fixes matter most given your site's specific profile. That prioritisation is where the real value sits, because a raw audit report with 400 issues is not actionable on its own. The Honest Trade-off With AI Content Tools AI content generation is fast. It is also, fairly often, generic. That is the trade-off that does not get said plainly enough. Google's guidance is clear that helpful, original content written for people, not search engines, is what gets rewarded. AI tools can produce technically correct text that satisfies a brief, but if it reads like a hundred other pages on the same topic, it will not stand out in search. The tool is only as good as the direction you give it. Used well, an AI content tool is a starting point, not a finished product. It drafts, you shape. The time saving is real. But anyone expecting to publish raw AI output and see rankings climb is going to be disappointed. The edit is where the value actually gets added. If you want to understand how these tools fit into a broader workflow, how automation slots into a content process is worth reading before committing to any single platform. Keyword Research and Clustering Tools This is probably the area where AI has made the most practical difference to day-to-day SEO work. Grouping keywords by intent used to take hours of manual sorting. Decent AI clustering tools do it in minutes, pulling search queries into topic groups so you can plan content that covers a subject properly rather than targeting isolated phrases. The output is not always perfect. Clusters sometimes lump together queries that have subtly different intent, which means a page built on that cluster serves none of them well. So you still need to check the actual search results for your target queries before building content around them. But as a first-pass time saver, keyword clustering is one of the more reliable uses of AI in an SEO workflow. On-Page Optimisation Assistants Several tools now score your page in real time as you write, comparing it against the top-ranking pages for your target keyword. They flag thin sections, missing related terms, and heading structure issues. Some integrate directly into WordPress. These tools are useful for writers who are not SEO specialists. They provide a checklist without requiring someone to manually pull apart competitor pages. However, they can push you toward over-optimised copy if you chase the score too aggressively. A page that reads naturally tends to perform better over time than one written to satisfy a tool's criteria. Use the score as a guide, not a target. If you want to understand what good on-page work actually involves, what SEO optimisation actually covers gives a clearer picture of the full scope. Automation for Reporting and Monitoring Pulling ranking data, traffic changes, and crawl stats into one place is genuinely tedious to do manually. AI-assisted reporting tools can surface anomalies automatically, flagging drops or indexation problems before they become serious. That early warning is worth something. The caveat is that automated reports still need someone who knows what they are looking at. A tool can tell you that organic traffic fell 18% in a month. It cannot always tell you why, or what to do next. That still takes judgement. For the detail on why SEO results move slowly regardless of your toolset, what makes SEO take time explains the mechanics honestly. What Actually Matters When Choosing Pick one tool that solves your actual bottleneck, not several tools that each do ten things adequately. A focused audit tool used properly beats a sprawling platform used inconsistently. Free tiers are worth testing before paying for anything. Most decent tools offer enough access to tell you whether the interface fits how you work. If it does not feel intuitive within the first hour, it will not get used regularly, and an unused tool does nothing for your rankings. ------------------------------------------------------------ # Bing AI Search Is Here. What Happens to Your Traffic Now? Source: https://yorkshiredesign.co.uk/bing-ai-search-is-here-what-happens-to-your-traffic-now/ Published: 2026-07-17 > Most people still treat Bing as an afterthought. That's understandable. Google has dominated search for years. But Bing's AI-powered search has quietly changed the picture, and it's already affecting how people find websites. If you've noticed a dip in referral traffic without an obvious cause, it's worth looking beyond Google for the answer. Here's what's actually happening, and what it means for your site going forward. The Myth: Bing Doesn't Matter for Traffic For years, dismissing Bing was a reasonable position. Its market share was small, and most SEO effort was rightly pointed at Google. That logic is getting shakier. Bing now powers search across Microsoft Edge, Windows, and through Copilot on millions of devices. Add the users who have switched to AI tools built on Bing's index, and the audience is larger than most people assume. The more important shift is behavioural. Bing's AI search doesn't just rank your page, it reads it, extracts an answer, and presents it directly. The user may never click through at all. That changes the traffic equation in a way that raw market share figures don't fully capture. What Bing's AI Search Actually Does Bing's AI results pull from indexed web content and generate a summarised answer at the top of the page. Sources are cited, but the citation doesn't always mean a click. A user asking a factual question gets an answer. If your page was the source, you might get a tiny reference link with no visit attached. For informational content, this is the core problem. Pages built entirely around answering simple questions, definitions, how-to steps, quick FAQs, are the pages most at risk. If AI can answer the question without the user visiting, many won't. This isn't a future concern. It's already happening, across Bing and Google's AI Overviews alike. However, not all content is equal here. Pages that offer something AI can't easily replicate, a specific case study, a price, a booking form, a genuinely held opinion, remain much harder to bypass. That's not a coincidence. It's the distinction worth building toward. The Traffic Types That Survive AI Search Transactional intent holds up well. Someone searching for a local tradesperson, a product with a specific spec, or a service they want to hire is still going to click through. The AI summary can shortlist options, but it can't complete the purchase or the enquiry. So does content with genuine depth. A shallow 400-word post covering a topic everyone else has covered gives AI everything it needs to answer the question and move on. A thorough piece that takes a real position, shows working, and adds something a scraper can't compress into two sentences, that has staying power. There's a reason longer, more substantive content tends to pull more consistent traffic over time. Brand-led searches also survive. If someone already knows who you are and types your name, no AI summary replaces the visit. Building a recognisable name, even a modest one in a specific niche, is better protection than it used to be. What Most People Get Wrong About This The instinct is to write more content, faster. That's usually the wrong call. Thin content published at volume is exactly what AI search strips for parts. One solid, specific, genuinely useful post does more work than ten filler pieces that cover the same ground as every other site in the niche. The other common mistake is ignoring technical basics while chasing content volume. If your site loads slowly, has broken structure, or isn't indexed properly, AI search has nothing reliable to pull from in the first place. It's worth checking your indexing and crawl status periodically. Google Search Console tells you how many of your pages are actually being crawled and indexed, and the same principles apply to Bing Webmaster Tools, which is free and takes minutes to set up. Should You Optimise Specifically for Bing? You don't need a separate strategy. Good SEO practice transfers. Clean page structure, fast load times, clear headings, well-written content that actually answers what the page promises. These things work regardless of which engine is reading your site. That said, Bing places slightly more weight on older, established domains and on social signals than Google does. A page with genuine backlinks and some external recognition tends to earn citations in Bing's AI results more reliably. None of that is a quick fix. What good SEO actually takes is steady, patient work, and that remains true across every search engine running AI on top of its index. The Honest Trade-off AI search will reduce clicks on some content, and there's no getting around that. Informational pages that answer simple questions will lose referral traffic over time. That's a real cost. The upside is that traffic which does come through tends to be more intentional. Users who click past an AI summary are looking for something deeper, something to buy, someone to contact, or a perspective they haven't already seen. That kind of visit converts at a higher rate than casual informational traffic ever did. Worth adjusting your expectations, not abandoning the work. ------------------------------------------------------------ # Why Cheap Web Hosting Is Costing You Rankings Source: https://yorkshiredesign.co.uk/why-cheap-web-hosting-is-costing-you-rankings/ Published: 2026-07-17 > Cheap hosting feels like a smart call when you're watching costs. The site loads. The emails arrive. Nothing looks broken. What you don't see is what it's doing to your search rankings month by month. Slow servers, shared resources, and poor uptime records all feed directly into signals that Google weighs. By the time the damage shows up in Search Console, you've already lost ground that takes real time to claw back. What Cheap Hosting Actually Means Most budget hosting plans put your site on a shared server alongside hundreds, sometimes thousands, of other sites. Everyone shares the same CPU, the same RAM, and the same bandwidth. When another site on that server gets a spike in traffic, your site slows down. You had nothing to do with it. Your visitors feel it anyway. There's also the question of where that server is. A server based in the US serving UK visitors adds latency before a single byte of your page loads. That delay is baked in before your code even runs. No amount of plugin-level optimisation fully compensates for a slow physical connection between server and browser. Server Speed and Core Web Vitals Google's Core Web Vitals metrics measure what a real user experiences when your page loads. LCP, which is Largest Contentful Paint, measures how quickly the main content appears. On a congested shared server, your Time to First Byte (TTFB) is often the bottleneck. If the server takes 800ms just to respond, LCP has no chance of hitting the threshold Google wants, regardless of how lean your theme is. The honest truth is that a slow TTFB is one of the hardest problems to fix without changing hosts. You can compress images, defer scripts, and minify CSS. But if the server itself is sluggish, you're patching around the root cause. Uptime: The Problem Nobody Talks About Budget hosts often advertise 99.9% uptime. That sounds solid. In practice, 99.9% still allows roughly eight hours of downtime per year. More importantly, that figure rarely accounts for periods of severe slowness, which aren't technically "down" but are functionally useless to a visitor. When Googlebot tries to crawl your site during one of these slow periods, it either times out or records an unusually slow response. Do that repeatedly and your crawl budget gets wasted. Pages that should be indexed aren't. Rankings for pages that were indexed can soften over time as Google's confidence in your site's reliability drops. Quick comparison, what budget vs. managed hosting typically affects TTFB (budget shared) Often 600ms+ TTFB (managed WordPress) Often under 200ms Shared server neighbours Hundreds to thousands of sites Managed server neighbours Few or none These are typical industry ranges, not guaranteed figures. Your results will vary by host and plan. Security and the "Bad Neighbourhood" Effect Shared hosting creates another less obvious risk. If a site on your shared IP gets flagged for spam or malware, your IP address can end up on blocklists. Emails from your domain start hitting junk folders. In rare but real cases, the shared IP reputation can affect how cautiously Google treats other sites on the same block. This isn't guaranteed to happen. But it does happen, and when it does, it's very difficult to diagnose. Most clients who come to us with unexplained ranking drops or email deliverability problems have never once thought to check their server's IP reputation. It's the kind of hosting detail that quietly causes damage long before anyone notices. What's Actually Worth Paying For Managed WordPress hosting costs more. That's just the reality. But what you're buying is a server configured specifically for WordPress, with caching, security hardening, and proper resource allocation built in. You're not sharing a box with a thousand other sites running everything from WooCommerce to Joomla. The SEO benefit isn't just faster load times. It's consistency. Google rewards sites that are reliably fast, reliably available, and reliably crawlable. A cheap host can give you two of those on a good day. Managed hosting tends to deliver all three as the baseline. For anyone serious about rankings, the case for managed hosting comes down to one question, how much is the traffic worth that you're currently losing? One Thing People Get Wrong Switching hosts won't fix a ranking problem overnight. That's worth saying plainly. If your site has been on a slow server for a year, Google needs time to re-evaluate it after you move. The improvement in speed is measurable within days. The ranking recovery follows over weeks or months, not hours. Hosting is infrastructure. Treat it like that. Get it right once, then focus your attention on content and technical SEO where the ongoing effort actually lives. ------------------------------------------------------------ # 7 Signs You Should Trust the Process or Push Back Source: https://yorkshiredesign.co.uk/7-signs-you-should-trust-the-process-or-push-back/ Published: 2026-07-17 > Most clients sit in one of two camps. Some never ask a single question, even when they should. Others chase weekly updates when the work simply needs time. Neither approach gets the best result. Knowing when to sit tight and when to press for an answer is worth understanding. These seven points should help you figure out where you actually stand. 1. A timeline was given upfront and nothing unusual has happenedIf your designer or SEO specialist set a clear timeframe at the start and you are still inside it, that is usually a signal to let things run. Good technical work takes time. A website rebuild or an SEO push does not visibly change overnight, even when progress is real and steady.Chasing updates every few days rarely helps anyone. It pulls the person doing the work away from doing it. If a timeline was agreed and nothing has gone wrong, waiting is the right call.2. You have had no communication for longer than agreedThis one tips the other way. Silence beyond a reasonable window is worth questioning. If your last message was three weeks ago and you were promised a monthly update, asking where things stand is completely fair.There is a difference between a quiet, heads-down worker and someone who has gone missing. A brief check-in asking for a short progress note is not impatient, it is sensible. Any competent person working on your site should be able to give you a one-line update without breaking their stride.3. You do not understand what is being done or whyYou do not need to understand every technical detail. However, you should be able to understand the general direction. If someone cannot explain what they are doing in plain terms, that is a red flag, not a sign of complexity.Ask a simple question. 'What are you working on this week and what will it change?' A good answer does not need to be long. It just needs to make sense. If the answer is vague every single time, that is worth noting.4. Something specific has changed and you were not toldYou notice your site is down. Or a page has disappeared. Or your enquiry form stopped working. If something changed on your end without warning, asking immediately is right. You should not feel like you are being difficult for flagging a concrete problem.There is an important distinction between impatience about results and a genuine issue with your site. Google Search Console will often show crawl errors or indexing drops before most clients notice them. Waiting on results is fine. Waiting on a broken site is not.5. Results are being promised, not explainedAnyone who promises you a specific ranking position by a fixed date is either guessing or being dishonest. SEO does not work that way and never has. Google's systems are not predictable to that level of precision.What you should hear instead is something like 'here is what we are doing and here is why we expect it to improve things over time.' That is an honest answer. Vague promises dressed up as guarantees are the point at which you should start asking harder questions.6. Early signs are pointing in the right directionNot all progress is visible as rankings or revenue. Impressions going up in Search Console, page speed scores improving, or crawl errors clearing are all meaningful signals. If you can see those moving even slightly, that is a reason to trust the process.The real work often happens well below the surface. Core Web Vitals improvements, schema corrections, internal link structure changes, none of this is obvious to a client, but it matters. Ask to see what is being tracked. A short monthly snapshot of two or three metrics is enough to show things are moving.7. Your gut says something is offThis one is harder to quantify, but it is real. If something consistently feels wrong, it probably is. Not because you are being unreasonable, but because a pattern of missed deadlines, unclear answers and zero visible progress is worth taking seriously.The honest trade-off here is this, good work does take time, and some clients push back too early on things that simply need space to develop. But there is a difference between patience and being kept in the dark. If you have asked a clear question twice and still have no clear answer, that is the point to push harder. Trusting the process only works when there is a real process to trust. Related: When to Trust the Process and When to Ask Questions Related: SEO Progress: When to Wait and When to Ask Questions ------------------------------------------------------------ # What Google’s Core Update Actually Changed (And What Didn’t) Source: https://yorkshiredesign.co.uk/what-googles-core-update-actually-changed-and-what-didnt/ Published: 2026-07-17 > Every time Google runs a core update, the same panic follows. Rankings move, forums fill up, and everyone starts second-guessing their content. Some of that reaction is justified. Most of it isn't. The honest truth is that core updates rarely change what Google is looking for. They change how well Google can find it. This post walks through what actually shifted, what people think changed but didn't, and the one or two things genuinely worth paying attention to. Start Here: What a Core Update Actually Is A core update is not a penalty. Google is not targeting your site specifically. What's happening is a recalibration of how Google weighs the signals it already uses. Think of it less as a rule change and more as a scoring adjustment. Sites that drop after a core update haven't suddenly broken any rules. They've been reassessed against a sharper version of the same criteria. Google runs these updates several times a year. The time it takes to recover after a core update is often longer than people expect, because the fix isn't technical. It's about the quality of what's on the page. What This Round Actually Changed The signal that's been weighted more heavily recently is what Google calls 'information gain'. That's a rough way of saying, does your page say something that isn't already said, identically, on a hundred other pages? Thin content that restates the obvious has always been weak. Now it's weaker still. There's also been a measurable shift in how Google handles pages that exist mainly to rank rather than to inform. Pages built around a keyword with no real depth behind them are losing ground to pages that actually answer the question. Not just mention it. AI-generated content is part of this picture. Google has been fairly clear that it doesn't object to AI-written content in principle. What it objects to is content that's hollow, whatever the source. If you're using AI to produce something genuinely useful, that's fine. If you're using it to fill a page, that's the problem. Our article on AI content and Google penalties goes into that in more detail. What Didn't Change Backlinks still matter. Page speed still matters. Technical health still matters. None of that moved. People who lost rankings and decided their link profile was suddenly the problem are probably wrong. Core updates don't target links. They target relevance and quality. E-E-A-T didn't change either, it just got harder to fake. Experience, expertise, authoritativeness, and trustworthiness have been in Google's Quality Rater Guidelines since well before this update. What's shifted is Google's ability to distinguish between a page that demonstrates real knowledge and one that performs it. That's a meaningful difference. The Sites That Dropped and Why Most of the sites that took a visible hit share a few common traits. Content that's broad rather than specific. Pages that cover a topic in 400 words when the question genuinely needs 900. A site structure where almost every page targets a keyword but none of them actually resolves the reader's query. There's also a category of sites that built authority a few years ago on the back of volume. Lots of posts, published fast, covering every related keyword. That model is getting harder to sustain. Google is increasingly good at telling the difference between a site where someone clearly knows their subject and a site that's just covering ground. The One Thing Worth Doing Right Now Pull up your top ten pages in Google Search Console and ask yourself honestly whether each one fully answers the question a person would have when they land on it. Not whether it mentions the keyword. Whether it actually helps. If the answer is no, that's the work. Rewrite the page so it does. Add the specific detail that's missing. Cut the padding that's there for length rather than value. This is slow, unglamorous work. It takes more time than adjusting a meta title. But it's what actually moves things after a core update, because it addresses the right problem. What's Not Worth Worrying About Chasing the exact date of a future update is a waste of time. Google doesn't publish a schedule, and even when it confirms an update has rolled out, it rarely tells you what the specific changes were. The sites that hold their ground through core updates tend to be the ones that weren't optimising for the update in the first place. They were just doing the basics properly. Page speed is worth keeping in good shape regardless, not because it's a core update factor specifically, but because a slow site compounds every other problem. If your Core Web Vitals are already weak, fixing those is a reasonable background priority. The practical fixes for Core Web Vitals are well-documented and most don't require a rebuild. The sites that struggle after core updates are nearly always the ones that were already on shaky ground. Fix the content. The rest tends to follow. ------------------------------------------------------------ # Page Speed Fixes That Actually Move Core Web Vitals Source: https://yorkshiredesign.co.uk/page-speed-fixes-that-actually-move-core-web-vitals/ Published: 2026-07-16 > A low PageSpeed Insights score does not mean your site is broken. It means the tool has found something worth looking at. Most site owners either panic and chase a perfect 100, or ignore the score entirely. Neither is quite right. The fixes that genuinely improve how fast a page feels to a real visitor are usually a short list, and most of them are straightforward once you stop optimising for the number and start looking at what is actually slowing the page down. The Myth: A Low PageSpeed Score Means Your Site Is Broken PageSpeed Insights is a diagnostic tool. Think of it like a car mechanic's fault reader. It tells you what to investigate, not whether the car is roadworthy. Plenty of sites score 65 on desktop and load perfectly well for real users. Plenty of sites score 95 and still feel sluggish on a mobile connection. Chasing 100 often costs more than it gains. Some of the last few points require trade-offs that break functionality or strip features your visitors actually use. A score in the 70s or 80s, with solid LCP and CLS numbers, will serve most small business sites far better than a pristine score built on compromises. Your Server Is Probably the Biggest Problem Nobody Fixes Time to First Byte, or TTFB, is how long it takes your server to respond when someone requests your page. Before the browser can paint a single pixel, it has to wait for that response. A slow server adds latency to everything that follows, including your Largest Contentful Paint score. Most site owners never look at TTFB. They install a caching plugin, notice the score improves slightly, and assume the job is done. But if the server itself is underpowered or overloaded, caching only masks the problem. A shared hosting plan at the cheaper end of the market often produces TTFB readings above 600 milliseconds. A decent managed WordPress host or a VPS with proper configuration can bring that under 200ms. That single change can shift your LCP more than any plugin. If you want to understand why server response time sits at the root of most speed problems, the detail on TTFB and what actually causes it is worth working through. Images Are Still the Most Common Culprit Unoptimised images are responsible for more slow LCP scores than almost anything else. A 2MB hero image uploaded straight from a camera, displayed at 400px wide, adds unnecessary weight every time the page loads. The browser downloads the full file regardless of how it is displayed. Converting images to WebP format typically cuts file size by 25 to 35 percent compared to JPEG, with no visible quality loss. Beyond format, using the srcset attribute lets the browser pick the right image size for the device it is running on. And lazy loading, applied to images below the fold, means the browser only fetches what the visitor is about to see. The one exception, never lazy load the main hero image. That is usually the LCP element, and lazy loading it actively delays the score. Render-Blocking Resources: What They Are and Why They Stall Everything When a browser loads a page, it reads the HTML from top to bottom. If it hits a CSS or JavaScript file before the main content, it stops and waits for that file to finish loading before it continues. That pause is called render-blocking, and it directly delays how quickly the page becomes visible. The fix is to defer non-critical JavaScript so it loads after the page content, and to inline only the CSS needed for what appears above the fold. Some performance plugins claim to handle this automatically. Some do it well. Others move the problem rather than solve it, shifting layout shift or breaking functionality instead. It is worth testing any automated deferral against real browser behaviour, not just the PageSpeed score. For a broader look at which WordPress-specific fixes genuinely hold up, there is more detail there. Third-Party Scripts Are Quietly Wrecking Your Score Chat widgets. Analytics. External font libraries. Marketing pixels. Each one adds an extra network request to an outside server you have no control over. If that server is slow, your page waits. If it is down, your page can stall entirely. Auditing third-party scripts is one of the most honest things you can do for your site's speed. Ask whether each one is genuinely earning its place. A live chat widget that gets used twice a month is not worth 400 milliseconds on every page load. Google Fonts loaded from an external URL can be self-hosted instead, removing that round trip entirely. The ones you keep should be loaded asynchronously wherever possible. CLS Fixes Are Simpler Than People Expect Cumulative Layout Shift measures how much the page jumps around while it loads. The two most common causes are images without defined width and height attributes, and fonts that load late and cause text to reflow. Setting explicit dimensions on every image takes minutes and prevents the browser from having to guess how much space to reserve. For fonts, using font-display, swap and preloading the font file stops text from shifting once the custom typeface arrives. Neither fix is complicated. Most CLS problems come from a handful of specific elements, and once you know which ones, correcting them is mostly methodical work rather than anything especially technical. The Fixes That Look Good on Paper But Change Very Little Minification, the process of stripping whitespace and comments from CSS and JavaScript files, is often the first thing people turn on. It helps marginally. On most sites, the file size reduction is small enough that the real-world impact is negligible. Database cleanup plugins get talked about as though they improve speed significantly. For most WordPress sites, they do not. The database query time saved by removing old post revisions is usually measured in single-digit milliseconds. Caching plugins are genuinely useful, but they are often treated as a substitute for fixing the underlying problem rather than a complement to it. If your server is slow, your images are oversized and your third-party scripts are unaudited, a caching plugin papers over all three. It is worth being clear-eyed about that. Related: Image Optimisation WordPress: File Size, Format and Lazy Load ------------------------------------------------------------ # SEO Engine Optimisation: What It Actually Involves Source: https://yorkshiredesign.co.uk/seo-engine-optimisation-what-it-actually-involves/ Published: 2026-07-16 > Most people know SEO matters. Far fewer understand what it actually involves once you get past the surface. It is not just adding keywords to a page. There is a good deal of technical groundwork that never gets seen but makes the difference between a site that ranks and one that sits quietly at page four. This piece covers what SEO engine optimisation genuinely requires, what takes the most time, and where most sites are letting themselves down without realising it. The Work That Happens Before Any Page Gets Written Good SEO starts long before a word of content appears. The technical foundation has to be solid. That means checking how search engines crawl the site, whether pages are being indexed correctly, and whether there are any signals that tell Google to ignore certain URLs entirely. A blocked robots.txt file, a poorly set canonical tag, or a page marked noindex by accident can quietly undo weeks of content work. These are not exotic edge cases. They come up regularly on sites that have been live for years. Core Web Vitals also sit in this category. Google measures how fast pages load, how stable the layout is, and how quickly a page responds to the first user interaction. A slow, unstable page puts a ceiling on how well it can rank, no matter how well written it is. Keyword Research Done Properly Keyword research is not about finding the biggest search volume and chasing it. That approach wastes time. The more useful question is whether a search term reflects genuine intent and whether the site actually has a chance of ranking for it. A local or specialist business rarely wins against an established national brand on a broad term. However, longer, more specific phrases often convert better anyway because the person searching them knows exactly what they want. Finding those terms, understanding the intent behind them, and mapping them to the right pages is where the real work is. It also pays to look at what pages already have some ranking traction and build from there, rather than starting from scratch every time. On-Page SEO: More Than Just the Title Tag Title tags and meta descriptions matter, but they are the most visible part of a much larger picture. On-page SEO also covers heading structure, internal linking, how images are labelled, page load speed, and whether the content actually answers what the searcher came to find. Google's own helpful content guidance is plain on this point, pages written for people, not search engines, perform better over time. Thin pages stuffed with repeated phrases have been deprioritised for years now. Internal linking is one area most sites underuse. Connecting related pages properly helps search engines understand site structure and spreads authority to pages that need it. Done well, it also keeps visitors on the site longer because the next relevant page is right there when they need it. If you want a clearer picture of what that process genuinely demands, it is worth reading through the detail. What Most People Underestimate: The Time Factor SEO does not produce overnight results. That is not a caveat or an excuse. It is how the process works. Search engines re-crawl sites on their own schedule, not yours. New content can take weeks to be properly indexed. Even after indexing, it takes time for a page to build enough signals to move up the rankings. Competitive terms take longer. Less contested niches move faster. But neither happens in days. The sites that do well over time are the ones that stay consistent. Regular updates, fixing technical issues as they appear, adding content that genuinely covers a topic properly. There is no shortcut that holds up. The tactics that produce a quick spike tend to attract a penalty shortly after. Where SEO and Web Design Meet A page cannot rank well if the site it lives on is technically poor. Slow load times, broken mobile layouts, excessive JavaScript blocking the page render, and missing schema markup all pull in the wrong direction. This is where SEO and web design genuinely overlap rather than sit in separate boxes. A clean, fast site built with search visibility in mind from the start is much easier to optimise than one bolted together quickly and handed to an SEO consultant to fix later. Understanding how the time investment maps to real outcomes helps set realistic expectations from the start. The Honest Trade-Off SEO is not free. Even if you do it yourself, it costs time, and that time has a value. Paying someone to do it properly costs money, but done badly it costs more because you end up paying twice to fix it. The honest position is this: SEO engine optimisation done thoroughly, on a site with a solid technical base, produces durable results. It does not produce them quickly. Businesses that understand that and commit to the process tend to see it pay off. Those chasing fast results usually end up starting over. Get an honest SEO assessment ------------------------------------------------------------ # What Is Google Search Console and What Does It Actually Do Source: https://yorkshiredesign.co.uk/what-is-google-search-console-and-what-does-it-actually-do/ Published: 2026-07-16 > Most people assume Google Search Console is some kind of ranking tool. It isn't. It doesn't tell you what position you'll be in next week, and it won't push you up the results by itself. What it does is show you exactly how Google sees your site right now, what it can crawl, what it can't, and which pages are actually showing up in search. That information is genuinely useful. But only if you know what you're looking at. The Myth: Search Console Improves Your Rankings People set it up and then wait for traffic to go up. That's not how it works. Search Console is a diagnostic tool, not a ranking system. It gives you data. What you do with that data is what moves the needle. Think of it like a car's dashboard. The dashboard doesn't make the engine run better, but without it you wouldn't know the engine was overheating until it was too late. What It Actually Tells You At its core, Search Console answers four questions about your site. Which pages has Google indexed? Which search queries are bringing people to your site? Are there any crawl errors stopping Google from reading your pages? And is your site performing well enough on mobile to meet Google's standards? The Performance report is where most of the useful data lives. It shows impressions (how many times your pages appeared in search results), clicks, average position, and click-through rate. You can filter by page, by query, by device, and by country. That combination tells you a lot about where your content is being seen and where it's being ignored. The Coverage report is equally important, though less glamorous. It lists every URL Google has tried to crawl and what happened. Pages marked as 'excluded' or 'error' need attention. A page that isn't indexed simply won't appear in search, no matter how good the content is. The Mistake: Ignoring the Coverage Report Most small business owners glance at the Performance tab, feel reassured by the graph, and close the tab. The Coverage report gets skipped entirely. That's a real problem. If Google can't access a page because of a redirect loop, a noindex tag left on by accident, or a server error, it won't show up in search. You could spend months improving content on a page that Google has quietly decided not to index. The Coverage report is the first place to check when traffic drops without any obvious reason. For a practical walkthrough of the setup process, the step-by-step guide to connecting your site covers property verification and getting your sitemap submitted correctly. What Search Console Won't Tell You It won't show you competitor data. It won't predict future rankings. And it only shows data from Google, so if a significant portion of your audience uses Bing, you'll need Bing Webmaster Tools separately. The position data is also an average, which can mislead. A page showing an average position of 8 might rank third for one query and 40th for another. Averages flatten the detail. Always look at individual queries rather than relying on a single headline number. One more thing worth knowing: Search Console data has a delay of around two to three days. What you're seeing is never fully live. Refreshing it every hour won't help. Core Web Vitals: The Report People Underestimate Google added Core Web Vitals data to Search Console a few years ago and it remains one of the most underused sections. It shows how real users experience your pages in terms of loading speed, visual stability, and how quickly the page responds to interaction. Pages flagged as 'Poor' in this report are likely losing rankings to faster competitors. Google uses these signals as part of its ranking criteria, and the data here is based on real Chrome user data, not a lab test. That makes it meaningful. If your site is on WordPress and you're seeing poor scores, the impact of Google Fonts on load time is one of the quicker things to address, and Search Console will show you whether the fix has registered with real users over the following weeks. How Often Should You Check It Once a week is enough for most small sites. You're not looking for daily fluctuations. You're looking for trends, pages gaining or losing impressions, new crawl errors appearing, Core Web Vitals shifting. Set up email alerts for critical issues. Search Console will notify you if it detects a manual penalty, a significant indexing problem, or a security issue. Those alerts matter. The rest of the time, a weekly check is more than sufficient. SEO is a slower process than most people expect. Understanding what actually takes time in search optimisation helps you read Search Console data with the right expectations rather than panicking at normal week-to-week variation. The One Thing Worth Doing Today Submit your sitemap if you haven't already. Go to Sitemaps in the left menu, enter your sitemap URL (usually yoursite.com/sitemap.xml for WordPress), and hit submit. This doesn't guarantee indexing, but it tells Google exactly which pages you want crawled. It's a small step, but it's concrete, and it's free. Get a free SEO review of your site ------------------------------------------------------------ # NitroPack Review: What It Actually Does and Is It Worth It Source: https://yorkshiredesign.co.uk/nitropack-review-what-it-actually-does-and-is-it-worth-it/ Published: 2026-07-16 > NitroPack gets recommended a lot. It shows up in WordPress speed groups, it scores well in demos, and the sales pitch is simple, install it, watch your PageSpeed score climb. That much is often true. But a higher score in a test tool does not always mean a faster, better experience for real visitors. This review looks at what NitroPack actually does under the hood, where it genuinely helps, and where you should think twice before relying on it. What NitroPack Is, in Plain Terms NitroPack is a performance plugin for WordPress. It connects your site to an external service that handles caching, image compression, code minification, and a content delivery network (CDN) all in one. Instead of installing five separate plugins to cover those jobs, NitroPack bundles them together. That convenience is the main appeal. For a site owner who wants better speed without digging into technical settings, it removes a lot of decisions. You install it, pick a configuration level, and it starts rewriting and caching your pages automatically. What It Actually Changes on Your Site NitroPack does a significant amount of work that most people never see. It minifies and combines your CSS and JavaScript files, which reduces the number of requests a browser has to make. It converts images to WebP format where supported, defers scripts that are not needed immediately, and serves a cached version of each page rather than generating it fresh on every visit. The CDN piece means your site's files are served from a server geographically closer to the visitor. Someone in Australia loading a site hosted in the UK sees a meaningful improvement from that alone. You can read more about what NitroPack does to a WordPress site technically if you want the deeper breakdown. The result, in most cases, is a noticeably higher Google PageSpeed score. That is real. The question is whether it translates to a genuinely better site. Where It Works Well For straightforward WordPress sites, particularly blogs, brochure sites, and small WooCommerce shops with standard themes, NitroPack tends to do exactly what it promises. Page load times drop. Core Web Vitals scores improve. Google's Lighthouse tool returns better numbers across the board. If your site currently scores in the 30s or 40s on PageSpeed and has no specific technical issues, NitroPack can push that into the 80s or 90s without you touching a line of code. For many small-business owners, that matters because Google uses page speed as part of how it evaluates sites for ranking. The Real Trade-Offs This is where most NitroPack reviews get quiet. There are genuine drawbacks worth knowing about before you commit. First, it is a paid service. The free tier covers very low traffic volumes. Once your site gets any real usage, you are paying monthly, and the pricing scales with traffic. That is not a criticism, just a fact to factor in. Second, NitroPack works by rewriting your pages and serving them through its own infrastructure. That means your site becomes dependent on an external service. If NitroPack has an outage, your site performance suffers. That dependency is worth thinking about. Third, on heavily customised WordPress builds, it can cause layout or functionality issues. Advanced animations, certain page builders, and custom JavaScript can break when scripts are deferred or combined aggressively. Testing thoroughly after installation is not optional. How It Compares to Doing It Manually A well-configured setup using separate tools, proper caching, a standalone CDN, and careful image handling can outperform NitroPack. But that takes time to set up and knowledge to maintain. NitroPack trades some of that ceiling for convenience and consistency. For a site owner without technical support, that trade is usually the right one. For a developer who wants precise control over how a site loads, it can feel limiting. Nine times out of ten the limiting factor is not the tool, it is whether the work gets done at all. NitroPack at least makes sure it does. If you want to see how Core Web Vitals fit into the broader picture, the Core Web Vitals fixes that actually work post covers the underlying metrics NitroPack is trying to improve. Is It Worth Installing For most WordPress sites that are not already well-optimised, yes. It does real work, it does it automatically, and the results are visible in the metrics that search engines and visitors both notice. Go in with sensible expectations. Test it on a staging copy first if your site has any complexity. Check that nothing breaks. And remember that even with NitroPack running, a slow server or a bloated theme will hold your scores back. The plugin can only do so much if the foundations are shaky. Your hosting setup matters more than most people expect before any optimisation tool can do its best work. Get a free site speed review Related: NitroPack Reviewed: What It Does Well and Where It Falls Short ------------------------------------------------------------ # What AI Automation Actually Does Inside a WordPress Website Source: https://yorkshiredesign.co.uk/what-ai-automation-actually-does-inside-a-wordpress-website/ Published: 2026-07-16 > Most talk about AI automation stays vague. 'It saves time.' 'It does the work for you.' That's not useful. What matters is what it actually touches inside a WordPress site, what it hands off, what it still can't do without a human, and whether it's worth the setup. This is the practical version of that conversation. What 'Automation' Inside WordPress Actually Means Automation is not a feature you switch on. It is a set of instructions that run quietly in the background whenever something specific happens. At its most basic, WordPress automation follows a simple logic. A trigger fires, a condition is checked, and an action runs. Someone submits a contact form and, rather than that data sitting in a database waiting for a human to deal with it, a workflow picks it up, routes it to a CRM, sends a personalised reply, and tags the lead, all without anyone touching a keyboard. Where AI enters the picture is in the parts that used to need a human decision. Categorising a support ticket, writing a first draft from a product data feed, generating image alt text from surrounding copy, pulling structured data from an unstructured customer message. These are judgement calls that rule-based automation could never handle cleanly. AI handles them at scale, inside the same WordPress environment your site already runs on, connected through APIs and plugin hooks rather than anything exotic. One thing worth being clear about. AI automation does not mean the site runs itself. It means the repetitive, low-judgement work gets handled without manual input, so attention goes where it actually counts. The more these workflows speed up content and data tasks, the more obvious it becomes how much time was being lost to work that should never have needed a person in the first place. The Tasks It Handles Well Content scheduling is where WordPress AI automation earns its keep fastest. Instead of manually setting publish dates, chasing authors for copy, and remembering to post across channels, a properly configured automation pipeline picks up a finished draft, checks it against a predefined ruleset, and queues it without anyone touching a button. Image alt-text generation is another genuine time-saver. Every image uploaded through the media library gets a descriptive alt attribute written automatically, based on the filename and surrounding page context. That matters both for accessibility and for how search engines read the page. Form submissions are a good example of the kind of repetitive routing that quietly eats an hour a week. When a contact form fires, the automation moves the lead into the CRM, tags it by service type, and sends a confirmation email, all without anyone logging in to copy and paste. SEO meta drafting works similarly. The automation pulls the page title, reads the first paragraph, and generates a draft meta description that a human can approve or tweak in thirty seconds rather than write from scratch. These are not glamorous wins. They are the kind of repetitive tasks that stack up across a working week and disappear quietly once the system is in place. The honest caveat is that setup takes real time upfront. The hours come back later, not straight away. Where It Falls Short Automated content generation is the obvious one to watch. AI tools connected to WordPress can draft product descriptions, meta tags, and category copy at speed, but the output is often technically correct and editorially flat at the same time. It repeats itself across pages. It misses nuance that only comes from actually knowing the business. Run an AI content workflow without a proper review pass and you can end up with a site full of text that reads like it was written by someone who has never spoken to a customer. That is not a hypothetical. It is a pattern that shows up regularly when automation is treated as a replacement rather than a first draft. The distinction between drafting and publishing is where most people trip up. Schema markup and structured data are another weak point. AI can generate the JSON, but it cannot always tell whether that schema suits the page type or whether it conflicts with something already in the theme. The bigger limitation is context. AI automation has no feel for what makes a particular client's voice different from their competitor three streets away. It cannot weigh up whether a page should be longer or shorter based on what the search results page actually looks like. It does not know when something is factually wrong about a specific product or service. These are judgement calls, and judgement still sits with a person. Automation handles repeatable work well. The parts that require reading a situation accurately still need a human looking at them. The Setup Work People Underestimate Getting WordPress AI automation to actually work the way you want takes considerably more time than most people expect. The install itself is the easy part. What follows is a back-and-forth process of configuring triggers, mapping outputs to the right fields, testing each workflow under real conditions, and catching the edge cases that only appear once live content starts flowing through. A tool that generates and schedules posts needs to know how your categories are structured, what your image library looks like, how your SEO fields are wired up, and what happens when a post fails to publish. None of that is guesswork. It is methodical, patient configuration work that takes genuine hours to get right. The gap between 'installed' and 'reliable' is wide, and it does not close by itself. Ongoing maintenance is the part nobody mentions in the demos. APIs change, plugins update, and a workflow that ran cleanly for three months can quietly break without any warning. This is not a reason to avoid automation. It is just worth knowing upfront. The payoff is real, but it comes after the groundwork is done properly, not before. Core Web Vitals and the Hidden Performance Risk AI plugins add weight. That is the plain truth most people discover after the site goes live, not before. Every automation layer you bolt onto WordPress has to load something. A script, an API call, a widget that initialises on the front end. A chat assistant that polls an external API on every page load, a personalisation engine that fires JavaScript before the page is ready, a recommendation block that delays the largest element from rendering. These are the things that quietly push your Largest Contentful Paint past the threshold Google considers acceptable. The fixes that move Core Web Vitals scores are often small and technical, but an AI plugin undoes several of them at once if it is not configured carefully. Interaction to Next Paint is particularly at risk because most AI widgets attach event listeners the moment the DOM is ready, competing directly with everything else the browser is trying to do. Before adding any automation layer, check where your current scores sit using PageSpeed Insights and run a waterfall test in GTmetrix to see what is actually blocking render. Then add the plugin to a staging environment first and run the same tests again. If LCP climbs by more than roughly 200 milliseconds, or if Total Blocking Time spikes, the plugin needs to load asynchronously or defer its API calls until after the page is interactive. Performance is not the reason to avoid AI automation, but it is absolutely a reason to test before you commit. What to Check Before You Add Any AI Layer Before anything else, look at your hosting. Shared hosting that is already straining under a standard WordPress install will not cope well with AI-driven processes running on top of it. Check your server response time in Google Search Console or run a quick test in PageSpeed Insights. If you are regularly sitting above 600ms before the page even starts loading, sort that first. AI automation adds requests, it does not reduce them, and a slow foundation just means slow automation. The same applies to your database. Bloated post revisions, orphaned metadata, and tables that have not been cleaned in years will drag on any tool that queries them repeatedly. Next, think honestly about your workflow. Write down the specific tasks you want to automate and how often they actually happen. If the answer is 'a few times a month', the overhead of setting up and maintaining an automation layer probably is not worth it yet. As a rough guide, automation earns its place when a task happens at least weekly and takes more than a few minutes each time. Also worth checking is whether your theme and plugins are up to date and conflict-free. Automation tools that hook into the deeper technical layers of WordPress will surface problems that were quietly sitting there already. Get in touch ------------------------------------------------------------ # Cumulative Layout Shift: 8 Fixes That Actually Work Source: https://yorkshiredesign.co.uk/cumulative-layout-shift-8-fixes-that-actually-work/ Published: 2026-07-16 > Cumulative layout shift is what happens when a page rearranges itself while you're reading it. A button moves. An image pushes the text down. You tap the wrong link. It's one of Google's three Core Web Vitals, and a poor score does real damage, both to how the site feels and where it ranks. Most of the causes are fixable. They just take a bit of digging to find. 1. Set Width and Height on Every Image This is the most common cause of a bad CLS score. When a browser loads a page and encounters an image with no declared dimensions, it has no idea how much space to reserve. So it collapses the space to nothing, loads the content around it, then shunts everything down when the image finally arrives. The fix is straightforward. Add width and height attributes to every <img> tag in your HTML. WordPress now does this automatically for images inserted through the block editor, but older themes and custom code often miss it. Check your image handling in WordPress if you're unsure whether your setup is covering this properly. 2. Reserve Space for Ads and Embeds Adverts are one of the worst offenders. They load late, they vary in size, and they push content around without warning. The same goes for embedded videos, third-party widgets, and social media blocks. Give these elements a fixed container. Set a minimum height on the wrapper div so the space exists before the content loads. It won't look perfect every time, but it stops the page lurching around for the person reading it. 3. Preload Your Key Fonts When a custom font loads late, the browser substitutes a fallback font first. Then, once the real font arrives, it swaps it in. If the two fonts are different sizes, everything on the page shifts. Preloading the font tells the browser to fetch it early, before it's needed. Add a <link rel="preload"> tag in the <head> of your page for any font files the design depends on. It's a small change that removes a surprisingly common source of layout shift. 4. Use font-display, swap Carefully There's a trade-off here worth being honest about. font-display, swap is widely recommended because it stops invisible text while fonts load. But it can actually increase cumulative layout shift if the fallback font and the web font render at very different sizes. The better approach is to also use size-adjust, ascent-override, and descent-override on your fallback font face. These CSS descriptors let you make the fallback closer in size to the real font, so the swap causes less movement. It's fiddly, but it's the proper fix. 5. Avoid Inserting Content Above Existing Content Cookie banners, notification bars, and pop-ups that load after the page renders are a straightforward cause of layout shift. If something appears above the fold and pushes everything else down, that registers as CLS. Either render these elements server-side so they exist from the first paint, or position them as overlays that don't affect document flow. A banner that slides in from the bottom causes far less shift than one that pushes the header down. 6. Watch Out for Animations That Affect Layout CSS animations are fine when they use properties like transform and opacity. These run on the GPU and don't trigger a layout recalculation. The problem comes when animations change width, height, top, left, or margin. Those properties force the browser to recalculate the whole layout, and that shows up as shift. Go through any entrance animations or hover effects on the site. If they're moving elements by changing positional properties rather than using transform, translate(), they're costing you CLS. 7. Test With Real Field Data, Not Just Lab Tools PageSpeed Insights gives you a lab score, which is useful. But Google measures CLS using real user data collected in Chrome, published through the Chrome UX Report. The two scores can look quite different. A page might score well in the lab because the test loads everything instantly on a fast connection. Real users on slower devices, with ad blockers off and third-party scripts firing, often see much worse shift. If your Search Console is showing a CLS issue that your lab score doesn't reflect, trust the field data. That's what Google is actually using to rank the page. 8. Check Lazy-Loaded Images Below the Fold Lazy loading is good practice. But if it's applied to images that are close to the viewport on mobile, the browser may load the page, begin rendering visible content, and then shift things around as those near-viewport images arrive. The practical Core Web Vitals fixes for this involve adjusting the lazy-load threshold so images a little further down the page are fetched sooner, before they enter the viewport. It's worth auditing which images on each page template actually need lazy loading and which are close enough to the fold that eager loading makes more sense. Get a free CLS audit Related: Core Web Vitals Explained: LCP, INP and CLS for Rankings Related: Page Speed Fixes That Actually Move Core Web Vitals ------------------------------------------------------------ # NitroPack Reviewed: What It Does Well and Where It Falls Short Source: https://yorkshiredesign.co.uk/nitropack-reviewed-what-it-does-well-and-where-it-falls-short/ Published: 2026-07-16 > NitroPack is one of the most talked-about speed plugins for WordPress, and for good reason. It bundles caching, image optimisation, code minification and a CDN into one place. That sounds appealing, especially if you'd rather not spend hours configuring separate plugins. But a tool this opinionated about your site needs looking at honestly. Here's what it actually does, where it earns its reputation, and where it quietly creates problems you might not spot straight away. What NitroPack Actually Does NitroPack sits between your WordPress site and your visitors. It takes your pages, processes them through its cloud servers, and serves a heavily optimised version back. That processing includes HTML, CSS and JavaScript minification, image compression and conversion to next-gen formats like WebP, lazy loading, and a global CDN to deliver files from a server closer to the visitor. It also handles Critical CSS generation automatically. This is the bit that most manual setups get wrong. NitroPack generates a stripped-down version of your CSS that loads only what the browser needs to paint the visible screen, then defers the rest. Done properly, this alone can move your Largest Contentful Paint score noticeably. The appeal is obvious. One plugin, one dashboard, most of the heavy lifting handled for you. Where It Performs Well On a standard WordPress site with a typical theme and a handful of plugins, NitroPack tends to produce real, measurable improvements in PageSpeed Insights scores. The automated Critical CSS is the strongest part. It removes a fiddly manual job that many developers skip entirely, and it generally gets it right without breaking the layout. Image handling is solid too. Auto-converting images to WebP and applying lazy loading are things every WordPress site should do. NitroPack does them without you needing to think about it. For site owners who genuinely do not want to touch caching configuration, it removes a real barrier. Configuring WP Rocket or a server-level cache correctly takes time and some technical understanding. NitroPack compresses that into a mode selector. Where It Falls Short The cloud processing model is also NitroPack's biggest weakness. Your pages are sent off-site for optimisation before they reach the visitor. On a busy site, or during a cache warming period after a purge, response times can creep up. You are also dependent on NitroPack's own infrastructure staying fast and available. JavaScript optimisation causes the most support headaches. NitroPack is aggressive about deferring and delaying scripts. On a clean site, that is fine. On a site with form plugins, booking systems, WooCommerce checkout logic or anything interactive, deferred scripts frequently break things. Buttons stop working. Forms fail silently. The fix usually involves exempting those scripts from optimisation, which takes you back into configuration territory most people bought NitroPack to avoid. There is also the matter of cost. NitroPack's pricing scales with monthly page views. At low traffic it is affordable. As a site grows, the monthly bill grows with it. At that point it is worth asking whether a well-configured server-level caching setup and a dedicated image optimisation plugin would give you similar results at a fraction of the price. The Honest Trade-Off on Scores vs Real-World Speed NitroPack is very good at improving lab scores. Google's PageSpeed Insights, GTmetrix, scores like that. Whether those improvements translate equally into real visitor experience is a different question. Lab scores are synthetic tests. They measure what a single simulated user sees under controlled conditions. Real-world performance depends on your server, your hosting, your database and dozens of other factors NitroPack does not touch. A site on slow shared hosting with a bloated database will still feel slow to visitors, even with a green score. Nine times out of ten, the sites that see the biggest real-world gains from NitroPack are already on decent hosting. The plugin then makes a good foundation better. It rarely rescues a fundamentally poorly set up site on its own, and it is worth being clear-eyed about that before signing up. If you suspect your hosting is the bottleneck, it is worth reading up on what managed hosting actually changes before investing in a speed plugin. Who Should Use It and Who Probably Should Not NitroPack suits a WordPress site owner who wants meaningful speed improvements without getting into the technical detail, and whose site is relatively straightforward. Blogs, brochure sites, simple portfolio pages. Those see consistent, reliable gains. It is harder to recommend for complex WooCommerce stores, membership sites or anything with a lot of dynamic content and custom scripts. The risk of something breaking during a JavaScript deferral conflict is real, and troubleshooting it is not always simple. If your theme is already lightweight and well-built, you may also find that a smaller, targeted set of plugins gets you most of the same result without the monthly subscription or the cloud dependency. The Bottom Line NitroPack works. On the right site, it saves time and moves the score. The automated Critical CSS alone justifies a look, because getting that right manually is genuinely fiddly. But it is not a fix-all, and it is not free. Know what your site actually needs before committing. Speed problems on WordPress usually have a root cause, and finding it takes a bit of digging before any plugin can really help. Related: NitroPack Review: What It Actually Does and Is It Worth It ------------------------------------------------------------ # 7 Core Web Vitals WordPress Fixes That Actually Work Source: https://yorkshiredesign.co.uk/7-core-web-vitals-wordpress-fixes-that-actually-work/ Published: 2026-07-15 > Core Web Vitals failures on WordPress sites almost always come down to the same handful of problems. Heavy images, missing dimensions, scripts that block rendering before anything appears on screen. The fixes are not complicated, but they do need to be done properly, in the right order. This checklist covers the six that move the needle most consistently, based on what we see when auditing sites that are failing their vitals. 1. Switch your images to WebP JPEG and PNG are still the default on most WordPress installs, and both formats carry far more weight than necessary. WebP typically cuts file size by 25 to 35 per cent with no visible drop in quality. WordPress has supported native WebP uploads since version 5.8, so there is no technical barrier to making the switch. If uploads are still arriving as JPEG, a plugin like Imagify or ShortPixel will convert them automatically on upload. Oversized images are one of the most consistent causes of a poor Largest Contentful Paint score, and this is almost always the right place to start. 2. Add width and height to every image Cumulative Layout Shift happens when the browser does not know how much space to reserve for an image before it loads. Without declared dimensions, the page reflows mid-load and content jumps down the screen as images arrive. That reflow is exactly what CLS measures. WordPress adds width and height automatically for images inserted through the media library. The problem usually comes from images added via a page builder, a custom HTML block, or hardcoded into a theme template. Check those manually. It takes around ten minutes, and the CLS improvement tends to show up immediately. 3. Defer render-blocking scripts Every JavaScript file that loads in the <head> without a defer or async attribute stalls the browser before it can paint anything visible. On some themes, six or seven of these are queued before the first pixel appears. Audit what is actually loading and defer anything that does not need to run before the page displays. Most contact form scripts, analytics tags, and slider libraries can be deferred safely. It is unglamorous work. It is also one of the highest-impact changes you can make for both LCP and INP scores. One honest caveat, deferring the wrong script can break functionality. Test after every single change, not just once at the end. 4. Start with a lightweight theme Themes carry a lot of hidden weight. A popular commercial theme can load dozens of CSS files, register several JavaScript libraries, and pull in font packages you never asked for. All of it runs whether or not you use those features. Themes like GeneratePress or Kadence are built lean by default. Switching mid-project is not always practical, but if you are starting fresh or rebuilding, the theme is the single decision that shapes every performance choice that follows. A bloated base is genuinely hard to work around, no matter how much optimisation you layer on top. A common issue we see is a site built on a theme that was originally layered on top of another theme, creating custom post type conflicts and styling overhead that compounds over time. Getting back to a clean foundation is often what actually returns a site to the first page of Google for competitive terms, not one small tweak in isolation. 5. Host your fonts locally Google Fonts served from Google's CDN add a DNS lookup, a connection, and a stylesheet request before any font file arrives. On a fast desktop connection that is barely noticeable. On a slower mobile connection, it shows up clearly in Time to First Byte and LCP. The fix is straightforward. Download the font files, add them to your theme, and serve them from your own server. The visitor sees no difference. The performance difference is measurable. It also removes a third-party dependency that can cause GDPR complications for visitors in the UK and Europe, since the request to Google's servers logs an IP address. 6. Set up proper caching Without caching, WordPress builds every page from scratch on every single request. That means a database query, PHP processing, and a full HTML build each time someone visits. For a site with even modest traffic, that overhead adds up quickly. A caching plugin like WP Rocket or W3 Total Cache stores a pre-built HTML version of each page and serves that instead. The difference in server response time is significant, and it is one of the simpler wins available. If your host offers server-level caching, use that as well. Both together outperforms either on its own. None of this is quick to get right across an entire site. Google's own Core Web Vitals documentation lays out what each metric measures, which helps when you are trying to understand why a fix did or did not move the score. The technical work underneath the surface takes time, but the gains are real and they hold. Related: Image Optimisation WordPress: File Size, Format and Lazy Load Related: Page Speed Fixes That Actually Move Core Web Vitals ------------------------------------------------------------ # Web Hosting Explained: What Actually Matters for Your Site Source: https://yorkshiredesign.co.uk/web-hosting-explained-what-actually-matters-for-your-site/ Published: 2026-07-15 > Most people pick a web host based on price and forget about it. That is understandable. It is not an interesting decision. But the server your site sits on affects how fast pages load, how often the site goes down, and whether Google thinks it is worth ranking. Getting it wrong does not announce itself loudly. It just quietly costs you visitors and enquiries over time. So it is worth spending ten minutes understanding what you are actually buying. What Web Hosting Actually IsYour website is a collection of files. HTML, CSS, images, and probably a database if you run WordPress. Web hosting is simply renting space on a server that stays switched on and connected to the internet around the clock, so those files load whenever someone types your address into a browser.The host is not your domain name. It is not your website builder. It is the server those things live on. Many people confuse the three, particularly when they buy everything from one provider. They are separate things, and they perform very differently depending on who you choose.Shared, VPS and Dedicated: What the Difference Means in PracticeShared hosting puts your site on the same physical machine as hundreds of others. It is cheap because the cost is split between everyone on it. The problem is that if another site on that server gets a traffic spike, yours slows down too. You have no control over your neighbours.A VPS (Virtual Private Server) gives you a partitioned section of a server. You still share the hardware, but your resources are isolated. You get a fixed allocation of RAM and CPU, so another site's traffic does not eat into yours. For most small business websites, a decent VPS is a much cleaner setup than shared hosting.Dedicated hosting means the whole machine is yours. Most small sites do not need it. It costs significantly more, and the performance gain only really matters at serious traffic volumes.Why Server Location Matters for SpeedData travels fast, but distance still adds up. If your customers are in the UK and your server sits in the United States, every page request makes a longer round trip. It might only be a few hundred milliseconds, but those milliseconds feed directly into your Core Web Vitals scores, which Google uses as a ranking signal.Always check where a host's data centres are before committing. For a UK audience, a UK or European server is the sensible choice. Some budget hosts only offer US-based servers by default and bury the location in the small print.Uptime: The Number That Actually MattersHosts advertise uptime percentages. 99.9% sounds reassuring until you do the arithmetic. That figure still allows for roughly eight hours of downtime per year. 99.5% allows for over two days. For an ecommerce site, or any business that takes enquiries online, a few hours offline on a busy day is a real cost.Check whether a host publishes a live status page and whether their service agreement includes compensation for outages. Many do not. A handful of independent reviews on a site like Trustpilot will tell you more about real-world reliability than any marketing page.What Hosting Does to Your SEOGoogle measures page speed as part of its ranking algorithm. Slow server response times push up your Time to First Byte, which is one of the first signals Google sees when it crawls a page. An overloaded server will hold your site back regardless of how well the code is written.There is also the question of IP reputation. On shared hosting, if another site on your IP address has been used for spam or malicious activity, that can affect how search engines treat your domain. It is not common, but it does happen. It is another reason a VPS is worth the extra cost once your business genuinely depends on the site.For a closer look at what affects your scores, the PageSpeed measurement guide covers what Google is actually checking and why some fixes matter more than others.The Honest Trade-Off on PriceVery cheap shared hosting is not worthless. If you are just starting out and the site is a basic brochure with low traffic, a budget host gets you online without overspending. The issue is that people stay on those plans long after their site has outgrown them, because switching hosts feels complicated.It is less complicated than it seems. A decent host will migrate your site for you. The cost difference between a reliable VPS and a cheap shared plan is often less than £10 a month. Weighed against slower load times and the odd outage, that gap closes quickly.If you are unsure whether your current hosting is holding your site back, understanding what small UK businesses should actually look for in a host is a good place to start.One Thing Most People OverlookBackups. A surprising number of hosts either do not include them or store them on the same server as your live site. If the server fails, the backup goes with it. Always confirm that daily backups exist, that they are stored off-site, and that you can restore from them without waiting two days for support to respond.It is the kind of detail that seems unimportant until the moment you actually need it. Related: Managed WordPress Hosting vs Shared Hosting: Real Numbers ------------------------------------------------------------ # PageSpeed by Google: What It Actually Measures and Why It Matters Source: https://yorkshiredesign.co.uk/pagespeed-by-google-what-it-actually-measures-and-why-it-matters/ Published: 2026-07-15 > Most people run PageSpeed by Google once, glance at the score, and feel either relieved or confused. The number itself tells you almost nothing useful. What matters is what sits underneath it, the specific signals Google is actually measuring, why they affect your rankings and your visitors, and which ones are worth fixing first. This is a plain-English look at what the tool does and what to take seriously. The score is a summary, not the point Google's PageSpeed Insights gives you a number out of 100. It feels definitive. It isn't. The score is a weighted average of several individual metrics, and a site scoring 72 can outrank one scoring 85 if the right signals are in better shape. Chasing the headline number is the wrong goal. The tool runs two separate tests, one simulated on a mobile connection, one on desktop. The mobile result is almost always lower, and that's the one Google weighs more heavily in search rankings. A site that looks fine on a laptop can still be slow where it matters most. The six metrics it actually tests PageSpeed Insights measures a handful of specific things. Some carry far more weight than others in the final score calculation. Largest Contentful Paint (LCP) , how long before the biggest visible element on the page loads. For most sites that's the hero image or the main heading block. First Contentful Paint (FCP) , the time until any content appears at all. A slow FCP means the visitor stares at a blank screen. Total Blocking Time (TBT) , a lab-measured proxy for how long scripts block the browser from responding to clicks. Heavy Javascript is usually the cause. Cumulative Layout Shift (CLS) , how much the page jumps around as it loads. Images without dimensions, fonts swapping in late, ads loading after text, all of these push the score up. Speed Index , how quickly content becomes visible during load, not just when it technically finishes. Interaction to Next Paint (INP) , a newer addition that measures how quickly the page responds after a user clicks or types something. LCP, CLS and INP are the three Google has designated as Core Web Vitals, meaning they feed directly into search ranking signals. The others matter for user experience, but these three are what Google officially tracks. Lab data versus field data PageSpeed Insights shows two types of data, and most people ignore the difference. Lab data is a simulated test run in controlled conditions. Field data is real-world performance collected from actual Chrome users visiting your site, pulled from the Chrome User Experience Report (CrUX). Field data is what Google uses for ranking. If your site doesn't have enough traffic to generate a CrUX dataset, you'll see no field data at all, and Google falls back on lab data instead. For low-traffic sites, this means the lab result matters more than it usually would. The practical gap between the two can be large. A page might score 90 in lab conditions and show a poor LCP in field data, because real users are on slower connections, older phones, or have browser extensions running. Always read both. What actually slows a page down The tool flags a list of opportunities and diagnostics beneath the score. These are the specific things worth paying attention to. Common culprits include uncompressed images, render-blocking scripts loaded in the wrong order, unused CSS, and third-party embeds like chat widgets or video players that fire requests before the main content has even painted. WordPress sites often struggle here because themes and plugins add their own scripts and stylesheets without much regard for what's already on the page. The more plugins, the more requests, and the heavier the page gets. It compounds quietly over time, and most site owners don't notice until the score has already dropped. If you want to understand what a theme is actually loading, our look at what sits under a WordPress theme covers this in more detail. Why it matters for SEO Google confirmed page experience signals, including Core Web Vitals, as ranking factors. A site with poor LCP and high CLS is not invisible to the algorithm. It's at a disadvantage, particularly in competitive niches where two sites are otherwise similar in quality and authority. The effect is rarely dramatic overnight. SEO changes bed in gradually, and page speed is no different. Fix a slow LCP and you won't jump ten positions the next morning. But across weeks and months, a technically cleaner site accumulates a small but real edge. That compounds. There's also the human side. A page that takes four seconds to show anything loses visitors before they've read a word. No ranking matters if people leave immediately. What not to obsess over A score of 100 is not the target. Most high-performing commercial sites sit in the 60s or 70s on mobile and rank well regardless. The honest trade-off is this, a completely stripped-back site with no images, no interactivity and no third-party tools might score 100 and convert nobody. Real sites have real features, and features cost milliseconds. Focus on the Core Web Vitals thresholds Google actually publishes. LCP under 2.5 seconds. CLS below 0.1. INP under 200 milliseconds. Hit those and you're in good shape. Everything above that is diminishing returns unless you're running a high-traffic site where even small gains add up at scale. ------------------------------------------------------------ # Content Writing for SEO: How Small Businesses Can Rank Without an Agency Source: https://yorkshiredesign.co.uk/content-writing-for-seo-how-small-businesses-can-rank-without-an-agency/ Published: 2026-07-15 > A plumber in Leeds wrote one detailed page about fixing a dripping combi boiler. Nothing fancy. No agency. Just a clear, honest answer to a question his customers kept asking him in person. Six months later, that page was pulling in enquiries from three surrounding towns. He did not have a content budget. He had specific knowledge and the patience to write it down properly. That is what content writing for SEO actually looks like for a small business. Start With What You Know, Not What Sounds Impressive The biggest mistake small businesses make is writing content that sounds like every other site in their sector. Generic, vague, slightly formal. Nobody searches for that, and Google does not reward it either. Write about the problems you actually solve. The questions customers ask on the phone. The thing people get wrong before they call you. You already know this stuff. The job is just getting it onto a page in plain English. A good starting point is to write down five questions you answered last week. Each one of those is a potential page. Not a paragraph tucked inside a bigger article. A page of its own, with a proper answer. One Topic Per Page, Treated Properly Thin pages do not rank. A 200-word page that mentions a keyword twice and then stops is not useful to anyone, and Google knows it. The question is not how many keywords you include. It is whether someone who lands on that page actually gets what they came for. Pick one topic. Cover it properly. Explain the context, give a real example, address the follow-up questions someone would naturally have. That kind of depth is what separates a page that ranks from one that sits at position 47 and never moves. Three solid pages on specific topics will consistently outperform thirty thin ones. It takes longer to write them, but that is the point. Good pages take time. How to Structure a Page That Google Can Follow Structure matters, but not in a complicated way. Use one clear H1 that says what the page is about. Break the content into sections with descriptive H2 headings. Keep paragraphs short. Put the most useful information near the top. Google's own guidance on creating helpful content is blunt about this, write for people first. A page that genuinely helps a reader will tend to perform better than one that is written around a keyword count. One practical check, read your page aloud. If a sentence sounds odd when you say it, it will read odd too. Cut it or rewrite it. Plain sentences that move forward are what you want, not padded paragraphs that circle back on themselves. Keywords Matter, But Not the Way Most People Think You do not need a keyword tool to get started. Type your topic into Google and look at what comes up. Check the questions in the "People also ask" section. Look at what the top results actually cover. That is a free, honest picture of what the search needs. Use the phrase people would actually type, not the professional version. "How much does a new boiler cost" ranks better for that audience than "domestic central heating installation pricing". Match the language your customers use, not the language your industry uses internally. If you want to go deeper on how content strategy connects to what actually moves rankings, the thinking behind what makes a page worth ranking is worth reading alongside this. The Trade-Off Nobody Talks About Writing your own content is cheaper than hiring an agency. It is also slower, and the quality gap is real if writing is not your strong suit. That is worth being honest about. What you have that an agency does not is genuine first-hand knowledge. An agency will research your sector. You have lived it. The best small business content tends to combine both, your knowledge, shaped into a readable page by someone who knows how to structure it for search. If you are writing everything yourself, pick your best two or three topics and do those properly before moving on. Do not spread yourself thin trying to publish every week. One thorough page per month, done well, beats four rushed ones that say nothing new. What to Do When Progress Feels Slow New pages can take months to rank. That is not a fault in your content. It is just how search works. Google needs time to crawl the page, assess it against everything else competing for that topic, and decide where it belongs. The thing that trips people up is expecting fast results and then abandoning a page after six weeks. Most good pages are not rewarded that quickly. The ones that do rank tend to have been left alone long enough to settle. Check Google Search Console to see if the page is being indexed and what queries it is beginning to appear for. That data tells you far more than traffic figures alone, especially in the early months. If you have not set that up yet, the practical setup guide for Search Console covers exactly how to do it. Write the page, give it time, and check the data before changing anything. That is the honest process. There is no shortcut worth taking. ------------------------------------------------------------ # Web Hosting for Small UK Businesses: What Actually Matters Source: https://yorkshiredesign.co.uk/web-hosting-for-small-uk-businesses-what-actually-matters/ Published: 2026-07-15 > Most small business owners pick a hosting plan based on price alone, then wonder why their site runs slowly or goes down at awkward moments. The hosting decision is one of the few things that sits underneath everything else , speed, uptime, security , and it rarely gets the attention it deserves. Here is a plain look at the main options, what they actually mean in practice, and where it is reasonable to spend a bit more. The Three Types You'll Actually Choose Between Shared hosting puts your website on a server alongside hundreds of others. It is cheap, often under a tenner a month, and perfectly fine for a brand-new site with low traffic. The catch is that a busy neighbour on the same server can slow your pages down. You have no control over that. VPS (Virtual Private Server) hosting gives you a slice of a server that is genuinely reserved for you. Performance is more predictable. Costs sit somewhere between shared and dedicated, typically £15 to £60 a month depending on the spec. Managed WordPress hosting is a different shape entirely. The host handles updates, caching, backups and security tuning specifically for WordPress. You pay more, but you spend less time doing housekeeping. For a small business without a technical person on hand, that trade-off is often worth it. Speed: Where Hosting Makes a Real Difference Server response time is what your hosting controls directly. Google's own guidance on Time to First Byte treats anything under 800ms as acceptable. Budget shared hosting can push that past 1.5 seconds before a single image has loaded. That server delay compounds. A slow response plus unoptimised images plus a bloated theme adds up fast. You can fix images and themes, but you cannot fix a slow server from inside WordPress. If your site already has decent Core Web Vitals scores and is still underperforming, the hosting is usually the first place to look. A server sitting in the US when all your visitors are in the UK adds latency that no plugin will fix. UK-based or UK-CDN-backed hosting matters for a UK audience. Uptime: What the Guarantee Actually Means Most hosts advertise 99.9% uptime. That sounds near-perfect. In practice, 99.9% still allows roughly 8 hours of downtime a year. For an e-commerce site taking orders around the clock, that is 8 hours of lost sales. The honest question is not what the SLA says but what the host actually delivers. Check independent monitoring reviews, not testimonials on the host's own site. A host with no public status page should give you pause. What Shared Hosting Is and Is Not Good For A shared plan is a reasonable starting point. If you are building a first website, testing an idea, or running a brochure site that gets a few dozen visitors a day, shared hosting does the job. There is no need to overspend at that stage. Where shared hosting starts to create problems is when traffic grows or when the site runs WooCommerce. Checkout pages, stock queries and account logins put a consistent load on the server. A shared environment handles that unevenly. Moving up to a VPS at that point is not a luxury, it is a practical fix. For anyone serious about building a WordPress site that holds up under real use, our thoughts on what to look for from a web design setup cover how the infrastructure decisions connect to the finished result. Security: The Unglamorous Part Cheap hosting often skips proper server-level malware scanning, firewall rules and daily backups. Those omissions are invisible until something goes wrong. A hacked WordPress site on shared hosting can take a week to clean up properly. If your host does not isolate accounts from each other, one compromised site on the server can affect yours. That is not theoretical, it happens regularly. Managed WordPress hosts tend to be more thorough here because their entire product depends on sites staying clean. It is one of the genuinely good reasons to pay the premium, not just a marketing point. The Trade-Off Most People Miss The real cost of cheap hosting is not the monthly fee. It is the time spent dealing with slow load times, a hacked install, or a support queue when something breaks. A £5-a-month plan sounds efficient. If it costs you three hours sorting a problem that better hosting would have prevented, the maths look different. That is not an argument for the most expensive option, just an honest one for the right one. Speed and stability are also directly tied to how your site performs in search. A site that loads slowly or goes offline regularly will eventually feel that in organic rankings. It is not the only factor, but it is a consistent one. If you are putting effort into tracking your search performance, poor hosting will quietly work against everything else you are doing. A Reasonable Way to Choose New site, low traffic, tight budget. Start on a reputable shared host with UK-based servers. Avoid the very cheapest options with no reputation behind them. Growing site, WooCommerce, or regular traffic above a few hundred visitors a day. Move to VPS or managed WordPress hosting. The jump in cost is small relative to the improvement in reliability. No technical resource in-house. Managed WordPress hosting is worth the extra cost. The time it saves on maintenance and the security baseline it provides are both worth something real. Related: Managed WordPress Hosting vs Shared Hosting: Real Numbers ------------------------------------------------------------ # 7 Reasons SEO Takes Time and What It Actually Involves Source: https://yorkshiredesign.co.uk/7-reasons-seo-takes-time-and-what-it-actually-involves/ Published: 2026-07-15 > Search engine optimisation is the work you do so that Google and Bing decide your pages are worth showing to people. That covers everything from the words on the page to the code underneath it. Most businesses want to know why it takes so long. The honest answer is that there is no shortcut, because search engines are deliberately slow to trust anything new. Here are seven specific reasons why, and what is actually going on at each stage. 1. Google Crawls Pages on Its Own Schedule Before anything else can happen, Google has to find and read your page. That process, called crawling, runs on Google's timeline, not yours. A new page can sit unindexed for days or weeks. A well-established site with strong internal links gets crawled more often, which is one reason older sites can publish and rank faster than newer ones. You can speed this up slightly by submitting a sitemap through Google Search Console, but you cannot force the crawler to come sooner. That waiting period alone accounts for a chunk of the delay most people find frustrating. 2. Indexing and Ranking Are Two Separate Things A lot of people assume that once Google has indexed a page, it will start ranking. Those are two different stages. Indexing means Google has stored a copy of your page. Ranking means Google has decided where that page sits among every other page competing for the same search terms. Working out that position involves hundreds of signals. Content quality, page speed, backlinks, how long people stay on the page, how the site performs on mobile. All of that takes time to assess, and Google revisits those assessments repeatedly as more data comes in. You can read about how Google approaches the full ranking process and what actually moves the dial. 3. Authority Builds Slowly, and That Is Intentional Search engines weight older, more established sites more heavily. That is partly because spammers create new sites constantly, so trust has to be earned over time. A domain that has been around for several years and has accumulated genuine links from other reputable sites will almost always outrank a brand-new competitor on a similar topic, at least initially. Building that kind of authority is not something you can fake or rush. It comes from consistently publishing useful content, earning links from relevant sources, and not cutting corners. The sites that show up on page one for competitive terms have usually been doing that work quietly for a long time. 4. Content Has to Prove Its Value Over Time Publishing a page is just the start. Google watches how people interact with it. Do they click through from search results? Do they stay and read, or do they bounce straight back? Do other sites link to it because they found it genuinely useful? Those behavioural signals accumulate over weeks and months. A page that earns consistent engagement will gradually climb. A page that looks fine on the surface but fails to satisfy the search intent will stall or drop. That feedback loop is one reason the time SEO takes is so hard to compress, no matter how good the initial work is. 5. Technical Issues Quietly Hold Rankings Back This is where a lot of businesses lose ground without realising it. Slow page load times, broken internal links, duplicate content, poor mobile performance, missing structured data. None of these announce themselves loudly. They just cap how far a site can go. Core Web Vitals, the set of speed and stability measures Google uses as a ranking signal, are a good example. A site that passes those thresholds has removed one obstacle. A site that fails them is being held back by something the owner may not even know exists. Fixing technical problems is unglamorous work, but it is often where the biggest gains are hiding. 6. Competition Does Not Stand Still Even if your own SEO is moving in the right direction, your competitors are not waiting. Other sites in your niche are publishing content, earning links, and improving their pages. Rankings are relative. You are not just trying to hit a fixed target, you are competing against everyone else chasing the same terms at the same time. That ongoing competition is one reason SEO is never really finished. Maintaining a position takes continued effort, not just a one-off push. 7. Google's Algorithm Updates Shift the Ground Google updates its ranking algorithm regularly, sometimes with significant changes to what it values. A page that was performing well can slip after an update, not because anything was done wrong, but because the criteria shifted. The reverse is also true, pages that were underperforming sometimes rise after an update rewards factors they already had. These updates are another reason results take time and why a steady, honest approach tends to hold up better than tactics built around gaming a particular signal. Understanding why rankings shift over time makes it easier to stay patient when progress feels slow. The short version is this. SEO works, but it works on the search engine's terms, not yours. The businesses that get the most out of it are the ones that treat it as steady, ongoing work rather than a switch to flick. Related: Google Search Engine Optimisation: What Actually Takes Time ------------------------------------------------------------ # AI Prompt Writing for Business Tasks That Actually Work Source: https://yorkshiredesign.co.uk/ai-prompt-writing-for-business-tasks-that-actually-work/ Published: 2026-07-14 > Most people type a vague question into an AI tool and wonder why the output is generic. The prompt is the problem. AI is only as useful as the instruction you give it, and for business tasks that means being specific about what you need, who it is for, and what good looks like. Once you understand that, the output changes noticeably. This is what that looks like in practice. The Prompt Is the Brief Think of an AI tool the way you would a capable contractor who knows nothing about your business yet. You would not hand them a one-line note and expect a finished product. You would explain the job, the context, and the standard you want. A prompt works the same way. The biggest shift people make when they start getting useful output is treating the prompt like a proper brief. That means stating the task, the audience, the tone, and any constraints up front, not hoping the tool fills in the gaps. What a Useful Prompt Actually Contains A prompt that gets a usable result for a business task will usually include four things. The role you want the AI to take, the task itself, the audience it is writing for, and the format you expect back. For example, instead of asking 'write me a product description', you would say something like: 'You are writing for a UK audience of tradespeople aged 30 to 50. Write a 100-word product description for a cordless drill in plain English. Focus on durability and battery life. No jargon.' That one prompt cuts revision time sharply because the tool is not guessing at half the decisions. Format matters more than people realise. If you want bullet points, say so. If you want a short paragraph with no subheadings, say that too. AI tools default to whatever structure feels average, which is rarely what you actually need. Context Is What Most People Skip Generic output almost always traces back to missing context. The AI does not know your business, your tone, or what you have already published. You have to supply that. Paste in a short style example. Tell it what you do not want. If your brand voice is direct and plain, say 'no marketing language, no superlatives, short sentences'. If you are writing a follow-up email and you want it to feel warm but not salesy, say exactly that. The more context you give, the less editing you do on the other end. This is where AI content writing starts to earn its keep for businesses, not when it replaces thinking, but when it executes the thinking you have already done. What Prompt Writing Is Not Good For Here is the honest part. AI prompt writing does not fix a brief you have not thought through. If you do not know what you want to say, the tool will not figure it out for you. It will produce something that sounds confident but has no real substance behind it. Strategy, editorial judgement, and knowing your own audience are still your job. The tool can handle the drafting once you know the direction. Skipping the thinking and expecting the output to be good is where most businesses waste their time with AI. Iteration Is Part of the Process A single prompt rarely produces a finished result. That is not a failure, it is just how the work goes. The first output tells you what needs adjusting, and you refine from there. Treat it as a conversation rather than a one-shot request. A practical approach is to run a first prompt, read the output, then write a follow-up instruction addressing whatever missed the mark. 'Make it shorter', 'cut the second paragraph', 'use a more direct tone throughout' are all valid follow-up prompts. You can get to a usable draft in three or four exchanges, which is still faster than writing from scratch for most repetitive business tasks. If you are running AI across multiple tasks and want that process to feel less manual, building light automation around it is worth considering once you have the prompts working reliably on their own. Prompts Worth Saving Once a prompt gets a good result, save it. Build a small library of templates for the tasks you repeat, product descriptions, email replies, social captions, FAQ answers. This is one of those unglamorous habits that pays off quietly over time. The demand for people who can write and refine prompts well is rising fast. Search interest in AI automation roles has jumped significantly in recent months, and the skill sits at the practical end of that trend, no coding required, just clear thinking and a willingness to be specific. ------------------------------------------------------------ # How Disabling Google Fonts Improves WordPress Load Time Source: https://yorkshiredesign.co.uk/how-disabling-google-fonts-improves-wordpress-load-time/ Published: 2026-07-14 > Most WordPress themes load Google Fonts automatically, and most site owners never think to question it. Each font family makes a separate request to Google's servers before your page finishes rendering. That adds latency you can see in PageSpeed Insights, and it adds up fast when a theme pulls in three or four different weights. Disabling them is one of the quieter performance fixes available, but it has a measurable effect on real-world load time. What Google Fonts Actually Do to Your Load Time When a browser hits your page, it parses the HTML and finds a link to fonts.googleapis.com. It then has to make a DNS lookup, open a connection to Google's servers, download a CSS file, and then make another request for the actual font files. All of that happens before the browser can display text in that typeface. Google's CDN is fast, but it's not instant. On a slow mobile connection, that chain of requests can add anywhere from 100ms to over 400ms to your render time. For Core Web Vitals, that delay hits your Largest Contentful Paint score directly. There's also a privacy angle. Every visitor who loads your page sends a request to Google's servers, which matters if you're operating under GDPR. Some hosting environments block third-party font calls by default for exactly this reason. Check Whether Your Site Is Actually Loading Them Before you change anything, confirm the problem is real. Open Chrome DevTools, go to the Network tab, and filter by 'font'. Reload the page and look for any requests going to fonts.googleapis.com or fonts.gstatic.com. If you see them, you're loading Google Fonts. You can also paste your URL into Google's PageSpeed Insights and look under 'Opportunities'. It will flag render-blocking resources, and Google Fonts requests often appear there. Some themes load fonts you're not even using. A theme might pull in six font weights and only display text in two of them. That's wasted bandwidth on every page load, not just the homepage. The Cleanest Way to Disable Them The right method depends on where the fonts are being called from. There are three common sources, your theme, your page builder, or a plugin. For themes, check the Customiser first. Many themes built in the last few years have a typography setting where you can switch from Google Fonts to a system font. That's the cleanest option because you're not patching anything. If there's no such setting, a small code snippet in your child theme's functions.php can dequeue the font stylesheet. Search for the specific handle your theme registers, then use wp_dequeue_style() to remove it. This approach is tidy and doesn't rely on a third-party plugin staying updated. For page builders like Elementor or Divi, the setting is usually buried in the builder's own performance or typography options. Elementor has a 'Disable Google Fonts' toggle in its settings. Divi has a similar option under its performance settings. Both are worth checking before you try anything else. Replace Them With System Fonts or Self-Host Disabling Google Fonts only helps if you replace them with something sensible. Two options work well in practice. System font stacks use fonts already installed on the visitor's device, so there's nothing to download at all. A stack like -apple-system, BlinkMacSystemFont, 'Segoe UI', Roboto, sans-serif covers almost every modern device. The site renders text instantly because the font is already there. For many business sites, the visual difference is barely noticeable. If you need a specific typeface, self-hosting the font files is the better approach. You download the font files once, host them on your own server, and serve them from there. Tools like google-webfonts-helper make it straightforward to download the right file formats. This removes the third-party dependency entirely and keeps your load time predictable. Self-hosting does require a bit of setup. You'll need to add the @font-face declarations to your stylesheet and make sure the files are correctly preloaded. Done properly, it's more reliable than the external call, and it sidesteps the GDPR concern too. What This Won't Fix Disabling Google Fonts is worth doing, but it's not a silver bullet. If your site is slow because of uncompressed images, a bloated database, or a poorly configured server, removing a font call won't rescue it. It's one piece of a broader picture. If you've already dealt with image file sizes and formats, this is a logical next step. If you haven't sorted images yet, start there first. The gains are larger. The font fix is more of a finishing move than an opening one. That said, it's a low-risk change and most sites benefit from it. The combination of fewer external requests, better Core Web Vitals scores, and a cleaner privacy posture makes it worth the half-hour it takes to sort out properly. Related: How to Disable Google Fonts in WordPress and Speed Up Your Site ------------------------------------------------------------ # AI Automation Tools That Actually Speed Up Content Workflows Source: https://yorkshiredesign.co.uk/ai-automation-tools-that-actually-speed-up-content-workflows/ Published: 2026-07-14 > A small ecommerce site owner spent three hours a week writing product descriptions. Same format, same structure, different product each time. She tried an AI tool on a Tuesday afternoon, got a draft in forty seconds, edited it in five minutes, and published before lunch. That gap, three hours down to twenty minutes, is what good AI automation actually looks like. Not magic. Not a full replacement for thinking. Just the slow, repetitive work done faster so the real decisions get more time. The problem with most AI tool lists Most roundups of AI tools are just feature lists with affiliate links. They tell you what a tool does, not whether it genuinely fits into a working content process. So the honest starting point is this, most AI tools add a step before they remove one. You still need a brief, still need an edit, still need a human to check the output is actually correct. The tools worth keeping are the ones where the time saved on output outweighs the time spent on setup and checking. That ratio is what matters. If a tool takes twenty minutes to configure every time, it is not saving you anything. Where AI tools genuinely cut time First drafts. That is where the real saving is. Staring at a blank page is slow. An AI that gives you a rough 400-word draft in thirty seconds, even a mediocre one, is faster than starting from nothing. You edit from something rather than building from nothing. Repurposing is the second big win. Take a long blog post and turn it into a short social caption, a summary paragraph, a meta description. Each of those tasks is small, but they add up across a month. Automating the reformatting, not the thinking, is where content teams quietly save hours. If you are already producing AI-assisted content for SEO, repurposing that same content across formats is a natural next step. Brief generation is underrated too. Feeding a URL and a target keyword into an AI and getting a structured brief back in two minutes beats a standing meeting about what to cover. Not perfect, but a solid starting point. Tools worth actually using ChatGPT and Claude are the workhorses. Most people already have access to one of them. They handle first drafts, rewrites, headline variants, and brief generation without needing any setup. The skill is in the prompt, not the platform. For structured content at scale, tools like Jasper or Copy.ai offer templates built around specific content types, product descriptions, ads, email subject lines. They are faster than a blank chat window when you are producing the same format repeatedly. Notion AI and similar workspace-native tools are useful when the content work and the planning live in the same place. You brief, draft, and edit without switching tabs. That sounds small. Across a day it is not. For SEO-focused content, tools like Surfer or Frase sit between the research stage and the draft stage. They show you what a page needs to cover based on what is already ranking. That is genuinely useful because it replaces the manual work of reading ten competitor pages and noting what they share in common. Bear in mind though, if you want to understand what actually puts AI content at risk with Google, that is a separate question worth understanding before you publish at volume. What most people get wrong They automate the wrong step. The temptation is to automate publishing, scheduling, and distribution first because those feel technical and time-consuming. But a bad piece of content published efficiently is still a bad piece of content. The better order is, automate drafting and research first, then worry about distribution. Get the content quality up, then speed up the delivery. There is also a tendency to use too many tools. Three AI subscriptions doing overlapping jobs is not a workflow, it is overhead. One general-purpose model and one SEO-focused tool covers most content operations cleanly. If you are not sure how to bring automation in without disrupting what already works, starting with one tool and one task is always the right call. The edit still matters No AI tool removes the need for a final read. Tone drifts. Facts get softened into vagueness. Specific claims disappear and get replaced with generalities. A five-minute edit after an AI draft catches most of that. The workflow that actually works looks like this. Brief the piece properly. Generate a draft. Edit for accuracy, tone, and specificity. Publish. The AI handles the volume. You handle the quality. That division is where the time saving becomes real without the output becoming generic. ------------------------------------------------------------ # What Is Search Engine Optimisation and Why It Takes Time Source: https://yorkshiredesign.co.uk/what-is-search-engine-optimisation-and-why-it-takes-time/ Published: 2026-07-14 > Search engine optimisation is the process of making a website easier for Google and other search engines to find, read, and rank. That sounds simple enough. In practice, it is one of the most misunderstood services a small business can buy. People expect it to work like a light switch. It does not. Getting a page to rank takes months of quiet, technical work that most clients never see. This guide explains what SEO actually is and why the timeline is what it is. What Search Engine Optimisation Actually Means At its core, SEO is about making your pages the best answer to a specific question someone types into Google. That means the content needs to be accurate, the page needs to load quickly, and the site needs to be structured in a way a search engine can follow without getting lost. Google's job is to serve the most useful result. SEO is your job of giving it a good reason to pick yours. Every signal matters, from the words in a heading to how fast the first byte of HTML reaches a browser. There is no single thing you fix once. It is a collection of smaller decisions that compound over time. The Technical Side People Rarely See Most of the work in SEO happens in places a visitor never looks. Page structure, internal linking, canonical tags, crawl budgets, schema markup. None of it is visible to someone browsing the site. All of it affects whether Google can understand and trust what it finds. A page might be well-written and genuinely useful, but if it loads in four seconds, has duplicate title tags, or sits behind a broken redirect chain, Google will give it less attention than it deserves. Fixing those problems is not glamorous work. It is thorough, detail-level work that takes time to get right. Core Web Vitals are a good example. Google measures how fast a page feels to a real user, not just how fast the server responds. Improving those scores involves understanding what is blocking render, what is deferrable, and what is genuinely slowing the page down. That kind of diagnosis is not quick. There is no plugin that does it properly for you, as we cover in more detail on what actually works for SEO on a website. Why Google Does Not Trust New Signals Overnight Search engines are cautious by design. Google has seen enough manipulation over the years that it does not reward sudden changes quickly. A new page, a fresh batch of links, an updated title tag. None of these flip a switch. Google watches a domain over time to see if it behaves consistently and reliably. This is worth understanding before you invest. A site that has been around for years with a clean history tends to rank faster than a new one. That is not unfair. It is Google trying to avoid promoting sites that look good for a week and then go quiet. So even if every technical decision is right from day one, patience is not optional. It is part of the process. Content Is Only Half the Work Good content matters. But it does not rank on its own. A well-written page still needs a sensible internal link structure so Google can find it. It needs a title tag that matches what people actually search for. It needs to sit on a fast, secure site that Google crawls regularly. The mistake most people make is treating content and technical SEO as separate things. They are not. A thorough approach looks at both at the same time, because weaknesses in one limit what the other can achieve. You can publish fifty strong articles and still not rank if the site's technical foundations are shaky. What tends to move the needle is the combination of clean, specific content and a site that gives Google no technical reason to look elsewhere. Anything less is half a job. For a closer look at what this actually involves day to day, this piece on what SEO companies actually do breaks it down plainly. What a Realistic Timeline Looks Like For a new site, three to six months before meaningful movement is a reasonable expectation. For an established site with existing authority, improvements can show sooner, sometimes within weeks of fixing a specific technical problem. The honest answer is that it depends on the competition in your niche, the current state of your site, and how consistently the work gets done. There is no shortcut that holds up. Quick wins from low-quality links or keyword stuffing tend to reverse when Google updates its algorithms. The sites that stay ranked are usually the ones that did the unglamorous work quietly and kept at it. One caveat worth naming. SEO is not always the right investment at the start. If a site has fundamental usability problems, those need sorting first. Ranking a page that does not convert is a waste of everyone's time. That is something worth being straight about before any SEO work begins. You can read more on this in why SEO takes the time it does. ------------------------------------------------------------ # Ecommerce SEO Mistakes That Quietly Lose You Sales Source: https://yorkshiredesign.co.uk/ecommerce-seo-mistakes-that-quietly-lose-you-sales/ Published: 2026-07-13 > Most ecommerce SEO problems are not obvious. The site looks fine, the products are listed, the checkout works. But sales are flat and search traffic barely moves. The issues are usually below the surface, in the structural and technical decisions that get made early and never revisited. This post covers the mistakes that come up again and again, the ones that are easy to miss precisely because they do not break anything. They just quietly cost you. Duplicate Content Across Product Variants This is probably the most common one. A product comes in three colours and four sizes, so the site generates a separate URL for each combination. Suddenly you have thirty-two near-identical pages competing with each other for the same search terms. Google has to guess which one to rank. It usually picks badly, or ignores most of them entirely. The fix is not glamorous. Canonical tags, proper parameter handling in Google Search Console, or consolidating variants onto a single page with a size and colour selector. None of it is difficult, but it takes methodical work to go through a large catalogue and sort it out properly. Most sites never bother. Product Titles Written for the Warehouse, Not for Search Internal product codes and supplier names mean nothing to someone typing into Google. A title like "BRK-994-CHARCOAL" tells a search engine nothing useful. The person searching is typing "charcoal grey kitchen bar stool with backrest" or something close to it. Product page titles need to reflect how real people search. That means doing at least basic keyword research before writing them, not after the catalogue has been live for two years. Retrofitting this across hundreds of SKUs is the kind of work that takes time, but the improvement in organic visibility is usually significant once it is done properly. For a closer look at what makes a product page worth ranking, the structural decisions behind ecommerce pages are worth understanding first. Thin Category Pages That Do No Heavy Lifting Category pages often get neglected. They have a heading, a grid of product thumbnails, and nothing else. No descriptive copy, no context, no internal links to related categories. From a search engine's point of view, there is nothing to rank the page for beyond the category name itself. A short, honest paragraph at the top of the category page, written around how people actually search for those products, makes a real difference. It does not need to be long. A hundred words of well-placed copy that answers the obvious question, "what will I find here and why should I buy it?", gives Google something to work with. Ignoring Crawl Budget on Large Catalogues Smaller sites rarely need to think about crawl budget. But once a catalogue gets into the thousands of products, it matters. Googlebot has a finite amount of time to spend crawling your site on each visit. If it is wasting that time on paginated archive pages, filtered URLs with no content value, or out-of-stock product pages that have been left live with no redirect, it is spending less time on the pages that actually matter. A clean robots.txt, sensible use of noindex on low-value pages, and a well-structured sitemap all help. So does keeping your hosting fast enough that the crawler does not time out. These are not exciting tasks. But ignoring them costs you indexation on the pages you do want ranking. Page Speed Problems That Kill Conversions Before SEO Gets the Chance Google's Core Web Vitals are a ranking factor, but the more immediate damage from a slow ecommerce site is conversion rate. A product page that takes four seconds to load on mobile loses a large portion of its visitors before they have even seen the product. Unoptimised images are usually the biggest culprit on ecommerce sites, simply because there are so many of them. Large, uncompressed product photography served at full resolution on a mobile screen is a straightforward problem with a straightforward fix. What catches people out is that it takes time to process a full catalogue properly, not just the homepage hero image. Schema Markup Left Off Product Pages Product schema tells search engines the price, availability, and review rating of a product directly. When it is implemented correctly, those details can appear in the search result itself as rich snippets. That changes how the listing looks compared to a plain blue link, and it tends to improve click-through rates. According to Google's own structured data documentation, product markup supports price, review score, availability and more. Most ecommerce platforms can generate this automatically, but it still needs checking. Incorrect or missing required fields mean Google will not show the rich result at all. It is one of those things that is worth auditing properly rather than assuming the platform has handled it. Not Treating Internal Links as a Ranking Tool Internal linking on ecommerce sites tends to be an afterthought. Products link to a category, the category links back to the homepage, and that is about it. There is no real thought given to which pages need more link equity, or how to connect related products in a way that keeps people browsing. A well-structured internal link strategy pushes authority toward the pages you most want to rank. It also keeps users on the site longer. Understanding where internal linking typically goes wrong is a good starting point before auditing your own catalogue. The honest truth about ecommerce SEO is that most of the work is unglamorous. It is auditing, fixing, checking, and repeating. There is no shortcut that replaces going through a catalogue methodically and getting the basics right. That said, getting the basics right is exactly where the gains are hiding. Related: WooCommerce SEO Setup: The Structural Decisions That Matter ------------------------------------------------------------ # WordPress Speed Optimisation Without Adding More Plugins Source: https://yorkshiredesign.co.uk/wordpress-speed-optimisation-without-adding-more-plugins/ Published: 2026-07-13 > A client came with a WordPress site that was loading in over six seconds. They had WP Rocket, Smush, a caching plugin, and three others all running at once. The site was still crawling. The problem was not a lack of plugins. The problem was everything underneath them that nobody had looked at. Speed optimisation does not always mean adding something. More often, it means fixing what is already there. The Plugin Stacking Trap It is easy to reach for another plugin when a site feels slow. Caching, minification, lazy load, image compression , there is a plugin for each one. But every plugin you add carries a cost. PHP execution, database queries, extra HTTP requests. At some point you are adding weight to fix a weight problem. The sites that respond fastest tend to have fewer moving parts, not more. That is not an opinion , it follows from how WordPress loads a page. Every active plugin hooks into that process somewhere. The question is whether you actually need it there. Start With the Database Most WordPress databases are full of junk that has built up quietly over months. Post revisions alone can run into thousands of rows. Add orphaned metadata, spam comments, transient records that never cleared, and you have a database that takes longer to query than it should. You can clear most of this with a single SQL query or the built-in tools in phpMyAdmin. No plugin required. Delete post revisions older than a set count, clear expired transients, and remove draft metadata from posts that were never published. It takes twenty minutes and the difference in query time is usually noticeable immediately. If you want to go further, a bloated database will slow every page regardless of how much you cache on top of it. Sort Your PHP Version First This is the one people underestimate. Running PHP 7.4 on a host that offers 8.2 or 8.3 is leaving real performance on the table. PHP 8.x handles WordPress significantly faster at the interpreter level. It is a setting change in your hosting control panel, not a rebuild. Check your current version in Site Health under Tools in the WordPress dashboard. If you are not on the latest stable release your host supports, change it. Test your site afterward for any plugin conflicts, but nine times out of ten it runs clean. Fix Image Delivery Without a Plugin Images are usually the single biggest page weight issue. Most people install a compression plugin and assume that covers it. It often does not, because the problem is not just file size. It is format, dimensions, and how the browser requests them. Serving images in WebP format and setting proper width and height attributes in HTML prevents layout shift. Both are achievable without a plugin if you convert images before upload and write the markup correctly. Your theme's functions.php can also add native lazy loading across all images with a single filter, no plugin needed. For the cases where plugin-based approaches fall short, image optimisation gaps that plugins consistently miss are worth reading through. Reduce What Loads on Every Page WordPress loads scripts and stylesheets globally by default. A contact form plugin adds its CSS and JS to every page, even pages with no form on them. A slider plugin does the same. Over time this adds up to hundreds of kilobytes loading on pages that have no use for any of it. You can conditionally dequeue these assets using WordPress's wp_dequeue_script and wp_dequeue_style functions. It requires a small amount of PHP in your theme's functions.php, but it is not complex. Identify which handles belong to which plugins using the browser's network panel, then write a conditional that only loads them on the relevant page template. A contact form's assets should load on the contact page. Nowhere else. GZIP and Cache-Control Headers at Server Level Caching plugins do a reasonable job, but they operate at the application layer. The most reliable place to set HTTP caching headers and enable compression is directly in your server configuration, either in .htaccess for Apache hosts or nginx.conf for Nginx. Browser cache headers, GZIP or Brotli compression, and keep-alive connections all sit at this level. Setting a Cache-Control max-age of 31536000 on static assets like fonts, images, and CSS files means repeat visitors load almost nothing. That alone cuts time-to-interactive significantly for anyone who has been to your site before. Google's own web performance guidance treats server-level compression and caching as foundational, not optional extras. What Is Not Worth Bothering With Minification gets talked about a lot. In practice, the gains from minifying CSS and JS on a modern WordPress site are marginal if your server is already compressed and your assets are cached. It is not nothing, but it is the last 2%, not the first 20%. Fix your database, your PHP version, and your image pipeline before you spend time on it. The same goes for CDNs on small sites. A CDN makes sense when you have a global audience or very high traffic. For a typical small business site with most visitors in one country, a fast host with proper server-side caching achieves the same result without the added complexity. Speed optimisation without plugins is about stripping back, not adding layers. Get the foundations right and the numbers follow. Related: WordPress Image Optimisation Plugins: Which Ones Are Worth It ------------------------------------------------------------ # Engine Optimisation Search: What Actually Moves the Needle Source: https://yorkshiredesign.co.uk/engine-optimisation-search-what-actually-moves-the-needle/ Published: 2026-07-13 > Some SEO work genuinely moves your rankings. Some of it just looks like progress. The hard part is knowing which is which before you spend three months on the wrong thing. This piece weighs the approaches that actually make a difference against the ones that eat time without much to show for it. No rankings promised overnight. Just a clear-eyed look at where the effort is worth putting in. Technical health comes first, not last A lot of people treat technical SEO as a finishing touch. It isn't. If Google can't crawl your pages cleanly, or if your site loads slowly on mobile, nothing else you do will carry full weight. Core Web Vitals, in particular, are worth getting right before you focus on content or links. Google has been clear that page experience signals factor into ranking, and a site that fails on Largest Contentful Paint or Cumulative Layout Shift is already starting behind. That said, fixing technical issues doesn't mean instant ranking gains. Think of it as clearing the way. The site stops working against itself. What comes after that has a proper foundation to build on. Content depth beats content volume Publishing more pages rarely helps. Publishing thorough, specific pages usually does. A single page that genuinely answers what a searcher needs, in plain language, with real detail, will outperform ten thin pages built around keyword counts. Search engines have got considerably better at understanding whether a page actually covers a topic or just mentions the right words. Where people go wrong is treating content like a numbers game. Ten articles a month sounds productive. But if each one is vague and interchangeable with a hundred other pages online, none of them will rank well. One article that goes deep, covers the trade-offs, and gives the reader something they couldn't find in thirty seconds elsewhere , that's the one worth writing. You can see how content built around real searcher intent differs from surface-level copy in practice. On-page signals still matter, but not how most people apply them Keyword placement in titles, headings and the first paragraph does still carry weight. That's not the problem. The problem is when on-page SEO becomes a mechanical exercise , stuffing a phrase into every heading regardless of whether it reads naturally, or obsessing over keyword density as though it were a formula. What actually helps is writing page titles that match the real intent behind a search, structuring headings so they reflect the genuine shape of the content, and making sure the page answers what the title promised. That's it. The rest is diminishing returns. Links, quality over quantity, by a distance A single link from a relevant, respected site does more than fifty links from directories nobody visits. This has been true for a long time and it hasn't changed. What has changed is that low-quality link building is riskier than it used to be. Patterns that look manufactured get noticed. Earning links by producing something genuinely worth referencing is slower, but it holds up. Guest posts on real publications, being cited as a source, building something useful that others naturally link to. None of that happens quickly. It's the kind of work that explains why serious SEO takes months, not weeks. What doesn't move the needle much Meta descriptions don't directly affect rankings. They affect click-through rates, which can indirectly influence performance, but writing the perfect meta description while ignoring page speed or thin content is getting priorities backwards. Social media signals don't carry direct ranking weight either, despite what a lot of guides suggest. Sharing content can bring visitors and occasionally earn links, but social activity alone doesn't shift your position in search results. And chasing every algorithm update with a tactical tweak is mostly noise. The sites that hold their rankings through updates tend to be the ones that built something solid to begin with, rather than the ones constantly adjusting to the latest theory. How to actually decide where to start If your site has obvious technical problems , slow load times, crawl errors, broken pages , fix those first. Then look at your best existing content and ask whether it genuinely earns its place on the page. Is it thorough? Does it match what someone searching that term actually wants to find? After that, think about which pages matter most to your business and whether they have any real authority behind them. The places where the detailed, unglamorous SEO tasks tend to stack up are exactly where the gains eventually show. There's no single lever to pull. It's always a combination. But some combinations work, and some just keep you occupied. Knowing the difference is most of the job. ------------------------------------------------------------ # What Is SEO and Why Does It Take So Long to Work? Source: https://yorkshiredesign.co.uk/what-is-seo-and-why-does-it-take-so-long-to-work/ Published: 2026-07-13 > Most people asking what search engine optimisation SEO is expect a short, tidy answer. The honest one is a bit more complicated. SEO is the process of making a website easier for search engines to read, trust, and rank. That sounds straightforward. The part people underestimate is how long that process actually takes, and why cutting corners rarely saves any time at all. The myth that SEO is mostly about keywords A lot of people still think SEO means scattering the right words across a page and waiting for Google to notice. That was roughly true about twenty years ago. Today it accounts for maybe a tenth of what actually moves rankings. Google now weighs hundreds of signals. The speed your pages load at, how other sites link to yours, whether your content answers a question properly, how your server responds under load. Keywords still matter, but they are one thread in a much bigger picture. What search engines are actually doing Search engines send automated programmes, called crawlers, across the web constantly. They follow links, read page code, and file what they find in an enormous index. When someone searches for something, the engine pulls from that index and ranks results based on relevance, authority, and technical quality. The crawling and indexing part alone takes time. A new page might not get indexed for days or weeks, depending on how often Google visits your site. After indexing, Google still has to decide where to rank it, and that decision changes as other sites publish similar content and compete for the same spots. So even before any SEO work has a chance to show results, there is a waiting period baked into how the whole system operates. That is not a flaw. It is just how it works. Why the technical side gets ignored The visible parts of SEO, like page titles and blog posts, are easy to point at. The technical side is harder to explain, which is probably why it gets skipped. But it is often where the real problems hide. A slow server, a poorly structured internal link setup, pages that accidentally block crawlers, duplicate content caused by URL variations... none of these are obvious from the front end. You need to look at the code and the server logs to find them. For anyone who wants to understand which fixes actually shift rankings, the technical audit is usually the place to start. Fixing these issues does not produce an overnight jump. Google has to re-crawl the pages, re-evaluate them, and update its index. That cycle takes time, sometimes weeks, sometimes longer. The one thing people get wrong about timelines The expectation that SEO should produce results within a few weeks is probably the most common misunderstanding in the whole field. It is also the one that causes the most friction between clients and the people doing the work. A well-established site with strong existing authority might see movement in six to eight weeks after targeted changes. A newer site with no backlinks and thin content is looking at six months before meaningful organic traffic starts to build, and that is assuming the work is thorough and consistent throughout. This is not a reason to avoid SEO. It is a reason to start earlier than you think you need to, and to keep at it. The sites that rank well are almost always the ones that have been worked on steadily over time, not the ones that had a big push followed by nothing. What the actual work looks like Good SEO involves a lot of unglamorous detail. Checking that every page has a proper title and description. Making sure the site loads quickly on mobile. Building content that answers real questions thoroughly, not just ticking a word count. Earning links from other sites by being genuinely useful or well-known enough that people reference you. None of that is dramatic. Most of it is invisible to the average visitor. But it is the kind of methodical, behind-the-scenes attention that compounds over time. If you want a clearer sense of where that time actually goes, the day-to-day reality is less exciting than most people imagine. The honest trade-off SEO is not the right tool if you need enquiries this week. Paid search can do that. SEO is the right tool if you want a steady stream of organic traffic that does not disappear the moment you stop paying for it. The trade-off is patience for permanence. Rankings built on solid technical foundations and genuinely useful content tend to stick. Rankings chased through shortcuts tend to drop just as fast as they appeared, and sometimes take the whole site down with them when Google updates its approach. For a closer look at how the process unfolds step by step, the full process is worth reading through before committing to any SEO work. ------------------------------------------------------------ # 7 Things a Search Engine Optimisation Company Actually Does Source: https://yorkshiredesign.co.uk/7-things-a-search-engine-optimisation-company-actually-does/ Published: 2026-07-13 > Most people hiring an SEO company for the first time have a rough idea of the goal , rank higher, get more visitors , but not much idea of what actually happens day to day. That gap causes friction. Clients wonder why results take months. Agencies send reports full of numbers that don't explain much. So here is a plain account of what a search engine optimisation company is actually doing with your time and budget. 1. Auditing What's Already There Before anything gets fixed, the site gets pulled apart. A proper technical audit looks at crawl errors, duplicate content, slow pages, broken links, missing metadata, redirect chains and indexing gaps. This is not a five-minute scan with a free tool. It takes time to go through what the data is actually saying and separate the problems worth fixing from the noise. Most sites have a handful of issues that genuinely hold them back and a long tail of minor points that barely matter. Knowing the difference is most of the skill. 2. Researching the Right Keywords Keyword research is not just finding terms with high search volume. A decent SEO company looks at what people are actually trying to find when they search, whether the page can realistically rank for a term, and whether ranking would bring the right kind of visitor in the first place. Getting this wrong early is costly. Optimising for the wrong terms means months of effort pointing at pages nobody useful will ever land on. The research stage sets the direction for almost everything else, so it needs to be thorough. 3. Fixing Technical Problems This is where a lot of the quiet, unglamorous work sits. Page speed, Core Web Vitals scores, mobile usability, crawl budget, structured data, canonical tags, sitemap accuracy. None of it is visible to the reader, but all of it affects whether Google can properly access, understand and trust the site. For example, a site with poor crawl configuration might be serving thousands of thin or duplicate URLs to search engines that should never be indexed at all. That wastes crawl budget and dilutes authority from the pages that actually matter. Fixing it properly means going into the server settings, the CMS configuration and the redirect logic, not just toggling a plugin switch. 4. Improving On-Page Content Once the technical foundation is sound, attention moves to the pages themselves. Title tags, meta descriptions, heading structure, internal linking, word count, topic coverage. A search engine optimisation company will look at whether each page is genuinely the best answer to the query it is targeting, or whether it is thin, off-topic, or duplicating something else on the site. This often means rewriting or expanding content that was written without SEO in mind. It is not about stuffing keywords in. It is about making sure the page actually covers the subject properly, so Google has a clear reason to rank it over something better. 5. Building Authority Through Links Links from other websites are still one of the strongest signals Google uses to assess trust. Earning them takes time. The legitimate approach involves finding relevant sites, building relationships, producing content worth linking to, or getting the business listed in directories and publications that matter to its sector. There is a real trade-off here worth naming. Bought links or low-quality link schemes can move rankings short term, but Google's algorithms are good at spotting patterns and the penalties are severe. Any reputable SEO operation will tell you the slower route is the only safe one. 6. Tracking, Reporting and Adjusting Rankings shift. Competitors update their sites. Google changes how it evaluates pages. A search engine optimisation company watches what's moving, spots drops early and adjusts the approach accordingly. That means checking Search Console data regularly, monitoring keyword positions, and looking at what pages are gaining or losing traffic and why. Good reporting explains what changed and what is being done about it, not just a table of numbers. If a report arrives and you cannot tell what decision it is supporting, that is a problem. 7. Thinking Several Months Ahead SEO is not a short loop. Actions taken now often show results three to six months later, sometimes longer for competitive terms. A good SEO company is always working on things whose payoff is not immediate, because that is how the process actually works. This is the part clients most often underestimate. Understanding why results take time is not just helpful context, it is essential to making good decisions about budget and patience. The sites that win tend to be the ones whose owners stopped expecting a quick fix and committed to steady, consistent work instead. Related: Search Engine Optimisation for Websites: What Actually Works ------------------------------------------------------------ # Search Engine Optimisation for Websites: What Actually Works Source: https://yorkshiredesign.co.uk/search-engine-optimisation-for-websites-what-actually-works/ Published: 2026-07-12 > Most people want to know one thing, what do you actually do to make a site rank? Not the theory. The real process. Search engine optimisation for websites comes down to a handful of things done thoroughly and consistently. Get those right and rankings follow, given enough time. Skip them or do them halfway and you'll wonder why nothing moves. This post walks through what that process actually looks like in practice. Start With What Google Can Actually Read Before anything else, Google needs to be able to crawl and index your pages cleanly. That sounds obvious, but it trips up a surprising number of sites. Crawl errors, pages blocked by robots.txt, missing canonical tags, or a sitemap that hasn't been updated since the site launched. All of these quietly hold a site back. Open Google Search Console and check the Coverage report first. Fix any indexing issues before you touch anything else. There's no point writing great content if Google can't find the page. On-Page Signals Still Matter, Done Properly Every page needs a clear focus. One topic, one target phrase, handled properly across the title tag, the H1, a couple of the subheadings, and the body copy. Not stuffed. Just present where it makes sense. The meta title and description carry real weight, not just for rankings but for click-through rate. A well-written meta description won't push a page higher on its own, but it does affect whether people choose your result over the one above or below it. That matters more than most site owners realise. If you want a closer look at how search engine optimisation companies handle this day to day, there's a useful breakdown in what the daily work actually looks like behind the scenes. Technical SEO Is the Part Nobody Sees This is where most of the real work happens. Page speed. Core Web Vitals. Schema markup. Proper heading structure. Internal linking. Clean HTML. A site that loads in under two seconds on mobile is going to outperform a slower one with equivalent content, almost every time. Core Web Vitals, the set of speed and usability metrics Google uses as a ranking factor, reward sites that load fast, respond quickly to input, and don't shift the page around while it's loading. These aren't optional anymore. They're part of how Google scores the experience of being on your site. Internal linking is another one that people underestimate. Linking between relevant pages on your own site helps Google understand what each page is about and how the site fits together. It also passes authority around. A well-linked site is easier to crawl and tends to rank more evenly across its pages. Content That's Actually Worth Ranking A page earns its ranking by being genuinely useful for the search it's trying to rank for. That means covering the topic properly, answering the real question, and doing it in plain language a reader can follow. Thin pages, pages that skim the surface, or pages that repeat the same phrase ten times without saying anything new, these don't hold rankings. Google has got much better at telling the difference between a page that covers a topic and one that just mentions it. The honest trade-off here is time. Good content takes longer to write, and it takes longer to rank. A page targeting a competitive phrase might sit quietly for three or four months before it climbs. That's normal. It doesn't mean something is broken. For a clear picture of why the timeline works the way it does, the breakdown of what SEO actually takes time to achieve is worth reading before you start setting expectations. Backlinks Still Count, But Quality Beats Quantity A link from a relevant, well-regarded site carries far more weight than fifty links from low-quality directories. One decent mention from a trade publication or a respected blog in your sector is worth more than most link-building campaigns produce in six months. Building links the right way is slow. It comes from publishing content people actually want to reference, from building real relationships with other sites, and occasionally from outreach done properly. There's no shortcut that doesn't carry risk. How Long Before You See Results For a new site or one starting from scratch, expect three to six months before organic traffic begins to move noticeably. For a site with existing authority that needs technical fixes and better content, it can be faster. For a competitive niche, it can be longer. What most people get wrong is expecting SEO to behave like paid advertising. Switch on a campaign and traffic starts the same day. SEO doesn't work like that. The gains compound slowly, but they tend to last. A well-optimised page can sit in a top position for years with occasional maintenance. If you're working through an SEO process step by step, keeping that timeline in mind from the start makes the whole thing easier to manage. Related: 7 Things a Search Engine Optimisation Company Actually Does Related: What Search Engine Optimisation SEO Actually Takes Related: Engine Optimisation Search: What Actually Moves the Needle ------------------------------------------------------------ # Content Writing for SEO: What Makes a Page Worth Ranking Source: https://yorkshiredesign.co.uk/content-writing-for-seo-what-makes-a-page-worth-ranking/ Published: 2026-07-12 > Good writing alone does not make a page rank. The words matter, but they sit inside a larger set of decisions, and getting any one of them wrong can waste all the effort that went into the others. Search intent, headline clarity, logical structure, genuine depth, a clear purpose. Each one pulls its own weight. Miss any of them and the page either fails to rank or fails the reader once it does. This piece works through each in plain terms. The Search Intent Has to Match Before Anything Else Before a single word gets written, the intent question has to be answered honestly. Is the person searching for an answer, a product, a comparison, or a process to follow?A page that targets a how-to question but sells at the reader from paragraph one is not satisfying that intent. Google knows it. The reader figures it out faster. Getting intent wrong is a quiet failure. The page can be well-written, well-structured, and technically clean, and it will still stall. The content simply is not what the search was for. That mismatch is the most common reason a page sits on page three and stays there, regardless of what else gets tweaked. The Headline Has to Earn the Click The title tag is the first thing a reader judges. A vague headline like "Our Services" or "Web Tips" tells no one anything. A precise one that matches what the person searched for earns the click before the page even loads. The H1 carries its own weight too. If it contradicts the title tag or overpromises something the page cannot deliver, trust goes immediately. Readers do not wait around to be disappointed. One clear, honest headline that reflects the actual content is far more useful than a clever one that confuses. Structure Is What Makes a Page Scannable Most people scan before they read. They drop into a heading, skim a paragraph, decide if it is worth their time. A page with no clear heading hierarchy, long unbroken blocks of text, or a logic that jumps around loses that reader in roughly eight seconds. Heading order matters to search engines too. An H2 signals a major section. An H3 signals a sub-point within it. When the structure is logical and consistent, it gives both the reader and the crawler a clear map of what the page covers and how the ideas connect. Poor structure is not just a readability problem. It is a signals problem for search engines as well. Depth Over Word Count: Cover the Topic, Not Just the Keyword Word count targets are mostly a distraction. A 2,000-word page stuffed with repetition ranks below a focused 900-word page that actually answers the question and its natural follow-ups. The real measure is coverage. Does the page handle the sub-questions a reader would reasonably have? Does it explain the why, not just the what? For content writing SEO specifically, that means addressing things like intent, structure, and thin copy, not just repeating the target phrase. Related questions answered properly signal genuine topical depth. Padding to hit a number does the opposite. What most people underestimate is how much the surrounding questions matter. A page about pricing that never mentions typical ranges, or a how-to that skips the most common mistake, is incomplete. Length alone does not decide which format earns traffic, depth does. Thin Writing Is the Most Common Reason Pages Stall Thin content is not just short content. A 1,500-word page can be thin. The tell is that nothing on it would surprise or inform anyone who already had a passing knowledge of the subject. It restates what everyone knows and stops there. The honest trade-off is time. Writing something with real substance takes longer. It requires checking what competitors miss, thinking through the reader's actual problems, and being willing to say something specific rather than something safe. That takes time most people do not want to spend. A page that offers nothing the reader could not find in thirty seconds elsewhere has very little reason to sit at position one. One Page, One Clear Purpose Pages that try to cover three topics at once end up ranking for none of them. The relevance gets diluted. A page about web design that also covers SEO, hosting, and content strategy gives search engines no clean signal to latch on to. Tightening focus often does more than rewriting the copy. Pulling a secondary topic out into its own page, or cutting a section that does not belong, can improve rankings without touching a single keyword. Less is not always less. Sometimes it is the fix. The Page Has to Do Something When the Reader Arrives A page that ranks and then leaves the reader with nowhere to go has done half the job. Content written for SEO still needs to guide the reader to a next step, whether that is a contact form, a related post, or a clear answer that builds enough trust to bring them back. A good call to action in a content context does not shout. It sits where the reader has just learned something and offers a logical continuation. "If this is useful, here is where to go next" works far better than a generic button with no connection to what they just read. Getting the brief right before writing starts is what makes that final step feel natural rather than bolted on. Related: Content Writing for SEO: What Search Engines and People Both Want ------------------------------------------------------------ # What NitroPack Actually Does to Your WordPress Site Under the Hood Source: https://yorkshiredesign.co.uk/what-nitropack-actually-does-to-your-wordpress-site-under-the-hood/ Published: 2026-07-12 > NitroPack gets mentioned a lot in page speed conversations, usually by someone who installed it, watched their score jump, and assumed the job was done. The reality is a bit more involved. NitroPack makes a large number of automatic changes to how your site delivers code, images and cached pages. Some of those changes are genuinely useful. Some of them quietly break things. Understanding what it actually does helps you decide whether it fits your site, or whether you're better off doing the work another way. What NitroPack Is and What Problem It Solves NitroPack is a cloud-based performance service, not a standard caching plugin. The distinction matters. A plugin like WP Rocket sits on your server and handles caching locally. NitroPack routes your pages through its own infrastructure, applying optimisations on the way out. It compresses code, converts images, and serves content from its own CDN before the page reaches the browser. The problem it solves is real. Getting strong Core Web Vitals scores manually requires touching HTML, CSS, JavaScript, images, and your server configuration. That's a lot of unseen work that takes time. NitroPack tries to automate most of it in one install. For someone without a technical background, that's a genuine shortcut. Don't expect results overnight, and don't expect perfection out of the box. The tool sets a reasonable baseline quickly, but complex sites usually need some configuration on top. The Caching Layer and How It Works NitroPack generates fully rendered HTML versions of your pages and stores them on its CDN edge nodes. When a visitor arrives, they get the cached version served from a location geographically close to them, not a fresh PHP request through your server. That alone cuts a significant chunk of time-to-first-byte on most shared hosting setups. Because the cache lives outside your server, troubleshooting works differently. With WP Rocket, you clear the cache in WordPress and the change is immediate. With NitroPack, the cache is on their infrastructure. Purging can take a few minutes to propagate, and if something looks wrong after a content update, the first question is always whether the CDN has refreshed. It's a small thing, but it catches people out regularly. For sites that sit on slow or congested hosting, this external caching layer can make a noticeable difference to real-world load times, not just lab scores. HTML, CSS and JavaScript Minification and Deferral NitroPack strips whitespace and comments from your HTML, CSS and JavaScript files, combines scripts where it can, and defers non-critical JavaScript so it loads after the main content. It also inlines critical CSS directly into the <head>, which helps the browser paint the visible portion of the page faster. These are sound techniques. They're also the ones most likely to cause breakage on a real site. Deferring a script that another script depends on, or inlining CSS that conflicts with a page builder's output, can produce layout shifts, missing elements or broken functionality that only shows up on specific pages. The technical side of WordPress optimisation rarely fails loudly. It tends to fail quietly, on one template, on mobile, at a viewport width nobody tested. Always check your site properly after enabling aggressive minification settings, not just the homepage. Image Optimisation and the WebP Conversion Process NitroPack compresses uploaded images and converts them to WebP format automatically, serving the converted versions via its CDN. For sites with a lot of unoptimised images, this can be the single biggest win. WebP files are typically a third smaller than an equivalent JPEG, and the conversion happens without you touching anything. The trade-off is worth noting. Your images are being served from NitroPack's CDN domain, not your own. That's usually fine for page speed purposes, but it means your image URLs change. If you ever cancel your NitroPack subscription or they have a service outage, those optimised images won't load until you sort out an alternative. It's a dependency that's easy to overlook when everything's working. For a more hands-on approach to image handling in WordPress, the options available without coding are worth understanding alongside what NitroPack automates. Where NitroPack Can Cause Trouble JavaScript conflicts are the most common problem. WooCommerce cart behaviour, booking forms, sliders and anything that runs dynamic logic on the front end can break when NitroPack defers or combines the scripts they depend on. The fix usually involves excluding specific scripts from optimisation, but finding which ones takes time. Over-aggressive settings on a complex site can also produce a high lab score that masks a broken user experience. A perfect score in PageSpeed Insights doesn't mean your checkout works. Nine times out of ten, when someone reports a strange front-end bug after installing NitroPack, the culprit is a deferred script or an aggressive CSS inlining rule. There's also the cost. NitroPack's free tier is limited to a small number of page views. For a site with real traffic, the paid plans are a recurring cost that adds up. That's worth factoring in honestly. NitroPack vs Doing It Yourself NitroPack automates a stack of work that would otherwise take a technically capable person several hours to do properly, across caching configuration, code minification, image conversion, and CDN setup. For a site owner who doesn't want to get into that detail, it's a reasonable spend. The trade-off is control. When something breaks, you're working within NitroPack's system, not your own stack. Exclusions and edge cases are handled through their interface, which has limits. Anyone who wants fine-grained control over exactly what gets deferred and when will find the automation frustrating rather than helpful. Approach Setup Time Control Ongoing Cost Best For NitroPack Low Limited Monthly subscription Non-technical site owners wanting quick gains Manual / plugin stack High Full Plugin licences only Technically confident owners or developers If the unseen work that takes time is work you genuinely can't do yourself, NitroPack earns its cost. If you're comfortable going deeper, a thorough manual approach gives you a cleaner result with fewer surprises. Related: NitroPack Reviewed: What It Does Well and Where It Falls Short Related: NitroPack Review: What It Actually Does and Is It Worth It Related: NitroPack vs WP Rocket: Which One Speeds Up WordPress ------------------------------------------------------------ # Web Design Costs in the UK: Why Prices Vary So Much Source: https://yorkshiredesign.co.uk/web-design-costs-in-the-uk-why-prices-vary-so-much/ Published: 2026-07-12 > Most people expect web design to have a rough going rate. It doesn't. You can get quotes from five people this week and the gap between the cheapest and the most expensive will make no sense on paper. Same brief, wildly different numbers. The reason isn't random. It comes down to what's actually being built, who's building it, and how much unseen work goes into making it do its job properly. The Myth That a Cheap Site Saves You Money A low price upfront is not the same as a low cost overall. That distinction matters more with web design than almost anything else you'll buy for your business. What tends to happen with a budget build is this, the site goes live, it looks reasonable enough, and for a while nobody thinks much about it. Then, around 18 months in, problems start showing up. Pages load slowly on mobile. Google's crawlers can't read the structure properly. The theme is bloated, the images are uncompressed, and there's no clean technical foundation underneath any of it. At that point you're not patching a site, you're rebuilding one. You pay twice, and the second time you're also paying to undo the first job. The SEO damage is harder to quantify, but it's real. A site that launched without proper heading structure, without schema, without any thought given to page speed, is already behind before a single piece of content goes up. That ground takes time to recover. The honest trade-off is this, a cheaper site might genuinely suit some situations, a basic brochure for a business that gets all its work by word of mouth, for instance. But if you need search traffic, if your site is part of how customers find and judge you, then cutting the budget on the build is usually where the real expense begins. What the Price Ranges Actually Look Like The table below gives you a rough sense of where money goes at each level. These are realistic UK ranges, not best-case figures. Option Cost What You Actually Get Template builders (Wix, Squarespace) £0 to £300 A pre-built layout you customise yourself. Fast to launch, limited under the bonnet. You handle everything ongoing. Freelancer £500 to £5,000 A real person building your site. Quality varies enormously. At the higher end you get someone thorough who pays attention to the technical detail, not just the look. Agency £5,000 to £30,000+ Multiple people involved, account managers, structured process. You are partly paying for overhead. Output can be excellent or surprisingly average depending on who actually does the work. The freelancer range is where most small businesses land, and it is also where the biggest variation sits. A £600 site and a £4,000 site can look almost identical in a screenshot. The difference is in the unseen work that takes time, how the code is structured, how fast the pages load, whether the technical SEO foundations are clean, and whether the site will actually hold up when Google crawls it. If you want to understand how those technical decisions affect your rankings, the piece on what actually moves rankings in WordPress is worth reading alongside this one. Agencies are not automatically better. You are paying for a process as much as a product, and that process does not always result in a better website for your spend. Why Solo Operators and Agencies Price So Differently An agency quote carries a lot of weight before a single line of code gets written. There is a salesperson who took the call, an account manager who writes the brief, a project coordinator who sits between you and the person doing the actual work, and a director who wants margin on top of all of it. That overhead is real, and it gets baked into your invoice whether you know it or not. A mid-sized agency can have four or five people involved in a project that one experienced solo operator would handle from start to finish, which is why the same brief can come back at wildly different prices depending on who you ask. That is not a criticism of agencies. It is just how their model works. The cost is the cost. A solo operator does not carry that overhead. The person who takes your call is the same person who builds the site, writes the code, and fixes anything that needs fixing afterwards. There are no layers, no handoffs, no margin stacked on margin. What you are paying for is the work itself, and because the technical detail stays with one person throughout, nothing gets lost between departments either. If you want to understand what actually goes into choosing the right kind of build, knowing what separates a thorough agency from a thin one helps set realistic expectations before you start comparing quotes. The Unseen Work That Drives the Price Up Most of what separates a £500 website from a £3,000 one is never visible in the browser. Core Web Vitals tuning, server configuration, image compression pipelines, database structure, clean semantic HTML, and a properly thought-through internal linking architecture, none of it shows up when a client clicks through the finished pages. But Google sees it, and so does every visitor on a slow connection. Getting LCP, INP and CLS into healthy ranges on a real device, not just a lab test, takes methodical work. You check render-blocking resources, audit third-party scripts, sort out lazy loading, look at server response times. That process takes hours, and on a cheap build those hours simply do not exist in the budget. Corners get cut quietly. A builder on a tight quote will upload full-size images, skip caching configuration, and leave the database bloated with post revisions. The site looks fine on launch day. Six months later it is slow, fragile, and harder to fix than if it had been built properly from the start. That unseen work is where the price difference actually lives. It takes time, and you don't expect results overnight because the foundations have to be right first. Where Most Businesses Are Being Underserved A good-looking website is not the same as a good website. That distinction costs people a lot of money. The build looks polished in the browser. The client signs it off, the designer moves on, and six months later the site is sitting on page four of Google with a Core Web Vitals score that would embarrass a site built in 2010. Nobody flagged it because nobody looked underneath. That is the pattern behind a huge number of mid-range builds in the UK. The visual layer gets attention, the technical layer gets ignored, and the client has no way of knowing the difference until the traffic numbers stay flat and the phone stays quiet. Things like page speed, proper heading structure, image compression, render-blocking scripts and the Core Web Vitals signals Google actually uses to rank pages are not visible to the untrained eye. They are unseen work that takes time to do properly, and a lot of web designers simply do not do it. The honest trade-off is this. Spending less up front often means paying twice later, either to fix what was built badly or to fund paid ads because organic search is going nowhere. A thorough build costs more for a reason. What to Actually Ask Before You Pay Anything Before you agree to anything, ask who owns the finished files. Some designers hand everything over. Others retain the source files or lock the site to their own hosting, which means you pay again if you ever want to move. Ask directly, and get the answer in writing. Then ask what CMS they're building on and why. "We use WordPress" is fine, but the reason matters. A builder who understands what sits underneath the theme will make different decisions than one who just installs a page builder and calls it done. Ask about page speed too. Not "will it be fast?" but "what Largest Contentful Paint score are you aiming for, and how are you testing it?" If they look blank, that tells you something. Google's own guidance makes clear that Core Web Vitals scores affect search rankings, so a build that ignores them costs you twice. Also ask whether basic SEO is included. Title tags, meta descriptions, clean URL structure, an XML sitemap. These are not extras. They should be standard. If the quote doesn't mention them, they probably aren't in it. One honest caveat worth naming, even a well-built site needs time to gain traction. Don't expect results overnight, and be cautious of anyone who promises otherwise. Related: What a Web Design Company Actually Does for Your Money ------------------------------------------------------------ # What Search Engine Optimisation Companies Actually Do All Day Source: https://yorkshiredesign.co.uk/what-search-engine-optimisation-companies-actually-do-all-day/ Published: 2026-07-12 > Most clients never see the work. They see a monthly report, maybe a ranking change, and a bill. That gap between what search engine optimisation companies charge and what they visibly produce is where most of the frustration lives. The honest answer is that the bulk of SEO work happens in places most clients never look. Server configurations. Crawl reports. Page structure. It is not glamorous, and it does not move fast. But it is the work that actually matters. The Work That Fills Most Days A typical day for a serious SEO practitioner is largely unglamorous. Crawl logs, indexation reports, duplicate content checks, page speed analysis. These are not tasks you can photograph or put in a presentation slide. They are quiet, methodical and take real time to do properly. Good search engine optimisation companies tend to spend a significant portion of their time just diagnosing. Before you can fix anything, you need to understand what is actually broken. That means reading raw data rather than relying on a dashboard summary that smooths over the detail. Technical Fixes Nobody Told You About Most clients come in expecting keyword lists and content plans. Those matter. But what often holds a site back has nothing to do with content. It is a slow server response time, a bloated database, redirect chains that have built up over years, or images that weigh three times what they should. On a WordPress site, for example, the difference between a page that loads in one second and one that loads in four is rarely a single fix. It is ten small ones. Schema markup, Core Web Vitals, crawl budget, internal link structure. Each piece is part of the same picture, and you cannot skip to the end. When a site has technical problems quietly dragging it back, no amount of content will compensate. This is the unseen work that takes time. It rarely gets explained on a call, because explaining it properly would take longer than doing it. What Keyword Research Really Involves It is not typing ideas into a tool and picking the ones with the biggest numbers. That approach produces a list that looks good and performs badly. Real keyword research involves understanding how people phrase a question at different stages of a decision. Someone searching 'what is SEO' is nowhere near ready to buy. Someone searching 'SEO company prices UK' is much closer. Good SEO work maps those differences and builds content to match intent, not just volume. It also involves checking what already ranks. If the top ten results are all major publications or national brands, a small business site is not going to break into that page without a very long runway. Honest search engine optimisation companies tell you that upfront. The ones who do not will have you waiting indefinitely for results that were never coming. On-Page Work: Slower Than It Looks Rewriting a page's title tag takes thirty seconds. Rewriting it well, after checking the SERP, reading the top-ranking content, and deciding on the right angle, takes much longer. Multiply that across fifty pages and you start to understand where the hours go. Meta descriptions, heading structure, internal linking, page copy that serves both Google and a real human reader. Each element needs thought. Done carelessly, it can make things worse. A heading structure that confuses crawlers, or internal links that point users away from the pages that convert, are common mistakes that come from moving too quickly. Plenty of people underestimate how much the on-page process compounds over weeks and months of steady attention. Reporting and Why It Is Not Enough on Its Own Every SEO company sends reports. Rankings, impressions, clicks. These are useful. They are not the whole story. What a report rarely shows is the work behind it. A ranking improvement on a competitive term can take months of quiet, consistent effort to produce a single position change. That does not look impressive on a graph. But that is how it works. Don't expect results overnight, and be sceptical of anyone who tells you otherwise. Worth saying plainly, a report full of green arrows does not always mean your business is growing. Traffic that does not convert is not success. The best search engine optimisation companies measure what matters to your revenue, not what flatters their dashboard. What Actually Gets Results Thoroughness. Paying close attention to the technical detail that most people overlook. Building clean, well-structured pages. Writing content that answers real questions rather than stuffing in phrases. Getting the smaller performance details right, including images and load times, because Google notices everything. None of it is fast. The sites that perform well in search have usually had consistent, careful work behind them for a long time. There are no shortcuts that hold up. Related: 7 Things a Search Engine Optimisation Company Actually Does Related: What a Search Engine Optimisation Company Actually Does ------------------------------------------------------------ # WordPress Themes: What’s Under the Hood Actually Matters Source: https://yorkshiredesign.co.uk/wordpress-themes-whats-under-the-hood-actually-matters/ Published: 2026-07-12 > Most people pick a WordPress theme because it looks right. That's understandable. But the look is the easy bit. What the theme is doing underneath, the code it loads, the scripts it fires, the bloat it carries, is what actually determines how fast your site runs and how well Google treats it. A good-looking theme built on poor foundations will hold you back from day one. Start With What the Theme Loads, Not How It Looks Before you buy or install anything, check what the theme actually pulls in. A lot of themes bundle jQuery plugins, sliders, icon libraries, and Google Fonts requests that fire on every single page, even when you're not using those features. That adds weight. It also adds render-blocking requests, which means the browser sits waiting before it can show the user anything. Use your browser's developer tools or run the demo URL through PageSpeed Insights before committing. You'll see exactly how many requests the theme makes on a blank page. Fewer is almost always better. Theme Code Quality Is the Thing Nobody Talks About Two themes can look identical in a screenshot. Open the source code and they'll be completely different stories. A well-built theme has clean, minimal markup. A poor one wraps every element in four unnecessary divs, loads its own CSS reset on top of WordPress core styles, and registers scripts it never uses. That extra code doesn't just slow the page. It can conflict with plugins, break during WordPress updates, and make any future changes needlessly painful. The unseen work that takes time is often undoing what a badly built theme set in motion. If you can, look at the theme's functions.php. It tells you a lot. A clean file, well-commented, with targeted enqueues, is a good sign. A file that reads like a dumping ground is a warning. Block Themes vs Classic Themes: Understand the Difference WordPress has moved toward block-based themes built on Full Site Editing. These use theme.json to control typography, spacing, and colour, rather than scattered CSS across multiple files. For most new builds, a block theme handled properly will give you leaner output than an older classic theme loaded with page builder dependencies. That said, block themes are not automatically better. A poorly built block theme can generate just as much unnecessary markup. The format matters less than the execution. What you're looking for is a theme that gives the browser less to do, whatever the approach. Page Builders Change the Equation Some themes are built to work with a page builder, Elementor being the obvious example. That's not inherently wrong. But you need to understand that the page builder itself adds another layer of code. You're not just loading the theme, you're loading the builder's assets on top of it. This is where Core Web Vitals scores can fall apart. Largest Contentful Paint suffers when there are too many render-blocking files. Cumulative Layout Shift creeps in when fonts and images load late. For anyone doing serious SEO work, these scores matter. Google's own guidance confirms that page experience signals factor into how pages rank. If you need a page builder, look for one that loads assets conditionally, only on pages where its elements are actually used, not sitewide on every request. What Most People Get Wrong When Switching Themes Switching themes mid-life on an established site is where things quietly go wrong. Content built with one theme's shortcodes or custom blocks often breaks or renders as raw text when you swap the theme out. It's not always visible in the backend. Sometimes you only spot it on the front end after you've already switched. Before you change theme, audit every page. Check for theme-specific shortcodes. Export your content and read it. The technical knock-on effects of a badly handled theme migration, broken markup, orphaned styles, missing structured data, are exactly the kind of unseen work that takes time to diagnose and fix properly. The Hosting Side Matters Too Even a well-coded theme will underperform on the wrong server. PHP version, server response time, and caching all interact with how a theme renders. If your host is running an outdated PHP version, some theme features won't work as intended, and you'll see slower execution times. Pairing a clean theme with hosting that's actually set up for WordPress makes a real difference to the numbers. Pick Boring Over Clever The best themes for performance are often the least exciting ones to look at in a demo. They're clean, they load fast, and they get out of the way. Plenty of popular, heavily marketed themes are slow by design because they're built to impress in a screenshot, not to perform in the real world. Don't expect results overnight once you've sorted your theme. But getting the foundation right means everything you build on top of it, SEO, content, conversions, has a fair chance of working. Start with a theme that doesn't fight you. ------------------------------------------------------------ # How to Optimise SEO Without Expecting Results Overnight Source: https://yorkshiredesign.co.uk/how-to-optimise-seo-without-expecting-results-overnight/ Published: 2026-07-12 > A client once asked why their new site wasn't ranking after two weeks. Good question. The site was clean, the copy was solid, and the technical side was tidy. But two weeks is nothing. SEO doesn't work like a light switch. There's unseen work that takes time before Google even forms a clear picture of what a site is about. Understanding that gap between doing the work and seeing the result is the first honest step toward getting it right. What Google Is Actually Doing While You Wait Google doesn't index a page and immediately know where to rank it. It crawls, indexes, processes signals, and then runs the page against thousands of competing results. That process takes weeks, sometimes months, depending on how often your site is crawled and how much authority it already has. A brand new domain gets crawled infrequently at first. Google is cautious. It wants to see consistency before it commits ranking real estate to something it doesn't know yet. That's not a flaw in the system. It's the system working as intended. Start With the Technical Foundation Most sites have problems Google can't see past. Slow page loads, missing canonical tags, crawl errors, thin pages competing with each other for the same keyword. These aren't exciting fixes, but they matter more than any clever content strategy built on a broken base. Core Web Vitals are a good place to start. Google's own guidance names page experience as a ranking factor, and a site that loads poorly on mobile is fighting uphill before it's even said anything useful. Fix the foundation first. Everything after that works harder when the base is solid. If you're on WordPress, the structure of your site often creates internal linking problems that quietly dilute your rankings without any obvious warning sign. Worth checking before you write another word of new content. What's Actually Worth Your Time Early On Keyword research, yes. But not chasing the big broad terms nobody new can realistically rank for. Find the specific questions your actual customers are typing in. Longer, more specific phrases convert better and compete less. Get your title tags and meta descriptions right. They don't directly boost rankings, but they affect click-through, and Google notices that. A well-written snippet that earns the click is doing quiet work in the background. For a practical look at writing snippets that actually get clicked, that's worth a read before you touch another meta description. Beyond that, build content that answers real questions thoroughly. Not thin pages. Not keyword stuffing. Actual useful content that a person would share or bookmark. The Thing Most People Get Wrong They optimise once and wait. SEO isn't a one-time task. It's more like maintenance on a car. You don't service it once and expect it to run perfectly forever. Pages need reviewing. Rankings shift. Competitors publish new content. Search intent changes over time. The sites that hold their positions are the ones where someone is paying attention consistently, not just at launch. Honest caveat here. There are situations where even thorough, well-executed SEO takes a long time to pay off, and sometimes a specific keyword proves harder to crack than the research suggested. That happens. It's not always a sign that something's wrong. Don't expect results overnight, and don't panic if month two looks the same as month one. Where AI Fits In AI tools can help with content ideation, spotting gaps in coverage, and processing data faster than any manual audit. But they don't replace judgement. A list of suggested keywords from a tool is only useful if someone with experience knows which ones actually make sense for the business. There's a lot of noise around AI and SEO right now. If you want a plain-English breakdown of what actually works versus what's mostly hype, that cuts through most of it. The short version is that AI is a useful tool, not a shortcut to rankings. A Realistic Timeline For a site with some existing authority, three to six months of consistent work usually starts to show movement. A brand new domain in a competitive space can take longer. That's not a cop-out. It's just how search engines build trust. The clients who get the best results for their spend are the ones who treat SEO as an ongoing process rather than a campaign with a deadline. They ask good questions, they don't panic at week four, and they let the thorough, patient work compound over time. That's the part nobody selling a quick fix will tell you. ------------------------------------------------------------ # How to Write Product Page Copy That Actually Ranks Source: https://yorkshiredesign.co.uk/how-to-write-product-page-copy-that-actually-ranks/ Published: 2026-07-11 > Most product pages fail before a visitor even arrives. They're thin, they repeat the manufacturer's description word for word, and Google has no real reason to show them to anyone. Writing product copy that ranks isn't about stuffing in keywords. It's about giving the page enough substance that it earns its place in search results. This is what that actually looks like. Why Most Product Pages Are Invisible to Google A product page with 80 words and a borrowed image tells Google almost nothing. There's no context, no depth, no signal that this page knows more about the product than any other page on the internet. Google's quality guidelines are clear that pages need to demonstrate genuine expertise. A thin description copied from a supplier catalogue does the opposite. It signals that the page is interchangeable, and interchangeable pages don't rank well. The fix isn't complicated. It takes time, and it takes actually thinking about what a buyer needs to know. Start With What the Buyer Is Actually Asking Before writing a single word, think about the person searching. What problem are they trying to solve? What do they need to know before they'll feel confident buying? What would make them hesitate? For a waterproof jacket, that might be seam sealing, weight, and how it packs down. For a piece of software, it's compatibility and what happens if they need support. The keyword matters, but the intent behind the keyword matters more. A product page that genuinely answers those questions will outperform one that's been padded with keyword variations. Specifics win. "Weighs 340g and compresses to the size of a water bottle" beats "lightweight and packable" every time, both for the reader and for search. Write a Description That Goes Beyond the Spec Sheet The spec sheet tells people what the product is. Good copy tells them why that matters. "1200 thread count" is a spec. "Soft enough that most people stop noticing the bedding within a week" is what that spec means to someone lying in it. Both belong on the page. The spec answers the factual search. The explanation earns the trust to buy. Aim for somewhere between 300 and 600 words on a strong product page. That's enough room to cover the product properly without padding. If you genuinely can't reach 300 words without repeating yourself, the product probably needs a supporting FAQ section or a 'who this is for' paragraph to add real context. For pages that are already written but still not ranking, the issue is often thinner than it looks. You can see a pattern quickly when you audit the technical side alongside the copy. Use the Right Keywords, in the Right Places The focus keyword belongs in the page title, the first paragraph, at least one subheading, and naturally through the body. That's it. There's no magic number of times to repeat it. What often gets missed is the supporting vocabulary. Google understands related terms. A page about running shoes that also mentions heel drop, pronation, and road versus trail running signals topical depth. One that just says "running shoes" fifteen times signals the opposite. Don't forget the meta description. It won't lift rankings directly, but a well-written snippet increases the chance someone actually clicks. A clear, benefit-led sentence there does real work, and it's one of the easier wins on any product page. See how a properly written snippet performs differently in the results. The Honest Trade-off Most People Don't Mention Good product page copy takes time to write properly. A catalogue with 400 products cannot realistically have 400 hand-crafted descriptions in a week. Anyone who tells you otherwise is either underestimating the work or planning to cut corners somewhere. The practical approach is to prioritise. Start with your best-selling products, your highest-margin lines, and the pages already close to ranking. Get those right first. Thin pages on low-traffic products can wait. Don't expect results overnight either. A page rewritten today might take eight to twelve weeks before you see any movement in rankings. That's normal. The unseen work that takes time is exactly that, unseen until it isn't. Structure Helps Both Readers and Search Engines A wall of text puts people off. Break the page up. Use a short intro paragraph, a bullet list of key features, a longer descriptive section, and an FAQ block if the product has common questions attached to it. That FAQ block isn't just helpful for users. Google often pulls FAQ content into search results directly, which means more visibility without needing a higher ranking. It also forces you to think about what people actually want to know, which tends to improve the main copy too. Clear structure also makes the page easier to read on a phone, where most ecommerce traffic now arrives. If someone has to squint or scroll past a dense paragraph to find the size guide, they'll leave. Good content that's built to be read performs better than content that's built to look complete. ------------------------------------------------------------ # AI Workflow Automation for Agencies: What’s Real and What Isn’t Source: https://yorkshiredesign.co.uk/ai-workflow-automation-for-agencies-whats-real-and-what-isnt/ Published: 2026-07-11 > Most people assume web design agencies are using AI to write all the code and replace their developers. That's not really what's happening. The agencies actually cutting delivery time are using AI in far more unglamorous places, brief analysis, content structuring, image preparation, QA checklists. The flashy stuff gets the attention. The quiet process work is where the time savings actually live. Here's what's genuinely changing, and where the myths are getting in the way. Myth: AI writes the website so delivery is almost instant This one comes up constantly. The assumption is that an agency types a prompt and a finished site appears. In reality, AI-generated code needs heavy review before it goes anywhere near a live server. It can produce functional-looking output that breaks under real conditions, fails accessibility checks, or quietly ignores performance best practice. The code might look right. That doesn't mean it is right. The agencies cutting genuine time from their schedules are using AI as a drafting tool, not a finisher. They review, rewrite, and test everything. That's not a limitation to hide. That's just how responsible development works. Myth: AI content tools mean you don't need a copywriter AI can produce a serviceable first draft faster than any human. That part is true. What it can't do is bring real knowledge of your client's business, their customers, or the specific way they want to come across. Generic output reads generic. Most clients notice, even if they can't quite say why. Where AI content tools genuinely help is in the structural groundwork. Generating page outlines, writing meta descriptions at scale, producing FAQ drafts from a list of topics. That kind of repetitive, templatable work is exactly what AI handles well. Agencies using AI well still have a human refining every word that goes out. The tool cuts the blank-page problem. It doesn't cut the thinking. Myth: Automating agency workflows is a technical project most small agencies can't manage This puts a lot of people off before they've even started. The truth is that some of the most effective AI workflow automation for agencies involves nothing more complex than a well-structured prompt template, a form, and a tool like Zapier or Make connecting the two. You don't need to build software from scratch. A practical example is client onboarding. Feeding a completed brief into an AI tool to generate a scoped project outline, a suggested page structure, and a first-pass content checklist takes minutes instead of hours. That's not exotic. It's just a repeatable process with AI doing the drafting leg work. For a look at how to introduce this kind of thinking without disrupting what already works, the post on starting automation without breaking your workflow covers the practical starting points well. Myth: Faster delivery means lower quality This one has things backwards. The agencies reducing delivery time through AI automation are mostly cutting the administrative drag, not the craft. Brief processing, asset organisation, copy structuring, report generation. These are real time costs that have nothing to do with the quality of the finished site. If anything, removing that drag gives designers and developers more focused time on the work that actually matters. The structure of a site, its load performance, how it handles real traffic. That's where quality lives, and AI isn't cutting corners on any of it. It's freeing up attention for it. What agencies are actually getting right The honest answer is that the gains come from boring places. Automating the brief-to-scope handoff. Using AI to produce image alt text in bulk. Running automated accessibility and performance checks before any human QA pass. Generating first-draft page titles and meta descriptions from page content, then editing them down. None of that sounds exciting. All of it compounds over a project. A site that might have taken four weeks to deliver starts finishing in three, not because the hard work disappeared, but because the surrounding admin was handled faster. Knowing where to put the right information in a brief also tightens this loop considerably, less back-and-forth means less time lost before a line of work is even written. Where AI workflow automation for agencies genuinely falls short Client relationships. Anything that requires reading between the lines of what a client said versus what they meant. Design decisions that depend on brand feel rather than specification. These are still fully human problems, and no amount of automation changes that. Don't expect too much from the tools. AI handles repetition well. It handles ambiguity badly. Build your automations around tasks that are already clearly defined, and keep a human in the loop for anything that requires actual judgement. That balance is what separates agencies using AI sensibly from those chasing hype and delivering worse work faster. ------------------------------------------------------------ # Image Optimisation in WordPress: What Plugins Miss Source: https://yorkshiredesign.co.uk/image-optimisation-in-wordpress-what-plugins-miss/ Published: 2026-07-10 > Plugins make image optimisation feel easy. Upload, compress, done. Except it is not done, not by a long way. The compression part is maybe thirty percent of the job. The rest sits in file format choices, delivery settings, markup decisions, and server config that no plugin touches automatically. This post covers what the plugins actually handle, where they stop, and what you have to do yourself if you want the full gain. What Compression Plugins Actually Do Compression plugins do one thing well. They reduce file size by stripping data from your images, either losslessly or by discarding some visual detail. That is genuinely useful, and most sites benefit from it. A plugin like ShortPixel or Imagify will take a 2MB JPEG uploaded by a client and bring it down to 300KB or less, often without any visible quality loss. It does that automatically, in the background, without you touching a thing. Some plugins also convert images to modern formats like WebP, which loads faster in supporting browsers. That combination of smaller file size and a more efficient format is the bulk of what plugin-based optimisation actually delivers, and for many sites it moves the needle on page load time in a meaningful way. What plugins cannot do is fix the problems that exist before compression runs. If someone uploads a 5,000-pixel-wide photograph to fill a 400-pixel thumbnail slot, the plugin compresses that oversized image and serves it anyway. The browser still has to download far more data than the layout requires. Similarly, no compression plugin sets your width and height attributes correctly, controls how images are loaded relative to the viewport, or decides which image should be in the critical path and which can wait. Those decisions sit outside the plugin's scope entirely. File Format Choices That Plugins Get Wrong Most image optimisation plugins default to converting everything to WebP, and on the surface that makes sense. WebP is well supported, compresses well, and Google likes it. The problem is that "convert everything" is a blunt approach. A photograph with thousands of subtle colour gradients suits WebP or JPEG well. A logo or icon with flat colours, hard edges, and transparency is a different matter entirely. PNG preserves that kind of image cleanly without introducing the blocky artefacts that lossy compression creates. Converting a transparent logo to WebP with aggressive settings can leave halos and colour fringing that look fine in a thumbnail and terrible at full size. AVIF compresses even smaller than WebP and handles both photographic and graphic content well, but browser support is still catching up, and if you're not serving a fallback, older browsers will simply show nothing. The technical side of format selection matters far more than most plugin settings pages suggest. The plugin does the conversion. You have to decide the rules it follows. Blanket settings applied across an entire media library are where the real optimisation decisions get made, and most people never look at them. Don't expect a single toggle to cover every image type correctly. Format choice is context-dependent, and that judgment still sits with you. Dimensions and Display Size: The Gap Nobody Closes Most compression plugins do exactly what they say. They take whatever image you upload and reduce the file size. The problem is that "whatever you upload" is often a 4000px wide photo straight from a camera or a stock site, destined for a sidebar slot that displays at 600px. The plugin compresses it faithfully at full resolution, hands it back, and marks the job done. You end up with a smaller version of a still-enormous image. The browser then downloads all those pixels it will never use and scales the image down in the viewport, which costs loading time and does nothing for your Core Web Vitals score. That gap, the distance between upload dimensions and display dimensions, is almost never closed by a plugin automatically. It is the one thing you have to sort out yourself before compression even becomes relevant. The fix is straightforward once you know what to look for. Check what size the image actually renders at on your page, using browser dev tools or a tool like Google's PageSpeed Insights. Then resize the source file to match that display size before uploading. A 600px display slot needs a source image somewhere around 1200px wide to account for high-density screens, not 4000px. Once you have the dimensions right, a good approach to format and compression will actually move the needle. Getting the dimensions wrong first means you are optimising the wrong thing entirely. Lazy Loading: What WordPress Gives You by Default and Where It Falls Short WordPress has added loading="lazy" to images automatically since version 5.5. That sounds like a job done, and for most images buried halfway down a page, it is. The browser defers loading them until they're close to entering the viewport, which cuts initial page weight and helps load times on image-heavy posts. The problem is that WordPress applies this attribute broadly, and it doesn't always distinguish between images the user will never see until they scroll and images that land directly in front of them the moment a page opens. That distinction matters a lot more than most people realise when you're trying to improve your overall Core Web Vitals score. The image most likely to hurt you is your Largest Contentful Paint element. That's usually a hero image, a large featured photo, or a banner sitting above the fold. If that image carries a lazy load attribute, the browser deliberately delays fetching it. Your LCP time suffers directly as a result. Google's own guidance on LCP is clear on this point, and yet it's the one thing WordPress native lazy loading doesn't protect you from out of the box. The fix is simple but manual. Remove loading="lazy" from your LCP image, or add fetchpriority="high" alongside it. Neither happens automatically. That's the part no plugin reliably handles for you. CDN Delivery and Why Local Hosting Limits Your Gains Compress an image down to 40KB and it still has to travel from your server to your visitor. That journey matters more than most people realise. A CDN, or content delivery network, stores copies of your images across servers in different locations. When someone in Sydney loads your site, they get the image from a nearby node rather than a server sitting in a data centre in London. The file size stays the same, but the physical distance it travels shrinks dramatically, and that cuts latency in a way no compression plugin can touch. Most WordPress image plugins do not come anywhere near this. They optimise the file, then leave it sitting on your origin server waiting for every request. Cloudflare, BunnyCDN and similar services handle the delivery side, and they need to be set up separately. It is not complicated, but it does not happen automatically. The honest trade-off is that a CDN adds a layer to your setup, and if it is misconfigured you can end up serving stale images or breaking cache rules you spent time putting in place. Done right though, delivery improvements on a properly configured caching setup compound each other. That is where real-world load time improvements come from, not from shaving off another few kilobytes. The Manual Checks No Automation Replaces Plugins will compress a file and move on. They won't tell you that your hero image is 2400px wide when the container only ever renders at 1200px, or that the same background graphic is loading on mobile where it contributes nothing to the page. That kind of judgement comes from actually looking at the site, not reading a plugin dashboard. The hero image is worth real attention. It loads first, it sits above the fold, and if it's oversized or the wrong format it costs you on Core Web Vitals before the rest of the page has even started. Resize it properly for the breakpoints you actually use, and test it on a real device, not an emulator. Alt text is the other area that automation gets badly wrong. A plugin can flag a missing attribute, but it can't write accurate alt text. Decorative images should have an empty alt attribute so screen readers skip them entirely. Content images need a short, plain description that tells both the user and Google what's actually there. Stuffing keywords into every alt tag is an old habit that does more harm than good, and getting the format and load behaviour right matters just as much as the words you write. Don't trust plugin scores as a final answer. Load the page over a real mobile connection and watch what actually happens. Related: Page Speed Fixes That Actually Move Core Web Vitals ------------------------------------------------------------ # The History of WordPress: Versions, Turns and What It Taught Me Source: https://yorkshiredesign.co.uk/the-history-of-wordpress-versions-turns-and-what-it-taught-me/ Published: 2026-07-10 > WordPress powers roughly a third of the web. That is a strange fact when you remember it started as a blogging tool in 2003. I have been building sites since before WordPress existed, and I have watched it change from something I was sceptical about to something I use every day. This is not a Wikipedia summary. It is an honest look at what WordPress actually is, where it came from, and what each big shift meant for people building sites on it. Before WordPress: What the Web Looked Like Building a website in the early 2000s meant writing every line yourself. There was no drag and drop, no plugin library, no update button. I built Find-Me-Now.com in 2005, and the process was exactly what you'd expect from that era. PHP files, hand-rolled HTML, a text editor, and a lot of patience. Every page was a decision. Navigation links were hardcoded. If you wanted to change the header across thirty pages, you changed it thirty times, or you wrote an include file and hoped it behaved. Databases were MySQL, queries were written by hand, and if something broke at 2am you were the one fixing it. There was no community forum to rescue you. You either knew what you were doing or the site stayed broken. I genuinely enjoyed it. There is something satisfying about understanding every layer of what you have built, knowing exactly why a page loads the way it does because you wrote the logic that makes it happen. That grease-monkey instinct, wanting to see what is going on underneath rather than just polishing the surface, came from those years of handbuilt work. I was working with Google at Palo Alto in 2004, and even there the web felt raw compared to what came later. The infrastructure existed, the traffic was real, but the tooling for building and managing sites was still largely a DIY exercise. Content management was either a custom-built admin panel someone had cobbled together in PHP, or it simply did not exist. You published by FTP. That was the web WordPress was born into, and understanding that context matters if you want to understand why it changed everything. WordPress 1.x to 2.x: A Blogging Tool, Nothing More WordPress started as a fork. In May 2003, Matt Mullenweg and Mike Little took the b2/cafelog codebase, which had been largely abandoned by its original developer Michel Valdrighi, and rebuilt it into something they could actually use. The name came quickly. The first proper release, version 0.70, landed that same month. It was rough, it was simple, and it did one thing, it let you publish blog posts. There was no plugin architecture to speak of, no theme system in the way we understand it now, and the template tags were basic enough that any halfway competent PHP developer could read the whole codebase in an afternoon. That simplicity was the point. Mullenweg wanted a publishing tool that a non-technical person could install and use without calling in a favour. Version 1.0, named after jazz musician Miles Davis, arrived in January 2004. It introduced a genuine template system and the beginnings of a plugin hook structure. By 1.5 in February 2005, named after Strayhorn, you had theme support and the Kubrick default theme that stuck around for years. These were real steps forward, but the platform still sat firmly in the "personal blog" category. Serious developers building actual business sites were not paying attention. PHP developers with any experience were hand-rolling their own CMS or using something like Drupal, which had a proper content architecture from early on. WordPress felt lightweight by comparison, and not always in a flattering way. Version 2.0 arrived in late 2005 and brought a redesigned admin panel and WYSIWYG editing via TinyMCE. Useful, but still not enough to shift the perception. It was a blogging tool. That was the honest truth of it. WordPress 3.x: The Version That Changed Everything Before version 3.0, I kept WordPress at arm's length. It was a blogging tool, and a fairly limited one at that. I was building sites in PHP by hand, and that felt like the right way to do serious work. Then WordPress 3.0 dropped in 2010 and merged the main platform with WordPress MU, the multisite variant that had been running separately for years. Suddenly you could run multiple sites from a single install, manage them from one dashboard, and actually think about WordPress as infrastructure rather than just a content layer. That merger alone changed the conversation. But what really shifted my thinking was custom post types. Custom post types meant you were no longer stuck forcing everything through the 'post' or 'page' model. A property listing, a staff profile, a product, a case study , each could have its own structure, its own fields, its own admin interface. That is when WordPress stopped being a blog platform and started behaving like a real CMS. Pair that with custom taxonomies and you had a content architecture that could serve almost any kind of site without hacking the core to pieces. It was not perfect, but it was serious. I remember building a property site around that time and thinking, for the first time, that WordPress was doing the heavy lifting rather than fighting me. That shift in 3.x is also where a lot of the bad habits crept in. Developers started treating WordPress as a framework it was never quite designed to be, loading custom post types and meta boxes onto sites that did not need them, and wondering later why performance had fallen off a cliff. Understanding what sits underneath the surface of a WordPress build matters far more than most people realise, and the 3.x era is honestly where that lesson started. The Gutenberg Era: WordPress 5.x and the Block Editor WordPress 5.0 dropped in December 2018 and with it came Gutenberg, a block-based editor that replaced the old TinyMCE setup most developers had built their workflows around. The idea was sound enough. Instead of writing HTML in a text box and hoping your theme rendered it cleanly, you would place discrete content blocks, paragraphs, images, headings, columns, each self-contained. On the surface that looks tidier. Under the hood it was a significant shift in how content is stored. Every block is wrapped in HTML comments that act as delimiters, so the database now holds structured markup rather than raw prose. That is fine until you switch themes or drop the plugin that registered a custom block, at which point those comment tags become orphaned and your content page looks like a car with its engine on the back seat. I have spent more than a few afternoons unpicking exactly that kind of mess for clients who changed themes without realising what Gutenberg had quietly done to their post data. The Classic Editor plugin hit over five million active installs almost immediately, which tells you everything about how the community felt at the time. Developers who had built shortcode-heavy sites or relied on the old meta box layout found whole sections of their admin UI rearranged or gone. Page builders like Elementor carried on largely unaffected because they were already abstracting the editor away, but anyone building leaner sites without a builder had to rethink their approach. What Gutenberg did fix is real, though. Full-site editing, introduced properly in the 5.9 cycle, finally gave non-technical users a way to edit headers and footers without touching PHP templates. Block patterns made consistent layout reuse straightforward. And for technical SEO on WordPress, the shift to cleaner block output, when you keep the block count sensible, tends to produce leaner markup than the old shortcode soup ever did. It is not perfect, but it is the direction WordPress is heading and the internals are more coherent for it. WordPress Types: Core, Multisite, Headless and the Rest Most people think of WordPress as one thing. It isn't. A standard single-site install is what the majority of people run, and it covers most use cases well. You get a database, a theme, a plugin directory, and a front end that WordPress itself renders. That's the setup I've worked with since the early days, and it still makes sense for the vast majority of client projects. But underneath that familiar admin panel, WordPress has grown into something considerably more flexible. Multisite networks, for instance, let you run dozens or even hundreds of separate sites from a single WordPress installation, each with its own content, its own users, and optionally its own domain. News publishers and university departments tend to use this setup because managing updates and plugins from one place is far more practical than maintaining separate installs. The trade-off is complexity. A misconfigured multisite can create permission headaches and plugin conflicts that take real time to unpick. If you're choosing someone to build on this kind of architecture, it's worth knowing what you're looking for. Then there's headless WordPress, which is a genuinely different way of thinking about the platform. In a headless setup, WordPress handles content management and data storage, but it doesn't render the front end. Instead, the REST API serves content as JSON to a separate front-end framework, typically something like Next.js or Nuxt. The result can be extremely fast and gives developers fine control over performance. The downside is that you lose a lot of the convenience that makes WordPress approachable. Theme customisers, page builders, and many plugins simply don't apply. It's a setup that suits high-traffic editorial sites or web apps more than a small business wanting to update their own pages. Knowing which deployment type fits the actual brief is part of building websites properly from a technical perspective, not just picking the most fashionable option. What WordPress Still Gets Wrong (and How to Work Around It) WordPress carries a lot of baggage. The more a site grows, the more that baggage weighs on every page load. Database bloat is the problem most people ignore until something breaks. Every time a post is saved, WordPress creates a revision. Every plugin that runs an automated task writes to the database. Over a few years, a busy site can accumulate tens of thousands of rows that serve no purpose at all. That noise adds up. Queries take longer, pages load slower, and Core Web Vitals scores start to slip in ways that are genuinely hard to diagnose unless you know where to look. The fix is straightforward, regular database maintenance, pruning revisions, clearing transients, and keeping autoloaded data to a minimum, but almost nobody does it until the damage is visible. If you want to understand what is actually happening under the hood, this breakdown of database bloat and page speed covers the specifics in plain terms. Plugin dependency is the other structural problem. WordPress makes it too easy to install a plugin for every small task. Before long, a site is running thirty plugins, several of which are doing overlapping jobs, loading scripts on pages that do not need them, and quietly killing Largest Contentful Paint scores. The right approach is to do more in code and less through plugins. That takes more time upfront, but the performance headroom it creates is real and lasting. Hosting choices matter more than most people admit. A slow server makes every optimisation effort pointless. WordPress does not self-tune to a bad environment, no amount of caching fixes a genuinely underpowered host. Pick the wrong plan and you are fighting the infrastructure on every page. Don't expect too much from a five-pound-a-month shared account. Where WordPress Is Heading and What That Means for Your Site Full Site Editing has been the biggest structural shift in WordPress since Gutenberg landed. The idea is sound, give site owners control over headers, footers, and templates without touching PHP. In practice, the execution is still catching up. FSE themes are getting more capable with each release, but the underlying block system adds markup that needs careful attention if you care about page speed and Core Web Vitals. A block-heavy homepage can easily balloon with render-blocking assets if nobody is watching the output. That is the part most people building with FSE miss, and it is exactly the kind of unseen work that makes the difference between a site that ranks and one that sits there looking fine but loading slowly. AI integration is coming into WordPress properly now. Not just content tools bolted on top, but automation woven into the build itself. I built the ComPOS AI Automation System to handle exactly that kind of workflow. The goal was a leaner stack where repetitive tasks run without manual input, and the site stays fast because nothing unnecessary is being loaded. That is where WordPress development is heading, and the sites that get it right will be noticeably quicker and easier to maintain than those still running ten plugins doing what one automated process could do. If you want to understand how automation tools compare at the workflow level, this breakdown of Make vs Zapier for WordPress covers the practical differences. Faster, leaner, information-rich. That is the direction. A site built properly from a technical perspective is the foundation that makes everything else, the SEO, the automation, the content, actually work. ------------------------------------------------------------ # AI-Generated Content and Google Penalties: What Actually Gets You Source: https://yorkshiredesign.co.uk/ai-generated-content-and-google-penalties-what-actually-gets-you/ Published: 2026-07-10 > A lot of people are worried about using AI-written content and getting hit by Google. The concern is understandable, but most of it is aimed at the wrong target. Google does not penalise content because a machine wrote it. It penalises content that is thin, repetitive, or built to game rankings rather than help a reader. Those are different problems. This post walks through what Google actually flags, what the Quality Rater Guidelines say, and where the real duplicate risk sits. What Google's Guidelines Actually Say About AI Content Google has been clear on this. The source of content, whether a person wrote it or a machine did, is not what triggers a penalty. The Quality Rater Guidelines and Google's own public statements consistently point to the same measure, does the content actually help the person reading it? Google's documentation describes what it's looking for as content that demonstrates experience, expertise, authoritativeness and trustworthiness. None of those qualities are exclusive to human writers. A well-constructed AI article that answers a real question with accurate, specific information sits on the right side of those guidelines. A human-written page stuffed with repeated keyword phrases and no real substance sits on the wrong side. Google has said as much directly, in plain language, through multiple Search Central posts and John Mueller's public statements over the years. The framing that 'AI content equals penalty' is a simplification that doesn't hold up against the actual documentation. What Google does penalise is content produced at scale with the primary purpose of manipulating rankings rather than helping readers. That is the line. It has always been the line, long before AI writing tools existed. The mechanism changed but the intent-based standard did not. If you love your business, other people will love your business, and the money will take care of itself. Chasing volume for its own sake is the problem, not the tool you used to produce the words. The Duplicate Content Problem Nobody Talks About The real risk with AI-generated content is not that Google can detect a robot wrote it. The risk is that the same model, trained on the same data, generates the same sentences for thousands of different websites. Ask ten different people to use a popular AI tool to write about, say, "what is technical SEO", and you will get ten articles that share whole phrases, the same structural beats, and near-identical introductions. Publish that at scale and you have a duplicate content problem, not because your page copied another page, but because the source material did. Google's systems are built to filter redundant results, and pages that look algorithmically similar to dozens of others already in the index tend to rank poorly or not at all. That is where the actual algorithmic risk sits. The fix is not to avoid AI. It is to treat any AI output as a first draft that needs genuine editorial work, real examples, and specific knowledge that comes from actually doing the work. That is what separates a page that ranks from one that disappears into page four. If you want to understand how thin or duplicate content interacts with site performance, the technical SEO fixes that actually move rankings cover the structural side of this in plain terms. Thin Content vs Scaled Abuse: Google Draws a Clear Line A short page that answers one question clearly is not a problem, even if AI helped write it. Google's issue has never been with brevity. It has been with intent. When a site publishes hundreds of near-identical pages targeting slight keyword variations, each one adding nothing that the others do not already say, that is scaled content abuse. That is what the Helpful Content updates were built to catch. The signal Google is looking for is not length or authorship. It is whether a real person would find the page genuinely useful, or whether it exists purely to occupy a search result. The practical difference is straightforward. One AI-assisted page explaining how to fix a WordPress caching conflict, written with real knowledge behind it, sits on the right side of that line. Five hundred auto-generated product description pages that swap out a single noun do not. Where it gets harder is in the middle ground. A page that is technically unique but adds no real depth, no original angle, no useful detail that a reader could not find in two seconds elsewhere, that qualifies as thin regardless of how it was produced. AI makes it easier to generate that kind of content at volume, which is exactly why Google tightened its stance. If you want to understand how content quality connects to actual rankings, this piece on AI content writing for SEO covers where the real risks sit. The tool is not the issue. The lack of effort is. How to Use AI Content Without Triggering a Quality Signal The practical fix is straightforward, even if it takes a bit of discipline. Start with AI output as a rough draft, not a finished page. Read every sentence and ask whether it actually answers the specific question your page targets, or whether it is just filling space with plausible-sounding sentences. That distinction matters more than most people realise. A page about replacing a boiler thermostat should contain the kind of detail only someone who has done it would know, which terminals are live, what the common wiring mistakes are, why some thermostats need a neutral and others do not. Generic AI output skips all of that because it is averaging across everything it has seen. Editing means putting that specificity back in, and that is the part no tool does for you. Structure variation helps too. If every section on your site runs to four bullet points and two short paragraphs, Google's quality signals notice the uniformity even if the words differ. Mix it up. Use a longer explanation where the topic needs it, then cut to a single direct sentence when that is all the point requires. Check that the page actually covers what someone searching your focus keyword needs to know. A quick way to test this is to read this breakdown of where AI content helps and where it hurts before you publish. The penalty risk is not the AI origin. It is the thinness that AI makes easy to ship by accident. Where to Check Before You Publish Before anything goes live, run it through a basic originality check. That one step catches most problems. Copyscape and Originality.ai are both worth using, but for different reasons. Copyscape finds content that already exists on the web verbatim or near-verbatim. Originality.ai checks for AI generation patterns that might flag the piece as low-effort to a trained reviewer. Neither tool is infallible, but together they give you a clearer picture before you commit. After publishing, keep an eye on Google Search Console to watch for coverage drops, manual action notices, or sudden ranking changes on recently updated URLs. If a page starts losing impressions shortly after a content update, that is the signal to go back and look harder at what changed. Core Web Vitals are worth mentioning here, because slow, poorly built pages amplify every other quality problem. A thin AI article on a site that loads badly sends compounding negative signals. Getting the technical side right is not a substitute for good content, but it removes one more reason for Google to discount the page before it even reads the words. The Honest Truth About AI Content and Rankings AI content can rank. I've seen it sit comfortably on page one, pulling consistent traffic, with no penalty in sight. But that only happens when someone who actually knows the subject reads it back, spots what's wrong, and edits it into something a real person would want to read. The raw output almost never gets there on its own. It tends to be technically coherent but hollow, full of sentences that sound like they mean something without committing to any real position. Google's systems are getting better at detecting that kind of surface-level writing, and more importantly, so are readers. A high bounce rate on a page full of AI padding is its own signal, even if an AI content writing approach can genuinely speed up the first draft. The problem isn't the tool. It's treating the output as finished work. What Google actually penalises is content that adds nothing. Thin rewrites, pages that cover the same ground as a dozen identical competitors, text generated at volume with no editorial judgement applied. If you love your website, other people will love your website, and the rankings will take care of themselves. That principle applies here. Write something that reflects what you actually know, use AI to help you structure or draft it, then edit it properly. That's the version that earns rankings. ------------------------------------------------------------ # Can Targeting AI Visibility Hurt Your Website Traffic? Source: https://yorkshiredesign.co.uk/can-targeting-ai-visibility-hurt-your-website-traffic/ Published: 2026-07-09 > Appearing in an AI answer sounds like a win. Your content gets cited, your brand gets mentioned, and the AI confirms you know your stuff. But here is the problem, the user already has their answer. They do not need to click. For sites that built their traffic on informational content, that structural shift is already moving the needle in Google Search Console. This post breaks down exactly where the risk sits, which content types are most exposed, and what actually keeps traffic coming through. What AI Visibility Actually Means Right Now Google AI Overviews, ChatGPT Browse, Perplexity, and Bing Copilot all share one behaviour. They pull content, synthesise an answer, and deliver it inside the interface. The user gets what they need without clicking anywhere. The content does the work. The site gets nothing back. That is structurally different from a traditional blue-link ranking. A position-one result still needs a click to deliver value. An AI citation delivers the value without one. Being quoted in an AI answer is closer to being quoted in a newspaper than appearing in a search result. Awareness, possibly. Reliable traffic, no. Why Being Cited in an AI Answer Does Not Equal Traffic AI tools operate on a citation model. They quote your content, construct a complete answer, and the question is resolved. The user moves on. No click, no session, no conversion opportunity. Compare that to a featured snippet. A featured snippet still shows your URL, still puts a clickable link in front of the user, and still pulls follow-up intent. An AI answer buries the citation in a footnote, or drops it entirely. The information economy looks the same. The traffic economy is not. The content formats most at risk are the ones AI handles cleanly. As I cover in Long-Form Content vs Short Posts: Which Earns More Traffic, long-form reference pieces earn strong impressions but are also the formats AI can consume and summarise most efficiently. Short definitive posts get swallowed whole. Long guides get cherry-picked for the useful parts. The Content Types Most Likely to Disappear Into AI Summaries Some formats offer almost no resistance to AI summarisation. Definition posts answer one question clearly, so an AI can restate the answer in a single sentence. How-to guides follow a predictable structure that AI parses with ease. Listicles become bullet points inside the AI response. FAQ pages are essentially pre-formatted for AI extraction. Transactional and comparison content carries less risk. When a user wants to buy, book, or compare real pricing across providers, the intent demands a destination. An AI can describe your service but it cannot complete the transaction. That intent gap is where click-through traffic still lives. Where Optimising for AI Visibility Conflicts With SEO The signals that help AI parse your content are largely the same signals Google's Quality Rater Guidelines reward. Clear headings, structured data, concise summaries, and logical hierarchy all help. The irony is that a well-structured page is also the easiest page for AI to answer from without sending a single click your way. E-E-A-T protects your credibility in Google's quality assessment. It does not protect your traffic share when an AI Overview intercepts the query before the user sees a blue link. The ranking signal and the traffic outcome are decoupling, and that gap is widening on informational queries. What Actually Survives the AI Filter From my own experience, the content AI struggles to replicate cleanly shares a few consistent qualities. Proprietary data is one. If a finding comes from your own testing or client work, an AI cannot fabricate a matching source. Strong opinion backed by specific reasoning is another. AI tends toward consensus, so a clear and argued point of view stands out. Original research, practitioner voice, and content that references real decisions from real projects all create friction for AI summarisation. The AI can note that an opinion exists, but it cannot replace the reasoning behind it. That is where depth earns its keep. If your site has already seen a drop in click traffic from informational pages, the practical next step is working out which posts are worth refreshing and which formats to retire. The Content Refresh SEO guide walks through how to prioritise that work without wasting time on pages that have already lost their relevance window. The Strategic Bet: Chase AI Placement or Protect Click Traffic? AI citation builds brand familiarity over time. When your name appears repeatedly in AI answers, some users will search for you directly. Branded search and direct traffic do grow alongside consistent AI presence, but only once enough awareness exists for the name to register. For most smaller sites, that flywheel has not started turning yet. Chasing AI placement without a strong brand foundation is a slow path to awareness with no short-term traffic return. Protecting click-through traffic on transactional, comparison, and original content is the more immediate priority. How to Track Whether AI Is Already Eating Your Traffic Open Google Search Console and compare impressions against clicks over a rolling 90-day window. If impressions are holding or growing while clicks are falling, AI Overviews are the most likely cause. The query is being served. The click is not. GSC includes an AI Overviews filter inside the Search Type dropdown. Use it to isolate which queries appear inside AI results, then cross-reference those against your click-through rates. A widening gap between impressions and sessions in GA4 on the same URL confirms the pattern. That data tells you exactly where to act first. High-impression, low-click pages on informational topics are your most exposed assets. Those are the pages to either deepen with original content or repurpose toward a format with clearer transactional intent. ------------------------------------------------------------ # Meta Description SEO: Write Snippets That Get Clicked Source: https://yorkshiredesign.co.uk/meta-description-seo-write-snippets-that-get-clicked/ Published: 2026-07-09 > Your meta description does one job, convince someone already looking at ten results to click yours instead. Google won't count it as a ranking factor, but a well-written snippet routinely lifts click-through rates by a measurable margin. Most sites treat it as a checkbox. We treat it as copy. There is a real craft to it, and most briefs get it wrong before a word is written. Understand What a Meta Description Actually Does Meta descriptions do not move your rankings. Google confirmed this years ago, and nothing has changed since. What a meta description does is sit directly below your title tag on a search results page, competing for attention against nine other listings, a handful of ads, and sometimes a featured snippet eating the top of the screen. That context matters. A user lands on the SERP, scans quickly, and decides where to click in a matter of seconds. Your meta description is the only piece of copy you fully control at that moment, and if it reads like a page summary rather than an invitation to click, you're handing ground to whoever wrote theirs with more intent. Think of it less like a label and more like a small ad, the kind you'd pay for on Google Ads. The best paid search copy names a specific benefit, speaks to a clear reader, and gives them a reason to act. The same thinking applies here, and most organic listings miss it entirely. The practical implication is straightforward. Stop writing meta descriptions to describe your page. Start writing them to win a click from a specific person who typed a specific query. Those are two very different briefs, and the gap between them is usually visible the moment you look at your own search listings honestly. Match the Description to Search Intent, Not Just the Keyword Keyword stuffing a meta description does almost nothing for CTR. What moves the needle is writing a snippet that answers the unspoken question behind the search. Someone typing "what is a meta description" wants a plain explanation, so your snippet should open with exactly that, not a list of features or a call to book a consultation. Someone typing "hire SEO copywriter" is in buying mode, so your snippet should lead with an outcome, a price signal, or a proof point, not a dictionary definition. The mismatch between snippet tone and search intent is one of the most common reasons a page sits at position four and still gets passed over, because the title earns the click, but the description kills it. Informational queries reward brevity and clarity. Transactional queries reward specificity and confidence. Navigational queries, where the user already knows where they want to go, barely need a description at all because brand recognition does the work. Getting this right is less about copywriting talent and more about reading the intent behind the brief before you type a single word. When you write for intent first, the keyword tends to appear naturally anyway. Keep Your Character Count Where Google Will Actually Show It The safe window is 150 to 160 characters. Go beyond that and Google clips your description mid-sentence, often mid-word, leaving a trailing ellipsis where your call to action used to be. The cut lands even earlier on mobile, typically around 120 characters, because the snippet column is narrower. That means a description written to the desktop limit can already be truncated before most of your readers ever see the full version. Front-loading fixes this. Put the core value, the specific benefit, the thing that earns the click, in the first 100 characters. Everything after that is reinforcement, not foundation. A description that opens with "Find out how our team helps businesses grow online with tailored..." is already wasting the first third on filler. Swap it for "Cut your checkout drop-off rate with a one-page flow built for mobile" and the message survives any cutoff point. Character count is a symptom of a wider technical discipline. If your site is regularly throwing malformed snippets, overlong descriptions, or pulled-from-body fallbacks, the description problem is usually part of something bigger. The technical SEO fixes that actually move rankings post covers the structural issues that cause Google to ignore your meta entirely and generate its own, which is almost always worse than what you wrote. Get the count right, but make sure the infrastructure underneath it is solid too. Write One Clear Benefit, Then One Clear Reason to Act The most common mistake in meta description SEO is writing a summary of the page instead of a pitch for the click. A summary tells the reader what exists on the page. A good meta description tells them what they will walk away with, then gives them a reason to go and get it now. The structure is simple, one clear benefit, followed by one clear prompt to act. For a page selling WordPress hosting comparisons, that might read "Find out which host cuts your load time without doubling your bill, and see our side-by-side breakdown before you commit." The benefit is the faster, cheaper outcome. The prompt is the comparison, positioned as the thing standing between the reader and a bad decision. This differs from a page summary the moment you strip out passive language. "This article covers hosting options for WordPress users" is a summary. It describes the page. It gives the reader no reason to prefer your result over the nine others sitting above or below it in the SERP. If you want to understand why most briefs produce forgettable pages, the meta description is often where it starts, because the brief never asked for a pitch in the first place. Keep the benefit specific and the prompt urgent without being gimmicky. "Learn exactly which fix moved our rankings" works. "Click now for amazing tips" does not. Know When Google Will Rewrite Your Description Anyway Google rewrites roughly two thirds of meta descriptions. Write the best one you can, and still expect it to be swapped out regularly. The trigger is almost always relevance. When Google decides your written description doesn't closely match what the searcher actually typed, it pulls a passage from the page body that it thinks does a better job. This happens most often on long-form content, where a single meta description can't possibly cover every angle the page addresses. It also happens when the description reads like marketing copy and the body copy reads like genuine information, because Google will pick the passage it trusts more. Thin, vague, or keyword-stuffed body text gives Google nothing worth quoting, so it either falls back on your written description or cobbles together something awkward from navigation text and headings. Neither outcome is good. The practical read here is that weak page content undermines your meta description before a searcher ever sees it. If Google keeps rewriting your snippet, that's a signal worth taking seriously. It usually means the page body isn't earning enough trust to anchor the search result on its own terms. Fix the content first, then write a description that complements it rather than pitching something the page doesn't fully deliver. Audit Your Existing Snippets Before Writing New Ones Before you write a single new meta description, pull your Search Console data and look at what Google is actually serving. Go to Performance, filter by page, and cross-reference your click-through rates against impressions. Pages with high impressions and low CTR are the ones crying out for better snippets. That combination tells you Google thinks the page is relevant enough to show, but searchers are not convinced enough to click. Start your audit there, not with a blank content brief. Check for three specific problems in that data. Missing descriptions are the most common, and Google will rewrite them using whatever text it finds first, which is often a navigation label or a repeated boilerplate phrase. Duplicate descriptions are the second issue, particularly on sites where category pages share template copy. Truncated snippets are the third, where the description runs past roughly 155 characters and gets cut mid-sentence in a way that kills the message. All three are straightforward to fix once you can see them, but they are invisible if you skip the audit. Page priority matters here too. If you are working through a large site, use your internal linking structure as a rough signal for which pages carry the most weight. Pages that receive the most internal links are usually the ones your site treats as important, so fix their snippets first. ------------------------------------------------------------ # AI Automation for Small Business: Start Without Wasting Budget Source: https://yorkshiredesign.co.uk/ai-automation-for-small-business-start-without-wasting-budget/ Published: 2026-07-09 > A small e-commerce owner spent three months testing AI tools across her business. She tried AI image generation, a chatbot on her homepage, and an automated social media scheduler. None of it moved the needle. Then she automated one thing, the follow-up email sent after an abandoned cart. Open rates climbed, revenue recovered, and she spent about four hours setting it up. That single workflow did more than the previous three months combined. The lesson is not which tools to buy. It is where to start. The Real Cost of Starting in the Wrong Place Most small businesses that struggle with AI automation have the same problem. They start with the visible stuff, the shiny front-end tools, rather than the repetitive back-end tasks that quietly eat hours every week. Chatbots, AI-generated images, and social media tools all have their place. But they rarely solve the problems that actually cost you time and money. The smarter move is to map your week before you buy anything. Write down every task you do more than twice. Flag the ones that follow a predictable pattern. Those are your automation candidates, and they are usually unglamorous, invoice chasing, form responses, lead notifications, appointment reminders. Where AI Automation Pays Off First For most small businesses, the highest-value starting points sit in three areas. Lead handling. A new enquiry comes in via your contact form. Without automation, it sits in an inbox until someone notices it. With automation, a confirmation email goes out instantly, your CRM is updated, and you get a Slack or email alert. Response time drops from hours to seconds. Repetitive admin. Invoice reminders, appointment confirmations, onboarding checklists. These tasks are low-skill but high-frequency. Automating them does not require complex AI, just a trigger, a condition, and an action. Data entry between tools. If someone fills in a form and you manually copy that data into a spreadsheet or CRM, that is a workflow ready to automate today. Tools like Make or Zapier connect the dots without writing a line of code. Start with one of these. Get it working properly before you touch anything else. If you want a broader picture of what automation looks like in practice, 8 practical uses of AI for automation in small business covers a range of real scenarios worth reading through first. How to Choose Your First Automation A useful filter is the three-part test. Ask yourself, does this task happen at least weekly, does it follow the same steps every time, and does a human have to do it manually right now? If all three are yes, it is a strong candidate. Avoid starting with anything creative, nuanced, or customer-facing in a sensitive way. AI handles repetition well. It handles judgment calls poorly. Your first automation should require zero human decision-making once it is set up. That keeps it reliable and keeps the risk low while you learn how the tooling behaves. The Budget Trap Most Businesses Fall Into Paid AI tools are easy to accumulate. A subscription here, a platform there, and within a few months you are paying for five tools with overlapping features and using none of them fully. This is one of the most common budget drains in small business AI spending. The fix is to pick one automation platform and stick with it long enough to build something that actually runs. Make, Zapier, and n8n are all capable of handling the core workflows a small business needs. The platform matters less than actually shipping a working automation. For a more structured look at deciding what to build first, AI automation for small business, what to build first walks through a practical prioritisation method. Triggers Are the Foundation Every automation starts with a trigger. A form submission, a new row in a spreadsheet, a payment received, a calendar event. If you do not understand what fires your automation, the whole workflow becomes unpredictable. Spend time getting your triggers right before worrying about AI models or complex logic. A webhook from your contact form triggering a sequence of actions is more valuable, and more reliable, than a sophisticated AI agent that nobody has tested properly. If you want to go deeper on this, AI automation triggers explained covers webhooks, schedules, and events in plain English. What Good Looks Like After 30 Days After one month, a well-chosen first automation should be running without your involvement. You should not be checking it daily or fixing it weekly. If it needs that level of attention, either the trigger is unreliable or the workflow logic has too many edge cases. A good result looks like this, a task that used to take 20 minutes now takes zero. You have documented what the automation does and why. And you have a second candidate already identified, ready to build once the first one is genuinely stable. That steady, boring cadence is how small businesses actually get compounding value from automation, not by chasing the newest tool. ------------------------------------------------------------ # Internal Linking for SEO: The Structure WordPress Sites Get Wrong Source: https://yorkshiredesign.co.uk/internal-linking-for-seo-the-structure-wordpress-sites-get-wrong/ Published: 2026-07-09 > Internal linking is one of the few SEO levers you control completely, yet most WordPress sites handle it badly. Pages float without parent topics. Money pages get fewer links than blog archives. Anchor text says 'click here' and tells Google nothing. None of this requires a technical fix or a new plugin. It requires a structure, applied consistently. The sections below cover the seven habits that separate a well-linked site from one that quietly bleeds authority. Every Page Sits in a Clear Topic ClusterBefore you touch a single link, map your content into topic clusters. Each cluster has one pillar page covering a broad subject, with supporting posts linked back to it. Without this, pages become orphans. An orphan page receives no internal links, so crawlers find it rarely and authority never reaches it.On WordPress, a quick export of all published URLs into a spreadsheet reveals the gaps fast. If a post cannot be assigned to a parent topic within ten seconds, it probably needs consolidating or cutting. Crawl equity is finite. Spending it on unfocused content is a waste.Your Most Important Pages Earn the Most Internal LinksRun a crawl of your site using a tool like Screaming Frog and sort pages by inbound internal link count. What you usually find surprises people. The blog archive or the homepage collects the most links, while the service pages that actually generate revenue sit at two or three inbound links total.Fix the ratio deliberately. Every new post should ask, 'Which service or pillar page is most relevant here?' Then link to it. Over time, the pages that matter to the business accumulate the signals that matter to Google. For a deeper look at how content writing for SEO connects to this, the brief itself shapes where internal links land.Anchor Text Describes the Destination, Not the Action'Click here' tells Google nothing. 'Read more' tells Google nothing. Descriptive anchor text, such as 'WordPress plugin management guide' or 'technical SEO audit checklist', gives both the user and the crawler a clear signal about the destination page's topic.Go through your existing posts and flag every generic anchor. Replace each one with two to five words that describe what the linked page actually covers. This is not just an SEO improvement. Users convert better when they know where a link leads before they click it.No Page Sits More Than Three Clicks From the HomepageCrawl depth is how many clicks it takes to reach a page starting from the homepage. Pages buried at depth four or five are visited far less frequently by Googlebot, which means updates to those pages take longer to be indexed and any authority passed to them is diluted across a long chain.Audit your crawl depth report and pull out everything sitting at four clicks or more. Often the fix is simple, add a link to a deeply buried post from a relevant pillar page or a high-traffic category index. One well-placed link can move a page from depth five to depth two overnight.New Posts Link Out Before They Earn Any Links InA new post published without outbound internal links is a dead end. It receives traffic, then sends visitors nowhere useful, and passes no authority onward. Worse, it does nothing to support the existing pages that have already earned rankings.Make it a publishing rule. Every new post links to at least two or three relevant existing pages before it goes live. This is especially useful for supporting older pillar pages that already carry authority. The WordPress Plugin Organizer guide is a good example of an established post that benefits from fresh posts pointing toward it.Old Posts Are Audited and Updated With Links to New ContentNew content published today cannot receive internal links from posts written before it existed. That means every post you publish starts with zero inbound internal links unless you go back and add them.A quarterly review process solves this. Filter your top-performing posts by organic traffic or rankings. Open each one and look for natural places to link to content published since that post was last updated. Established pages that already rank pass authority more effectively than new pages. Use them as the channel.Broken and Redirected Internal Links Are Caught EarlyInternal links pointing to 301 redirects waste crawl budget. The crawler follows the link, hits the redirect, then follows again to the final destination. That is two hops instead of one, and the authority passed through a redirect is reduced. Internal links pointing to 404 pages pass no authority at all and deliver a dead end to real users.Run a crawl monthly or after any significant site change. Filter for internal links returning 3xx or 4xx status codes and update them to point directly to the correct live URL. Tools like Screaming Frog surface these in minutes. Leaving them unfixed is one of the quieter ways a site leaks the authority it has spent months building. If slow server responses are compounding the problem, the detail in our TTFB and server response time guide explains how crawl efficiency connects to hosting performance. Related: Technical SEO Audit: 12 Things to Fix Before You Build Links ------------------------------------------------------------ # Technical SEO for WordPress: The Fixes That Actually Move Rankings Source: https://yorkshiredesign.co.uk/technical-seo-for-wordpress-the-fixes-that-actually-move-rankings/ Published: 2026-07-09 > Most technical SEO guides hand you a checklist and leave you to guess which items actually matter. For WordPress specifically, a handful of fixes move the needle in measurable ways while the rest are housekeeping at best. This piece weighs the most common technical issues against each other, explains what each one actually does to your rankings, and helps you decide where to spend your time first. Start With What Google Can Actually See Before anything else, confirm your site is crawlable. A misconfigured robots.txt or a stray 'discourage search engines' checkbox in WordPress settings can block Googlebot entirely. It happens more often than it should, usually after a migration or a staging-to-live push. Check Google Search Console under Settings, then Crawl Stats. If impressions dropped sharply on a specific date, crawlability is the first thing to rule out. Fix a blocked site and rankings recover fast, often within days of recrawling. XML Sitemaps vs Manual Indexing Requests Both get pages into Google's index, but they serve different purposes. An XML sitemap tells Google what exists. A manual URL inspection and request tells Google something specific has changed and needs fresh attention. For a WordPress site with fewer than a few hundred pages, a well-structured sitemap from a plugin like Yoast or Rank Math is enough. For larger sites, or sites that publish frequently, combining an accurate sitemap with strategic manual requests on high-priority pages beats relying on either alone. The sitemap wins on scale. Manual requests win on speed for important pages. Use both, and keep your sitemap clean by excluding paginated archive pages, tag pages, and anything with thin content. Core Web Vitals: Which Metric Is Doing the Damage Core Web Vitals cover three things, loading speed (LCP), visual stability (CLS), and responsiveness to input (INP). All three feed into Google's page experience signals, but they have very different causes on WordPress. LCP is usually an unoptimised hero image or a slow server response time. CLS is almost always caused by images without defined dimensions or late-loading fonts shifting the layout. INP is the newest metric and tends to reflect heavy JavaScript blocking the main thread. Run a real-device test in PageSpeed Insights rather than relying solely on the lab score. Field data reflects what actual users experience. For a deeper read on what each metric means for rankings, Core Web Vitals Explained: LCP, INP and CLS for Rankings breaks it down clearly. PHP Version and Server Configuration WordPress runs on PHP. An outdated PHP version slows every request before the page even starts building. Running PHP 7.4 instead of 8.2 can add hundreds of milliseconds to your time-to-first-byte, and TTFB directly affects LCP. Most managed hosts let you switch PHP versions from the control panel in under two minutes. It is one of the fastest performance gains available, and it costs nothing. Check your current version in WordPress under Tools, then Site Health. If it flags your PHP as outdated, treat it as urgent. For a fuller explanation of how much this matters, WordPress PHP Version: The Performance Setting Nobody Checks covers the practical steps. Canonical Tags and Duplicate Content WordPress generates multiple URLs for the same content by default. A post can appear at its permalink, on a category archive, on a date archive, and on a tag page simultaneously. Without canonical tags, Google sees four versions of the same page and splits any ranking signals between them. Rank Math and Yoast both set canonical tags automatically. The issue is when they are overridden by a theme, a page builder, or a plugin that injects its own head tags. Check your source code on a few key pages and confirm the canonical points to the URL you want Google to index. Pagination is a related trap. If you use a plugin for related posts or WooCommerce product filtering, it can generate hundreds of near-duplicate URLs that dilute crawl budget on larger sites. Internal Linking as a Technical Signal Internal links pass PageRank between pages and tell Google which pages matter most to you. A flat site where every page links back to the homepage only, but important content pages link to nothing, leaves ranking potential on the table. The fix is straightforward. Identify your highest-value pages and make sure two or three other relevant posts link to them with descriptive anchor text. Not keyword-stuffed anchor text, just clear, accurate descriptions of what the linked page covers. For a structured approach to getting this right, 7 Internal Linking Strategy Fixes Most SEO Work Skips is worth a read. Schema Markup: Where It Earns Its Place Structured data does not directly boost rankings, but it increases the chance of rich results, which lift click-through rates. For WordPress, the types worth adding first are Article, FAQPage, LocalBusiness if relevant, and Product for any e-commerce pages. Add schema through a dedicated plugin rather than hand-coding it into templates. Plugins keep the markup valid and easier to update. Validate everything in Google's Rich Results Test before assuming it is working. Invalid markup is ignored entirely, so checking takes thirty seconds and saves wasted effort. Related: Technical SEO Audit: 12 Things to Fix Before You Build Links ------------------------------------------------------------ # WordPress Database Optimisation: Why a Bloated Database Slows Every Page Source: https://yorkshiredesign.co.uk/wordpress-database-optimisation-why-a-bloated-database-slows-every-page/ Published: 2026-07-09 > Your WordPress database is the engine room behind every page on your site. Every post, every setting, every revision, every plugin option gets stored there. Over time, that database fills up with data your site no longer needs, old revisions, spam comments, expired transients, and leftover rows from plugins you deleted months ago. None of that junk disappears on its own. It just quietly adds weight to every database query your site runs, which means every page loads a little slower than it should. What a WordPress Database Actually Does When a visitor lands on one of your pages, WordPress does not serve a static file. It connects to a database, runs a series of queries, pulls back the data it needs, and then builds the page on the fly. That process happens on every single request unless a caching layer intercepts it first. The database itself is a collection of tables. The wp_posts table holds your content. The wp_options table holds site settings. The wp_postmeta table holds extra data attached to posts. Each query has to scan through whatever rows exist in those tables to find what it needs. A clean, compact table is faster to scan than one bloated with thousands of redundant rows. What Causes Database Bloat Post revisions are one of the biggest culprits. Every time you save a draft, WordPress stores a complete copy of that post. Write and edit a post a dozen times and you end up with twelve revisions sitting in the database, none of which your visitors ever see. Plugins are the other major source of bloat. When a plugin stores data, it typically adds rows to wp_options or creates its own tables. When you deactivate and delete that plugin, those rows often stay behind. Repeat that across five or six plugins over a couple of years and the leftover data adds up fast. Spam and trashed comments, expired transients, and unused tags also contribute. Transients are temporary pieces of data that plugins cache in the database. They are supposed to expire and get cleared, but on many sites they accumulate instead. You can see the kind of plugin sprawl that feeds this problem explained in our guide to taming a bloated plugin list. How Bloat Affects Load Time A larger database does not automatically mean dramatically slower queries. But it does mean slower queries over time, particularly when tables become fragmented or when wp_options grows very large. The wp_options table is searched on almost every page load. WordPress looks for autoloaded options, settings that get pulled into memory whenever the site initialises. Some plugins mark their data as autoload, which means it gets loaded regardless of whether the current page needs it. A wp_options table with hundreds of autoloaded rows from old plugins adds measurable overhead to every single request. Database fragmentation is a separate issue. When rows get deleted, MySQL leaves gaps in the storage. Over time those gaps slow down reads. Running an optimise command compacts those gaps and can noticeably improve query speed on older, heavily edited databases. How to Clean Up Your Database Start with revisions. You can limit how many WordPress stores by adding a line to your wp-config.php file. Setting define( 'WP_POST_REVISIONS', 5 ); caps revisions at five per post going forward. To remove the existing backlog, a plugin like WP-Optimize or Advanced Database Cleaner lets you bulk delete old revisions safely. Next, clear expired transients. Most cleanup plugins handle this in one click. Then look at your spam and trashed comments, your unused tags, and any orphaned post metadata left behind by removed plugins. After cleaning, run an optimise on your database tables. In phpMyAdmin you can select all tables and run Optimise Table from the dropdown. WP-Optimize does the same thing from inside WordPress without needing server access. If your site relies heavily on images, reducing what gets stored there pairs well with keeping the database lean. See our image optimisation guide for the full approach. Preventing Bloat From Building Back Up A one-off clean is useful but not enough. Set a schedule. Running a database cleanup once a month keeps things from accumulating again. Most optimisation plugins let you automate this so it runs in the background without you having to remember. Be deliberate about which plugins you keep active. Every plugin you install is a potential source of future database rows. If you are not using it, remove it properly rather than just deactivating it. Also check your PHP version. An outdated PHP version slows down the database layer too, because the code that handles queries runs less efficiently. The PHP version guide covers exactly what to check and why it matters. The Payoff Is Cumulative WordPress database optimisation is not a single dramatic fix. It is one layer in a broader performance stack. But it is a layer that many site owners skip entirely because the problem is invisible until it is not. A clean database means faster queries, a lighter autoload stack, and a server that spends less time hunting through fragmented tables. Every millisecond you shave off a database query is a millisecond your visitors do not wait. Over thousands of page loads, that compounds quickly. Related: WordPress Speed Optimisation Without Adding More Plugins ------------------------------------------------------------ # AI Automation Engineer: What the Role Actually Involves Source: https://yorkshiredesign.co.uk/ai-automation-engineer-what-the-role-actually-involves/ Published: 2026-07-09 > Search demand for 'ai automation engineer' has grown over 100% in recent months. The title is everywhere, but the actual definition varies wildly depending on who you ask. Some organisations treat it as a developer role. Others hand the job to an ops person with a Zapier subscription. This guide cuts through the noise and maps out what the role genuinely involves, what tools it leans on, and what separates a capable engineer from someone who just connects a few APIs. Where the Role Came From The ai automation engineer title did not appear out of nowhere. It evolved, piece by piece, from roles that already existed. Ten years ago, the people doing this work were called RPA developers or DevOps engineers. They built bots in UiPath or Blue Prism to click through legacy systems, and they wrote Bash and Python scripts to move files, trigger deploys, and chain together infrastructure tasks. The tooling was rigid. If the input changed shape, the automation broke. Maintaining those pipelines took as much time as building them, and the scope stayed narrow. What shifted the role was not one tool but a cluster of them arriving at roughly the same time. Large language models became cheap enough to call via API. Orchestration platforms like n8n and Make added native AI nodes. Vector databases made it practical to give a workflow long-term memory. Suddenly the automation layer could interpret unstructured input, make conditional decisions, and recover from unexpected states without a human stepping in. The job description changed because the capability changed. The difference between AI and automation matters here. Classic automation follows a fixed path. An ai automation engineer builds systems that can reason about which path to take, which is a meaningfully different skill set, and why the role carries its own name now. What an AI Automation Engineer Actually Builds The work is concrete, not theoretical. An AI automation engineer builds the systems that connect your tools, read incoming data, make decisions, and fire the right action without a human in the loop. A typical project might pull a customer form submission, run it through a language model to classify intent, route a complaint to one queue and a sales enquiry to another, then post a drafted reply back to your CRM, all in under three seconds. That chain involves a trigger, a data pipeline, at least one API call to an AI model, and conditional logic that decides which branch fires. Each of those pieces has to be designed, connected, tested, and hardened against the moments when upstream data arrives broken or a third-party API times out. The engineer also defines the decision logic, which is the part most people underestimate. Rules like "if confidence score is below 0.7, escalate to a human" have to be written somewhere, tested against real edge cases, and updated when behaviour drifts. That layer is what separates a brittle script from something genuinely reliable. For a closer look at how automation triggers like webhooks, schedules and events fit into this picture, that breakdown covers the mechanics clearly. The output is always a running system, not a document or a recommendation. The Technical Stack You Need to Know Python sits at the centre of most production automation builds. It handles data transformation, API calls, and logic branching cleanly, and the ecosystem around it, requests, pydantic, httpx, makes working with external services fast to prototype and solid to deploy. JavaScript fills the gaps where Python can't go, particularly inside browser-based workflows, Node.js webhook receivers, and any front-end triggers that need to talk back to an automation pipeline. Knowing both languages isn't a bonus at this level, it's the baseline expectation. Platforms like Make and n8n do the heavy lifting for orchestration. They let you wire services together visually, but the engineers who get the most out of them are the ones who drop into the code modules when the no-code path runs out. Webhooks, schedules, and event triggers are how these platforms actually fire, so understanding the mechanics behind each method separates engineers who build reliable systems from those who build brittle ones. LLM APIs, OpenAI and Claude in particular, slot into the pipeline at the point where unstructured input needs a structured output. A webhook receives a customer message, n8n routes it to a Claude API call, and the response feeds a formatted record into a CRM. That single loop is now standard across dozens of real business builds. Knowing how to manage token limits, prompt structure, and error handling inside those calls is what keeps production systems stable under load. How It Differs From a Standard Developer or DevOps Role A software engineer builds products. A DevOps engineer keeps those products running reliably, managing pipelines, containers, and infrastructure. An AI automation engineer does neither of those things as a primary job. The focus sits on designing workflows that connect existing tools, models, and data sources so that a business process runs without a human triggering every step. That might mean wiring a webhook from a CRM into an LLM, having the model classify the input, then routing the result into a project management tool, all without writing a single line of application code. The work is more architectural than it is programming-heavy, though solid scripting skills in Python or JavaScript are still expected. DevOps engineers optimise for uptime and deployment speed. AI automation engineers optimise for decision quality and process throughput. The success metrics are genuinely different. Where a developer might spend a sprint building a feature from scratch, an AI automation engineer is more likely to spend that same time mapping a broken approval process, identifying where an AI model can make a reliable judgment call, and testing whether the output holds up under edge cases. If you want to understand how triggers and events fit into this picture, AI Automation Triggers Explained covers the mechanics clearly. Where WordPress and Web Infrastructure Intersect WordPress is no longer just a publishing tool. For an AI automation engineer, it has become a genuine integration layer. Most client websites run on WordPress, which means automation engineers need to work inside that environment rather than around it. The WordPress REST API is the standard entry point here, giving engineers a clean way to push and pull data programmatically, whether that is publishing AI-generated content on a schedule, routing inbound leads from a contact form into a CRM, or triggering custom workflows when a user hits a specific page. Webhooks handle the real-time side of this, firing outbound payloads the moment something happens in WordPress, so downstream systems respond immediately rather than waiting on a cron job. Custom plugins take things further still, letting engineers embed logic directly into the CMS rather than relying on third-party connectors that add latency and cost. The practical result is that AI automation engineers working in this space need solid PHP and JavaScript knowledge, a clear understanding of WordPress hook architecture, and enough server-side experience to debug when a payload drops silently. Building reliable pipelines between AI content tools and a live WordPress environment is not a no-code task. It rewards engineers who understand what happens beneath the surface. Skills That Actually Matter at a Senior Level Junior workflow builders connect two tools and call it done. Senior AI automation engineers think in systems, which means they understand what breaks, why it breaks, and how to build so it rarely does. The competency gap lives in a few specific places. First, data modelling, because an engineer who cannot design a clean payload schema will create fragile pipelines that collapse the moment an upstream API changes its response format. Second, error handling, not just catching failures but designing retry logic, dead-letter queues, and alerting that tells you exactly where in a multi-step workflow something went wrong. Third, security, understanding OAuth flows, token scoping, and how to avoid exposing credentials inside webhook payloads. A senior engineer treats these as baseline, not bonus skills. If you want to understand how triggers plug into this kind of thinking, this breakdown of webhooks, schedules and events covers the mechanics clearly. Knowing when not to automate matters just as much as knowing how. The engineers who genuinely own end-to-end architecture can draw a clear line between what a workflow tool should handle and what needs custom code, and they make that call based on maintenance cost, not novelty. Prompt engineering sits in this stack too. Designing an LLM call that returns consistent, parseable output under real-world conditions is an engineering problem, not a creative one. Related: What AI Automation Actually Does Inside a WordPress Website ------------------------------------------------------------ # 7 Things Kinsta Hosting Gets Right (And One It Doesn’t) Source: https://yorkshiredesign.co.uk/7-things-kinsta-hosting-gets-right-and-one-it-doesnt/ Published: 2026-07-09 > Kinsta sits at the premium end of managed WordPress hosting, and the price tag makes people nervous. That nervousness is fair. Plenty of hosts charge top rates and deliver mid-tier results. Kinsta is not that, but it is not perfect either. Here are seven things it genuinely gets right, and the one area where the gap between the marketing and reality is wide enough to matter before you sign up. 1. The Infrastructure Is Built Around Google Cloud Kinsta hosting runs entirely on Google Cloud. That single fact changes what you get under the hood. Most shared and managed hosts sit on ageing commodity hardware. Kinsta provisions sites on Google Cloud's C2 and C3D compute-optimised machines, which are built for high-frequency, low-latency workloads. The C2 generation runs at up to 3.8 GHz sustained all-core turbo. The newer C3D machines push that further with AMD EPYC processors designed specifically to reduce time-to-first-byte. For a WordPress site, that means PHP executes faster, database queries return sooner, and the browser starts receiving HTML earlier. Every one of those gains feeds directly into Largest Contentful Paint and Time to First Byte, two signals Google weighs when assessing Core Web Vitals. A site that consistently returns sub-200ms server response times will always have an easier path to a passing LCP score than one sitting on shared hardware fighting for CPU cycles with hundreds of other accounts. The practical difference shows up in Google Search Console's page experience report. Shops and editorial sites migrated to Kinsta regularly report TTFB dropping from 600ms or more down to under 150ms, without any code changes on the WordPress side at all. 2. Staging Environments Are First-Class, Not an Afterthought Cheaper hosts either skip staging entirely or bolt it on as a paid add-on that barely works. Kinsta hosting builds it into every plan, and the workflow is genuinely useful rather than a checkbox feature. You spin up a staging environment with one click, make your changes, test everything thoroughly, and then push only the files or database you want back to live. That selective push is the detail that matters, because it means you can update a plugin on staging, confirm it does not break anything, and deploy just that change without overwriting content your client added to the live site while you were testing. For anyone managing WordPress sites professionally, that alone removes a whole category of late-night panic. Most incidents that take sites down come from untested plugin updates or theme edits applied directly to production. A proper staging setup catches those before they reach real visitors. If you want to understand how your hosting choice shapes that risk more broadly, web hosting choices that quietly kill your SEO covers the knock-on effects in detail. The pull direction works just as well. You can pull a fresh copy of live down to staging at any point, keeping your test environment current without any manual export and import routine. 3. The MyKinsta Dashboard Actually Saves You Time Most shared hosts still ship cPanel, and cPanel is a maze. You click through five menus to clear a cache, hunt a separate tool to read error logs, and piece together site health from half a dozen unconnected screens. MyKinsta puts all of that in one place. Cache purging is a single button. Error logs are a live, scrollable feed inside the same interface where you manage DNS, redirects and PHP versions. Site health checks surface real problems, not generic green ticks, so you know immediately whether a memory limit is throttling a plugin or a failed cron job is queuing up. That compression of steps adds up fast on a busy site. Debugging a 502 error that used to eat 40 minutes in cPanel takes closer to five in MyKinsta, because the log and the server controls are on the same screen. It is worth saying clearly that the dashboard alone is not a reason to pay Kinsta's prices. But if you manage more than one site, or if you regularly need to diagnose performance issues rather than just upload content, the tooling removes genuine friction. Developers who have worked with Cloudways alongside Kinsta often note that MyKinsta edges ahead specifically on log access and the clarity of its cache controls, two areas where most managed hosts still feel unfinished. 4. Support Response Times Hold Up Under Real Pressure Kinsta runs 24/7 chat support staffed by WordPress engineers, not first-line agents reading from a script. That distinction matters when your site goes down at 2am on a Sunday and the problem sits somewhere between a PHP memory limit, a plugin conflict, and a server configuration you cannot touch yourself. Generic hosting support at that hour typically means a ticket queue and a copy-pasted knowledge base article. Kinsta's team can look directly at your environment, pull server logs, and give you a concrete answer. Typical first responses arrive within a few minutes, not hours, and the person responding already understands WordPress at a technical level. A phone number you can call between 9am and 5pm on weekdays sounds reassuring until your traffic spike happens at midnight. Real-world hosting problems rarely respect business hours. If you want to understand how support quality and infrastructure sit alongside each other before committing to a plan, our breakdown of Kinsta vs Cloudways covers both in practical terms. 5. Built-In CDN and Edge Caching Work Without Plugin Conflicts Kinsta runs Cloudflare's CDN at the infrastructure level. There is nothing to install, nothing to configure, and no plugin fighting over cache headers. On a shared host, you typically stack a caching plugin like W3 Total Cache or WP Rocket on top of whatever server-level caching the host half-heartedly offers, then spend an afternoon debugging why your contact form stops submitting or your WooCommerce cart keeps serving cached pages to logged-in users. Kinsta sidesteps all of that by handling page caching at the server level before PHP even loads. Dynamic pages, like checkout and account areas, are automatically excluded. Static assets get pushed to Cloudflare's edge network and served from a node close to the visitor, so a user in Sydney gets roughly the same response time as one in London. The practical upside is that you get a measurably faster site without touching a single plugin setting, which also means fewer things to break during a WordPress core update. If you want to understand how hosting infrastructure choices quietly affect load times and search rankings, our breakdown of hosting decisions that hurt SEO covers the mechanics in plain detail. 6. Automatic Daily Backups With Two-Week Retention Come Standard Most shared hosts keep a single rolling 24-hour snapshot, and some charge a monthly fee just to access it. Kinsta hosting includes automatic daily backups retained for 14 days on every plan, with no extra cost and no plugin required. That 14-day window matters more than it sounds. A malware injection or a botched plugin update can sit unnoticed for several days before anyone spots a problem, and a 24-hour backup is already useless by the time you need it. Restoring from Kinsta takes a couple of clicks inside MyKinsta, and the restore runs on infrastructure that can handle the job quickly rather than queuing behind shared resources. Compare that to budget hosts where a "backup restore" means raising a support ticket and waiting hours for a manual process. For sites that publish several times a day, Kinsta offers an hourly backup add-on. News sites, high-volume WooCommerce stores, and membership platforms with constant content changes are the obvious candidates. Losing six hours of orders or articles is a real cost, and the add-on removes that exposure. If you want a broader view of how hosting choices affect your site's resilience and performance, the backup policy is one piece of a much larger picture worth reviewing. 7. Visit-Based Pricing Is the One Thing Worth Scrutinising Hard Kinsta charges by monthly visits, not by storage or bandwidth. That distinction matters more than most people realise before they sign up. A shared viral post, a product launch, or a mention on a high-traffic site can push you past your tier limit inside 48 hours, and Kinsta's response is an automatic overage charge or a prompt to upgrade your plan. On the Starter tier, the visit cap sits low enough that a modest spike in organic traffic, say a page landing on page one of Google, could trigger it within the same billing cycle. Overage fees are not the end of the world, but an unplanned plan jump mid-month is worth avoiding if your traffic is seasonal or unpredictable. Before committing to a tier, pull three to six months of Google Analytics data and look at your peak month, not your average. Add roughly 30 percent headroom above that peak and match the result to Kinsta's tier limits. Also check whether your visit count is measured across all sites on your account or per site individually, because the answer changes the maths entirely for anyone running multiple WordPress installs. If you want a broader comparison of how Kinsta's model stacks up against other managed hosts on real traffic scenarios, our Kinsta vs Cloudways comparison breaks the numbers down in plain terms. ------------------------------------------------------------ # Google Search Console Setup: A Practical Guide for Small Business Sites Source: https://yorkshiredesign.co.uk/google-search-console-setup-a-practical-guide-for-small-business-sites/ Published: 2026-07-09 > By the end of this guide, Google Search Console will be verified, your sitemap submitted, and you'll know exactly which reports to open first. Most small business owners skip setup entirely, or rush it and miss the property type that actually matters. This walkthrough covers each step in order, explains why it matters, and flags the mistakes that quietly cost you search visibility before your site has a fair chance. Choose the Right Property Type First Search Console gives you two property types when you create a new property. The first is a URL-prefix property, which tracks a single URL version such as https://yourdomain.com. The second is a Domain property, which tracks every version, every subdomain, and both HTTP and HTTPS under one roof. For almost every small business site, choose the Domain property. It captures data from www and non-www versions, so you never end up wondering why traffic looks lower than expected. The URL-prefix type is fine for staging subdomains or specific subdirectories, but it's the wrong default for your main site. Verify Ownership Without Breaking Your Site Google offers five verification methods. DNS record verification is the most reliable for Domain properties and it doesn't touch your site files at all. You add a TXT record in your domain registrar's DNS settings and Google confirms ownership within a few minutes. If your host manages DNS, log into the hosting dashboard and look for a DNS or Zone File section. Paste the TXT record Google gives you, set the TTL to the lowest available value, and save. Google usually confirms within five minutes, though DNS can occasionally take up to an hour to propagate. For URL-prefix properties, the HTML tag method is the quickest alternative. You paste a single meta tag into the <head> section of your homepage. On WordPress, a plugin like Yoast or Rank Math has a dedicated field for this so you never edit theme files directly. Submit Your Sitemap Straight Away Once verified, go to Sitemaps in the left sidebar and paste your sitemap URL. For most WordPress sites this is /sitemap.xml or /sitemap_index.xml, depending on which SEO plugin you use. Yoast generates /sitemap_index.xml by default. Rank Math uses /sitemap_index.xml too. If you're unsure, open your site URL followed by /sitemap.xml in a browser. If a page of URLs appears, that's your file. Submit it, then check back in 24 hours to confirm Google shows it as a success and has started reading URLs from it. A submitted sitemap doesn't guarantee instant indexing. What it does is give Googlebot a clear map so it doesn't have to discover pages by following links alone. For a new site, that head start matters. You can read more about how Google crawls and prioritises pages in our crawl budget explainer. Set Your Preferred Country and Crawl Settings Under Settings, open Search Console's older settings panel and confirm your geographic target if your business only serves one country. This nudges Google toward showing your pages to users in that region. It won't override strong on-page signals, but it removes ambiguity for borderline cases. There's no crawl rate slider in the modern Search Console interface for most sites. Google manages this automatically. However, if your server is under strain and Googlebot is hitting it hard, you can still request a lower crawl rate via the older Search Console tools accessible through the settings menu. The Three Reports to Check in Your First Week Once data starts populating, three reports give you the most actionable picture early on. Coverage report. Shows which pages are indexed, which are excluded, and which have errors. Start here. A page showing as 'Excluded by noindex' that you didn't intentionally block is a real problem worth fixing immediately. Performance report. Shows clicks, impressions, average position, and click-through rate. Filter by page to see which URLs are actually appearing in search and which are invisible. Sort by impressions descending to find pages with visibility but no clicks, a sign of weak titles or meta descriptions. Core Web Vitals report. Flags pages with poor LCP, INP, or CLS scores based on real user data. This feeds directly into ranking signals. A clean pass here is worth the effort. Our PageSpeed numbers breakdown explains what each metric is actually measuring. Connect Search Console to Google Analytics Linking the two accounts unlocks Search Console data inside Analytics, so you can see which organic search queries lead to conversions, not just visits. In Google Analytics 4, go to Admin, then Property Settings, then Search Console Links. The connection takes about two minutes and the joined data appears within 24 hours. This matters because Search Console shows search behaviour and Analytics shows what visitors do after they land. Together they answer the question most single tools can't, which keywords bring people who actually do something useful on your site. For small businesses thinking about what to build next in their digital setup, that data is the right place to start. See our guide on SEO as a step-by-step process to understand how to act on what you find. Keep It Maintained, Not Just Set Up Search Console isn't a one-time task. Manual actions from Google appear here and nowhere else. A manual penalty can suppress your entire site from search results with no warning email and no obvious sign in Analytics. Check the Manual Actions report once a month. Also revisit the Coverage report after any major site change, a redesign, a migration, or a plugin update. These events regularly introduce accidental noindex tags or broken redirects that disappear into the background until rankings drop. ------------------------------------------------------------