Technical SEO

Quick answer A canonical tag tells search engines which URL is the preferred version when the same or very similar content appears at several addresses. Use self-referencing canonicals on normal pages, point duplicates and variants to the main version, keep your internal links and sitemap consistent with it, and never canonicalise to a redirected or noindex page. Last updated: November 2026 Duplicate content is one of the most misunderstood problems in SEO. Google does not issue a penalty for ordinary duplicates, but it does have to choose one version to index, and it may not choose the one you want. Meanwhile, links and signals get split between versions, weakening each. Canonical tags are the standard tool for guiding that choice. They are simple in theory and surprisingly easy to get wrong, particularly on WordPress, WooCommerce and Shopify sites where plugins and themes generate many URL variations. This guide explains how canonicals work, where duplicates come from, the right way to use them, the mistakes that cause lost rankings, and how to audit your own site. In this guide What a canonical tag is Where duplicate content comes from Self-referencing canonicals Canonicals for duplicates and variants Canonical, 301 redirect or noindex: which to use? Common canonical mistakes WordPress, WooCommerce and Shopify specifics How to audit canonicals on your site A worked example Good practice checklist When duplicates do not matter FAQs What a canonical tag is A canonical tag is a line in the head of a page, written as a link element with rel=”canonical” and an href pointing to the preferred URL. It says: if you find this content at several addresses, please treat this one as the main version. It is a hint, not a directive. Google may ignore it if other signals disagree, for example if internal links, redirects and sitemaps all point to a different URL. That is why consistency matters more than the tag itself. Where duplicate content comes from HTTP and HTTPS, www and non-www, and trailing slash variations. URL parameters for tracking, sorting and filtering, such as ?utm_source or ?sort=price. Product variants and categories that show the same product at multiple paths. Printer-friendly pages, AMP versions and paginated series. Syndicated content republished on other websites. CMS settings that create archives, tags and attachment pages with thin or repeated text. Self-referencing canonicals Most SEO plugins add a canonical tag to every page that points to itself. This is good practice, because it protects against accidental parameter variants being treated as separate pages. A page at /services/ with a canonical to /services/ is saying “this is the original”. Check that your self-referencing canonicals use the exact preferred form: HTTPS, your chosen www or non-www version, and your chosen trailing slash style. A mismatch creates confusion that your own tag cannot fix. Canonicals for duplicates and variants When pages are near-duplicates, such as the same product in different colours with identical descriptions, you can canonical the variants to the main product page. When content is syndicated to another site, ask them to include a canonical pointing back to your original. Do not canonicalise pages that are genuinely different, even if they are similar. If a page for “boiler repair Leeds” canonicals to “boiler repair Bradford”, you tell Google to ignore the Leeds page. Each page that should rank in its own right needs its own self-referencing canonical. Canonical, 301 redirect or noindex: which to use? Choose the right tool for the situation. Use a 301 redirect when an old URL should no longer exist, such as after a page move or merging content. Use a canonical when the duplicate must stay accessible to visitors, for example a tracking URL or a filtered view. Use noindex when a page should be available to users but not appear in search at all, such as thank-you pages. Do not combine conflicting signals on the same page. A page with a canonical pointing elsewhere and a noindex tag, or one that redirects and also carries a canonical to itself, sends mixed messages and can cause unpredictable indexing. Common canonical mistakes Canonicalising to a URL that redirects, returns 404 or is blocked in robots.txt. Pointing every page to the homepage, which tells Google to ignore them all. Using relative or malformed URLs, including missing protocols. Having two different canonical tags on one page, for example from a theme and a plugin. Canonicalising paginated pages to page one, which can hide deeper content. Leaving staging URLs in canonical tags after launch. WordPress, WooCommerce and Shopify specifics On WordPress, Yoast and Rank Math handle canonicals automatically, but you can override them per page. Watch for plugin conflicts that output duplicates, and for attachment pages that create thin URLs. On WooCommerce, make sure variations and filtered URLs canonical to the main product or category. On Shopify, products can be reached through both /products/name and /collections/x/products/name. Shopify themes normally canonical to the /products/ version, which is correct, but your internal links should use that version too. Our Shopify build service sets this up properly from the start. How to audit canonicals on your site Crawl your site with a tool such as Screaming Frog and review the canonical column. Look for pages with missing canonicals, canonicals to non-200 URLs, canonicals pointing to a different page and multiple canonicals. In Search Console, the Pages report flags “Alternate page with proper canonical tag” and “Duplicate without user-selected canonical”, which show how Google interpreted your signals. The URL Inspection tool shows both the canonical you declared and the one Google chose. If they differ, investigate internal links, redirects and sitemap entries that may be pushing Google to another version. A worked example A Bristol furniture shop finds the same sofa page at /sofas/oslo, /sofas/oslo?colour=grey and /sale/oslo, each with different internal links. Google indexes the sale URL, which has less authority than the main product page, and rankings stay low. The shop sets the main product page as canonical on all three, updates internal links and the sitemap to

Quick answer A robots.txt file tells crawlers which parts of your site they may access. The most damaging mistakes are blocking the whole site with Disallow: /, blocking CSS and JavaScript, confusing blocking with noindex, and leaving a staging rule live after launch. Test any change in Search Console before and after publishing. Last updated: November 2026 A robots.txt file is a tiny text file with outsized power. One misplaced line can stop Google crawling your whole website, and it happens more often than most owners realise, usually after a redesign or when a developer forgets to remove a setting. Robots.txt is also misunderstood. It controls crawling, not indexing, and it is not a security tool. Treating it as either can cause problems. This guide lists the mistakes we see most often on UK business sites, explains how to check yours in minutes, and gives a sensible WordPress template you can adapt. In this guide What robots.txt does and does not do Mistake 1: Blocking the whole site Mistake 2: Blocking CSS, JavaScript or images Mistake 3: Using robots.txt to hide sensitive content Mistake 4: Blocking pages you want noindexed Mistake 5: Forgetting the sitemap and using the wrong syntax Mistake 6: Blocking AI crawlers by accident A safe WordPress robots.txt template How to test your robots.txt Real-world scenarios we see What to do after a mistake Staging sites and launches FAQs What robots.txt does and does not do Robots.txt sits at the root of your domain, for example yourdomain.co.uk/robots.txt. It tells well-behaved crawlers which paths they are allowed to request. Google, Bing and most legitimate crawlers obey it, though malicious bots ignore it. It does not remove pages from Google. A blocked URL can still appear in results if other sites link to it, usually without a description. To keep a page out of search results you need a noindex tag, and Google must be able to crawl the page to see that tag. Mistake 1: Blocking the whole site The line “Disallow: /” under “User-agent: *” blocks every crawler from every page. It is common on staging sites, which is correct there, but disastrous if it is copied to the live site. WordPress also has a setting, “Discourage search engines from indexing this site”, that can add similar blocks. Check your live file now. If you see a full block and your site is live, remove it and request recrawling. Rankings can recover, but the longer it stays, the more visibility you lose. Mistake 2: Blocking CSS, JavaScript or images Google needs to render pages like a browser to understand them. Blocking /wp-content/ or /wp-includes/ wholesale can prevent access to styles and scripts, leading to poor rendering and mobile usability problems. A safe default for WordPress blocks only the admin area, while allowing the AJAX endpoint that many themes and plugins use. Avoid copying long block lists from old tutorials. Mistake 3: Using robots.txt to hide sensitive content Listing private paths in robots.txt tells everyone, including bad actors, exactly where to look. Do not rely on it for security. Protect sensitive areas with authentication and proper permissions, and use noindex or password protection for pages that should not appear in search. Mistake 4: Blocking pages you want noindexed If you add noindex to a page and also block it in robots.txt, Google cannot crawl it to see the noindex instruction, so the page may stay indexed. Choose one approach deliberately: allow crawling and use noindex for pages that should drop out of results, and use robots.txt only to save crawl on genuinely useless sections. Mistake 5: Forgetting the sitemap and using the wrong syntax Add a Sitemap line pointing to your XML sitemap so crawlers can find it. Use correct paths, with a leading slash and case-sensitive names. Put each directive on its own line under the right user-agent group. Do not use unsupported directives such as noindex inside robots.txt, which Google ignores. Remember that rules for specific user-agents override the general group. Mistake 6: Blocking AI crawlers by accident Many security plugins and hosts now add rules for AI crawlers such as GPTBot or CCBot. That may be what you want, but check it was a decision, not a default. If your aim is visibility in AI search, blocking the crawlers of those tools can reduce your chances of being cited. Decide your policy deliberately and document it. Our guide to generative engine optimisation explains how crawler access fits into AI visibility. A safe WordPress robots.txt template A sensible starting point is: User-agent: *, Disallow: /wp-admin/, Allow: /wp-admin/admin-ajax.php, and a Sitemap line pointing to your sitemap index. For WooCommerce sites you may also block cart, checkout and account pages, and parameters that create duplicate URLs. Keep it short. Every additional rule is a possible mistake. If you are not certain what a line does, leave it out and test. How to test your robots.txt View yourdomain.co.uk/robots.txt in a browser and read every line. Use the robots.txt report in Google Search Console to see the version Google fetched and any errors. Use the URL Inspection tool to confirm key pages are crawlable. Crawl your site with a tool that respects robots.txt and see whether important sections are skipped. Re-check after redesigns, migrations and plugin changes. Real-world scenarios we see A common case is a Manchester trades business whose new website was built by a freelancer on a staging copy. Two weeks after launch, enquiries fall sharply. The cause: the live robots.txt still contains a full block, so Google stopped crawling new pages and dropped several from results. Removing the block and resubmitting the sitemap restored visibility within a few weeks. Another is an online shop whose developer blocked all parameter URLs, including the ones used by product filters that customers actually link to. Rankings for filtered category pages vanished because Google could not crawl them. The fix was to allow the filters that had search demand and block only the genuinely useless combinations. A third is a

Quick answer Crawl budget is the number of pages Google will crawl on your site within a given time. For most small business websites with under a few thousand pages it is not a limiting factor, but wasted crawling on duplicates, filters and broken URLs can still delay indexing, so it is worth keeping the site tidy. Last updated: November 2026 Crawl budget is one of those SEO phrases that sounds important and often gets used to sell unnecessary work. Google itself has said that most sites do not need to worry about it. Yet there are situations where crawling problems do hold back small sites, and they are usually easy to fix. This guide explains what crawl budget is in plain English, who it matters for, the signs that Google is wasting time on the wrong URLs, and a practical clean-up list for WordPress and e-commerce sites. You do not need log files or specialist tools to get started. Search Console and a basic crawl of your own site will tell you most of what you need to know. In this guide What crawl budget actually means Who needs to worry about it Signs that crawling is a problem Where to look in Search Console Fix 1: Remove or block low-value URLs Fix 2: Clean up redirects and broken links Fix 3: Tidy your XML sitemap Fix 4: Handle duplicates with canonicals Fix 5: Improve internal linking and site speed A short example What not to do FAQs What crawl budget actually means Google does not have unlimited time for every website. For each site it balances two things: the crawl capacity limit, which is how much Googlebot can fetch without overloading your server, and crawl demand, which is how much Google wants to crawl based on popularity and freshness. Together these produce the number of URLs Googlebot is willing to request. If a large share of those requests go to useless pages, such as duplicate parameter URLs, calendar pages or endless filters, your important pages may be crawled less often or discovered later. Who needs to worry about it Google has said crawl budget is mainly relevant to very large sites with hundreds of thousands of URLs, sites with frequently changing content such as news, and sites that auto-generate huge numbers of pages. A typical brochure site, local service business or small blog rarely hits limits. E-commerce stores with faceted navigation, sites with many tag and archive pages, and sites that have been hacked or have generated thousands of spam URLs are exceptions. For them, crawl waste can be real and slow down indexing of new products and pages. Signs that crawling is a problem New or updated pages take weeks to appear in Google. Search Console shows large numbers of URLs as “Discovered, currently not indexed” or “Crawled, currently not indexed”. Google crawls many parameter, filter or internal search URLs. Server logs or crawl stats show Googlebot spending most time on low-value URLs. Your server is slow or returns errors during crawls. Where to look in Search Console Open Settings, then Crawl stats, to see how many requests Google makes each day, average response time and the breakdown by response code and file type. A sudden spike in 404s, redirects or server errors is a red flag. The Pages report shows why URLs are not indexed, which often reveals duplicates, soft 404s and redirected pages. Compare the number of URLs Google knows about with the number you actually want indexed. A big gap suggests wasted crawl, while a close match suggests you are fine. Fix 1: Remove or block low-value URLs Identify URLs that add no search value: internal search results, tag archives with a handful of posts, session or tracking parameters, and duplicate sort and filter combinations. Use a noindex tag for pages that should exist but not be indexed, and robots.txt rules for areas that should not be crawled at all. Be careful with robots.txt. A mistake can block important content, and blocking a URL prevents Google from seeing a noindex tag on it. For WordPress, decide whether tag and author archives are useful, and noindex them if they are thin. Fix 2: Clean up redirects and broken links Long redirect chains and redirect loops waste crawl and slow users. Update internal links to point straight to final URLs, and fix links that lead to 404 pages. A site crawl using a tool such as Screaming Frog or Sitebulb will list redirects, broken links and orphan pages in minutes. Keep a redirect map when you restructure pages, and use single-step 301 redirects. Our technical SEO service covers redirect audits, broken link repairs and migrations. Fix 3: Tidy your XML sitemap Your sitemap should list only canonical, indexable, 200-status URLs that you want in search. Remove redirected, noindex and 404 pages, and keep lastmod dates accurate. Submit it in Search Console and reference it in robots.txt. A clean sitemap is a strong hint to Google about what matters. A messy one full of junk teaches Google to distrust it. Fix 4: Handle duplicates with canonicals Where similar content exists on several URLs, such as product variants, print versions or UTM-tagged links, use canonical tags to point to the preferred version, and be consistent about www versus non-www, HTTP versus HTTPS and trailing slashes. Canonicals are hints rather than commands, so make sure internal links, sitemaps and redirects all point to the same preferred URL. Mixed signals cause Google to pick its own choice, often not yours. Fix 5: Improve internal linking and site speed Pages that are deep in the site or only reachable through a few links are crawled less. Link important pages from your homepage, navigation and related content, and keep click depth shallow. Fast servers also allow Google to crawl more, so improve response times with good hosting and caching. Fixing orphan pages is especially valuable. Add links from relevant pages, or remove pages that no longer serve a purpose. A short

Quick answer Core Web Vitals are Google’s three measures of real-world page experience: Largest Contentful Paint (loading, aim for 2.5 seconds or less), Interaction to Next Paint (responsiveness, 200 milliseconds or less) and Cumulative Layout Shift (visual stability, 0.1 or less). Check them in Search Console and PageSpeed Insights, then fix the slowest templates first. Last updated: November 2026 Few SEO topics generate as much jargon as Core Web Vitals. The idea behind them is simple: pages should load quickly, respond promptly when someone taps or clicks, and stay still while they load. Google measures those things using data from real Chrome users. Page experience is not the strongest ranking factor, and content relevance still wins most contests. But slow, jumpy pages lose visitors and leads long before rankings come into it, and when two pages are otherwise similar, experience can be a tie-breaker. This guide explains each metric in plain English, what good scores look like, how to measure your own site and the fixes that make the biggest difference on typical WordPress sites. In this guide What Core Web Vitals are Largest Contentful Paint (LCP): how fast the main content loads Interaction to Next Paint (INP): how responsive the page feels Cumulative Layout Shift (CLS): how stable the layout is How to measure your Core Web Vitals The biggest fixes for WordPress sites Page builders and Elementor Do Core Web Vitals really affect rankings? A realistic example Monitoring and maintenance Quick checklist FAQs What Core Web Vitals are Core Web Vitals are a set of metrics Google uses to describe the real-world experience of a page. They are drawn from the Chrome User Experience Report, which collects anonymised data from Chrome users, so they reflect what actual visitors experience, not just what a lab test shows. Google evaluates them at the 75th percentile, meaning that at least 75 percent of visits should meet the “good” threshold for a page or group of pages to pass. That is a demanding standard, and it explains why a site that feels fine on your fast office connection can still fail in the field. Largest Contentful Paint (LCP): how fast the main content loads LCP measures how long it takes for the largest visible element, usually a hero image, banner or main heading block, to appear. A good score is 2.5 seconds or less, and anything over 4 seconds is poor. The usual culprits are oversized images, slow server response, render-blocking CSS and JavaScript, and heavy page builders or sliders in the hero section. Compressing and correctly sizing the hero image, serving modern formats such as WebP or AVIF, and using fast hosting and caching often fix LCP quickly. Interaction to Next Paint (INP): how responsive the page feels INP replaced First Input Delay in 2024. It measures how long the page takes to respond visually after a user interaction such as a tap, click or key press, and reports the slowest typical interaction. A good score is 200 milliseconds or less. Poor INP usually comes from too much JavaScript: chat widgets, tracking scripts, sliders, popups and heavy plugins. Reducing third-party scripts, deferring non-essential code and removing unused plugins are the most effective fixes. Cumulative Layout Shift (CLS): how stable the layout is CLS measures unexpected movement of page elements while the page loads, such as text jumping when an image or ad appears. A good score is 0.1 or less. Layout shift is annoying and causes mis-taps, such as hitting the wrong button. Fix it by setting width and height attributes on images and videos, reserving space for ads, embeds and cookie banners, and avoiding injecting content above existing content. Web fonts that swap late can also cause shifts, so preload key fonts and use sensible fallbacks. How to measure your Core Web Vitals Start with Google Search Console, which has a Core Web Vitals report grouping URLs into good, needs improvement and poor, based on real user data. Then use PageSpeed Insights on key pages: the field data at the top shows real users, while the lab data below helps diagnose specific issues. Check mobile first, because most traffic and Google’s indexing use the mobile version. Test your homepage, a main service page, a blog post and any page with forms or heavy scripts. Pages built from the same template usually share the same problems, so fix templates before individual pages. The biggest fixes for WordPress sites Choose quality hosting with fast server response and enable page caching, for example with LiteSpeed Cache or a similar plugin. Compress images, serve them in WebP or AVIF, and use responsive sizes with lazy loading for below-the-fold images. Remove unused plugins and heavy sliders, and avoid loading scripts on pages that do not need them. Defer or delay non-critical JavaScript and minimise third-party tags such as chat widgets and trackers. Preload your main font and hero image, and set dimensions on all media to prevent layout shift. Use a content delivery network if you serve visitors from many places. Page builders and Elementor Page builders add flexibility but can add weight. Elementor sites can perform well when built carefully: use the latest version, enable built-in performance features such as optimised DOM output and lazy loading of backgrounds, avoid deeply nested containers, and limit add-on plugins. Our WordPress website design service builds pages with performance in mind from the start, and our technical SEO service fixes problems on existing sites without a rebuild. Do Core Web Vitals really affect rankings? Google has said page experience signals are used in ranking, but they are one of many factors and rarely override relevance and quality. In competitive niches where many pages are similar, a poor experience can hold you back, and a good one can help. The stronger effect is on behaviour. Faster, steadier pages convert better. Many studies of retail and lead-generation sites show that speed improvements correlate with higher conversion and lower bounce rates, so the business case is there regardless of ranking

Quick answer LocalBusiness schema is JSON-LD code that tells search engines your business name, address, phone, opening hours, services and area. On WordPress you can add it with an SEO or schema plugin, or paste JSON-LD into your header, then test it with Google’s Rich Results Test and keep it identical to your Google Business Profile. Last updated: November 2026 Your website may say you are a plumber in Sheffield open from 8 to 6, but a search engine has to infer that from text. Schema markup removes the guesswork by stating it in a structured format machines can read. For local businesses, LocalBusiness schema is one of the most useful pieces of structured data, because it reinforces your name, address and phone details, supports map visibility and gives AI assistants clean facts to quote. This guide explains what to include, how to choose the right type, how to add it to WordPress with and without plugins, and how to test and maintain it. In this guide What LocalBusiness schema does Choose the most specific type Properties to include Self-serving reviews and other rules Method 1: Use an SEO plugin Method 2: Add JSON-LD manually Schema for multiple locations How to test your markup A cautious example Common mistakes How it supports local SEO and AI search What to do this week FAQs What LocalBusiness schema does Schema.org defines a vocabulary for describing things on the web. LocalBusiness is a type for physical businesses and service-area businesses, with more specific subtypes such as Dentist, Electrician, Plumber, AccountingService, LegalService, Restaurant and RealEstateAgent. Marked-up details help search engines connect your website to your Google Business Profile, and to your entity more broadly. It does not guarantee rankings or rich results, but it removes ambiguity and supports consistent information across search and AI. Choose the most specific type Use the most specific subtype available that honestly describes you. A dental practice should use Dentist, a firm of solicitors should use LegalService, and a general plumber should use Plumber. If none fits, use LocalBusiness. Check the full list at schema.org. Using a precise type helps machines classify your business correctly and aligns with the category you chose in Google Business Profile. Properties to include name, url, logo and image. telephone and email. address as a PostalAddress with street, locality, postcode and country. geo coordinates and a link to your Google Maps listing via hasMap. openingHoursSpecification with days and times, including holiday variations where possible. areaServed for the towns or regions you cover. priceRange where appropriate, and sameAs links to your official profiles. aggregateRating only if it complies with Google guidelines on review markup. Self-serving reviews and other rules Google does not allow self-serving review markup for LocalBusiness and Organization on your own site in many cases, meaning you generally should not mark up ratings of your own business that you collect yourself. Avoid marking up content that is not visible on the page, and do not include misleading details. Make sure every value in your schema matches what appears on the page and in your Google Business Profile. Mismatches reduce trust and can trigger structured data warnings. Method 1: Use an SEO plugin Plugins such as Yoast SEO and Rank Math can output Organization or LocalBusiness schema from settings. Rank Math includes a local SEO module with fields for address, opening hours and coordinates. Yoast offers a local add-on. This is the safest route for most small businesses. Fill in every field carefully, set the correct business type, upload a logo, and add your official profiles. Check the output on the live page, not just in the settings. Method 2: Add JSON-LD manually You can paste a JSON-LD script into your site header using a plugin such as WPCode, or through your theme. A typical script includes the context, type, name, url, telephone, address, openingHoursSpecification and sameAs list. Keep it as a single, valid block on the homepage and contact page. If you use Elementor, an HTML widget on the page can hold the script, though a site-wide header injection is neater. Whichever method you choose, avoid duplicating schema from both a plugin and manual code, which can create conflicting data. Schema for multiple locations For multi-location businesses, create a separate LocalBusiness block on each location page with its own address, phone, hours and map link, and use a parent Organization on the homepage. Each location should match its own Google Business Profile. Our local SEO service sets up location schema and profiles together, so details stay consistent as you add branches. How to test your markup Use Google’s Rich Results Test and the Schema Markup Validator on your homepage and contact page. Check Search Console’s Enhancements reports for errors. View the page source and confirm only one set of LocalBusiness data appears. Compare each value with your Google Business Profile and footer. Re-test after theme, plugin or content changes. A cautious example A boiler servicing company in Sheffield would use the Plumber type, with its trading name, phone number, a PostalAddress in Sheffield, opening hours Monday to Friday 8am to 6pm and Saturday 9am to 1pm, areaServed set to Sheffield, Rotherham and Barnsley, and sameAs links to its Facebook, LinkedIn and Google Business Profile. Every one of those details appears visibly on the page too. That is the principle: the schema should describe, not invent. If you cannot see a fact on the page or in your listings, it does not belong in the markup. Common mistakes Using the generic LocalBusiness type when a specific one exists. Opening hours that differ from your profile. Outdated phone numbers or addresses after a move. Duplicate schema from multiple plugins. Marking up reviews in ways that break Google guidelines. Never re-checking after redesigns. How it supports local SEO and AI search Schema is a quiet but useful part of the local stack. It reinforces your NAP details, helps search engines connect your site to your profile and gives AI assistants clear facts to draw on.

Quick answer FAQ schema is structured data that labels questions and answers on a page so machines can read them. Google now shows FAQ rich results only for a few authoritative sites, but marking up genuine FAQs still helps search engines and AI tools understand your content and can support voice and AI answers. Last updated: November 2026 Few SEO tactics have changed as much as FAQ schema. A few years ago, adding it could earn extra space in search results with expandable questions beneath your listing. Then Google cut back how often these rich results appear, and many sites removed their FAQs altogether. That was a mistake for most businesses. Well-written FAQs remain one of the best ways to capture long-tail questions, answer customers and give AI systems clean, quotable content. This guide explains what FAQ schema is, what Google currently does with it, how to write FAQs that are worth marking up, how to add the code in WordPress, and how to test it. In this guide What FAQ schema is What Google shows today Why FAQs are still worth publishing How to write FAQs worth marking up How to add FAQ schema in WordPress Example FAQs for a UK service business A simple FAQ schema example How to test and monitor your markup Where to add FAQs on a business website Mistakes to avoid A quick implementation checklist FAQs What FAQ schema is Schema markup is code, usually in JSON-LD format, that describes the content of a page in a way machines can understand. FAQPage schema tells a search engine that a page contains a list of questions and the answers to them. The code does not change how the page looks. It sits in the background and says: this text is a question, and this text is its accepted answer. That makes the content easier to extract for features such as rich results, voice assistants and AI-generated summaries. What Google shows today In 2023 Google reduced the visibility of FAQ rich results, limiting them to well-known, authoritative government and health sites. For most businesses, an FAQ listing will not appear as an expandable result in Google search any more. However, the structured data is not harmful, and valid markup can still be used by other search engines, assistants and AI tools. Google continues to recommend marking up content that is genuinely on the page. So treat schema as a helpful signal, not a guaranteed visual reward. Why FAQs are still worth publishing They answer real customer questions, which reduces enquiries that stall because of uncertainty. They capture long-tail searches phrased as questions, including People Also Ask style queries. They give AI Overviews and chat assistants concise, self-contained answers to quote. They support voice search, where users ask natural questions. They let you address objections such as price, timescales and risk on the pages that convert. How to write FAQs worth marking up Source questions from real life: sales calls, emails, live chat, Google Search Console queries, People Also Ask and reviews. Avoid inventing questions just to hit a keyword. Answer directly in the first sentence, then add context in one or two further sentences. Keep each answer between 40 and 80 words where possible. Be specific and accurate, including real numbers and conditions, and avoid sales language. How to add FAQ schema in WordPress There are three main routes. Many SEO plugins such as Yoast and Rank Math include FAQ blocks for the block editor that output valid markup automatically. Elementor users can use an FAQ or accordion widget that generates schema, or add a JSON-LD script in an HTML widget. For a custom approach, a developer can add the markup in the page template. Whichever route you use, the markup must match the visible text. Never add questions and answers to schema that are hidden or do not appear on the page, as this breaches Google guidelines and can lead to structured data issues. Example FAQs for a UK service business A strong FAQ section for a boiler servicing company might include: “How much does a boiler service cost?” with a clear range and what is included, “How long does a service take?” with a typical duration, “Do I need a Gas Safe registered engineer?” with a plain explanation of the legal requirement, and “How often should my boiler be serviced?” with the usual annual recommendation. Each answer opens with the direct answer, adds one useful detail such as what the engineer checks, and ends with a gentle pointer, such as a link to a booking page. That structure works for humans scanning the page and for machines looking for a clean, quotable response. For an accountancy firm, the equivalent questions might be about fees, deadlines, switching accountants and what records to keep. For an e-commerce store, they would cover delivery times, returns and sizing. The key point is that these are all genuine concerns that stop people from buying or enquiring. Answering them well improves conversion, supports SEO and gives AI assistants accurate, quotable information about your business. When you update prices or services, update the FAQ text and the schema together. Out-of-date answers in structured data are an easy way to lose trust, so build a small review step into your regular website maintenance. A simple FAQ schema example A minimal block of JSON-LD for two questions looks like this in concept: a FAQPage containing a mainEntity list, where each item is a Question with a name and an acceptedAnswer containing a text field. You paste it into a script tag of type application/ld+json. Most plugins create this for you, which is the safer option for non-developers. After adding it, check that the plain text of each answer is clean. HTML such as links and lists is allowed in answers, but keep it simple, and make sure the final text reads well if extracted on its own. How to test and monitor your markup Use Google’s Rich Results Test to confirm the

Every UK website accumulates them. The product page left behind after a category restructure. The blog post from 2019 that was quietly removed from the navigation during a redesign but never redirected. The press release published eight years ago for a service the business no longer offers. The landing page created for a PPC campaign that ended, then forgotten entirely. Orphaned pages — pages that exist on your domain but receive no internal links from any other page on the site — are one of the most pervasive and most consistently underestimated technical SEO problems in UK web publishing. They cost crawl budget by pulling Googlebot’s attention toward content that cannot receive the ranking signals necessary to justify the crawl. They dilute topical authority by fragmenting your domain’s content graph into disconnected islands. They suppress quality signals by adding low-engagement, poorly linked content to the total page count against which your domain’s quality is assessed. And they are largely invisible. You cannot see orphaned pages in Google Search Console’s standard interface. You cannot see them in a standard Screaming Frog crawl run from the homepage. They exist in a kind of digital limbo — present in Google’s index (discovered through XML sitemaps, backlinks, or historical crawl history), visible to Googlebot, but disconnected from your site’s intentional content architecture and therefore unable to participate meaningfully in the link equity flow that powers your ranking performance. This guide covers the complete audit methodology for identifying orphaned pages on UK sites of any size, the prioritisation framework for deciding what to do with each orphan, and the systematic fixes that reclaim the crawl budget currently being wasted on content your own site has effectively abandoned. What Orphaned Pages Actually Are? Before the audit methodology, a precise definition — because “orphaned page” is used loosely in UK SEO discussions to mean several different things, and conflating them produces an imprecise audit and an ineffective remediation. An orphaned page, strictly defined, is a page that meets all three of the following criteria simultaneously: It exists on your domain. The page returns a 200 OK status code — it is a live, accessible page on your server. It is not a 404, not a redirect, not a staging page. It is a fully functional web page. It receives no internal links from other pages on your live site. No other published, indexable page on your domain links to it. It is not referenced in your navigation, not linked from any blog post, not cited in any service page, not included in any category or archive listing that other pages link to. It is accessible to Googlebot. The page is not blocked by robots.txt and does not carry a noindex meta tag. Googlebot can crawl it, read it, and choose whether to index it. Pages that are intentionally isolated — noindexed staging pages, password-protected drafts, robots.txt-blocked utility pages — are not orphans in the SEO sense. They are deliberately excluded from the crawlable index, and Googlebot respects that exclusion. True orphans are pages that your site architecture has inadvertently abandoned while leaving them fully crawlable — pages that receive Googlebot’s attention without receiving the internal authority signals that would make that attention worthwhile. The distinction matters for audit design: your audit is looking for pages that Googlebot can access, but your internal linking architecture has lost track of. Not pages you have intentionally hidden. Why Orphaned Pages Damage UK Sites More Than Most Owners Realise The damage orphaned pages cause operates across three dimensions simultaneously — each one meaningful in isolation, all three compounding when left unaddressed at scale. Crawl budget drain. Google allocates a finite crawl budget to every domain — a total crawl capacity determined by your server’s speed and stability, your domain’s authority, and Google’s assessment of how frequently your content changes. When Googlebot discovers an orphaned page — through your XML sitemap, a historical crawl log, or an external backlink pointing to the orphan — it crawls it. Every crawl of an orphaned page is a crawl that could have been spent on your highest-priority commercial pages instead. For large UK websites — ecommerce sites with product history going back years, media sites with extensive content archives, service businesses that have changed their offering multiple times — the cumulative crawl budget drain from orphaned pages can be substantial. A UK travel agency that has launched and retired dozens of destination-specific campaigns over eight years may have hundreds of orphaned campaign landing pages still visible to Googlebot, each consuming crawl budget that should be directed at their current booking pages. Topical authority fragmentation. Google’s assessment of your domain’s topical authority is built partly from the coherence and density of your internal linking graph — how well-connected your content is and how clearly the link structure signals the relationships between topics. Orphaned pages break this graph. They represent knowledge your site nominally contains but has structurally disowned — content that exists as an island, signalling neither that it belongs to your core topic cluster nor that it has been deliberately removed from it. For UK businesses investing in topical authority strategies — the hub-and-spoke and cluster models covered earlier in this series — orphaned pages are a direct counterforce. A carefully constructed content cluster with twelve interlinked posts suffers when three additional posts on the same topic exist as orphans with no connection to the cluster. The orphans dilute the cluster’s topical signal without contributing to it. Helpful Content quality suppression. Google’s Helpful Content system evaluates content quality at the domain level — the aggregate quality signal of all indexable content on a domain influences how Google ranks any individual page on that domain. Orphaned pages disproportionately contribute negative quality signals because they share three characteristics that the Helpful Content classifier penalises: they receive minimal organic traffic (nobody discovers them through navigation), they generate poor engagement signals (low dwell time, high bounce, no internal link depth), and they are frequently outdated (orphaned because the

If you’ve run a Lighthouse audit recently, you’ve probably seen a recommendation to “use HTTP/2 or later” buried in the diagnostics. What that line doesn’t tell you is that “later” now means something specific: HTTP/3, the protocol that finally retires TCP as the web’s default transport and replaces it with QUIC. For UK businesses competing on Google.co.uk, this matters less as a checkbox and more as a structural shift in how your site talks to browsers, CDNs, and Googlebot itself — with knock-on effects for the metrics Google actually rewards. This article unpacks what HTTP/3 and QUIC actually do differently, separates the genuine SEO impact from the noise around it, and gives you a practical adoption path, whether you’re running WordPress on shared hosting or a headless stack behind Cloudflare. A quick refresher: HTTP/3 is not “HTTP/2 but faster” Every HTTP version up to and including HTTP/2 ran on TCP (Transmission Control Protocol). TCP guarantees ordered, reliable delivery, which is exactly why the web was built on it. But that guarantee creates a structural cost: if a single packet goes missing, every stream multiplexed over that connection stalls until the lost packet is retransmitted. This is head-of-line blocking, and it’s the single biggest reason HTTP/2’s multiplexing promise was never fully delivered on lossy or congested networks — including the 4G and patchy office Wi-Fi that a large share of UK mobile searchers are actually using. HTTP/3 solves this by abandoning TCP altogether. It runs over QUIC, a transport protocol originally built inside Google and now standardised by the IETF, on top of UDP rather than TCP. Three changes fall out of that decision, and all three matter for performance. Independent stream multiplexing. QUIC maps each HTTP request to its own stream, and packet loss on one stream no longer blocks the others. A dropped packet carrying a lazy-loaded image no longer holds up the critical CSS that’s also in flight on the same connection. 1-RTT and 0-RTT handshakes. TCP plus TLS 1.3 typically needs two to three round-trip times before the first byte of your page arrives: one for the TCP handshake, one or two more for TLS negotiation. QUIC folds the cryptographic handshake into the transport handshake itself, getting a first-time visitor to one round trip, and a returning visitor who already holds a valid session ticket to zero round trips before the request goes out. On a connection with 150ms of latency (not unusual for someone in rural UK connecting to an under-optimised origin server), that’s a real, measurable chunk of time off Time to First Byte before a single byte of HTML has even arrived. 2-Connection migration. Because a QUIC connection is identified by a Connection ID rather than a source IP and port pair, a user moving from office Wi-Fi to mobile data — or a phone switching cell towers — doesn’t force a fresh handshake. The connection survives the network change. This is genuinely significant for mobile UX given how much organic traffic in the UK is now mobile-first, and how often a real browsing session crosses network boundaries mid-page. None of this is theoretical. Google’s own QUIC research reported roughly an 18% reduction in YouTube rebuffering after rolling QUIC out at scale, and that data point, more than any marketing material, is what convinced the rest of the industry this wasn’t just a Google pet project. The SEO question everyone gets wrong Here’s the part that needs stating plainly, because a lot of content on this topic gets it backwards: HTTP/3 is not a Google ranking factor. There is no algorithmic check for “does this origin support QUIC” that feeds into rankings. If you migrate to HTTP/3 and your content, backlink profile, and search intent match stay exactly the same, you should not expect a ranking bump from the protocol switch alone. In fact, Google’s own crawler documentation is more conservative on this than most SEO content acknowledges. Googlebot’s crawling infrastructure currently supports HTTP/1.1 and HTTP/2, defaults to HTTP/1.1, and explicitly states that crawling over HTTP/2 carries no ranking benefit for your site — only a potential resource saving for both your server and Google’s. HTTP/3 doesn’t even appear in that documentation as a crawling protocol option at the time of writing. So the crawl itself — the act of Googlebot fetching your page — almost certainly still happens over HTTP/1.1 or HTTP/2 regardless of what protocol you’ve enabled for human visitors. What HTTP/3 actually changes is the experience of the people loading your pages, not the bot indexing them. And that’s where the real SEO connection lives: through Core Web Vitals. The real mechanism: HTTP/3 → faster delivery → better Core Web Vitals → ranking signal Core Web Vitals are a confirmed part of Google’s page experience signals, made up of three metrics measured at the 75th percentile of real Chrome users via the Chrome UX Report (CrUX): Largest Contentful Paint (LCP, the “good” threshold sits at 2.5 seconds), Interaction to Next Paint (INP, threshold 200 milliseconds, having replaced First Input Delay as the responsiveness metric in March 2024), and Cumulative Layout Shift (CLS, threshold 0.1). Google has been explicit that these act as a tie-breaker rather than an override: strong content with poor Core Web Vitals will still usually outrank thin content with perfect Core Web Vitals, but among pages of genuinely comparable relevance and quality, speed and stability earn a measurable edge. This is where QUIC’s mechanics translate into something Google does reward. Faster handshakes and the removal of head-of-line blocking shrink the time before your largest content element paints — a direct LCP input, particularly for visitors on higher-latency or lossy mobile connections, where TCP’s retransmission penalty was always worse. Connection migration reduces the chance that a layout-shifting reconnection event interrupts a session mid-load. None of this rewrites your content relevance score. All of it nudges the loading-speed half of the equation in your favour, on exactly the device class and network conditions where most UK searches now originate.