` and `<meta name="description">`, with the result that whichever runs later wins, but both leave their schema in the head. Symptom: duplicate `BreadcrumbList`, duplicate `WebPage`, conflicting `Article` blocks. Google merges what it can and discards the rest, but the signal is muddy. Pick one, deactivate the other, then check the rendered HTML for stale schema cached by an object cache or page cache. Flush both after the migration. Rank Math tends to win on schema flexibility, Yoast on the opinionated content analysis that authors actually read. Neither matters more than the consistency of using one. ### How to set up hreflang on a multilingual WordPress site If you are running a multilingual site, hreflang is the difference between Google serving the right language to the right country and serving Polish content to Portuguese visitors who then bounce. The annotations have to be reciprocal (every alternate must list every other alternate, including itself), they have to point at canonical URLs, and they have to include `x-default`. Plugins handle this, but check the rendered HTML: Google [retired the International Targeting report](https://support.google.com/webmasters/answer/12474899) from Search Console, and silent hreflang errors are common after a slug change. ### WordPress core sitemap or a Yoast and Rank Math sitemap WordPress core ships `/wp-sitemap.xml`, which is fine for small sites and inadequate for everything else because it does not let you weight or exclude. Yoast and Rank Math both publish `/sitemap_index.xml` with separate post-type indices, which is what you want. The non-obvious move: exclude the `attachment` post type from sitemaps unless you are running a media library that is itself the product. Attachment URLs spawned by image uploads do not need to be in Google's index; they dilute crawl budget on larger sites and produce thin-content soft 404s on smaller ones. ### Best permalink structure for WordPress SEO Permalinks are the permanent URLs to your individual pages and posts. WordPress defaults to a numeric format (/?p=123), which provides no information to search engines or users. Instead, use a descriptive permalink structure that includes your post title. To change your permalink structure, go to Settings > Permalinks in your Dashboard. The "Post name" option is generally recommended as it creates clean, readable URLs like `yourdomain.com/your-post-title/`. For custom post types or categories, you can also configure custom structures. Just ensure your URLs are concise and include relevant keywords when appropriate. ### How to structure headings in WordPress posts Search engines prioritize content that provides value to users. Structure your articles using heading tags (H1 for titles, H2 for main sections, H3 for subsections) to create a logical hierarchy. This helps search engine crawlers understand your content organization. WordPress's Block Editor makes it easy to add headings, lists, and other structural elements. Use the built-in blocks to create: - H2 and H3 headings for section organization - Numbered lists for step-by-step content - Bullet points for quick tips - Quote blocks for testimonials or citations - Table blocks for comparative data ### How to optimize images for WordPress SEO Images can significantly impact your page load times and SEO performance. Before uploading images to WordPress, compress them using online tools or image editing software. WordPress also includes basic image optimization settings. When adding images, always include descriptive alt text - this improves accessibility and provides search engines with context about the image content. You can add alt text through the Image block sidebar in the Block Editor or via the Media Library. ### How many categories and tags a WordPress post should have WordPress's taxonomy system helps organize your content and improve site navigation. Categories are broad groupings (like "Technology" or "Business"), while tags are more specific descriptors. Both help search engines understand your content structure. Create logical category hierarchies and use relevant tags sparingly. Avoid over-tagging, as this can dilute your content's relevance signals. A typical post should have 1-2 categories and 5-10 relevant tags. ### How to write custom excerpts in WordPress Excerpts are brief summaries of your posts that appear in various contexts - search results, archive pages, and RSS feeds. Write custom excerpts that include your primary keyword naturally. You can set custom excerpts in the Document settings sidebar of the Block Editor. ### Where to find the WordPress XML sitemap …[truncated, fetch the canonical URL for the full body]… --- ## Legal compliance guide for WordPress agencies in Spain: GDPR, AEPD, LSSI and NIS2 URL: https://wppoland.com/en/wordpress-legal-compliance-guide-spain/ Description: A technical guide to the digital regulations that apply to WordPress sites in Spain. Practical requirements for GDPR, AEPD rulings, LSSI-CE, VeriFactu and NIS2. Published: Sat May 02 Updated: Wed Oct 14 Tags: compliance, seguridad, guide, 2026 # Legal compliance guide for WordPress agencies in Spain: GDPR, AEPD, LSSI and NIS2 Legal requirements for corporate and ecommerce websites in Spain are no longer a set of theoretical guidelines. They have become a strict operating framework. In 2026, building a website in Spain with WordPress takes detailed knowledge not only of the technology but also of the [national and European laws](/en/eu-compliance-audit-wordpress/) that govern privacy, ecommerce, invoicing and cybersecurity. Ignoring these rules exposes companies to sanctions from the Spanish Data Protection Agency (AEPD), from the Secretaría de Estado de Digitalización e Inteligencia Artificial (the Secretary of State for Digitalisation and Artificial Intelligence) and from the Spanish Tax Agency. This article walks through the technical requirements a WordPress installation has to meet to comply with the current regulatory framework in Spain, with references to the consolidated texts in the BOE (the Spanish official gazette) and to the AEPD guides. --- ## How to comply with the GDPR on WordPress under AEPD rules The GDPR (Regulation (EU) 2016/679) is the foundation of personal data processing in the European Union. In Spain it is enforced very actively by the AEPD through Organic Law 3/2018 on the Protection of Personal Data and Guarantee of Digital Rights (LOPDGDD). ### How to host Google Fonts locally in WordPress One of the most common mistakes on WordPress sites is hotloading external resources. When a website makes a request to an external server (such as Google's servers to download fonts), the visitor's IP address (personal data under the GDPR) is passed to that third-party provider and, often, outside the European Union. That transfer needs a legal basis and, if the server sits outside the European Economic Area, safeguards for the international transfer. Hosting the fonts on your own server removes the external request and, with it, both problems. The technical fix in WordPress is simple: every font is downloaded and served locally from the server or bundled into the static build (for headless sites built with Astro). To host fonts locally on a classic WordPress build: 1. Download the font files (`.woff2`) from Google Webfonts Helper or a similar source. 2. Upload the fonts to the theme or child theme folder (`/assets/fonts/`). 3. Define the `@font-face` rules in the CSS stylesheet. 4. Disable external requests with filters in `functions.php` or with optimisation tools. ```css @font-face { font-family: 'Outfit'; font-style: normal; font-weight: 400; font-display: swap; src: url('/assets/fonts/outfit-v11-latin-regular.woff2') format('woff2'); } ``` ### Choosing GDPR-compliant hosting in the EU The GDPR requires the controller to ensure that user data is stored and processed on infrastructure that meets European rules. International data transfers to countries without an adequacy decision from the European Commission need additional safeguards (such as signing Standard Contractual Clauses, SCC). In 2026, data sovereignty has pushed agencies towards hosting physically located in the European Union. Platforms that route traffic through proxies outside Europe without a signed DPA (Data Processing Agreement) are a significant compliance risk. CDN and hosting providers that offer storage exclusively in European data centres are the standard choice for production builds. --- ## What the LSSI requires from a WordPress site The LSSI (Law 34/2002) transposes the Electronic Commerce Directive into Spanish law. It governs services offered online when they form an economic activity for the provider. ### What the Aviso Legal page must include Any website that forms an economic activity for its owner (direct sales, advertising, affiliate links or lead generation) must give permanent, easy, direct and free access to the information listed in Article 10.1 of the [LSSI](https://www.boe.es/buscar/act.php?id=BOE-A-2002-13758), usually gathered on the **Aviso Legal** (legal notice) page: - Name or registered company name, residence or address (or a permanent establishment in Spain), email address and any other detail that allows direct and effective communication. - Registration details in the Commercial Registry (Registro Mercantil) or in the public register where the owner is registered. - If the activity requires prior administrative authorisation, the details of that authorisation and of the body that supervises it. - If a regulated profession is practised, the professional association and membership number, the qualification, the State that issued it and the applicable professional rules. - Tax identification number. - If the site shows prices, clear and accurate information on whether they include taxes and, where relevant, shipping costs. - The codes of conduct the owner has signed up to. The law does not require a phone number: an email address plus any other direct contact channel is enough. Article 38 grades the breaches. A significant failure to comply with paragraphs a) (identification and contact) and f) (prices) of Article 10.1 is a serious infringement (Article 38.3 b), and failing to provide the other details is a minor infringement (Article 38.4 b). Under Article 39, serious infringements carry fines of 30,001 to 150,000 euros and minor ones fines of up to 30,000 euros. In WordPress, the natural place for this information is a page linked from the footer of every template, including the WooCommerce checkout. ### Cookie management and the consent banner Article 22.2 of the LSSI allows data storage and retrieval devices to be used on the user's equipment only if the user has given consent after receiving clear and complete information about their use and purpose. The AEPD [Guía sobre el uso de las cookies](https://www.aepd.es/guias/guia-cookies.pdf) (guide on the use of cookies), updated in May 2024, sets out how the banner (CMP, Consent Management Platform) has to work: - **Equal buttons**: the option to reject must be offered at the same time, at the same level and with the same visibility as the option to accept, without sending the user to another layer to reject. Highlighting the accept button with loud colours while hiding the reject option behind a hard-to-read text link is not allowed. - **Categories**: users must be able to accept or reject cookies by purpose (analytics, advertising, preferences). Technical cookies needed to provide the service requested (such as keeping items in the cart or remembering the language) are exempt from consent. - **Active consent**: the guide adopts the European Data Protection Board's position that continuing to browse is not a valid way of giving consent, and adds that mere inactivity by the user is not valid either. Tracking scripts must stay fully inactive until the user clicks "Accept". ### Which web analytics can run without consent under AEPD rules The general AEPD guide points out that analytics cookies are not exempt from the consent requirement. The exception sits in a separate guide, [Uso de cookies para herramientas de medición de audiencia](https://www.aepd.es/guias/guia-cookies-analiticas-externas.pdf) (use of cookies for audience measurement tools, January 2024), which allows it only if all of these conditions are met: - The purpose is limited to measuring the audience of the site itself, solely on behalf of the publisher, and the result is anonymous statistical data. - The data is not combined with other processing or passed to third parties, and it does not allow the person to be tracked across different sites or apps. - The cookie lifetime is limited to a period that allows audiences to be compared (the guide gives thirteen months as an example), without being extended on each visit, and the data is kept for no more than twenty-five months. - The user is informed, for example in the privacy policy. - If the measurement is provided by an external vendor, there is a contract under Article 28 of the GDPR that forbids the vendor from reusing the data. The guide also lists the measurements it considers strictly necessary: audience per page, referring pages, device and browser type, load times, time on page, user actions and geographic area, always in aggregate form. A setup that shares data with advertising platforms falls outside the exemption. A self-hosted tool, configured not to combine or pass on data, can fit within it. ### What fine the AEPD imposes for cookies without consent Using non-exempt cookies without informing users or without obtaining consent on the terms of Article 22.2 is a minor infringement under Article 38.4 g) of the LSSI, punishable by a fine of up to 30,000 euros (Article 39.1 c). If the breach is repeated and a final decision issued in the previous three years has declared it, the infringement becomes serious (Article 38.3 i), with a fine of 30,001 to 150,000 euros. Most LSSI infringements are sanctioned by the Secretaría de Estado de Digitalización e Inteligencia Artificial, but Article 43.1 gives the AEPD those concerning cookies, commercial communications by email and the withdrawal of consent. To set the amount, Article 40 takes into account, among other criteria, intent, how long the infringement lasted, the profits obtained, the turnover affected and the steps taken to mitigate or repair the damage. Fixing the banner as soon as the fault is found and documenting the fix is therefore a factor the law itself weighs. --- ## How to build GDPR-compliant forms in WordPress Lead capture through contact forms, newsletter sign-ups or quote requests is a critical point under AEPD scrutiny. Because WordPress relies heavily on form plugins (such as Contact Form 7, Gravity Forms or Formidable Forms), it needs careful configuration to avoid legal gaps: ### Consent checkbox on the contact form Every contact form that collects personal data (such as name, email or phone number) must include a checkbox that is unticked by default, through which the user explicitly accepts the site's privacy policy. - Pre-ticked boxes are not allowed. - Form submission must stay blocked until the user actively ticks the box. - The text next to the box must link clearly and accessibly to the **Privacy Policy** page. ### What the first layer of privacy information must include The AEPD requires a simplified "first layer" of information about data processing to appear directly below the form's submit button. It must state clearly and directly: - **Controller**: name of the site owner or company. - **Purpose**: why the data is collected (for example, answering enquiries or sending commercial offers). - **Legal basis**: the lawful basis for processing (usually the data subject's consent). - **Recipients**: whether data will be shared with third parties (for example, email marketing tools such as Brevo or Mailchimp). - **Rights**: how users can exercise their rights of access, rectification, erasure and objection (for example, by emailing a dedicated mailbox). ### How to log form consent in WordPress To meet the GDPR accountability principle, the company must be able to prove that a specific user accepted the privacy policy on a specific date and time. In WordPress, this means configuring the form plugin to store in the database the IP address (partly anonymised where possible), the timestamp and the consent state of the ticked box for every form submission. --- ## Mandatory web accessibility in WordPress under the EAA Directive (EU) 2019/882, known as the European Accessibility Act (EAA), was transposed in Spain through Title I of [Ley 11/2023, de 8 de mayo](https://www.boe.es/buscar/act.php?id=BOE-A-2023-11022) (Law 11/2023 of 8 May). It requires certain products and services to be accessible to people with disabilities, among them ecommerce services (including those built with WooCommerce) and banking, transport and electronic communications services. …[truncated, fetch the canonical URL for the full body]… --- ## Will AI replace WordPress developer? URL: https://wppoland.com/en/will-ai-replace-wordpress-developers/ Description: What is a WordPress developer, what does one do, and will AI replace the role? Honest look at rates, skills, and the real impact of AI on WordPress development in 2026. Published: Wed Feb 25 Updated: Wed Feb 25 Type: guide Level: intermediate Tags: AI, WordPress, Web Development, Career, Future <div id="introduction" class="speakable-summary"> ## Can AI replace WordPress developers let's be honest. if you're a WordPress developer in 2026, you've seen the headlines. you've tried chatgpt. you've probably used copilot. and you've wondered: is my career over? here's the truth: it's not. but it's changing. this isn't another article telling you AI will revolutionize everything or that you need to panic. it's just what actually matters for your work. i've been building WordPress sites since before it was cool. i remember when WordPress was just a blogging platform. i've seen the platform evolve, seen frameworks come and go, and now i'm watching AI reshape how we work. here's what i think. </div> ## What is a WordPress developer A WordPress developer is a web professional who builds, customizes, and maintains websites on the WordPress platform. The role spans a wide spectrum: - **Theme developers** create the visual layer -- templates, layouts, responsive design, CSS, and the integration between design and WordPress's template hierarchy. - **Plugin developers** extend WordPress functionality through custom PHP code, hooks (actions and filters), REST API endpoints, and database interactions. - **Full-stack WordPress developers** handle both frontend and backend, including server configuration, performance optimization, security hardening, and deployment pipelines. - **WooCommerce developers** specialize in e-commerce -- product configurations, payment gateway integrations, shipping logic, and compliance (VAT, GDPR, Omnibus). In 2026, a WordPress developer also increasingly works with [headless architectures](/en/headless-wordpress-architecture-2026-enterprise-guide/) (WPGraphQL + React/Astro frontends), AI integrations ([Abilities API](/en/wordpress-abilities-api/)), and performance engineering (Core Web Vitals optimization). For a deeper breakdown of [the role and how it is defined](/en/wordpress-developer/), each of these specializations maps to a different day-to-day reality. ## What does a WordPress developer do Day-to-day work varies by specialization, but a typical WordPress developer's responsibilities include: 1. **Building custom themes and plugins** from client specifications, translating business requirements into working code. 2. **Integrating third-party systems** -- CRMs, payment processors, shipping APIs, analytics platforms, marketing automation tools. 3. **Performance optimization** -- diagnosing slow queries, reducing TTFB, optimizing images, implementing caching strategies, and hitting Core Web Vitals targets. 4. **Security maintenance** -- applying updates, hardening configurations, running vulnerability scans, handling incident response when sites get compromised. 5. **Debugging production issues** -- plugin conflicts, PHP fatal errors, database corruption, hosting environment problems. 6. **Client communication** -- translating technical constraints into business language, managing expectations, and delivering projects on time. 7. **Content architecture** -- designing custom post types, taxonomies, ACF field groups, and Gutenberg block patterns that match how the client's team actually works. The role is not just "making websites." It is solving business problems using WordPress as the platform. The developers who earn the most are the ones who understand both the technical stack and the business context. With [WordPress 7.0 shipping AI integration](/en/wordpress-7-0-complete-guide-ai-integration/) natively, AI literacy is becoming part of the core skill set. ## What WordPress developers use AI for let's give credit where it's due. [AI tools](/en/ai-wordpress-tools-content-generation-guide/) are genuinely useful for certain tasks. **code generation** works for standard stuff. need a basic plugin structure? a custom post type setup? standard WordPress patterns? AI handles this fine. it's not magic, but it saves typing. **documentation questions** are where AI shines. forget how a WordPress function works? just ask. it beats searching through codex. it beats Stack Overflow when the answers are outdated. sure, sometimes it hallucinates, but so does half of Stack Overflow. **debugging help** can speed things up. AI won't fix your bug, but it might point you in the right direction faster than random Googling. it can read your error message and suggest common causes. that's useful. **boilerplate everything** from email templates to privacy policies to cookie banners. AI generates reasonable first drafts that you then customize. it's faster than writing from scratch. for WordPress-specific help, check out our [WordPress development services](/en/wordpress-developer/) if you need help with custom projects. ## Which WordPress tasks AI cannot replace now for the real talk. here's where your job is safe. **client conversations.** someone needs to talk to the client, understand their actual business, translate that into a website, and manage expectations. that's not code. that's a conversation. AI can't do that. it can generate professional emails, but it doesn't know your client's personality, their patience level, whether they want a quick call or detailed written responses. **custom solutions.** every client thinks their needs are unique. sometimes they're right. when you need to build something that doesn't exist, figure out why three plugins aren't working together, or solve a problem no one else has solved, you're doing it. AI can only work with what exists. innovation is human. **the messy reality.** production WordPress sites are a disaster. old plugins, deprecated code, weird configurations. you can't automate your way through someone else's technical debt. you show up, you dig in, you figure it out. that's not going anywhere. **security and compliance.** clients need GDPR compliance, security audits, accessibility fixes. these require understanding context, making judgment calls, and taking responsibility. AI can suggest best practices but can't sign off on compliance. that signature is human. **project management.** timeline estimates, resource allocation, scope management. these are human skills. AI doesn't know your team, your client's budget flexibility, or which features are actually critical versus nice to have. **relationships.** clients hire developers they know. trust is built through actual communication, reliability, and results. this is human work. the guy who shows up when he says he will, who explains things clearly, who solves problems quickly. that's who gets the work. ## Will AI take WordPress developer jobs the work isn't disappearing. it's shifting. **faster basics.** if AI handles the simple stuff faster, you have more time for complex work. this is good. it means faster delivery, happier clients, more money. **different expectations.** clients now expect you to use AI tools. they don't want to pay full rate for work a robot could do faster. adapt or lose bids. it's simple economics. **new opportunities.** AI integration in WordPress is becoming a service. if you understand both, you can offer something valuable. who else would do this? traditional developers don't get AI, AI specialists don't get WordPress. **the bar is higher.** because AI handles basics, clients expect more. the commodity work is getting automated. the value is in the custom work now. that's where you need to be. ## What drives WordPress developer rates now here's what actually drives rates. **supply and demand** haven't changed that much. there's still massive demand for WordPress sites. every small business needs one. most can't build it themselves. they need you. **commoditization vs specialization.** basic WordPress sites are becoming commoditized. anyone with Elementor can build a landing page. but complex projects, [WooCommerce stores](/en/woocommerce-developer/), membership systems, [custom plugin development](/en/wordpress-developer/), that's where rates stay high. check our [pricing page](/en/wordpress-pricing/) to see current market rates. **the relationship premium.** developers with established client relationships can charge 30-50% more than strangers. clients pay for trust. for reliability. for not having to explain things twice. this is entirely human. [contact us](/en/contact/) to see how we build lasting client relationships. **location doesn't matter as much anymore.** remote work globalized the market. you're competing with developers worldwide. but that also means you can access clients worldwide. the opportunity is bigger, but so is the competition. ## How to future-proof a WordPress developer career against AI if you want to thrive as a WordPress developer in this environment, here's what actually helps. **be useful, not just technical.** clients don't care about your stack. they care about their website working. solve real problems. that's what gets you paid. **communicate clearly.** explain things in plain English. manage expectations. deliver on time. this is what makes clients happy. happy clients refer other clients. unhappy clients leave reviews that hurt your business. **embrace the tools.** AI isn't your enemy. it's a tool. use it for what it's good at, focus your energy on what you're good at. the developers making most money? they're using AI for 40% of the work and doing the complex 60% that requires skill. **specialize strategically.** don't try to be everything. pick a niche. healthcare WordPress sites. e-commerce with [WooCommerce](/en/woocommerce-developer/). membership platforms with [WordPress membership plugins](/en/wordpress-developer/). something where you can be the expert. specialists charge more than generalists. our [portfolio](/en/portfolio/) shows examples of specialized work. **keep learning.** but learn things that actually matter. not every new framework. not every plugin update. the fundamentals that let you solve new problems. the business skills that help you get and keep clients. follow our [blog](/en/blog/) for regular updates on WordPress trends. ## What is the future of WordPress developers having done this for years, here's my prediction. **AI won't replace you.** it will replace the parts of your job that are boring anyway. you'll spend less time on boilerplate, more time on interesting work. that sounds good to me. **the role evolves.** the job description changes every few years anyway. from raw PHP to themes to page builders to headless. this is just another evolution. the developers who adapt will be fine. **opportunities emerge.** new services appear. AI integration, AI-powered features, AI-assisted support. these are revenue streams that didn't exist before. early adopters capture value. **human skills become more valuable.** as technical work automates, the human stuff stands out. communication, relationship building, project management. these become differentiators. ## Should you still learn WordPress in the age of AI? AI won't replace WordPress developers. it will replace the boring parts of the job. and honestly? that's probably good. the developers who do well will be the ones who use AI as a tool, focus on the human side of the work, and keep getting better at solving actual problems for actual clients. your career isn't over. it's just evolving. same as always. need help with a WordPress project? [get in touch](/en/contact/). we specialize in complex WordPress work that AI can't handle. now go build something. ## WordPress integrations and migrations AI cannot handle let me tell you about a project i worked on last month. client needed a custom booking system for their medical practice. nothing out of the ordinary, right? wrong. they had three different software systems that somehow needed to talk to each other. their patient management software, their calendar, and their billing system. none of them had APIs. none of them were documented properly. and they needed everything to work by next month. …[truncated, fetch the canonical URL for the full body]… --- ## Headless WordPress for WooCommerce: when it pays back, and what to skip URL: https://wppoland.com/en/headless-wordpress-for-woocommerce/ Description: Headless WooCommerce shifts cost and complexity. It pays back when mobile Core Web Vitals are tied to revenue, when the catalogue stabilises, and when a senior front-end engineer is in the loop. It does not pay back for tiny shops or for sites where the bottleneck is not the front. Published: Sun Apr 12 Updated: Tue Sep 22 Type: guide Level: intermediate Tags: headless-wordpress, woocommerce, core-web-vitals, cloudflare-workers, astro, nextjs *Expanded and up-to-date version of this topic: [Headless WooCommerce with Astro](https://wppoland.com/en/headless-woocommerce-astro-ecommerce-guide-2026/).* # Headless WordPress for WooCommerce: when it pays back, and what to skip The intent behind the question "is headless WordPress a good fit for WooCommerce" is rarely about technology. It is about whether the store will keep working through the migration, whether the existing extensions survive, and whether the new architecture pays back inside the budget cycle. The honest answer is: depends on the store. This article makes the call concrete. It supports the [Headless WordPress service pillar](/en/services/headless-wordpress/) and the [headless economics piece](/en/economics-of-headless-wordpress-2026/), where the framework lives. ## Which stores suit headless WooCommerce - Good fit for stores where mobile Core Web Vitals limit conversion. - Good fit for stores with stable catalogues that cache well at the edge. - Bad fit for tiny shops where orchestration cost exceeds the saving. - Bad fit for stores running heavy WooCommerce extensions that assume PHP-rendered fronts. - Edge runtime: Cloudflare Workers handles both [Astro](/en/headless-woocommerce-astro-ecommerce-performance-2026/) and Next.js back to a WordPress origin. ## What headless WooCommerce actually means WordPress with WooCommerce keeps the editorial workflow, the order management, the inventory store, and the payment processing. The headless front (Astro or Next.js) renders the public catalogue, product pages, cart, and checkout UI. The two communicate over the [WooCommerce](/en/woocommerce-developer/) Store API, the REST API, or GraphQL. Three pieces of the architecture matter: **The origin.** Still WordPress. Still WooCommerce. Same admin, same plugins, same payment flows. Editors do not change tools. **The front.** Astro or Next.js running on Cloudflare Workers. Renders pre-built HTML for the catalogue and product pages, falls back to SSR for cart and checkout. Reads from the WordPress origin. **The boundary.** REST or GraphQL between the two. Cookies and headers preserved across the boundary so session continuity works. This is the load-bearing piece, and the one that breaks first if a junior engineer ships. ## When does headless WooCommerce pay back Concrete scenarios where the trade is positive: - A 200-product fashion store with 70 percent mobile traffic and a sub-2-second mobile LCP being directly tied to conversion. - A B2B catalogue with 5000 stable SKUs where most pages cache for hours at the edge. - A WooCommerce store also serving as the catalogue source for a mobile app or AI-shopping agent (Universal Commerce Protocol). - A site already serving its own JS bundle with heavy interactivity, where the cost of editorial WordPress + Next.js together is not much higher than the existing setup. In all four, the win is some mix of edge-rendered Core Web Vitals (revenue effect) and predictable Cloudflare Workers cost (saving effect). ## When is headless WooCommerce not worth it Concrete scenarios where it does not pay back: - Single-product stores or stores with under 20 SKUs and low traffic. The migration cost dwarfs the saving. - Stores running 10+ active WooCommerce extensions that touch the front end. Each one needs an audit, often a re-implementation, or a hybrid build. - High-volatility inventory (live auctions, flash sales, real-time bookings). Cache invalidation cost rises faster than the front-end saving. - Heavily personalised pricing per customer. Edge caching weakens; the architecture loses much of its advantage. The polemic version: headless is not a default. The default is "stay monolithic until the bottleneck moves to the front". Once the bottleneck is mobile Core Web Vitals, then the trade pays back. ## What should you audit before headless WooCommerce A senior engineer running this audit before any migration commitment: 1. List every active WooCommerce extension. Mark each as "supports headless", "needs re-implementation", or "blocks headless". 2. Snapshot Core Web Vitals on mobile for the top 50 product pages. If LCP and INP are already healthy, the headless saving is smaller. 3. Pull traffic shape: visit volume, return-visitor share, mobile share, geographical distribution. High mobile + diverse geography favours headless on Cloudflare Workers. 4. Map the redirect history. WooCommerce sites accumulate redirects from product renames and category restructures. Migration must preserve them. 5. Identify per-customer pricing or session-driven content. The more there is, the smaller the headless edge. The result is a yes or a no. We have advised against headless migrations as often as we have advised for them. ## What a headless WooCommerce build includes When the audit comes out positive, the senior-team build looks like this: - WordPress with WooCommerce on a small managed host as the origin. - Astro or Next.js front (per the [Next.js vs Astro decision matrix](/en/headless-wordpress-nextjs-vs-astro-2026/)). - Cloudflare Workers + Pages for edge delivery. - Redis at the WordPress origin for object cache and session storage. - WooCommerce Store API enabled, with rate limiting on the Worker. - All seven [SEO patterns for headless WordPress](/en/seo-patterns-for-headless-wordpress/) preserved. The decision flow runs in that order. The TCO framework in the [economics piece](/en/economics-of-headless-wordpress-2026/) closes the loop. ## Related headless WordPress articles This long-tail article anchors to the [Headless WordPress service pillar](/en/services/headless-wordpress/) and to its three supporting pieces. For migration-side risks, the [SEO patterns article](/en/seo-patterns-for-headless-wordpress/) is the seven-point checklist. For decision framing, the [Next.js vs Astro matrix](/en/headless-wordpress-nextjs-vs-astro-2026/) and the [economics article](/en/economics-of-headless-wordpress-2026/) carry the load. For platform comparison, see [Shopify Plus vs WooCommerce headless](/en/shopify-plus-vs-woocommerce-headless-2026/). --- ## Introduction to WordPress SEO optimization and positioning URL: https://wppoland.com/en/introduction-wordpress-seo-optimization/ Description: Practical guide to modern technical WordPress SEO in 2026: Semantic HTML, JSON-LD Knowledge Graphs, INP optimization, crawling budgets, and clean canonical architectures. Published: Sun Jun 26 Updated: Tue Sep 22 Type: guide Level: intermediate *Expanded and up-to-date version of this topic: [How to create an SEO-optimized WordPress site in 2026](/en/how-to-create-seo-optimized-wordpress-site-2026/).* <div id="introduction"> Search engine optimization for WordPress has evolved far beyond the era of installing an all-in-one plugin, configuring a green traffic light indicator, and stuffing meta keywords into page headers. In 2026, search engines and answer engines (such as Google AI Overviews, Perplexity, and ChatGPT Search) analyze structural document architecture, Core Web Vitals responsiveness, and unambiguous entity graphs. WordPress powers over forty percent of the web, making its architectural nuances a primary target for technical SEO auditing. While the platform offers an exceptional publishing foundation, default configurations frequently introduce duplicate URL bloat, render-blocking assets, and fragmented schema markup. This guide establishes the technical blueprint required to transform a standard WordPress site into an authoritative, high-ranking digital asset. </div> ## How to clean up WordPress URLs and archives The foundation of every high-performing website is a deterministic, predictable URL hierarchy. Search engine crawlers allocate a finite crawl budget to each domain; wasting that budget on duplicate or low-value routes directly impedes the indexation of commercial pages. ### Which WordPress archives to noindex or disable By default, WordPress automatically creates secondary taxonomy archives: * **Date Archives** (`/2026/03/`): Entirely redundant for ninety-nine percent of business websites and creates seasonal duplicate content. * **Author Archives** (`/author/admin/`): On single-author websites, the author archive is identical to the main blog feed and exposes backend usernames to scrapers. * **Tag Archives** (`/tag/wordpress/`): Uncontrolled tag creation by content editors generates hundreds of thin pages containing one or two posts. * **Attachment Pages**: Historically, WordPress generated a distinct URL for every uploaded media file, creating thousands of near-empty pages. Modern technical hygiene requires disabling date archives completely, redirecting author archives to the about page (or canonical author bio), and setting thin tag archives to `noindex, follow` or removing tags in favor of structured categories. ```php /** * Redirect author archives on single-author sites to the main team page. */ function wppoland_redirect_author_archive(): void { if ( is_author() ) { wp_safe_redirect( home_url( '/en/about/' ), 301 ); exit; } } add_action( 'template_redirect', 'wppoland_redirect_author_archive' ); ``` ### Best permalink structure for WordPress Avoid complex permalinks with date components (`/%year%/%monthnum%/%postname%/`). For enterprise sites, standardizing on `/%postname%/` for articles and nesting hierarchical pages under logical parents (e.g. `/services/cloud-engineering/`) ensures permanent URL stability during updates. ## How to unify JSON-LD schema in WordPress Modern search engines do not read HTML like human visitors; they parse structured data according to the Schema.org specification to extract facts and build knowledge graphs. A common failure in WordPress setups is injecting multiple disconnected `<script type="application/ld+json">` tags from different plugins: one script defines the organization, another defines the article, and a third defines a product. Search engines are left guessing whether the author of the article actually works for the organization. ### JSON-LD @graph example for WordPress The enterprise standard unifies all entities into a single `@graph` array connected by `@id` URIs: ```json { "@context": "https://schema.org", "@graph": [ { "@type": "Organization", "@id": "https://wppoland.com/#organization", "name": "WPPoland", "url": "https://wppoland.com", "logo": { "@type": "ImageObject", "@id": "https://wppoland.com/#logo", "url": "https://wppoland.com/images/logo.png" } }, { "@type": "WebSite", "@id": "https://wppoland.com/#website", "url": "https://wppoland.com", "name": "WPPoland", "publisher": { "@id": "https://wppoland.com/#organization" } }, { "@type": "TechArticle", "@id": "https://wppoland.com/en/introduction-wordpress-seo-optimization/#article", "isPartOf": { "@id": "https://wppoland.com/#website" }, "headline": "Introduction to WordPress SEO optimization and positioning", "inLanguage": "en-US", "publisher": { "@id": "https://wppoland.com/#organization" }, "author": { "@type": "Person", "name": "Mariusz Szatkowski", "jobTitle": "Principal WordPress Engineer" } } ] } ``` This explicit linkage proves ownership and domain authority, directly satisfying Google E-E-A-T (Experience, Expertise, Authoritativeness, and Trustworthiness) criteria. ## How to improve INP on a WordPress site Technical search performance is inseparable from user experience metrics. Google evaluates mobile websites using [Core Web Vitals](/en/core-web-vitals-2026-inp-optimization-guide/): 1. **Largest Contentful Paint (LCP)**: The rendering speed of the primary visual element (target: < 2.5s). 2. **Cumulative Layout Shift (CLS)**: Visual stability during page load (target: < 0.1). 3. **Interaction to Next Paint (INP)**: The responsiveness of page interactions upon user input (target: < 200ms). ### What causes poor INP in WordPress While LCP is often resolved with server-side page caching and AVIF/WebP image optimization, INP is where unoptimized WordPress sites fail. Common culprits include: * Heavy slider and mega-menu scripts binding global `touchstart` or `click` event listeners without passive flags. * Tag manager containers firing dozens of analytics beacons simultaneously upon user scroll. * Client-side rendering frameworks hydrating heavy DOM trees after initial HTML paint. To protect INP: * Defer non-critical JavaScript using the `wp_enqueue_script` attribute `'strategy' => 'defer'`. * Avoid attaching heavy calculations directly to resize or scroll events; use `requestAnimationFrame` or `IntersectionObserver`. * Replace JavaScript-heavy animations with hardware-accelerated CSS transforms. ```php /** * Modern script registration with native deferral in WordPress core. */ function wppoland_enqueue_deferred_assets(): void { wp_enqueue_script( 'wppoland-interactions', get_theme_file_uri( '/dist/interactions.js' ), array(), '1.0.0', array( 'strategy' => 'defer', 'in_footer' => true, ) ); } add_action( 'wp_enqueue_scripts', 'wppoland_enqueue_deferred_assets' ); ``` ## Pillar and cluster internal linking in WordPress Internal page rank distribution dictates how search algorithms evaluate the relative importance of your commercial pages. Random, uncoordinated internal links dilute topic relevancy. The recommended structure is the **Pillar-and-Cluster (Hub-and-Spoke)** framework: ```text [ Commercial Pillar Page: Enterprise WordPress Development ] ▲ ▲ │ │ [ Cluster Post A ] [ Cluster Post B ] (Headless Architecture) (Custom REST APIs) ▲ ▲ │ │ [ Cluster Post C ] ◄───────────────────► [ Cluster Post D ] (Decoupled Security) (GraphQL vs REST) ``` ### How to link cluster posts to the pillar page 1. **Pillar Primacy**: Every cluster spoke must link directly back to the main pillar page within the first two paragraphs using descriptive anchor text (e.g. `[enterprise WordPress engineering services](/services/enterprise/)`). 2. **Horizontal Association**: Related spokes link horizontally to each other when contextually relevant, establishing a semantic web of supporting topical depth. 3. **Avoid Cannibalization**: Ensure each post in the cluster targets a distinct keyword intent. If two articles answer the same query, consolidate them into a comprehensive guide rather than competing against yourself in search indexes. ## WordPress robots.txt and XML sitemap setup Your `robots.txt` file and sitemap indexes act as air traffic control for web crawlers. ### Recommended robots.txt for WordPress Ensure administrative paths and internal query searches are disallowed, while asset files (CSS/JS) remain accessible so Googlebot can accurately render the page layout: ```text User-agent: * Disallow: /wp-admin/ Allow: /wp-admin/admin-ajax.php Disallow: /search/ Disallow: /*?*s= Disallow: /trackback/ Sitemap: https://wppoland.com/sitemap-index.xml ``` ### What belongs in a WordPress XML sitemap WordPress 5.5 introduced native XML sitemaps under `/wp-sitemap.xml`. While functional for basic blogs, enterprise deployments require granular control to exclude custom post types used purely for layout parts (such as footer blocks or testimonials) and remove noindexed pages. Ensure your sitemap index contains only canonical, indexable URLs with HTTP 200 status codes. Including 301 redirects or 404 dead ends in sitemaps wastes crawler resources and signals poor technical management. ## WordPress technical SEO checklist Before deploying architectural updates, audit your WordPress instance against this verification checklist: 1. **Information Architecture**: Disable date and attachment archives; enforce consistent trailing slash standards. 2. **Entity Modeling**: Implement clean JSON-LD `@graph` structures uniting Organization, Author, and Content nodes. 3. **Core Web Vitals**: Audit [real-user INP metrics](/en/interaction-to-next-paint-inp-optimization-guide-2026/) using Chrome UX Report (CrUX) and defer non-essential scripts. 4. **Internal Link Graph**: Organize content into structured pillar-cluster networks with contextual anchor text. 5. **Crawl Efficiency**: Restrict crawler access to search queries in `robots.txt` and keep XML sitemaps strictly canonical. When technical search fundamentals are integrated into the core architecture of your theme and hosting infrastructure, your content naturally commands [topical authority](/en/programmatic-seo-topical-authority-guide/) and sustainable search rankings. If you need assistance auditing or engineering a high-scale WordPress platform, discover our [specialized WordPress optimization and development services](/en/speed-up-wordpress/). For the delivery side of this topic we keep the work under [GEO and LLMO](/en/geo-llmo-optimization/). --- ## WordPress forms and global communication in 2026 URL: https://wppoland.com/en/ultimate-guide-wordpress-forms-2026/ Description: Stop losing leads. Learn how to build secure, high-conversion contact forms in WordPress. Comparison of CF7, Gravity Forms, and Headless Forms. GDPR compliance included. Published: Wed Jan 01 Updated: Tue Sep 22 Type: guide Level: advanced Tags: forms, contact, smtp, security **If your contact form doesn't work, your business doesn't exist.** It sounds dramatic, but in 2026, 70% of B2B comms happen via forms. Yet, most WordPress sites rely on default PHP `mail()` configurations that send leads straight to the Spam folder. Learn more about [WordPress security services](/en/wordpress-security-audit/) at WPPoland. In this 1500-word engineering manual, we will move beyond "Install Contact Form 7" and build a **Lead Generation Machine**. ## WordPress contact form emails not delivered, use SMTP The #1 reason forms fail is **Deliverability**. Hosting providers (Shared Hosting, VPS) have terrible IP reputations. If you send email from `wordpress@yoursite.com` via PHP, Gmail and Outlook trust it as much as a Nigerian Prince scam. ### Transactional email services for WordPress forms You must use an [external SMTP provider](/en/wordpress-not-sending-emails-smtp-guide/). 1. **Postmark / SendGrid / Amazon SES**: These are dedicated delivery engines. 2. **Plugin**: `FluentSMTP` (Free, Open Source). 3. **Setup**: Connect via API (faster than SMTP credentials). **Code Snippet**: Checking email failure logs. ```php add_action( 'wp_mail_failed', function( $error ) { error_log( 'Email Failure: ' . print_r( $error, true ) ); } ); ``` ## How to stop spam in WordPress contact forms In 2026, AI bots are smarter than reCAPTCHA v3. They can navigate forms, click checkboxes, and submit "SEO Service" spam. ### Honeypot, Turnstile and server-side validation 1. **Honeypot**: A hidden field that only bots fill out. 2. **Cloudflare Turnstile**: The "user-friendly" captcha. No puzzles. Privacy-first. 3. **Server-Side Validation**: Check if the IP is from a known blacklisted country or ASN. ## Contact Form 7 vs Gravity Forms vs headless forms ### Contact Form 7 pros and cons * **Pros**: Free, infinite extensions, developer-friendly (HTML/Shortcodes). * **Cons**: Loads assets on every page (performance hit), ugly UI by default. * **Verdict**: Use only if you are a developer who loves CSS. ### Gravity Forms pros and cons * **Pros**: Accessibility (WCAG) compliant, deep integrations (Stripe, HubSpot, Zapier). * **Cons**: Expensive annual license. * **Verdict**: The standard for serious business sites. ### Headless forms in Next.js and Astro If you run a [Headless WP](/en/headless-wordpress-architecture-2026-enterprise-guide/), standard plugins won't filter the form render. * **Solution**: Post to `contact-form-7` [REST API endpoint](/en/contactable-io-rest-api-on-cloudflare-workers-2026/). * **Endpoint**: `POST /wp-json/contact-form-7/v1/contact-forms/{id}/feedback` ## GDPR compliant WordPress contact forms You are collecting PII (Personally Identifiable Information). 1. **Checkbox**: Must be unchecked by default. "I agree to the Privacy Policy." 2. **Retention**: Do not store entries in the DB forever. Auto-delete after 90 days if synced to CRM. 3. **Logs**: Ensure your SMTP provider (SendGrid) signs a DPA (Data Processing Agreement). ## Multi-step forms to increase form conversion rate A form with 10 fields scares users away. **The "Breadcrumb" Technique (Multi-Step Forms)**: Step 1: "What is your goal?" (Low friction). Step 2: "What is your budget?" Step 3: "Name & Email" (High friction, but they are already committed). The **300%** figure everyone quotes traces to [one agency's post about its own site](https://ventureharbour.com/multi-step-lead-forms-get-300-conversions/). A controlled test puts the lift closer to **59%**, which is still worth having. ## Summary 1. **Never use PHP mail()**. Use SMTP. 2. **Protect with Turnstile**, not annoying puzzles. 3. **Validate on Server**, not just Client (JS). 4. **Connect to CRM**, don't just email. Your form is the handshake. Make it firm. --- ## WordPress database optimization in 2026: Cleaning up the bloat URL: https://wppoland.com/en/wordpress-database-optimization-guide-2026-en/ Description: Is your WordPress site sluggish? The culprit is likely your database. Learn how to optimize MariaDB 11, clean options, and manage postmeta for 2026 performance. Published: Sun Aug 24 Updated: Tue Sep 22 Type: guide Level: advanced Tags: database, sql, mariadb, optimization, backend Your WordPress database is the heart of your website. Over time, that heart gets clogged with digital sediment: obsolete revisions, expired transients, and bloated options. In 2026, single-click optimization plugins that run basic queries are no longer sufficient for high-traffic platforms. You need a disciplined engineering approach to database management that addresses the root causes of degraded throughput and high server response times. Database optimization remains one of the most overlooked performance disciplines in the WordPress ecosystem, yet it is often the direct differentiator between a site that delivers sub-200ms Time to First Byte (TTFB) and one that stalls for two seconds before executing PHP output. In this detailed guide, we cover every technical layer of WordPress database tuning for 2026, spanning storage engine architecture, safe pruning of overhead, index design, query analysis, and automated maintenance workflows. ## MariaDB 11 versus MySQL for WordPress In 2026, high-performance hosting environments have moved beyond default MySQL configurations. MariaDB 11 delivers measurable performance advantages for the complex join operations that WordPress core and advanced plugins require, particularly on stores with extensive product catalogs, thousands of user profiles, or multi-site installations. ### Why MariaDB 11 optimizes WordPress queries better The query optimizer in MariaDB 11 handles Entity-Attribute-Value (EAV) table structures with superior efficiency compared to older database releases. In WordPress, tables such as wp_postmeta, wp_usermeta, and wp_termmeta force the database engine to perform repeated JOIN operations against identical primary tables to retrieve distinct keys. MariaDB 11 features improved cost-based optimization models, better subquery flattening, and sophisticated hash joins that prevent queries from degenerating into slow temporary table disk writes. Queries involving wp_postmeta filters execute significantly faster because table statistics in memory provide the optimizer with accurate row estimates before query execution begins. ### Recommended MariaDB configuration for WordPress To obtain consistent latency across peak traffic periods, configure MariaDB 11 with the InnoDB storage engine and dynamic row format. This configuration guarantees efficient page compression and prevents index size inflation: ```ini [mysqld] default_storage_engine = InnoDB innodb_file_per_table = 1 innodb_default_row_format = dynamic innodb_buffer_pool_size = 8G innodb_buffer_pool_instances = 8 innodb_log_file_size = 2G innodb_flush_log_at_trx_commit = 2 innodb_flush_method = O_DIRECT ``` Setting innodb_flush_log_at_trx_commit to 2 maintains database ACID reliability during server runtime while flushing transaction logs to disk once per second rather than on every write operation, drastically lowering write latency during checkout surges. ### Real-world performance of MariaDB 11 compared to MySQL 8.0 In benchmark testing across WordPress installations containing 50,000 published posts and complex taxonomy relations, MariaDB 11 achieved 25% to 40% reductions in execution duration for multi-join queries when compared directly against standard MySQL 8.0 builds. The performance advantage becomes especially evident on WooCommerce stores where faceted product search queries filter multiple attribute sets simultaneously. ## How to reduce autoloaded data in wp_options Autoloaded options are the single most common hidden bottleneck in sluggish WordPress applications. The wp_options table is queried during the earliest bootstrapping phase of every uncached request, and excessive data volume here degrades server responsiveness immediately. ### Why excessive autoload degrades WordPress TTFB When WordPress boots via wp-settings.php, it executes wp_load_alloptions(), running a query that retrieves every row in wp_options where autoload equals yes or on. This entire payload is fetched in a single database read and loaded into PHP memory before theme templates or plugins initialize. Over years of active site operation, abandoned plugins, cached API tokens, visual builder cache structures, and transient fallbacks accumulate inside this table. If autoloaded data expands from a healthy 400 KB to several megabytes, PHP processes spend substantial time transferring bytes over sockets and deserializing strings, inflating TTFB across every non-cached URL. ### Autoload architectural improvements in WordPress 6.6 Starting in WordPress 6.6, core introduced significant architecture enhancements to manage options bloat proactively. Core established an explicit default size ceiling for options and split autoload handling into distinct channels. Large option values that exceed safe memory limits trigger administrative notices in Site Health and receive altered autoload behaviors to avoid saturating object cache memory. Additionally, WordPress 6.6 improved options cache group management, allowing developers to set autoload values explicitly to boolean values rather than relying on legacy string enumerations. ### SQL queries to audit autoloaded options To locate the heaviest individual option values stored in your database, execute: ```sql SELECT option_name, length(option_value) AS size_bytes FROM wp_options WHERE autoload IN ('yes', 'on', '1') ORDER BY size_bytes DESC LIMIT 15; ``` To calculate the aggregate autoload memory burden loaded into PHP on every execution: ```sql SELECT ROUND(SUM(LENGTH(option_value)) / 1024 / 1024, 2) AS total_autoload_mb FROM wp_options WHERE autoload IN ('yes', 'on', '1'); ``` Healthy production sites maintain total autoload volume below 800 KB. Enterprise installations with Redis object cache should aim for under 500 KB to ensure near-instantaneous option hydration from memory. ### How to disable autoload on legacy options When you identify obsolete configuration entries or data blobs left behind by deleted plugins, update their autoload flag to prevent automatic retrieval: ```sql UPDATE wp_options SET autoload = 'no' WHERE option_name = 'legacy_deactivated_plugin_blob'; ``` If the option belongs to a plugin that was uninstalled permanently, remove the row entirely: ```sql DELETE FROM wp_options WHERE option_name = 'legacy_deactivated_plugin_blob'; ``` ### Auditing autoload with WP-CLI and Query Monitor WP-CLI provides quick command-line utilities to inspect options without manual SQL scripting: ```bash wp option list --autoload=on --format=table --fields=option_name,size ``` For live local development and staging inspection, Query Monitor inspects every database interaction per request. It highlights the total size of options loaded in the environment and flags queries that exceed memory thresholds or duplicate data reads. ## How to clean post revisions, auto-drafts, and transients Database tables that handle dynamic editorial actions accumulate redundant records rapidly. Pruning these records safely restores query efficiency and shrinks backup archives. ### Restricting revisions in wp-config.php By default, WordPress stores every revision created when authors click save or preview. A single post edited dozens of times over several years creates dozens of clone rows in wp_posts and hundreds of associated records in wp_postmeta. Constrain revision retention by adding this definition to wp-config.php: ```php define( 'WP_POST_REVISIONS', 5 ); ``` To prevent aggressive autosaves from spamming the database while authors draft content, extend the autosave interval: ```php define( 'AUTOSAVE_INTERVAL', 160 ); ``` ### Deleting revisions and orphaned auto-drafts with WP-CLI Avoid using resource-intensive admin dashboard cleaning plugins that risk timing out over web requests. Use WP-CLI to prune historical revisions safely through the terminal: ```bash wp post delete $(wp post list --post_type=revision --format=ids) --force ``` Similarly, remove abandoned auto-draft records created by aborted post creations: ```bash wp post delete $(wp post list --post_status=auto-draft --format=ids) --force ``` The --force flag ensures records bypass the trash queue and are purged immediately from the database. ### Cleaning expired transients with SQL and WP-CLI Transients provide temporary caching in wp_options, but WordPress only purges an individual transient when an application attempts to read it after its expiration timestamp. Unread transients persist indefinitely, turning wp_options into an accidental storage dump. First, trigger the standard WP-CLI transient garbage collection: ```bash wp transient delete --expired ``` On large databases where millions of expired transients cause WP-CLI to exhaust PHP memory limits, execute direct SQL queries to clear expired timeout records: ```sql DELETE FROM wp_options WHERE option_name LIKE '_transient_timeout%' AND option_value < UNIX_TIMESTAMP(); ``` Follow up by clearing the corresponding data payload records whose timeout records were deleted: ```sql DELETE a FROM wp_options a LEFT JOIN wp_options b ON b.option_name = CONCAT('_transient_timeout_', SUBSTRING(a.option_name, 12)) WHERE a.option_name LIKE '_transient_%' AND a.option_name NOT LIKE '_transient_timeout_%' AND b.option_id IS NULL; ``` Repeat the identical logic for network-wide transients on multi-site networks by targeting the wp_sitemeta table and _site_transient_% keys. ### Automating database cleanup with system cron jobs Relying on traffic-driven WP-Cron creates unpredictability. Disable web cron in wp-config.php: ```php define( 'DISABLE_WP_CRON', true ); ``` Configure a system crontab task on your Linux server to run cleanup routines during early morning low-traffic hours: ```bash 0 3 * * 0 /usr/local/bin/wp transient delete --expired --path=/var/www/html --allow-root > /dev/null 2>&1 0 4 * * 0 /usr/local/bin/wp post delete $(/usr/local/bin/wp post list --post_type=revision --format=ids --path=/var/www/html --allow-root) --force --path=/var/www/html --allow-root > /dev/null 2>&1 ``` ## How to speed up a large wp_postmeta table The wp_postmeta table handles custom attributes, eCommerce product properties, and plugin states. On content-rich sites and eCommerce platforms with 50,000 products, wp_postmeta frequently exceeds 5 to 10 million rows, turning simple search filters into slow full-table scans. ### Adding composite indexes to wp_postmeta The default WordPress schema provides indexes on post_id and meta_key independently. When a query filters by both meta_key and meta_value simultaneously (a standard pattern in plugin filters), the database engine must inspect thousands of candidate rows before matching values. Adding a composite index covering meta_key and meta_value dramatically accelerates targeted lookups: ```sql ALTER TABLE wp_postmeta ADD INDEX meta_key_value (meta_key(191), meta_value(100)); ``` The column length prefixes (191 characters for meta_key and 100 for meta_value) ensure index creation adheres to InnoDB index byte limitations on utf8mb4 character sets while providing high index selectivity. ### Deleting orphaned metadata across tables When posts, terms, or comments are deleted directly or via faulty uninstallation scripts, corresponding metadata entries often remain orphaned. Prune these disconnected rows: ```sql DELETE pm FROM wp_postmeta pm LEFT JOIN wp_posts p ON pm.post_id = p.ID WHERE p.ID IS NULL; ``` Clean corresponding orphaned rows from user metadata and comment metadata: ```sql DELETE um FROM wp_usermeta um LEFT JOIN wp_users u ON um.user_id = u.ID WHERE u.ID IS NULL; DELETE cm FROM wp_commentmeta cm LEFT JOIN wp_comments c ON cm.comment_id = c.comment_ID WHERE c.comment_ID IS NULL; ``` ### Relational data strategies and High-Performance Order Storage …[truncated, fetch the canonical URL for the full body]… --- ## WordPress database optimization guide (2026 edition) URL: https://wppoland.com/en/wordpress-database-optimization-guide/ Description: Is your database bloated with revisions, spam, and transients? A comprehensive guide to cleaning MySQL for better performance and TTFB. Published: Sat Oct 11 Updated: Tue Sep 22 Type: guide Level: advanced Tags: mysql, wp-optimize, performance *Expanded and up-to-date version of this topic: [WordPress database optimization in 2026: Cleaning up the bloat](/en/wordpress-database-optimization-guide-2026-en/).* WordPress stores everything in a MySQL (or MariaDB) database. Over time, this database "bloats", accumulating unnecessary data, which can slow down queries and the entire site. A larger database means longer backup times, slower `SELECT` queries, and increased Time To First Byte (TTFB). In this comprehensive guide for developers, we will go through advanced database optimization, from simple cleaning to query analysis and InnoDB configuration. --- ## Why database optimization is critical in 2026 In 2026, when a [TTFB under 100ms](/en/services/core-web-vitals-audit/) is the standard, a "heavy" database is an anchor for your site. Even if you have a super-fast server (PHP 8.4, NVMe), poorly optimized SQL queries can kill performance. ### What makes a WordPress database slow 1. **Bloatware (Excess Data):** Post revisions, comment spam, orphaned metadata. 2. **Autoloaded Options:** Data loaded on _every_ page refresh, even if unused. 3. **Missing Indexes:** Queries that must scan the entire table (Full Table Scan). 4. **Table Fragmentation:** Gaps in data that increase file size on disk. --- ## How to clean the WordPress database Let's start by removing the trash. You can do this with a plugin (WP-Optimize), but as a developer, you should know how to do it "manually" using SQL or WP-CLI. ### How to delete post revisions Every time you click "Save Draft", a new copy of the post is created. With long editing sessions, you can have hundreds of revisions for a single article. **SQL Query to Check Revision Count:** ```sql SELECT COUNT(*) FROM wp_posts WHERE post_type = 'revision'; ``` **Deleting Revisions (SQL):** ```sql DELETE FROM wp_posts WHERE post_type = 'revision'; ``` **Recommended: Use WP-CLI (Safer):** ```bash wp post delete $(wp post list --post_type='revision' --format=ids) --force ``` ### How to delete spam and trashed comments There is no point in keeping spam or deleted posts. **SQL:** ```sql DELETE FROM wp_comments WHERE comment_approved = 'spam'; DELETE FROM wp_comments WHERE comment_approved = 'trash'; ``` ### How to delete expired transients Transients are cache saved in the database (`wp_options`). Sometimes expired transients are not automatically removed. **SQL Cleaning Expired Transients:** ```sql DELETE FROM wp_options WHERE option_name LIKE ('_transient_timeout%') OR option_name LIKE ('_transient_%'); ``` **WP-CLI (Best Method):** ```bash wp transient delete --all ``` --- ## How to reduce autoloaded options in wp_options The `wp_options` table contains an `autoload` column. If set to `yes`, that option is loaded on **every** page load. Plugins often leave trash here after uninstallation. ### How to check autoload size in MySQL Check how much data (in bytes) is being autoloaded: ```sql SELECT SUM(LENGTH(option_value)) as autoload_size FROM wp_options WHERE autoload = 'yes'; ``` If the result exceeds **800 KB - 1 MB**, you have a problem. ### How to find the largest autoloaded options ```sql SELECT option_name, LENGTH(option_value) as option_size FROM wp_options WHERE autoload = 'yes' ORDER BY option_size DESC LIMIT 10; ``` You will often find old data from [cache plugins](/en/advanced-wordpress-caching-strategies-2026-guide/), builders, or logs here. If the plugin is no longer used, you can safely delete these options or change `autoload` to `no`. --- ## How to convert MyISAM tables to InnoDB In 2026, you should no longer use the MyISAM engine. InnoDB is the standard, offering: - **Row-level locking:** MyISAM locks the entire table on write. - **ACID Transactions:** Data safety. - **Foreign Keys:** Relationship consistency. ### How to check which engine your tables use ```sql SELECT TABLE_NAME, ENGINE FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_database_name'; ``` ### How to change the table engine with ALTER TABLE If you find MyISAM tables, convert them: ```sql ALTER TABLE wp_posts ENGINE=InnoDB; ALTER TABLE wp_comments ENGINE=InnoDB; ALTER TABLE wp_options ENGINE=InnoDB; -- and so on for all tables ``` --- ## How to index MySQL tables for WordPress speed WordPress usually has good default indexes, but plugins often add their own tables without proper indexes. Missing an index on a `WHERE` or `JOIN` query means MySQL must scan every row in the table. ### Why WooCommerce order search is slow without an index If you have a [store with 100,000 orders](/en/woocommerce-performance-optimization-2026/), and a plugin searches orders by `meta_key` without an index, the "My Account" page might take 10 seconds to load. **Solution:** Add indexes to columns you frequently search or sort by. ```sql CREATE INDEX idx_meta_key_value ON wp_postmeta (meta_key(191), meta_value(50)); ``` _(Note: Indexing `meta_value` is tricky because it's TEXT. Avoid searching by meta_value if possible)._ --- ## How to stop database bloat in `wp-config.php` Instead of constantly cleaning, it's better not to litter. Configure WordPress wisely. ### How to limit revisions, trash and autosave Add to `wp-config.php`: ```php // Limit to 5 recent versions define( 'WP_POST_REVISIONS', 5 ); // Empty trash every 7 days (default is 30) define( 'EMPTY_TRASH_DAYS', 7 ); // Increase autosave interval (fewer AJAX requests in editor) define( 'AUTOSAVE_INTERVAL', 300 ); // seconds ``` ### How to disable the WordPress file editor For [security](/en/wordpress-security-hardening-complete-guide-2026/) and hygiene: ```php define( 'DISALLOW_FILE_EDIT', true ); ``` --- ## How to find slow queries with Query Monitor Don't guess what slows down the site. Install the **Query Monitor** plugin. After installation, in the admin bar, you will see page generation time and number of SQL queries. 1. Click on statistics in the bar. 2. Go to the **"Queries"** tab. 3. Sort by **"Time"**. If you see a query taking 0.5s or more, that's your optimization target. It often comes from a poorly written plugin ("Recently Viewed Products", "Visit Counter", etc.). --- ## WordPress database optimization checklist Learn more about [WordPress speed optimization](/en/speed-up-wordpress/) at WPPoland. 1. **Backup:** Always backup before working on the database. 2. **Engine:** Ensure all tables are InnoDB. 3. **Autoload:** Check `autoloaded options` size (aim for < 800KB). 4. **Cleaning:** Remove revisions, spam, and expired transients. 5. **Indexes:** Check if heavy queries use indexes. 6. **Prevention:** Configure `wp-config.php` to limit trash creation. When your database is lean and fast, PHP uses less memory, and users get content instantly. This is the foundation of modern WordPress. --- ## WordPress media management & image optimization guide URL: https://wppoland.com/en/wordpress-media-management-guide/ Description: Master WordPress media library management. Learn how to disable attachment pages, optimize images for Core Web Vitals, and implement lazy loading for better performance. Published: Thu Jul 27 Updated: Tue Sep 22 Type: guide Level: advanced Tags: media, images, optimization, performance *Expanded and up-to-date version of this topic: [Mastering WordPress media optimization: Speed & scalability](/en/mastering-wordpress-media-optimization/).* **Images are the #1 performance killer on WordPress sites.** In 2026, with [Core Web Vitals](/en/services/core-web-vitals-audit/) as a ranking factor, a slow site means lost revenue. Yet most WordPress sites still serve bloated JPEGs and create useless "attachment pages" for every uploaded image. Learn more about [WordPress speed optimization](/en/speed-up-wordpress/) at WPPoland. This 1500-word engineering guide covers the complete media optimization stack for modern WordPress. ## How to disable attachment pages in WordPress By default, WordPress creates a dedicated page for every image you upload. Example: `yoursite.com/image-name/` **Why this is bad:** 1. **SEO Confusion**: Google indexes these empty pages instead of your actual content 2. **Wasted Crawl Budget**: Googlebot wastes time on useless pages 3. **User Experience**: Users clicking images land on dead-end pages ### Redirect or 404 attachment pages with PHP **Method 1: Redirect to Parent Post** ```php add_action( 'template_redirect', function() { if ( is_attachment() ) { global $post; if ( $post && $post->post_parent ) { wp_redirect( get_permalink( $post->post_parent ), 301 ); exit; } } } ); ``` **Method 2: Return 404** ```php add_action( 'template_redirect', function() { if ( is_attachment() ) { global $development; $development->set_404(); status_header( 404 ); } } ); ``` ## AVIF vs WebP for WordPress images JPEG is from 1992. It's time to move on. ### How much smaller are WebP and AVIF than JPEG? - **JPEG**: 100KB baseline - **WebP**: 60KB (40% smaller, good browser support) - **AVIF**: 40KB (60% smaller, excellent quality) ### Enabling AVIF in WordPress WordPress 6.5+ supports [AVIF upload](/en/modern-image-optimization-wordpress-2026-avif-jpeg-xl-guide/) natively, but you need to enable it: ```php add_filter( 'wp_image_editors', function( $editors ) { array_unshift( $editors, 'WP_Image_Editor_Imagick' ); return $editors; } ); add_filter( 'image_editor_output_format', function( $formats ) { $formats['image/jpeg'] = 'image/avif'; $formats['image/png'] = 'image/avif'; return $formats; } ); ``` **Warning**: This converts ALL uploads. Test thoroughly. ## WordPress lazy loading without layout shift WordPress 5.5+ adds `loading="lazy"` automatically. But you can optimize further. ### Why native lazy loading causes layout shift It loads images when they're in the viewport + a margin. For hero images, this causes [Layout Shift](/en/fixing-image-dimension-errors-cls-guide/) (bad CLS score). ### How to exclude the first image from lazy loading ```php add_filter( 'wp_lazy_loading_enabled', function( $default, $tag_name, $context ) { if ( 'img' === $tag_name && 'the_content' === $context ) { // Don't lazy load the first image static $first_image = true; if ( $first_image ) { $first_image = false; return false; } } return $default; }, 10, 3 ); ``` ## How to use srcset and sizes in WordPress WordPress generates multiple image sizes automatically. Make sure you're using them: ```php // In your theme the_post_thumbnail( 'large', [ 'sizes' => '(max-width: 600px) 100vw, 50vw' ] ); ``` This tells the browser: - On mobile: use full width - On desktop: use 50% width The browser downloads the optimal size. ## Best image CDN for WordPress For high-traffic sites, offload image processing to a CDN. ### Cloudflare Images vs Cloudinary vs imgix 1. **Cloudflare Images**: $5/month for 100K images 2. **Cloudinary**: Free tier available 3. **imgix**: Real-time image manipulation via URL parameters ### How to serve WordPress images from Cloudinary ```php add_filter( 'wp_get_attachment_url', function( $url, $post_id ) { $cloudinary_base = 'https://res.cloudinary.com/yourcloud/image/upload/'; $path = wp_get_attachment_metadata( $post_id )['file']; return $cloudinary_base . 'f_auto,q_auto/' . $path; }, 10, 2 ); ``` ## How to remove unused media in WordPress Over time, your media library fills with unused images. ### Find orphaned media ```sql SELECT * FROM wp_posts WHERE post_type = 'attachment' AND ID NOT IN ( SELECT meta_value FROM wp_postmeta WHERE meta_key = '_thumbnail_id' ); ``` **Plugin Recommendation**: Media Cleaner by Jordy Meow ## How to compress images in WordPress Compression isn't just about file size, it's about finding the sweet spot between quality and performance. ### Best JPEG quality setting for WordPress **JPEG Quality Settings:** - **90-100**: Almost no compression, large files (not recommended) - **80-89**: High quality, moderate compression (good for photos) - **70-79**: Balanced quality/size (recommended for most images) - **60-69**: Noticeable quality loss, small files (use sparingly) - **Below 60**: Significant artifacts (avoid) **For WordPress, aim for 75-85 quality** depending on image type. ### How to compress images automatically on upload ```php /** * Automatically compress uploaded images */ add_filter('wp_handle_upload_prefilter', function($file) { if ($file['type'] === 'image/jpeg' || $file['type'] === 'image/png') { $image = wp_get_image_editor($file['file']); if (!is_wp_error($image)) { $image->set_quality(82); $image->save($file['file']); } } return $file; }); ``` ### Batch compression tools **Command Line (ImageMagick):** ```bash ## Compress all jpegs IN a directory find . -name "*.jpg" -exec magick {} -quality 82 {} \; ## Convert to AVIF magick input.jpg -quality 80 output.avif ``` **WordPress Plugins:** - **ShortPixel**, Automatic optimization, supports AVIF - **EWWW Image Optimizer**, Free, open-source - **Imagify**, Cloud-based, free tier available ## How to organize the WordPress media library A messy media library slows down your site and makes content management difficult. ### How to name image files **Bad:** - `IMG_1234.jpg` - `screenshot-2026-01-15.png` - `photo(1).jpg` **Good:** - `hero-homepage-2026.avif` - `product-laptop-dell-xps-15.jpg` - `team-member-john-smith-headshot.jpg` ### How to rename uploaded files automatically ```php /** * Rename uploaded files based on post title */ add_filter('wp_handle_upload_prefilter', function($file) { $pathinfo = pathinfo($file['name']); $extension = $pathinfo['extension']; // Get post title if uploading to a post if (isset($_POST['post_id']) && $_POST['post_id']) { $post_title = get_the_title($_POST['post_id']); $sanitized = sanitize_file_name($post_title); $file['name'] = $sanitized . '-' . time() . '.' . $extension; } return $file; }); ``` ### Folder structure best practices WordPress stores all media in `/wp-content/uploads/YYYY/MM/` by default. For large sites, consider: 1. **Custom uploads structure**, organize by content type 2. **CDN offloading**, move media to cloud storage 3. **[Database cleanup](/en/wordpress-database-optimization-guide/)**, remove orphaned attachments ## How to measure image performance in WordPress You can't optimize what you don't measure. ### Which image metrics to track 1. **Total Media Library Size** ```sql SELECT ROUND(SUM(meta_value) / 1024 / 1024, 2) AS total_mb FROM wp_postmeta WHERE meta_key = '_wp_attached_file'; ``` 2. **Average Image Size** ```sql SELECT AVG(meta_value) AS avg_size FROM wp_postmeta WHERE meta_key = '_wp_attachment_metadata'; ``` 3. **Unused Media Count** - Use Media Cleaner plugin - Or custom query to find orphaned files ### Tools to measure image performance **Google PageSpeed Insights:** - Measures Core Web Vitals - Shows image optimization opportunities - Provides specific recommendations **GTmetrix:** - Detailed waterfall charts - Shows image load times - Identifies optimization opportunities **WordPress Plugins:** - **Query Monitor**, Database query analysis - **Debug Bar**, Performance profiling - **New Relic**, Advanced APM (paid) ## WebP fallback and art direction in WordPress ### WEBP fallback for older browsers ```php /** * Serve WebP with JPEG fallback */ function serve_webp_with_fallback($html, $post_id) { $webp_url = wp_get_attachment_image_url($post_id, 'full', false, ['format' => 'webp']); $jpeg_url = wp_get_attachment_image_url($post_id, 'full'); if ($webp_url) { $html = '<picture> <source srcset="' . esc_url($webp_url) . '" type="image/webp"> <img src="' . esc_url($jpeg_url) . '" alt="' . esc_attr(get_post_meta($post_id, '_wp_attachment_image_alt', true)) . '"> </picture>'; } return $html; } add_filter('wp_get_attachment_image', 'serve_webp_with_fallback', 10, 2); ``` ### Responsive images with art direction Sometimes you need different crops for different screen sizes: ```php // Add custom image sizes add_image_size('hero-mobile', 800, 600, true); add_image_size('hero-tablet', 1200, 800, true); add_image_size('hero-desktop', 1920, 1080, true); // Use in template $sizes = [ '(max-width: 600px) 800px', '(max-width: 1024px) 1200px', '1920px' ]; the_post_thumbnail('hero-desktop', [ 'sizes' => implode(', ', $sizes), 'srcset' => [ wp_get_attachment_image_url($id, 'hero-mobile') . ' 800w', wp_get_attachment_image_url($id, 'hero-tablet') . ' 1200w', wp_get_attachment_image_url($id, 'hero-desktop') . ' 1920w', ] ]); ``` ### Lazy loading with intersection observer For more control than native lazy loading: ```javascript // Advanced lazy loading const imageObserver = new IntersectionObserver((entries, observer) => { entries.forEach(entry => { if (entry.isIntersecting) { const img = entry.target; img.src = img.dataset.src; img.classList.remove('lazy'); observer.unobserve(img); } }); }); document.querySelectorAll('img.lazy').forEach(img => { imageObserver.observe(img); }); ``` ## Common WordPress image mistakes to avoid ### Uploading full-resolution images **Problem:** Uploading 4000x3000px images when you only need 1200x900px. **Solution:** Resize before upload or use WordPress image sizes: ```php // Set maximum upload dimensions @ini_set('upload_max_size', '10M'); @ini_set('post_max_size', '10M'); ``` ### Missing featured images for social sharing **Problem:** Using `the_content()` images instead of featured images for social sharing. **Solution:** Always set featured images and use Open Graph: ```php // In header.php or via plugin $og_image = get_the_post_thumbnail_url(get_the_ID(), 'large'); echo '<meta property="og:image" content="' . esc_url($og_image) . '">'; ``` ### Missing or generic alt text **Problem:** Missing or generic alt text hurts SEO and accessibility. **Solution:** Always add descriptive alt text: ```php // Auto-generate alt text from filename add_filter('wp_generate_attachment_metadata', function($metadata, $attachment_id) { if (empty(get_post_meta($attachment_id, '_wp_attachment_image_alt', true))) { $filename = basename(get_attached_file($attachment_id)); $alt = str_replace(['-', '_'], ' ', pathinfo($filename, PATHINFO_FILENAME)); update_post_meta($attachment_id, '_wp_attachment_image_alt', ucwords($alt)); } return $metadata; }, 10, 2); ``` ## Bulk convert old JPEGs and delete orphaned media ### How to migrate existing JPEGs to modern formats If you have an existing site with thousands of JPEGs: 1. **Audit current media**, identify largest files 2. **Batch convert**, use ImageMagick or cloud service 3. **Update references**, ensure all URLs point to new format 4. **Test thoroughly**, verify all images display correctly …[truncated, fetch the canonical URL for the full body]… --- ## How to clean the WordPress head section (RSS, emojis, generator) URL: https://wppoland.com/en/clean-wordpress-header-rss-emojis/ Description: WordPress injects unnecessary code into the head area: wlwmanifest, RSD, emoji polyfills, and feed links. Learn how to remove legacy tags and speed up your site. Published: Tue Jun 07 Updated: Tue Sep 22 Type: guide Level: advanced Tags: clean-head, performance, rss *Expanded and up-to-date version of this topic: [How to clean up WordPress header (remove RSS, emojis, shortlinks)](/en/how-to-clean-up-wordpress-header-remove-rss-emojis-shortlinks/).* <div id="introduction"></div> Open the source code of your website in your browser (`Ctrl+U` on Windows/Linux or `Cmd+Option+U` on macOS). Inspect the `<head>` element closely. In many WordPress installations, you will encounter dozens of lines of obscure markup. In 2026, most of these default elements represent obsolete baggage: legacy publishing manifests, individual comment feed declarations, emoji polyfills, and version tags inherited from era-defining software like Windows Live Writer. Cleaning the document head is not an aesthetic exercise. Each redundant `<link>` element and unnecessary inline script inflates HTML byte weight, adds parsing overhead, and occasionally triggers avoidable external DNS handshakes. On high-traffic WooCommerce stores running numerous extensions, head clutter accumulates rapidly. A streamlined `wp_head()` output simplifies troubleshooting and minimizes version disclosure. Primary technical documentation references: [`wp_head()`](https://developer.wordpress.org/reference/functions/wp_head/), [WordPress Developer Handbook](https://developer.wordpress.org/), and [web.dev LCP optimization guidance](https://web.dev/articles/optimize-lcp). ## What WordPress outputs in the head section A standard WordPress installation with a modern block theme typically prints several automated tags into the frontend head: - RSS feeds for posts, categories, tags, and comments - The `wlwmanifest` file link for Windows Live Writer - Really Simple Discovery links (`rsd_link`) - The `meta name="generator"` tag detailing the exact core version - Emoji detection scripts and inline CSS styles - Shortlink reference tags (`?p=123`) - Adjacent post navigation links (`rel="prev"` and `rel="next"`) - REST API and oEmbed discovery links | Head element | Utility in 2026 | Removal risk | | --- | --- | --- | | Comment feeds | Negligible | Very low | | Primary `/feed/` endpoint | Moderate (readers, newsletters) | Moderate | | wlwmanifest and RSD | Obsolete legacy | Very low | | Core generator tag | None (information leak) | Very low | | Emoji detection scripts | Handled natively by modern browsers | Very low | | REST API discovery | High for headless / decoupled apps | High if external consumers require discovery | | Shortlinks | Negligible | Very low | This matrix provides an architectural roadmap: remove obsolete protocols and information leaks, while preserving endpoints that your business applications actively consume. ## Why cleaning the WordPress head section matters ### Performance gains from head cleanup Prior to optimization, document headers frequently contain 10 to 20 superfluous tags and an external emoji script request routed to s.w.org. Eliminating these tags reduces total HTML size, accelerates DOM construction, and avoids unnecessary network requests. While desktop fiber users may notice small differences, the optimization delivers perceptible speed improvements on mobile cellular connections. ### Security and version leakage prevention The tag `meta name="generator" content="WordPress x.y.z"` reveals the exact version of your underlying engine. While obfuscation alone is not security, removing version signatures deprives automated vulnerability bots of easy profiling signals. Similar version strings appended to style and script URLs (`style.css?ver=6.x`) should be handled alongside generator tag removal. ### Maintainability and clean staging diffs A concise document head makes inspecting source changes significantly easier during staging deployments. When a newly installed extension injects third-party prefetch hints or tracking scripts, the addition stands out immediately in staging diff reviews. ## 1. Removing comment feeds and extra feed links WordPress automatically constructs distinct RSS channels for every single post, category, and comment thread. Unless you operate a publication where readers subscribe to individual comment threads via desktop RSS aggregators, these links represent unneeded markup: ```php // Disable comment feed links add_filter( 'feed_links_show_comments_feed', '__return_false' ); // Remove extra taxonomy and archive feeds remove_action( 'wp_head', 'feed_links_extra', 3 ); // Only if your organization never uses RSS feeds: // remove_action( 'wp_head', 'feed_links', 2 ); ``` Retain the primary `feed_links` hook if marketing newsletter tools or podcast syndication services depend on your central blog feed. ## 2. Removing wlwmanifest and RSD discovery tags Windows Live Writer ceased active relevance years ago, yet WordPress still outputs manifest links. Similarly, Really Simple Discovery (RSD) supported remote editing workflows over XML-RPC that modern REST-based workflows do not require: ```php remove_action( 'wp_head', 'wlwmanifest_link' ); remove_action( 'wp_head', 'rsd_link' ); ``` Executing these removals eliminates: - `<link rel="wlwmanifest" type="application/wlwmanifest+xml" ...>` - `<link rel="EditURI" type="application/rsd+xml" ...>` ## 3. Disabling WordPress emoji scripts and styles WordPress introduced a JavaScript library and inline CSS styles to convert text emoticons into raster images. All modern desktop and mobile operating systems render Unicode emojis natively. The default loader represents an unnecessary HTTP request and external DNS handshake to s.w.org: ```php remove_action( 'wp_head', 'print_emoji_detection_script', 7 ); remove_action( 'wp_print_styles', 'print_emoji_styles' ); remove_action( 'admin_print_scripts', 'print_emoji_detection_script' ); remove_action( 'admin_print_styles', 'print_emoji_styles' ); remove_filter( 'the_content_feed', 'wp_staticize_emoji' ); remove_filter( 'comment_text_rss', 'wp_staticize_emoji' ); remove_filter( 'wp_mail', 'wp_staticize_emoji_for_email' ); ``` For frontend optimization, removing the hooks attached to `wp_head` and `wp_print_styles` delivers the primary speed benefit. ## 4. Hiding the WordPress generator version tag Hiding the core version from public markup is standard operational hardening: ```php remove_action( 'wp_head', 'wp_generator' ); add_filter( 'the_generator', '__return_empty_string' ); ``` The filter also empties generator tags inside syndicated feeds. While this does not replace regular security patching, it prevents automated reconnaissance crawlers from profiling your infrastructure. ## 5. Removing shortlinks and adjacent post links Shortlink declarations (`?p=123`) and adjacent article relationship tags offer little benefit to modern search crawlers while adding unnecessary weight: ```php remove_action( 'wp_head', 'wp_shortlink_wp_head', 10, 0 ); remove_action( 'template_redirect', 'wp_shortlink_header', 11 ); remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 ); remove_action( 'wp_head', 'start_post_rel_link', 10, 0 ); remove_action( 'wp_head', 'index_rel_link' ); remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 ); ``` ## 6. Managing REST API and oEmbed discovery links ```php // Only remove if external tools do not require automated REST discovery: // remove_action( 'wp_head', 'rest_output_link_wp_head', 10 ); // remove_action( 'wp_head', 'wp_oembed_add_discovery_links' ); // remove_action( 'template_redirect', 'rest_output_link_header', 11 ); ``` Decoupled headless builds built on Astro or Next.js, as well as mobile applications, often rely on REST autodiscovery headers. On traditional marketing sites with no third-party integrations, removing these tags is entirely safe. ## Creating a clean head must-use plugin Rather than placing these instructions inside a theme's `functions.php` where they risk being overwritten during updates, create a Must-Use plugin at `wp-content/mu-plugins/wppoland-clean-head.php`: ```php <?php /** * Plugin Name: WPPoland Clean Head * Description: Eliminates obsolete legacy tags and scripts from wp_head. * Author: wppoland.com */ function wppoland_cleanup_head(): void { remove_action( 'wp_head', 'rsd_link' ); remove_action( 'wp_head', 'wlwmanifest_link' ); remove_action( 'wp_head', 'wp_generator' ); remove_action( 'wp_head', 'wp_shortlink_wp_head', 10, 0 ); remove_action( 'wp_head', 'adjacent_posts_rel_link_wp_head', 10, 0 ); remove_action( 'wp_head', 'start_post_rel_link', 10, 0 ); remove_action( 'wp_head', 'index_rel_link' ); remove_action( 'wp_head', 'parent_post_rel_link', 10, 0 ); remove_action( 'wp_head', 'feed_links_extra', 3 ); remove_action( 'wp_head', 'print_emoji_detection_script', 7 ); remove_action( 'wp_print_styles', 'print_emoji_styles' ); add_filter( 'feed_links_show_comments_feed', '__return_false' ); add_filter( 'the_generator', '__return_empty_string' ); } add_action( 'init', 'wppoland_cleanup_head' ); ``` Must-Use plugins execute automatically on every request without appearing in the standard plugin deactivation dashboard, guaranteeing architectural permanence. ## How to test head cleanup in your browser 1. Launch an incognito session and inspect the HTML: verify that generator tags, wlwmanifest links, and inline emoji scripts are absent. 2. Open the Network panel in developer tools and confirm that `wp-emoji-release.min.js` is no longer requested. 3. Validate that your primary `/feed/` endpoint returns valid XML if syndication is required. 4. Verify that drafting and publishing posts in Gutenberg functions normally without REST communication errors. 5. Walk through the checkout funnel on WooCommerce stores to ensure no interactive states were affected. ## Which head tags you should never remove Head optimization targets legacy clutter, not functional requirements. Always preserve: - Viewport declarations and character set metadata - Canonical URL declarations and `hreflang` international tags - Consent management and analytics loader tags - Structured JSON-LD schema definitions - Preload and preconnect directives for critical fonts and hero media ## Pre-launch checklist for head cleanup * [ ] Test changes on staging with all production plugins active. * [ ] Verify the source code across homepage, single post, and checkout templates. * [ ] Confirm primary RSS feeds operate in external reader software. * [ ] Test Gutenberg block saving and REST responses. * [ ] Clear edge caches (Cloudflare) and server-level page caches (Varnish / FastCGI). ## Frequently asked questions about head optimization For specialized architectural reviews, script auditing, and [performance tuning](/en/speed-up-wordpress/), consult our experienced [WordPress developer](/en/wordpress-developer/) team or explore our high-performance [WooCommerce developer](/en/woocommerce-developer/) services. Reach out directly via our [contact page](/en/contact/) to discuss your technical requirements. --- ## How to speed up a WordPress-Based website? URL: https://wppoland.com/en/how-to-speed-up-a-wordpress-based-website/ Description: Technical guide to speeding up WordPress sites: hosting, caching, PHP-FPM, Redis, CDN, database optimization, and Core Web Vitals improvement. Published: Mon Jun 23 Updated: Tue Sep 22 Type: guide Level: advanced Tags: speed, optimization, core-web-vitals *Expanded and up-to-date version of this topic: [WordPress optimization: how to speed up your site (WPO)](/en/wordpress-optimization-speed-guide/).* ## How to speed up a **WordPress-based** website? 1. **Choose the Right Hosting**: Highlights the importance of selecting hosting that ensures speed and reliability for WordPress sites. 2. **Use an Effective Caching Plugin**: Discusses how caching plugins can significantly improve [website speed](/en/speed-up-wordpress/). 3. **Optimize Images**: Points out the need to optimize images to reduce loading times. 4. **Regularly Update WordPress**: Emphasizes the importance of updating WordPress, themes, and plugins for security and performance. 5. **Optimize Background Processes**: Focuses on optimizing background tasks like backups and cron jobs. 6. **Use a CDN (Content Delivery Network)**: Explains how CDNs distribute website content globally, speeding up user access. 7. **Optimize the Database**: Discusses cleaning and optimizing the WordPress database. 8. **Limit or Disable Post Revisions**: Recommends limiting or disabling post revisions in WordPress. 9. **Split Comments into Pages**: Suggests paginating comments to avoid long loading times. 10. **Use a Lightweight WordPress Theme/Framework**: Stresses the choice of a speed-optimized theme. 11. **Reduce External HTTP Requests**: Advises minimizing the number of external resource requests. 12. **Reduce Database Calls**: Encourages efficient coding to minimize database queries. **Technical Methods for Optimizing Performance of WordPress-Based Websites** Speeding up a WordPress site requires deep intervention in its technical architecture, from the server layer to the frontend. Below, I present comprehensive, advanced optimization strategies, avoiding specific plugin names in favor of purely technical solutions. * * * ### How to optimize server infrastructure for WordPress * **Choosing a Hosting Environment**: Use VPS or dedicated servers with PHP-FPM (FastCGI Process Manager) and HTTP/2/3 support. Avoid shared hosting with limited CPU/RAM resources. * Configure **Nginx** instead of Apache, lean on its asynchronous worker model plus reverse-proxy caching when you offload TLS at the edge. * Enable **OPcache** (PHP opcode caching) with aggressive settings (`opcache.revalidate_freq=0`, `opcache.validate_timestamps=0` in staging environments). * **PHP Version**: Use PHP 8.x+ with JIT (Just-In-Time Compilation), offering up to 30% performance improvement over PHP 7.4. * * * ### Page, object and browser caching in WordPress * **Full-Page Caching at Server Level**: Implement full-page HTML caching in RAM using **Varnish Cache** or Nginx FastCGI Cache. Configure exclusion rules for dynamic elements (e.g., WooCommerce cart) via `Cache-Control` headers or cookies. * **Object Caching**: Use **Redis** or **Memcached** to cache database query results and PHP objects. Integrate with WordPress via definitions in `wp-config.php` (e.g., `WP_REDIS_HOST`). * **Browser Caching**: Set long expiration periods for static resources (CSS, JS, images) via `Expires` and `Cache-Control` headers in server configuration. Use **hashed filenames** (e.g., `style.a1b2c3.css`) to force re-download on changes. * * * ### How to minify and compress CSS, JS and images * **File Compression and Consolidation**: * Minify CSS/JS using CLI tools (e.g., **Terser**, **CSSNano**). * Combine critical resources into a single file, loading the rest asynchronously. * Enable **Brotli** (or GZIP) for compressing textual resources on the server. * **Image Optimization**: * Convert images to **WebP/AVIF** format using `picture` and `srcset` for responsiveness. * Apply **lazy loading** with the native `loading="lazy"` attribute for images and iframes. * Use **SVG** for vector graphics, optimizing them by removing metadata. * **CDN with Smart Routing**: Deploy a distributed content delivery network with **Edge Computing** capabilities to perform logic (e.g., image transformations) at the edge infrastructure. * * * ### How to optimize the WordPress database * **Cleaning and Indexing**: * Regularly remove post revisions, comment spam, and transients (`wp_options`). * Add indexes to columns frequently used in `WHERE` and `JOIN` clauses. * Replace the default MySQL **InnoDB** engine with **MyRocks** (for write operations) or **TokuDB** (for compression). * **Database Separation**: Split WordPress tables into separate database instances for `wp_posts`, `wp_postmeta`, and other high-traffic tables, using master-slave replication. * * * ### How to optimize WordPress code and queries * **Query Optimization**: * Replace `WP_Query` with direct SQL queries using `$wpdb` for complex operations. * Limit the use of `post__not_in` and `meta_query`, which generate expensive subqueries. * **Disable Unnecessary Features**: * Deactivate emojis, external embeds, and REST API endpoints via filters in `functions.php`. * Disable WordPress cron system and replace it with a real server cron job. * * * ### Critical CSS, preload and HTTP/2 in WordPress * **Inline Critical CSS/JS**: Implement a mechanism to extract critical CSS/JS (above the fold) and embed it directly in , loading the rest asynchronously. * **HTTP/2 Server Push**: Use Server Push to proactively send critical resources (fonts, main CSS) before the browser requests them. * **Preconnect and Preload**: Add for external domains (e.g., CDN) and for high-priority fonts/images. * * * ### Edge Side Includes and service workers * **Edge Side Includes (ESI)**: Apply fragment caching for dynamic sections (e.g., user header) using ESI with Varnish. * **Service Workers**: Implement a **Cache First** strategy for static resources, enabling offline content access. * * * ### How to monitor WordPress performance with RUM and Lighthouse CI * **Real User Monitoring (RUM)**: Collect end-user performance metrics using **Google Analytics Core Web Vitals** or custom scripts tracking LCP, FID, CLS. * **Synthetic Tests**: Automate performance tests with **Lighthouse CI** in the deployment process, blocking code merges that degrade results. * * * ## Why is site speed a priority for WordPress? In the online world, time is money. That's why we act as quickly as possible to minimize downtime for your website. Monitoring runs around the clock and alerts us the moment something breaks, and we work on a transparent pricing structure with a per-project scope rather than a templated tier. Speeding up WordPress is a process requiring multi-layered optimization, from server configuration and caching architecture to precise control over code and resources. The key is minimizing blocking I/O operations, reducing transferred data size, and maximizing the use of edge computing technologies. Regular audits with advanced analytical tools ensure performance remains competitive, even for dynamically growing projects. ## How can you contact WPPoland? Don’t wait until problems start affecting your business. Professional technical support is an investment that quickly pays off, providing peace of mind and stability for your website. <a href="/en/contact/" class="inline-flex items-center justify-center px-8 py-4 text-lg font-bold text-white transition-all duration-200 bg-emerald-600 rounded-xl hover:bg-emerald-700 hover:shadow-lg hover:-translate-y-1">Contact us</a> and start using our services today. Take care of your website, and we’ll help you do it! For the delivery side of this topic we keep the work under [Core Web Vitals audit](/en/services/core-web-vitals-audit/). --- ## The AI Act and labelling AI-generated content URL: https://wppoland.com/en/ai-act-labelling-ai-generated-content/ Description: Article 50 of the AI Act has applied since 2 August 2026 and imposes transparency duties on companies that use AI. What you actually have to label, when editorial review lifts the obligation, and how to put two layers of labelling into practice for media, marketing and agencies. Published: Tue Jun 02 Updated: Tue Oct 20 Type: guide Level: intermediate Tags: ai, law, compliance <p id="introduction">Article 50 of the AI Act has applied since 2 August 2026 and imposes transparency duties on companies for content created with the involvement of artificial intelligence. In short: a chatbot has to admit it is AI, generated graphics, audio and video must be machine-marked, and deepfakes and some text require a human-readable disclosure. This applies to every company publishing such content on the EU market, not only to model providers. This guide explains when the obligation actually arises, when editorial review lifts it, and how to set up a process now that the date has passed.</p> The legal basis is [Regulation (EU) 2024/1689](https://eur-lex.europa.eu/eli/reg/2024/1689/oj), commonly known as the AI Act. It entered into force on 1 August 2024, but its individual parts apply in stages. The transparency obligations under Article 50, meaning everything discussed here, have applied since 2 August 2026. This is not some distant abstraction for corporate legal departments. If you run media, an agency, a shop with a chatbot, or you simply drop generator graphics onto a website, this article concerns your everyday work. It is worth defusing two extremes that circulate around the market straight away. The first: "the AI Act will ban AI content." It does not. Article 50 prohibits nothing; it only requires you to be transparent. The second: "it is enough to add made with AI in the footer." Also untrue, because in many cases a visible note alone, without the technical layer, does not meet the requirement. The truth lies in between and is more workable than the panic suggests, but more demanding than a shrug suggests. ## Did the Digital Omnibus delay AI Act Article 50 The timeline shifted in mid-2026 and the headlines oversold it, so it is worth being precise. The EU adopted the Digital Omnibus on AI, a package that simplifies parts of the AI Act, with the Parliament voting on 16 June 2026 and the Council giving its final approval on 29 June 2026, and it is being published in the Official Journal. It defers several high-risk obligations (the stand-alone Annex III high-risk duties slip to 2 December 2027), but it leaves the Article 50 transparency duties discussed in this guide largely intact. The date that mattered for content labelling was **2 August 2026**, and it has passed. Chatbot disclosure under Article 50(1), and the deepfake and public-interest text disclosure under Article 50(4), have been in force since that day with no change. The one piece of relief is narrow and specific to the machine-marking of AI-generated content under Article 50(2): systems already placed on the market before 2 August 2026 got a three-month grace period and must carry the machine-readable marking by 2 December 2026. Systems placed on the market from 2 August 2026 onward get no grace period. The practical reading: any AI content tooling you stand up today is in scope from day one; if you are retrofitting an existing pipeline, the machine-readable layer still has until December, but the human-facing disclosures are already due. Anyone selling you a "the deadline moved to 2027" story is describing a different part of the regulation. ## AI Act Article 50 obligations for providers and deployers Article 50 splits the world into two roles, and that distinction decides what you have to do. A provider is whoever creates or makes an AI system available. A deployer is whoever uses the system and publishes the output. A single company is often in both roles at once, for example when it has built its own generator and publishes its outputs itself. The four paragraphs of Article 50 distribute the obligations like this: | Paragraph | Who it concerns | Obligation | |---|---|---| | Art. 50(1) | Provider | An AI system that talks to people (a chatbot) must inform them that they are dealing with AI, unless this is obvious from the context. | | Art. 50(2) | Provider | A system generating synthetic audio, image, video or text must mark the output in a machine-readable format, detectable as artificially generated or manipulated; the solution must be effective, interoperable, robust and reliable as far as is technically feasible. | | Art. 50(3) | Deployer | Anyone deploying an emotion recognition or biometric categorisation system must inform the people exposed to it. | | Art. 50(4) | Deployer | Anyone who generates or manipulates a deepfake (image, audio, video) must disclose that the content is artificially generated or manipulated; anyone who generates or manipulates text published to inform the public on matters of public interest must also disclose this, unless the content has undergone human review or editorial control and someone holds editorial responsibility. | The most common mistake in companies is thinking that because they did not build the model, it does not concern them. It does. Paragraph 4 speaks directly about the deployer, that is, about you, when you take a graphic from a generator and put it on a client's site. The machine-marking duty under paragraph 2 sits with the model provider, but the duty to disclose a deepfake and informational text sits with whoever publishes. ## When AI-generated content must be labelled This is the crux, because the law does not treat all content the same. The dividing line runs between visual and audio media and text, and between free-form text and text under editorial control. For image, audio and video the rule is firm. If the content is artificially generated or manipulated in a way that creates an impression of authenticity (a deepfake), the deployer must disclose it. There is no convenient editorial exemption here like the one known from text. The only softening concerns clearly artistic or satirical works, where the disclosure should be made in a way that does not spoil the experience of the work. For text there is an important exemption. Text published to inform the public on matters of public interest requires disclosure, but not when it has undergone human review or editorial control and a natural or legal person holds editorial responsibility for it. This is the loophole for newsrooms and for anyone who has a real content-approval process, rather than publishing raw model output straight to the site. The Commission's [Article 50 questions and answers](https://digital-strategy.ec.europa.eu/en/faqs/transparency-obligations-under-article-50-ai-act) add detail: superficial, solely formal checks such as spell-checking or grammatical correction are not human review or editorial control, and editorial responsibility means that a person holds the ultimate legal responsibility over the publication. | Content type | Situation | Label for humans? | |---|---|---| | AI graphic | Realistic photo of a person, place, event (deepfake) | Yes, disclosure required | | AI graphic | Clearly illustrative, abstract, not posing as reality | Usually not as a deepfake, but good practice to label | | AI video or audio | Synthetic voice-over, avatar, cloned voice | Yes, disclosure required | | AI text | Article informing the public, no editorial review | Yes, disclosure required | | AI text | The same article after review and with editorial responsibility | No, the editorial exemption applies | | AI text | Product description, internal note, non-informational content | Outside the scope of the disclosure duty | | Chatbot | An assistant talking to a customer | Yes, must inform that it is AI | | Minor AI edit | Proofreading, style improvement that does not change the meaning | Generally out of scope | The boundary of the "minor edit" is in practice the most important one for agencies and marketers. If AI fixes punctuation or trims a paragraph without changing the meaning and context, that is an assistive edit that usually does not trigger the obligation. If AI creates the whole narrative, fabricates a statement or generates a photorealistic image of an event that did not happen, you are on the other side of the line. ## Machine-readable marking vs visible AI disclosure The most important thing to remember: compliance is not a single gesture but two layers. You can have one without the other and still be non-compliant. The first layer, the machine layer, follows from paragraph 2. The AI output has to carry a signal that a machine will detect: that the content is artificially generated or manipulated. In practice this is done today in three ways, often combined. [C2PA Content Credentials](https://c2pa.org/) is an open provenance standard that attaches a cryptographically signed manifest with the history of origin to the file. A watermark, visible or invisible, woven into the pixels or the audio samples. Metadata, that is fields written into the file itself. The regulation requires the solution to be effective, interoperable, robust and reliable as far as is technically feasible, so easily removable metadata alone is a weak choice. The second layer, the human layer, follows from paragraph 4. It is a clear piece of information that a person will see and understand: a note under a graphic, a label next to an article, a chatbot's greeting line. Here we return to the myth from the introduction. A small visible note "made with AI" may not be enough on its own, because it does not replace the machine layer from paragraph 2. And the other way round, a technical watermark invisible to the reader does not satisfy the disclosure duty from paragraph 4 where that duty applies. You need both, matched to the content type. A technical trap that catches practitioners off guard: the publishing pipeline can destroy the machine layer. [Image optimisation](/en/modern-image-optimization-wordpress-2026-avif-jpeg-xl-guide/), conversion to AVIF, running a file through a CDN or the [media library in a CMS](/en/wordpress-media-management-guide/) often strips metadata and C2PA manifests. If you upload a labelled file and a system along the way strips the metadata, the labelling disappears and you are back to square one without knowing it. ## How to label AI content on social media and websites The three most common contexts in which this lands on a marketer's or agency's desk are social media, the website and marketing materials. The process is similar for each, but the details differ. On social media, platforms increasingly have their own AI disclosure mechanisms, and some of them read C2PA and add a label automatically. That does not release you from responsibility, but it makes the human layer easier. The practical move: mark the file with C2PA at the source, before it reaches the platform, and switch on the available "AI-generated content" toggles when you publish. Do not rely solely on the platform detecting it, because compression on upload can be aggressive. On your own website you have full control and full responsibility. This is where an agency genuinely helps a client: designing a label component next to graphics and video, adding a disclaimer to the chatbot, and making sure in the CMS that the image pipeline does not strip provenance data or that the label is appended independently of the metadata. For a blog with an editorial process, documenting that process is crucial, because it is what triggers the exemption under paragraph 4. In marketing materials (ads, presentations, sales content), approach it by risk. A photorealistic likeness of a person, a synthetic voice in a spot, a presenter avatar are high-risk cases requiring disclosure. An abstract background graphic or an icon is a low-risk case. Build a simple checklist for the team to run through before publishing, rather than deciding each case from scratch. …[truncated, fetch the canonical URL for the full body]… --- ## Does Cloudflare block Googlebot? The new AI bot settings and WordPress URL: https://wppoland.com/en/does-cloudflare-block-googlebot-ai-bot-settings/ Description: Since 15 September 2026 Cloudflare splits its AI bot settings into Search, Training and Agent. Google is not blocked by default, but the "Block" option stops Googlebot along with search. What changed and how to check it. Published: Thu Oct 08 Updated: Tue Oct 20 Type: guide Level: intermediate Tags: cloudflare, googlebot, ai-bots, robots-txt, search-console No, Cloudflare does not block Googlebot by default. Since 15 September 2026, though, one option in the AI bot settings does something many people do not expect: "Block" stops Googlebot at the door, search included, not just AI training. If your WordPress site sits behind Cloudflare and someone "turned off AI" in the last few weeks, check it today. On 7 October 2026 the daily recap on Search Engine Roundtable quoted a post from X: "Cloudflare switched to blocking Google by default on 9/15" ([Search Engine Roundtable, 7 October 2026](https://www.seroundtable.com/recap-10-07-2026-42249.html)). The X post itself could not be opened without logging in, so everything below relies only on Cloudflare's own sources. I checked every quote on 8 October 2026. ## What did Cloudflare change on 15 September 2026 Until now there was a single "Block AI bots" toggle. Now there are three categories, each with its own setting. Cloudflare defines them like this: - **Search:** "crawling to build a search index." - **Training:** "crawling to train or fine-tune a model." - **Agent:** "user-directed agents visiting a page on behalf of a human, such as chat fetch bots and browser-use agents." Source of the definitions: [Cloudflare Blog, 15 September 2026](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/). There are four options to choose from: Allow, Disallow AI Training, Block on pages with ads and Block. Disallow AI Training exists only in the Training category. Cloudflare says the new settings are available "to all customers, on all plans", so the free plan is included. ## Why does the Block option stop Googlebot Because Googlebot is a mixed-use crawler. That is Cloudflare's term for a bot that handles both search and training under one user agent: > "A mixed-use crawler is a single crawler doing both Search and Training." > > [Cloudflare Blog, 15 September 2026](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/) Cloudflare names three such crawlers: Applebot, Bingbot and Googlebot. Since there is no way to stop only "the part of Googlebot that trains", a block hits the whole bot. Cloudflare says so directly: > "It will stop Applebot, Bingbot, and Googlebot from reaching your site [...] search included." > > [Cloudflare Blog, 15 September 2026](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/) The same applies to Block on pages with ads, only in a narrower scope: according to Cloudflare, crawlers, mixed-use ones included, are then blocked on pages where an ad was detected. For a WordPress blog running AdSense, that can mean Google stops seeing exactly the posts that earn money. The search-safe option is Disallow AI Training. It only publishes a preference in robots.txt, and Cloudflare notes that Googlebot "can keep crawling your site for search". Opting out of Google's model training is handled by a separate token, Google-Extended, which I covered in the post on [Google's three AI controls](/en/google-ai-controls-compared/). ## What happened to the old Block AI bots toggle Cloudflare is deprecating it and moving existing zones to the new settings. The migration table from the blog post looks like this: | Old "Block AI" | Search | Training | Agent | |---|---|---|---| | Off | Allow | Allow | Allow | | Block | Allow | Disallow AI Training | Block on pages with ads | | Block on pages with ads | Allow | Disallow AI Training | Block on pages with ads | According to this table, nobody who had the old toggle got a Googlebot block automatically. Search always moves to Allow, and Training to Disallow AI Training, which is the robots.txt-based option. New domains, added from 15 September, get one of two sets during onboarding. A site without ads: everything on Allow. A site with ads: Search Allow, Training Disallow AI Training, Agent Block on pages with ads. Both sets have Preference Sync turned on, which according to Cloudflare "publishes the applicable no-training preference in robots.txt" and replaces the previous Managed Robots.txt. ## Does blocking AI training in Cloudflare also block Googlebot The documentation page on blocking AI bots contains a sentence that does not match the table: > "Mixed-purpose crawlers that combine Search and Training will also be blocked by all configurations to block AI training" > > [Cloudflare Docs, Block AI bots](https://developers.cloudflare.com/bots/additional-configurations/block-ai-bots/) Read literally, every configuration that blocks training, the old toggle included, also blocks Googlebot. The migration table says the opposite. Which version describes what Cloudflare's servers actually do with your traffic is settled only by your own zone and your own logs, not by either of these two texts. The documentation also states that the old toggle is "Deprecating on September 15, 2026", and that for new domains "Search will remain allowed". Neither the post nor the documentation mentions Cloudflare Pages. ## Why Cloudflare can block GPTBot without touching search, but not Googlebot The same post explains why Google, Apple and Microsoft get different treatment from other AI companies. Cloudflare introduced an "Accountable" designation for crawler operators. To get it, an operator has to meet, or commit to meeting, four requirements: a way to opt out of AI training (through robots.txt or a similar standard), a way to opt out of AI summaries, URL-level visibility into which pages were made available for training, and an assurance that opting out of training will not affect traditional search results ([Cloudflare Blog, 15 September 2026](https://blog.cloudflare.com/accountable-mixed-use-ai-crawlers/)). Cloudflare lists Applebot, Googlebot and Bingbot as Accountable mixed-use crawlers. The training crawlers of Amazon, Anthropic, Meta and OpenAI are classified differently: those companies run separate crawlers for search and for training, so Cloudflare can block the training bot and leave the search bot alone. That is the whole reason Disallow AI Training behaves the way it does. Training-only crawlers get blocked, while Accountable mixed-use crawlers stay allowed for search and receive the no-training preference through robots.txt. The preference only works if the operator reads it. Google honours a Disallow for the Google-Extended token and Apple honours one for Applebot-Extended. Microsoft is different: according to the same post, Bing is still building support for a domain-level no-training preference in robots.txt, targeted for early 2027, and until then Disallow AI Training does not automatically pass that preference to Bing. In the meantime Cloudflare points to the NOARCHIVE meta tag and Bing's Block URLs tool. ## How to check if Googlebot can crawl your WordPress site Three steps, about three minutes, if you have access to Search Console and your Cloudflare account. 1. **URL Inspection in Search Console.** Paste your home page URL and click Test live URL. You are looking for a successful page fetch and a last crawl date after 15 September. Repeat for one post with ads, if you show them, because that is where the Block on pages with ads option applies. 2. **Crawl stats.** In Search Console, go to Settings > Crawl stats and open the breakdown by response. A sudden rise in 403 responses from mid-September is a sign that something at the edge is stopping Googlebot. 3. **Zone settings in Cloudflare.** Cloudflare writes that the new controls "can be configured at the domain (zone) Security Settings". Check what is set for Search, Training and Agent. If you see Block in Training or Search and you want to stay in Google, change it to Disallow AI Training or Allow. While you are at it, look at robots.txt. If Preference Sync is active, Cloudflare adds its preference there. On WordPress, robots.txt is often generated by an SEO plugin as well, so check the served file at `/robots.txt`, not the plugin settings. Our own [Content-Signal line](/en/content-signal-robots-txt-one-group/) shows how easily robots.txt drifts from what we assume. ## Does Google-Extended in robots.txt remove a site from Google Search No. Google's documentation of its common crawlers says Google-Extended has no separate HTTP user agent string. Crawling is done by the existing Google user agents, and the token works only as a control in robots.txt. Google states that it does not affect a site's inclusion in Google Search and is not used as a ranking signal. What it controls is whether crawled content may be used to train future Gemini models and for grounding in Gemini Apps and Vertex AI ([Google Search Central, Google's common crawlers](https://developers.google.com/search/docs/crawling-indexing/google-common-crawlers)). The same page explains one detail that matters for testing. The Test live URL button in Search Console and the Rich Results Test fetch the page as Google-InspectionTool, a crawler used by Google's search testing tools that has no effect on Google Search. A successful live test therefore tells you the zone lets a Google crawler through right now. The Crawl stats report is what shows how Googlebot itself has been treated over the past weeks, which is why the check above uses both. ## What happens to indexed pages when Googlebot gets a 403 A Cloudflare block answers Googlebot with an error page instead of your content, and the check above looks for 403 responses for that reason. Google describes how its crawlers react. All 4xx status codes except 429 are treated the same way, they have no effect on crawl rate, and for Google Search the indexing pipeline removes a URL from the index if it was previously indexed ([Google Search Central, HTTP status codes and network errors](https://developers.google.com/search/docs/crawling-indexing/http-network-errors)). So a block does not just pause new crawling. Pages that already rank can drop out of the index while the block lasts. The same page warns against using 401 and 403 to limit crawl rate. If the real goal is to reduce load on a WordPress server, the codes Google treats as a slowdown signal are 429 and 5xx: they make Google's crawlers temporarily crawl more slowly instead of removing URLs. ## How to verify that a request in your logs really is Googlebot Anyone can send a request with "Googlebot" in the user agent, so a log line alone proves nothing. Google's method is a two-way DNS check: run a reverse DNS lookup on the IP address from your logs with the `host` command, confirm the hostname ends in `googlebot.com`, `google.com` or `googleusercontent.com`, then run a forward lookup on that hostname and check that it returns the same IP. Google also publishes its crawler IP ranges as JSON files, split into common crawlers, special-case crawlers, user-triggered fetchers and user-triggered agents ([Google Search Central, Verifying Googlebot](https://developers.google.com/search/docs/crawling-indexing/verifying-googlebot)). The hostname also tells you which kind of crawler you are looking at. Googlebot and other common crawlers resolve to `crawl-***-***-***-***.googlebot.com` (or a `geo.googlebot.com` variant) and always respect robots.txt for automatic crawls. User-triggered fetchers resolve under `gae.googleusercontent.com` or `google-proxy-***.google.com` and ignore robots.txt, because a person asked for the fetch. …[truncated, fetch the canonical URL for the full body]… --- ## WordPress contact forms in 2026: deliverability, spam and CRM URL: https://wppoland.com/en/wordpress-contact-forms-ultimate-guide-2026/ Description: Master WordPress contact forms in 2026. Complete comparison of form builders, SMTP configuration, anti-spam strategies, GDPR compliance, CRM integrations, and conversion optimization techniques. Published: Wed Jan 01 Updated: Tue Oct 20 Type: guide Level: advanced Tags: forms, contact, smtp, security, gdpr, conversion **If your contact form doesn't work, your business doesn't exist.** Learn more about [WordPress security services](/en/wordpress-security-audit/) at WPPoland. It sounds dramatic, but for many service businesses the form is the only inbound sales channel. Whether you're capturing leads, processing support requests, or collecting customer feedback, contact forms remain the backbone of digital business communication. Yet, most WordPress sites rely on default PHP `mail()` configurations that send leads straight to the Spam folder - costing businesses thousands in lost opportunities every month. Web forms have changed. AI-powered bots have become sophisticated enough to bypass traditional CAPTCHA systems. Privacy regulations like GDPR and CCPA have transformed how we collect and store user data. Meanwhile, user expectations have shifted toward forms that feel simple and explain each step clearly that guide them through complex submissions without adding unnecessary steps. The useful work starts beyond "Install Contact Form 7". Form delivery depends on choosing the right builder, configuring SMTP properly, reducing spam without blocking real users, respecting consent rules and measuring where submissions fail. For a small business site, an enterprise platform or a headless WordPress build, the goal is the same: make the form reliable enough that every valid enquiry reaches the right workflow. ## How to set up SMTP for WordPress contact forms The #1 reason forms fail is **Deliverability**. Not design, not copy - delivery. Hosting providers (Shared Hosting, VPS, Cloud) have terrible IP reputations because they're shared among thousands of websites, many of which send spam. If you send email from `wordpress@yoursite.com` via PHP's native `mail()` function, Gmail and Outlook trust it as much as a Nigerian Prince scam. ### Why PHP mail() Fails in 2026 PHP's `mail()` function sends emails without authentication, proper headers, or reputation management. Modern email providers use sophisticated filtering that checks: - **SPF (Sender Policy Framework)**: Validates that the sending server is authorized - **DKIM (DomainKeys Identified Mail)**: Cryptographically verifies message integrity - **DMARC (Domain-based Message Authentication)**: Enforces authentication policies - **IP Reputation**: Historical sending behavior from the IP address - **Content Analysis**: Spam keywords, link quality, and formatting Without proper [SMTP configuration](/en/wordpress-not-sending-emails-smtp-guide/), your form submissions end up in spam folders - or blocked entirely. ### Which SMTP provider to use for WordPress You must use an external SMTP provider with established reputations and authentication protocols. Here are the top providers for WordPress in 2026: #### Gmail / Google Workspace SMTP **Best for**: Small businesses already using Google Workspace **Setup**: 1. Enable 2-Factor Authentication on your Google account 2. Generate an App Password at [myaccount.google.com/apppasswords](https://myaccount.google.com/apppasswords) 3. Configure in FluentSMTP: - **Host**: `smtp.gmail.com` - **Port**: `587` (TLS) or `465` (SSL) - **Authentication**: Yes - **Username**: Your full email address - **Password**: Your 16-character App Password **Limitations**: Google lists a daily sending limit of 2,000 messages per Workspace user and 500 for trial accounts ([Gmail sending limits in Google Workspace](https://knowledge.workspace.google.com/admin/gmail/gmail-sending-limits-in-google-workspace)) #### SendGrid **Best for**: High-volume senders, marketing integrations **Setup**: 1. Create account at [sendgrid.com](https://sendgrid.com) 2. Generate API Key with "Mail Send" permissions 3. Configure in FluentSMTP using API (recommended) or SMTP: - **API Method**: Enter your API key directly - **SMTP Method**: - **Host**: `smtp.sendgrid.net` - **Port**: `587` - **Username**: `apikey` - **Password**: Your SendGrid API Key **Benefits**: deliverability analytics, Event Webhook for tracking bounces and opens #### Mailgun **Best for**: Developers, API-first applications **Setup**: 1. Sign up at [mailgun.com](https://mailgun.com) and verify your domain 2. Add DNS records (MX, TXT for SPF/DKIM) as provided 3. Configure in FluentSMTP: - **Host**: `smtp.mailgun.org` - **Port**: `587` - **Username**: `postmaster@yourdomain.com` - **Password**: Your Mailgun SMTP password **Benefits**: a free plan capped at 100 emails per day ([Mailgun pricing](https://www.mailgun.com/pricing/), October 2026), API, detailed logs #### Postmark **Best for**: Transactional emails, highest deliverability rates **Setup**: 1. Create account at [postmarkapp.com](https://postmarkapp.com) 2. Verify sender signature (domain or email) 3. Generate Server API Token 4. Configure in FluentSMTP using API: - Select "Postmark" as provider - Enter your Server API Token **Benefits**: 100 emails/month on the free developer plan, 45 days of full content history by default, bounce handling ([Postmark pricing](https://postmarkapp.com/pricing)) #### Amazon SES (Simple Email Service) **Best for**: Enterprise, cost-conscious high-volume senders **Setup**: 1. Create AWS account and access SES console 2. Verify your domain and request production access (removes sandbox limits) 3. Create SMTP credentials in the SES console, under SMTP settings 4. Configure in FluentSMTP: - **Host**: `email-smtp.us-east-1.amazonaws.com` (region-specific) - **Port**: `587` (TLS) or `2587` (TLS) - **Username**: Your SES SMTP Username - **Password**: Your SES SMTP Password **Benefits**: $0.10 per 1,000 outbound emails on a la carte pricing ([Amazon SES pricing](https://aws.amazon.com/ses/pricing/)), scales to millions, integrates with the AWS ecosystem ### How to set up FluentSMTP **FluentSMTP** is the gold standard for WordPress SMTP configuration in 2026: - **Free and Open Source**: No paid tier (700,000+ active installs on wordpress.org, October 2026) - **Multiple Provider Support**: Configure multiple SMTP connections with failover - **API Integration**: Connect via API keys (faster, more secure than SMTP credentials) - **Email Logging**: Built-in dashboard to track sent/failed emails - **Routing Rules**: Send different forms through different providers **Installation**: ```bash wp plugin install fluent-smtp --activate ``` ### How to debug WordPress email failures When forms submit but emails don't arrive, use this diagnostic code: ```php // Log all email failures for debugging add_action( 'wp_mail_failed', function( $error ) { error_log( 'Email Failure: ' . print_r( $error, true ) ); } ); // Log successful sends (for verification) add_action( 'wp_mail_succeeded', function( $mail_data ) { error_log( 'Email Sent: ' . implode( ', ', (array) $mail_data['to'] ) ); } ); ``` Check your error logs via: ```bash tail -f /var/log/apache2/error.log tail -f /var/log/nginx/error.log # Or use WP-CLI wp shell >>> error_log( 'Test email logging' ); ``` ## Best WordPress form plugins compared Choosing the right form builder impacts everything from user experience to development flexibility. Here's the definitive comparison: ### 1. Contact Form 7 **Price**: Free **Pros**: - Completely free with no premium version, 10+ million active installs on [wordpress.org](https://wordpress.org/plugins/contact-form-7/) (October 2026) - Native Akismet, reCAPTCHA and Cloudflare Turnstile integrations - Infinite extensibility through hooks and filters - Developer-friendly (pure HTML/shortcodes) - Massive ecosystem of add-ons - Lightweight when configured properly **Cons**: - Loads assets on every page by default (performance hit) - No visual form builder - requires HTML knowledge - No built-in entry storage (the companion Flamingo plugin stores submissions) - No conditional logic without add-ons - Default styling is barebones **Best For**: Developers who want complete control, simple contact forms **Performance Optimization**: ```php // Only load CF7 assets on pages with forms add_filter( 'wpcf7_load_js', '__return_false' ); add_filter( 'wpcf7_load_css', '__return_false' ); // Then manually enqueue on specific pages function my_cf7_scripts() { if ( is_page( 'contact' ) ) { wpcf7_enqueue_scripts(); wpcf7_enqueue_styles(); } } add_action( 'wp_enqueue_scripts', 'my_cf7_scripts' ); ``` ### 2. Gravity Forms **Price**: $59/year (Basic, 1 site), $159/year (Pro, 3 sites), $259/year (Elite, unlimited sites), per the [Gravity Forms pricing page](https://www.gravityforms.com/pricing/) in October 2026 **Pros**: - Tools to build forms that meet WCAG 2.1 AA, introduced in version 2.5 - Native add-ons (Stripe, HubSpot, Zapier; Salesforce on Elite only) - Advanced conditional logic - Multi-step forms with progress indicators - Built-in entry management and export - File uploads - Signature add-on **Cons**: - Expensive annual license - Can be resource-heavy on shared hosting - Learning curve for advanced features **Best For**: Enterprise sites, complex forms, accessibility requirements ### 3. WPForms **Price**: Free (WPForms Lite, 5+ million active installs on wordpress.org, October 2026) plus paid licences **Pros**: - Drag-and-drop builder with live preview - 2,100+ pre-built form templates, according to the [wordpress.org listing](https://wordpress.org/plugins/wpforms-lite/) - Conversational forms (Typeform-style) - Built-in spam protection (honeypot + CAPTCHA) - Entry management in WordPress dashboard - Form abandonment addon (save partial entries) - User registration and login forms **Cons**: - Multi-page forms, file uploads and conditional logic are Pro features - Add-ons require higher-tier licenses - Less developer-friendly than Gravity Forms **Best For**: Beginners, small businesses, quick deployment ### 4. Fluent Forms **Price**: Free (800,000+ active installs on wordpress.org, October 2026) plus Pro licences **Pros**: - Under 30 KB of combined CSS and JS for a standard form, per its [wordpress.org listing](https://wordpress.org/plugins/fluentform/) - Built-in conversational forms - Conditional logic, GDPR Agreement field and Turnstile field in the free version - 60+ third-party integrations in Pro - PDF generation - Quiz scoring - Excellent performance **Cons**: - Smaller ecosystem than Gravity Forms - Multi-step forms, file uploads and auto-delete of entries require Pro **Best For**: Performance-conscious sites, modern WordPress stacks ### 5. Formidable Forms **Price**: Free (300,000+ active installs on wordpress.org, October 2026) plus paid plans **Pros**: - Built-in database views and front-end display - Application builder capabilities - Calculated fields and complex math - Visual Views (display entries as directories, listings) - WooCommerce product configurator - API webhooks **Cons**: - Steeper learning curve - Interface feels dated compared to competitors **Best For**: Data-heavy applications, directories, calculators ### WordPress form plugins comparison table | Feature | CF7 | Gravity Forms | WPForms | Fluent Forms | Formidable | |---------|-----|---------------|---------|--------------|------------| | **Price** | Free | $59-259/yr | Free + paid | Free + paid | Free + paid | | **Free version on wordpress.org** | Yes | No | Yes (Lite) | Yes | Yes | | **Multi-step forms** | Third-party add-on | Yes | Pro | Pro | Pro | | **Conditional logic** | Third-party add-on | Yes | Pro | Free | Pro | Feature split as listed on each plugin's wordpress.org page and the Gravity Forms pricing page, October 2026. ## How to stop contact form spam without CAPTCHA In 2026, AI bots are smarter than reCAPTCHA v3. They can navigate forms, click checkboxes, solve image puzzles, and submit convincing "SEO Service" spam. Traditional CAPTCHA creates friction for legitimate users while failing to stop sophisticated attacks. …[truncated, fetch the canonical URL for the full body]… --- ## AI content creation ethics for publishing in 2026: a WordPress guide URL: https://wppoland.com/en/ethics-ai-content-wordpress-guide-2026/ Description: AI content creation in publishing has an ethics line. Disclosure, human oversight, source attribution and SEO safety practices for WordPress publishers in 2026, with EU AI Act, Google E-E-A-T and platform policies covered. Published: Mon Sep 08 Updated: Tue Oct 20 Type: guide Level: intermediate Tags: ai-ethics, transparency, content-strategy, publishing, eeat <span id="introduction"></span> In 2026, the question is not *whether* you use AI, but *how*. For WordPress publishers, the ethical line between efficient automation and lazy spam is what determines long-term brand survival. Generative models have democratised content production, but that democratisation arrives with duties that many site owners have not yet mapped out: disclosure, accuracy, originality, and a clear chain of human accountability. This guide is a practical manifesto for publishing AI-assisted content responsibly on WordPress. It covers what the EU AI Act now requires, what Google actually rewards, where copyright and plagiarism risk sits, and it ends with an editorial policy and a pre-publish checklist you can adopt this week. ## Why AI content ethics matters for publishers in 2026 The intersection of AI and publishing ethics has become the defining challenge for WordPress site owners in 2026. With every major LLM capable of producing polished text in seconds, the question has shifted from "can AI write my content?" to "should it, and under what rules?" Three forces are driving this conversation: - **Search engines penalise pure automation.** Google's March 2024 core update introduced the scaled content abuse policy, which replaced the older wording about spammy automatically generated content. Google is explicit that using automation, including AI, to produce content whose primary purpose is to manipulate rankings is a spam violation. Sites that publish unedited AI output at scale can lose a large share of organic traffic once a core or spam update lands. - **Readers detect and distrust [AI slop](/en/ai-slop-content-cleanup-wordpress/).** Audiences recognise generic phrasing, the empty introductions, the "in today's fast-paced world" openers. Trust, measured through engagement and return-visit rates, drops when content feels machine-made and interchangeable with ten thousand other pages. - **Legal liability is real.** Publishing AI-generated medical, legal, or financial advice without human fact-checking creates exposure that no disclaimer fully mitigates. In the 2023 Mata v. Avianca case, a New York court sanctioned lawyers who filed a brief citing court decisions that ChatGPT had invented. The same failure mode reaches any publisher who ships a hallucinated fact as if it were verified. The framework below gives actionable standards for WordPress publishers who use AI as a tool without letting it become the voice. ## 1. How to disclose AI-generated content Hiding your use of AI is no longer a viable strategy, and in Europe it is increasingly a legal question rather than a stylistic one. The [EU AI Act](/en/ai-act-labelling-ai-generated-content/) (Regulation 2024/1689) sets transparency duties in Article 50: providers must mark synthetic output in a machine-readable format, and deployers who publish AI-generated or AI-manipulated text to inform the public on matters of public interest must disclose that it is artificially generated, unless a human has reviewed it and a named person or organisation holds editorial responsibility. Those Article 50 transparency obligations apply from August 2026, which means the label is not a "nice to have" you can defer. ### How to word an AI disclosure statement Use a clear, visible statement on your WordPress posts rather than a line buried in a tiny footer. Something like: *"Produced with AI assistance. Final review and fact-checking by [named human author]."* The named human is the point. A disclosure that keeps a real, accountable editor in the loop is exactly the case the AI Act treats as acceptable, and it is the version readers trust. ### How to mark AI content in Article schema and C2PA Attach AI-disclosure metadata to your Article schema and separate the roles: the AI tool as an instrument, the human as `author` and `editor`. The C2PA standard (Coalition for Content Provenance and Authenticity) and its Content Credentials give you a cryptographically signed provenance manifest for images and, increasingly, text. WordPress plugins and media pipelines are beginning to write and read these manifests, so build the habit now while it is cheap to adopt. ### Does AI disclosure build reader trust Transparency builds the trustworthiness leg of your E-E-A-T profile. Readers who know a human expert verified the piece stay longer, share more, and convert better than readers who suspect they are talking to a ghost. Honesty about AI use has become a competitive advantage, not a confession. ## 2. How to add information gain to AI-assisted content The biggest ethical and SEO failure of AI is the echo-chamber effect. If you point an LLM at three competitor articles and publish the blended summary, you add nothing to the web. This is the root of knowledge homogenisation: thousands of pages converging on the same middle because they were produced from the same models and the same prompts. ### What counts as human-added value Every AI-assisted post on your WordPress site must carry human-added value that the model could not have had in its training set: an original opinion, first-party data from sites you actually operate, screenshots from real projects, an interview quote, or analysis grounded in direct experience. Google's helpful-content guidance calls this the difference between content made for people and content made to game search. ### How to test if an AI draft adds anything new Before you publish, ask the blunt question: "If I deleted everything the AI could have generated on its own, is anything valuable left?" If the answer is no, the draft is not finished. A WooCommerce performance guide passes this test when the author adds real before-and-after load times from a store they optimised; it fails when it merely restates what every plugin's marketing page already says. ## 3. Who is responsible for AI-generated content Who is responsible when an AI-generated post gives bad advice? The answer must be a person, not a process. ### Who should sign an AI-assisted post In 2026, every post needs a designated responsible author, a real human with a byline, bio, and demonstrable expertise who is legally and ethically accountable for the facts. It does not matter how much of the draft an LLM produced; the human owns the published result. This is E-E-A-T stated as a workflow rather than a slogan. ### How to add a human review status in WordPress Add a mandatory human review step before any AI draft can move to "Published" in your WordPress editorial workflow. The reviewer checks facts, adjusts tone to the brand voice, screens for bias, and confirms the piece earns its place. A simple post-status gate (Draft, In review, Verified, Published) enforces this without extra tooling. ### How to log prompts, tools and reviewers Keep a record of how each piece was made: the prompts used, the tools involved, the verification steps taken, and the reviewer's name. This log is useful for internal audit and, in a dispute over YMYL content, it is the evidence of due diligence that a disclaimer alone cannot provide. ## 4. How to fact-check AI hallucinations Large language models generate fluent, confident text whether or not the underlying claim is true. Fluency is not accuracy. Leading models in 2026 still fabricate citations, statistics, quotes, and legal references, and they do it in prose that reads as authoritative. The duty of care is straightforward: treat every AI-produced fact as unverified until a human checks it against a primary source. Verify each number, each quotation, each named study, and each statutory reference. For health, finance, and legal topics, the standard is higher still, because a hallucinated dosage or a wrong compliance claim causes real harm. A practical rule for WordPress teams: no AI-drafted statistic ships without a linked, dated source in the same paragraph, and no legal or medical claim ships without review by someone qualified to make it. The failure is easy to picture on a real site. An AI-drafted tutorial confidently references a WordPress hook that never existed, or cites a plugin setting under an old name, and a reader follows it into a broken configuration. A finance blog publishes an AI-generated tax figure that was accurate two years ago and is now wrong. Neither error looks wrong on the page, because the model wrote both in the same fluent, self-assured register it uses for facts it did get right. That is precisely why human verification cannot be optional: the surface signal of confidence carries no information about truth. ## 5. Can you copyright AI-generated content AI raises two distinct rights questions, and publishers should not conflate them. First, **can you own AI output?** The US Copyright Office has held that works generated purely by AI, without meaningful human authorship, are not eligible for copyright, a position it set out in the 2023 *Zarya of the Dawn* decision and expanded in its 2025 report on copyright and artificial intelligence. Practically, the more a human shapes, edits, and arranges the work, the stronger your claim to protection. Fully automated output leaves your best assets legally exposed. Second, **does the output infringe someone else?** Models can reproduce training data closely enough to create plagiarism or infringement risk, especially with distinctive phrasing or code. Run AI-assisted drafts through a plagiarism check, rewrite anything that mirrors a source too closely, and attribute quotations properly. Originality is both an ethical duty to other creators and a defensive measure for your own brand. ## 6. How to check AI content for bias AI models can reproduce social biases present in their training data: gender, racial, cultural, age, and socioeconomic. For a publisher this is a reputational and ethical risk that has to be managed actively, not assumed away. Audit prompts and outputs for skew, request diverse perspectives explicitly, and avoid the lazy stereotypes that surface from older datasets. Individual-article review catches some of this, but systematic patterns only become visible across the whole corpus, so run a periodic audit of published content rather than trusting a single pass. ## 7. Does Google penalize AI content It is worth being precise, because the myth that "Google bans AI content" costs publishers good decisions. Google's stated position is that it rewards high-quality, helpful content however it is produced, and that appropriate use of AI is not against its guidelines. What it targets is the abuse: content generated primarily to manipulate rankings, at scale, without adding value. The scaled content abuse policy from the March 2024 update exists to catch that pattern, not the technology itself. The takeaway for WordPress publishers is liberating and demanding at once. You are free to use AI, and you are judged on the same axis as always: does the page demonstrate experience, expertise, and trust, and does a real person stand behind it? ## How Google's 2026 spam updates affect AI content Two things changed this autumn, and one of them is only a prediction. The fact: on 1 October Google rewrote its [guidance on using generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content). As quoted by [Lily Ray](https://lilyraynyc.substack.com/p/prediction-the-next-massive-google), it now reads: > "It is critical to manually factcheck and review all AI-generated content for accuracy and trustworthiness before publishing." > > Google Search Central, [guidance on using generative AI content](https://developers.google.com/search/docs/fundamentals/using-gen-ai-content) The same review covers titles, meta descriptions, structured data and image alt text. For a WordPress site that means the SEO plugin fields and bulk alt text jobs are in scope, not only the article body. …[truncated, fetch the canonical URL for the full body]… --- ## Why simple WordPress changes take weeks URL: https://wppoland.com/en/why-wordpress-changes-take-weeks/ Description: Five signals that slow changes on a WordPress site or WooCommerce store come from the code, not the people, and how to measure each one on your own install in a single afternoon. Published: Tue Oct 20 Updated: Tue Oct 20 Type: guide Level: intermediate Tags: technical-debt, wordpress-maintenance, code-audit, woocommerce <p id="introduction">Changing a button on the homepage gets a two-week estimate. The plugin update waits until Monday because nobody wants to take the risk on a Friday. A week in, the new developer still has no working copy of the site on their machine. The business owner sees the invoices growing and draws the easiest conclusion: the people are too slow.</p> Ally Piechowski, who audits engineering teams, described in [Why Your Engineering Team Is Slow (It's the Codebase, Not the People)](https://piechowski.io/post/codebase-drag-audit/) five signals that the code, not the team, is holding the pace back. She wrote about applications, but each signal has a counterpart on a WordPress site and in a WooCommerce store. Below you will find each one, together with a way to measure it on your own install. ## Why is a simple WordPress change estimated so high The author calls the first signal the apology estimate. A developer says "Knowing this codebase, it'll probably take about two weeks" for a feature that should take three days, because they know a change in one place breaks something in three others. In her view, estimates that consistently come out 2-3x higher than they should are not an estimation problem. The team knows what this code costs; it has simply stopped explaining it. In WordPress these hidden couplings have familiar sources: a theme that generates part of the content itself instead of using blocks, WooCommerce template overrides copied several versions ago, a few plugins doing the same job, and custom code hooked into the same hooks. How to measure it: take the last ten changes from the ticket history and set the estimate against the actual time. If the gap is steady and always in the same direction, the estimate is telling the truth about the code. ## Why does nobody want to update the site on a Friday The second signal is deploy fear. The article gives the example of a team with an unofficial rule, "no deploys after Wednesday". It appeared after three Thursday deploys in a row caused weekend incidents, with no rollback plan, tests nobody trusted and a 45-minute deploy pipeline. On a WordPress site deploy fear looks like this: plugin updates clicked through on production, no staging site or a staging site with a database from six months ago, a backup nobody has ever restored. The result is the same as in the article: changes pile up into batches, and each batch is bigger and riskier than the last. How to measure it: answer three questions. Is there a staging site with a current database? Has anyone restored a backup in the last quarter? Are there days when the team does not deploy? Every "no" to the first two and a "yes" to the third raises the score. ## Which file in a WordPress theme is the no-go zone The third signal is the "don't touch that" file. The author looks for it in the repository history: a file that keeps showing up in git log, but whose structure nobody has changed in years. The team builds workarounds around it, so the code grows around a zone everyone avoids. In WordPress this is most often the theme's `functions.php`, which over the years has grown to several thousand lines, or the company's own plugin, where everyone added "just one function". How to measure it: in the theme or custom plugin repository, run ```bash git log --since="1 year ago" --format= --name-only | sort | uniq -c | sort -rn | head -10 ``` The list shows the most frequently changed files. The file at the top whose changes are only additions at the end is a candidate for the no-go zone. If the theme has no repository, this signal scores high anyway: there is no way to find out who changed the code and why. While you are at it, count the active plugins: ```bash wp plugin list --status=active --format=count ``` The number alone settles nothing, but several form, cache or SEO plugins at once are a common source of conflicts that make every change take longer. ## Does high test coverage protect the WooCommerce checkout The author calls the fourth signal the coverage lie. The dashboard shows a healthy coverage percentage, while three models that handle money have zero tests. On top of that, CI took 40 minutes, so developers stopped running tests locally. Her check is simple: when did a test last catch a bug before it reached production? A WooCommerce store with no tests at all has the same problem in a sharper form. The money path is the cart, the checkout, the payment gateway and the order confirmation email. If someone places a test order by hand after every update, the store does have a test, just a manual one that depends on one person's memory. How to measure it: check whether any automated test places an order, and ask when it last caught something. ## How long does it take to onboard a new developer to a WordPress site The fifth signal is time to first commit: how long it takes before a new person ships a real fix. According to the author, a day or two is healthy; in unhealthy projects she has seen two weeks or more. The cause is often setup rot: outdated install scripts, broken seed data, undocumented environment variables. With WordPress the list is similar: no repository, a database dump you have to beg the host for, API keys stored only on production, premium plugins without a development licence. How to measure it: set up a working local copy from scratch, for example with [wp-env](https://developer.wordpress.org/block-editor/getting-started/devenv/get-started-with-wp-env/), and note the time and every single thing you had to ask someone for. ## How do you score the five signals The author scores each signal from 0 to 2. A total of 4 or more means the code needs direct investment before other changes will help. From 7 points, as she writes, is where most of her engagements start. | Signal | 0 points | 2 points | |---|---|---| | Apology estimate | estimates match actuals | steady gap upwards | | Deploy fear | staging, rollback plan, deploys on any day | changes on production, no tested backup | | The file nobody touches | no file dominates the history | one file keeps collecting additions | | Test coverage | a test recently caught a bug before production | checkout with no test at all | | Time to first commit | local copy in an hour | several days and access requests | The points themselves are arbitrary; what matters is the order of the signals. The author advises starting with the highest-scoring signal, giving it a focused two-week sprint and measuring something concrete, such as deploy frequency or estimate accuracy. ## Why is the best developer on the site the slowest The author points out a paradox: with code like this, the best engineers slow down the most. They see the risk, they know a change in this file can break that process, so they work carefully, write defensive code and pad their estimates. A less experienced person is sometimes faster because they do not see the danger, and then causes an incident that makes everyone even more careful. An example from her article: two engineers spent a week adding a CSV export to the admin panel, when the actual work was maybe a day. The rest of the time went into understanding the existing code well enough to change it safely. That overhead shows up in no report, so management only sees slow people. ## Will rebuilding the site from scratch fix slow changes Not always. The author describes a client that went through six engineering teams in ten years. Each time the pattern was the same: pressure for new features, cleanup postponed, until the code started to look beyond saving. Then someone proposed a rewrite or splitting out microservices, which made things worse, because instead of one system there were two, and the old one was still running. On WordPress this scenario looks familiar: a new theme set up next to the old one, a headless frontend taking over some pages while the rest still runs through the old template, or a new store to which half the integrations never get moved. A rebuild makes sense when you know which signal is the brake and whether the new architecture removes it. Without that, the old obstacles move into the new code. ## What should you fix first for each signal The author gives a different first step for each signal. Below are her recommendations and their WordPress counterpart. - Apology estimate: decouple the modules with the widest blast radius. In WordPress that usually means splitting `functions.php` into separate files or a plugin with clearly named functions, and retiring WooCommerce template overrides nobody has updated. - Deploy fear: a faster deploy pipeline, automatic rollback and smaller batches of changes. In WordPress: a staging site with a current database, deploying code from the repository instead of over FTP, and a tested backup restore. - The file nobody touches: tests around it first, structural changes after. For a theme, a few tests checking that the key pages render are enough to start. - Test coverage: a test for the money path. In WooCommerce that is one automated test that places an order on staging and checks that the confirmation email arrived. - Time to first commit: according to the author, a single day spent fixing setup pays for itself. In WordPress: a wp-env config file in the repository, a script that pulls an anonymised database dump, and a list of environment variables. When you raise this with the board or with a client, specifics work better than generalities. The author contrasts two statements: "every feature takes roughly twice as long because of coupling in these three modules" is a completely different conversation from complaining about technical debt. ## Will AI speed up changes on an old WordPress site It is tempting to assume an AI agent will rewrite the problem away. The author cites a 2025 METR study: 16 experienced open-source developers were 19% slower with AI tools on repositories they knew well. She adds that writing code was never the bottleneck. The agent runs into the same hidden dependencies as a human; it just generates the next workaround around the file nobody touches faster. So bring the five signals down before you let AI into the repository. ## Where to start fixing a slow WordPress site With a score of four points or more, start by removing the obstacle with the highest score. A new developer or a new theme will run into the same obstacles. Usually that means a staging site with a current database and a repository for the theme, because without them no other signal can be tackled safely. This is how our [WooCommerce rescue sprint](/en/woocommerce-rescue-sprint/) works: a paid diagnosis, fixes in order of priority, deployment to staging first, and a written report on what was changed and why. If you are wondering whether the site is still worth fixing at all, start with the [redesign readiness audit](/en/redesign-readiness-audit/) or the guide on [when to rebuild your website](/en/when-to-rebuild-your-website-guide-2026/). --- ## jQuery vs Vanilla JS in 2026: migration, risks and when to keep it URL: https://wppoland.com/en/jquery-vs-vanilla-js-migration-guide/ Description: From $.click() to addEventListener, from $.ajax() to fetch(). A comprehensive technical guide for WordPress developers migrating from jQuery to modern vanilla JavaScript (ES2024+), including Web Components, performance benchmarks, and migration strategies. Published: Wed Oct 08 Updated: Tue Oct 20 Type: guide Level: advanced Tags: jquery, vanilla js, performance, migration, web components, es2024 <p id="introduction">This guide covers a practical <strong>jQuery replacement TypeScript</strong> path for WordPress themes and plugins: typed DOM helpers, incremental migration, and when keeping jQuery on legacy stacks is still rational.</p> jQuery solved real browser compatibility problems for over a decade. In 2008, when this article was first published, writing cross-browser JavaScript without jQuery was genuinely painful. Internet Explorer 6 handled events differently, CSS selectors were inconsistent, and AJAX required browser-specific XMLHttpRequest implementations. Learn more about [WordPress speed optimization](/en/speed-up-wordpress/) at WPPoland. In 2026, every problem jQuery solved is now handled natively by browsers. The question is no longer *whether* to migrate, but *how* to do it safely without breaking existing functionality. ## Does jQuery slow down WordPress sites? jQuery 3.7 weighs 87KB uncompressed (30KB gzipped). That may sound small, but consider what it costs: - **Total Blocking Time (TBT)**: jQuery must parse and execute before any dependent code runs. On mid-range mobile devices, this adds 150-300ms to TBT. - **[Interaction to Next Paint (INP)](/en/core-web-vitals-2026-inp-optimization-guide/)**: jQuery's event delegation system adds overhead to every user interaction, measurably worsening INP scores. - **Dependency chain**: Loading jQuery means every script that depends on it must wait, creating a waterfall of blocking resources. - **Redundant code**: Every jQuery method you call has a native equivalent that the browser already ships. You are paying twice for the same functionality. ### Performance benchmarks: jQuery vs vanilla JS Real-world measurements on a WordPress theme with typical interactions (menu toggle, tab switching, form validation, AJAX load-more): | Metric | With jQuery | Without jQuery | Improvement | |--------|-------------|----------------|-------------| | Total JS size | 142KB | 55KB | -61% | | TBT (mobile) | 480ms | 180ms | -62% | | INP (p75) | 220ms | 95ms | -57% | | LCP | 2.1s | 1.7s | -19% | | Lighthouse Performance | 72 | 94 | +22 points | These numbers come from a production WordPress site running GeneratePress with WooCommerce, tested on a Moto G Power (a representative mid-range device). ## What is the difference between jQuery and JavaScript? JavaScript is the programming language that browsers run; jQuery is a library written in that language. They are not two competing options at the same level. jQuery code executes as JavaScript, so every `$()` call is really a shorter way of invoking the browser's own DOM API. jQuery, first released in 2006, exists to paper over the DOM, event, and AJAX inconsistencies that plagued Internet Explorer and early browsers. `$('.btn')` wraps `document.querySelectorAll('.btn')`; `$.ajax()` wraps `XMLHttpRequest`. When developers search for the difference between jQuery and JavaScript, they usually mean the difference between jQuery's API and the browser's native API, which is the comparison this guide calls jQuery vs vanilla JS. The practical consequence: you can express everything jQuery does in plain JavaScript, but you cannot run jQuery without JavaScript underneath it. In 2026 the native APIs (`querySelector`, `addEventListener`, `fetch`, `classList`, `IntersectionObserver`) cover what jQuery once abstracted, which is why loading the 87KB library on top of the language it is built from is now optional rather than necessary. ## How to replace jQuery with vanilla JavaScript The ES2024 specification, fully supported in Chrome 124+, Firefox 126+, Safari 17.4+, and Edge 124+, provides native alternatives for every common jQuery pattern. ### DOM selection ```js // jQuery const $buttons = $('.btn'); const $container = $('#main-container'); const $firstItem = $('.menu-item:first'); // Vanilla JS (ES2024+) const buttons = document.querySelectorAll('.btn'); const container = document.getElementById('main-container'); const firstItem = document.querySelector('.menu-item'); // Scoped selection (like jQuery .find()) const navLinks = container.querySelectorAll('a.nav-link'); ``` **Key difference**: `querySelectorAll` returns a static `NodeList`, not a live collection. This is actually safer because the list does not change unexpectedly when the DOM mutates. ### Event handling ```js // jQuery $('.btn').click(function () { $(this).toggleClass('active'); }); $('.menu').on('click', '.menu-item', function () { // delegated event }); // Vanilla JS document.querySelectorAll('.btn').forEach(btn => { btn.addEventListener('click', () => { btn.classList.toggle('active'); }); }); // Event delegation (replaces .on() with selector) document.querySelector('.menu').addEventListener('click', (e) => { const item = e.target.closest('.menu-item'); if (item) { // handle menu item click } }); ``` The `closest()` method is the modern equivalent of jQuery's delegated event matching. It traverses up the DOM tree to find the nearest ancestor matching a selector. ### Class manipulation ```js // jQuery $el.addClass('active'); $el.removeClass('hidden'); $el.toggleClass('open'); $el.hasClass('visible'); // Vanilla JS el.classList.add('active'); el.classList.remove('hidden'); el.classList.toggle('open'); el.classList.contains('visible'); // Multiple classes at once el.classList.add('active', 'highlighted', 'animate-in'); el.classList.remove('hidden', 'collapsed'); ``` ### AJAX with fetch API and async/await ```js // jQuery $.ajax({ url: '/wp-json/wp/v2/posts', method: 'GET', data: { per_page: 5 }, success: function (posts) { renderPosts(posts); }, error: function (xhr) { console.error(xhr); } }); // Vanilla JS (modern async/await) async function loadPosts() { try { const response = await fetch('/wp-json/wp/v2/posts?per_page=5'); if (!response.ok) { throw new Error(`HTTP ${response.status}: ${response.statusText}`); } const posts = await response.json(); renderPosts(posts); } catch (error) { console.error('Failed to load posts:', error); } } // POST with nonce (WordPress pattern) async function submitForm(data) { const response = await fetch('/wp-json/custom/v1/submit', { method: 'POST', headers: { 'Content-Type': 'application/json', 'X-WP-Nonce': wpApiSettings.nonce, }, body: JSON.stringify(data), }); return response.json(); } ``` ### Animations without jQuery jQuery's `.fadeIn()`, `.slideDown()`, and `.animate()` can all be replaced with CSS transitions, CSS animations, or the Web Animations API. ```js // jQuery $('.panel').slideDown(300); $('.modal').fadeIn(200); // CSS approach (preferred for performance) // In CSS: // .panel { max-height: 0; overflow: hidden; transition: max-height 0.3s ease; } // .panel.open { max-height: 500px; } // In JS: panel.classList.add('open'); // Web Animations API (for complex, programmatic animations) modal.animate( [ { opacity: 0, transform: 'scale(0.95)' }, { opacity: 1, transform: 'scale(1)' }, ], { duration: 200, easing: 'ease-out', fill: 'forwards' } ); ``` The Web Animations API runs on the compositor thread, meaning animations do not block the main thread. jQuery animations run on the main thread and cause jank on slower devices. ### DOM manipulation ```js // jQuery $('<div class="notice">Hello</div>').appendTo('#container'); $('.old-element').replaceWith('<span>New</span>'); $('.item').remove(); $('.list').empty(); // Vanilla JS const notice = document.createElement('div'); notice.className = 'notice'; notice.textContent = 'Hello'; container.append(notice); // Or use insertAdjacentHTML for HTML strings container.insertAdjacentHTML('beforeend', '<div class="notice">Hello</div>'); // Replace oldElement.replaceWith(Object.assign(document.createElement('span'), { textContent: 'New' })); // Remove item.remove(); // Empty list.replaceChildren(); ``` ### Document ready ```js // jQuery $(document).ready(function () { /* ... */ }); $(function () { /* shorthand */ }); // Vanilla JS document.addEventListener('DOMContentLoaded', () => { // DOM is ready }); // Or simply place your <script> tag with type="module" at the end of <body> // Modules are deferred by default, so the DOM is already ready ``` ## How to replace jQuery plugins with Web Components in WordPress jQuery plugins provided reusable UI components (sliders, modals, tabs, accordions). In 2026, Web Components offer a standards-based alternative with better encapsulation. ### Example: a toggle panel component ```js class TogglePanel extends HTMLElement { constructor() { super(); this.attachShadow({ mode: 'open' }); } connectedCallback() { const title = this.getAttribute('title') || 'Toggle'; this.shadowRoot.innerHTML = ` <style> :host { display: block; margin: 1rem 0; } button { width: 100%; padding: 0.75rem 1rem; background: #f5f5f5; border: 1px solid #ddd; cursor: pointer; text-align: left; font-size: 1rem; font-weight: 600; } .content { display: none; padding: 1rem; border: 1px solid #ddd; border-top: none; } :host([open]) .content { display: block; } </style> <button part="trigger">${title}</button> <div class="content"><slot></slot></div> `; this.shadowRoot.querySelector('button').addEventListener('click', () => { this.toggleAttribute('open'); }); } } customElements.define('toggle-panel', TogglePanel); ``` Usage in HTML: ```html <toggle-panel title="Shipping information"> <p>Free shipping on orders over $50.</p> </toggle-panel> ``` Web Components provide Shadow DOM encapsulation (styles do not leak), slots for content projection, and lifecycle callbacks. They work in every modern browser without polyfills. ### When to use Web Components vs a framework | Scenario | Recommendation | |----------|---------------| | Simple interactive widget (accordion, tabs, modal) | Web Component | | Full SPA (single page application) | React / Vue / Svelte | | WordPress block (Gutenberg) | React (WordPress standard) | | Shared component across multiple sites | Web Component | | Complex state management | Framework with state library | ## How to remove jQuery from WordPress step by step ### Step 1: Audit your jQuery usage Run this command in your theme directory to find all jQuery references: ```bash grep -rn '\$(\|jQuery\.\|jQuery(' --include='*.js' --include='*.php' . ``` Categorize each usage: - **Your code** (theme/custom plugin): migrate this - **Third-party plugin**: leave this, the plugin manages its own dependencies - **WordPress admin**: do not touch, WordPress core handles this ### Step 2: Create a migration plan Prioritize by impact: 1. **Front-end theme code** (affects every visitor) - migrate first 2. **Custom plugin front-end** - migrate second 3. **Admin-side customizations** - migrate last (lower traffic) ### Step 3: Replace patterns incrementally Do not rewrite everything at once. Replace one file at a time: 1. Remove `array('jquery')` from the file's `wp_enqueue_script` dependency array 2. Replace all jQuery patterns with vanilla JS equivalents 3. Test in Chrome, Firefox, Safari, and Edge 4. Test with all active plugins enabled 5. Run Lighthouse before and after to measure improvement ### Step 4: Handle the WordPress AJAX pattern WordPress legacy AJAX uses `admin-ajax.php` with jQuery: ```js // Old pattern (jQuery + admin-ajax) jQuery.post(ajaxurl, { action: 'my_custom_action', nonce: myData.nonce, post_id: 123, }, function (response) { console.log(response); }); …[truncated, fetch the canonical URL for the full body]… --- ## Tiered and unit pricing architecture in WooCommerce B2B and Google Merchant Center URL: https://wppoland.com/en/tiered-and-unit-pricing-architecture-in-woocommerce-b2b-and-google-merchant-center/ Description: Implement scalable volume-based tiered pricing, unit pricing, and MOQ in WooCommerce B2B aligned with Google Merchant Center and AI shopping agents. Published: Thu Oct 15 Updated: Tue Oct 20 Type: guide Level: advanced Tags: woocommerce, b2b, google-merchant-center, structured-data, erp, performance Modern B2B digital commerce imposes rigorous architectural requirements on software engineering teams. Business purchasers demand negotiated contract rate tables, minimum order quantities (MOQ), and transparent volume-based discounts. Concurrently, search engines and AI shopping assistants require standardized, machine-readable data detailing unit costs and wholesale thresholds. Any discrepancy between feed prices and checkout cart calculations leads to product disapprovals in Google Merchant Center. Implementing a scalable volume pricing infrastructure within WooCommerce requires moving beyond legacy post metadata patterns. Engineering teams must introduce dedicated relational tables, deploy memory-safe XML and NDJSON feed generation pipelines, and construct granular Schema.org semantic graphs to guarantee sustained indexing compliance. ## Google Merchant Center technical specifications for wholesale and unit pricing Google Merchant Center enforces strict rules regarding goods distributed by weight, volume, length, or bulk unit packages. In the EU, EFTA countries, the UK, Australia and New Zealand, Google requires unit pricing for products that local regulations say must show it, so that buyers immediately perceive the comparative cost per standardized base unit (such as price per kilogram, liter, or square meter). The core technical feed attributes comprise: 1. `unit_pricing_measure`: The actual physical quantity or dimension contained within the sales unit (such as `25kg`, `500ml`, or `100ct`). This value informs parsing engines of the package contents. 2. `unit_pricing_base_measure`: The baseline comparative denominator (such as `1kg`, `100ml`, or `1ct`). Google utilizes this metric to generate standardized unit price badges. 3. `auto_pricing_min_price`: The lowest price to which Google may reduce a product in automated discounts and dynamic promotions. 4. `loyalty_program`: A group attribute for member prices, member shipping and loyalty points. It is the only place for prices that depend on joining a program; there is no separate wholesale tier attribute. Submitting malformed dimension units or mismatched currency denominations generates critical rejections during merchant catalog validation. For example, if an industrial chemical lubricant is marketed in a 20-liter container priced at 180 EUR, the feed must designate `unit_pricing_measure` as `20l` and `unit_pricing_base_measure` as `1l`, allowing search engines to calculate and display the corresponding 9 EUR per liter unit metric. ## How to submit tiered B2B prices in a Google Merchant Center feed Google's product data specification has no attribute for quantity tiers. A feed item carries one `price`, and Google's [price attribute rules](https://support.google.com/merchants/answer/6324371) define which number that has to be. If a minimum order quantity applies, the feed price is the price for that minimum quantity: Google tells merchants not to submit a single-item price when customers cannot buy just one. For a retailer-made multipack or bundle, the price is the total for the whole pack. That leaves three workable ways to expose a volume ladder: 1. Separate pack products. Each pack size (single pail, carton, pallet) becomes its own item with its own `id`, `price` and `unit_pricing_measure`, and all of them share one `item_group_id`. Google's [unit_pricing_measure documentation](https://support.google.com/merchants/answer/6324455) shows this pattern with rice sold in 5, 10 and 12 lb bags, each with a 1 lb base measure, so the unit price tells the buyer which pack is cheaper per unit of weight. 2. The `multipack` attribute. According to the [multipack page](https://support.google.com/merchants/answer/6324488), it is meant for packs the retailer assembled from identical products, and it is required for free listings once you create such a pack. For a manufacturer-defined pack you leave `multipack` out and express the count through `unit_pricing_measure`. 3. The tier table stays on the site. Quantity breaks above the minimum live in WooCommerce and on the product page, while the feed carries the entry price. This option does not multiply SKUs, and it stays consistent as long as the landing page shows the same entry price. For the unit price itself, both attributes must use the same unit type, and `unit_pricing_base_measure` accepts only specific values: 1, 2, 4, 8, 10 or 100 of a unit, plus 75cl, 750ml, 50kg and 1000kg ([unit_pricing_base_measure](https://support.google.com/merchants/answer/6324490)). The measure takes at most two decimal places. For the UK, Google reads imperial units as US imperial, so metric values are the safe choice. If an item carries both `unit_pricing_measure` and an energy efficiency class, Google shows only the energy class. ## Which landing page and checkout rules disapprove B2B products in Merchant Center Most B2B disapprovals come from the gap between the feed and what a buyer sees. The [price attribute rules](https://support.google.com/merchants/answer/6324371) contain the constraints that collide with typical wholesale setups: - The feed price must match the price on the landing page and at checkout, in the target country's currency, and "view price in cart" is not allowed. - Any user in the target country must be able to buy at the submitted price. An account requirement is allowed only when signup is free and straightforward, which rules out feeds built from prices that only approved trade accounts can see. - In countries such as Germany, France and the UK the price includes VAT, and Google applies this to wholesale offers as well. In the US and Canada, tax stays out of the price. - A minimum order value is not part of the price. It belongs in the shipping settings. Contract and member prices have their own channel. Google states that member prices must not go into `price` or `sale_price`; they go into the [loyalty_program](https://support.google.com/merchants/answer/12922446) group attribute, with sub-attributes such as `program_label`, `tier_label`, `price`, `loyalty_points` and `member_price_effective_date`. The program has to be set up in Merchant Center first, member prices must be visible to members on the site, and Google shows member pricing in ads only when the discount reaches at least 5% or 5 currency units. Google's examples are customer tiers such as silver and gold, not verified business accounts, so a B2B store has to check whether its trade price list fits that model at all. A time-limited tier promotion belongs in [sale_price](https://support.google.com/merchants/answer/6324471), which must be lower than `price`. The full price keeps going into `price`, the landing page shows both prices, checkout shows only the sale price, and `sale_price_effective_date` limits the period; without it the sale price applies immediately. `auto_pricing_min_price` is a different tool: Google's [minimum price attribute](https://support.google.com/merchants/answer/10071801) is required for automated discounts and dynamic promotions and must sit between the cost of goods sold, if you provide it, and 95% of the regular price. ## Why Google shows a price drop the store never set The price drop label does not come from the feed. Google compares the current price with the average price the store listed over the past 60 days and shows the badge only for a significant drop from a fairly stable price ([Merchant Center help on price drop annotations](https://support.google.com/merchants/answer/14991443)). Google gives no percentage threshold, and the help page does not say how to opt out. The `Has price drop badge` filter on the all products tab lists the affected items. In B2B this is easy to trigger by accident. Emina Demiri-Watson described a store in [Search Engine Journal](https://www.searchenginejournal.com/googles-hidden-data-layer-what-is-it-and-what-to-do-about-it/590234/) where Google assembled a sale story from three independent signals, one of them an `AggregateOffer` schema with a `priceSpecification` array and two tiers. A typical tiered pricing plugin emits exactly that markup: to a crawler, the lowest tier looks like a new, lower price. What I check on a WooCommerce store that got an unwanted badge: 1. The `Information found on your site` panel on the product in Merchant Center: the price and availability Google last crawled from the page, independent of the feed. A gap of exactly 20% on a UK store is almost always VAT added on one side and left out on the other. 2. The words "sale", "was" and "now" in the HTML and the schema when no promotion is running. A theme's sale badge and a struck-through regular price can stay on the product page after the sale ends. 3. Images of retired products. Deleting a product in WooCommerce does not delete its attachments from the media library, so the image file still answers 200 at its old URL and Google can keep using it in ads. Delete the file or return 404 or 410 on that URL. 4. A feed archive. A date-stamped export saved at every audit (a private Git repository works) shows what price the store was sending three months before Google showed the "drop". ## Database bottlenecks in wp_postmeta and a custom price tier table The default WordPress content architecture employs an Entity-Attribute-Value (EAV) model, routing product and variant metadata into the monolithic `wp_postmeta` table. While adequate for basic retail catalogs, this design breaks down when managing complex B2B matrices. When a single industrial component features 6 distinct volume breaks across 8 separate wholesale buyer tiers, metadata storage requirements escalate dramatically. Representing 48 pricing rules for one product requires 48 independent rows in `wp_postmeta`. Across an enterprise catalog encompassing 40,000 SKUs and associated variations, the metadata table quickly swells beyond tens of millions of records. Standard catalog queries generate nested `LEFT JOIN` chains, triggering table locking and severe memory contention in the MySQL InnoDB buffer pool. High-Performance Order Storage (HPOS) does not solve this on its own. According to the [WooCommerce HPOS documentation](https://developer.woocommerce.com/docs/features/high-performance-order-storage/), it moves orders and order addresses into four dedicated tables (`wc_orders`, `wc_order_addresses`, `wc_order_operational_data` and `wc_orders_meta`), while products stay in the posts tables. What HPOS offers is the pattern: data with a known shape gets its own table with indexes that match the queries. For price tiers that means a separate, composite-indexed table: ```sql -- Dedicated relational table for high-performance B2B price tiers CREATE TABLE IF NOT EXISTS wp_wc_b2b_price_tiers ( tier_id BIGINT UNSIGNED AUTO_INCREMENT PRIMARY KEY, product_id BIGINT UNSIGNED NOT NULL, customer_group VARCHAR(32) NOT NULL DEFAULT 'all', min_quantity INT UNSIGNED NOT NULL DEFAULT 1, max_quantity INT UNSIGNED DEFAULT NULL, price_cents BIGINT NOT NULL, currency CHAR(3) NOT NULL DEFAULT 'EUR', created_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP, INDEX idx_product_lookup (product_id, customer_group, min_quantity), INDEX idx_pricing_search (min_quantity, max_quantity) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci; ``` With the composite index `(product_id, customer_group, min_quantity)`, a lookup for one product, customer group and quantity becomes a single index range read instead of a chain of joins on `wp_postmeta`. Eliminating queries against `wp_postmeta` keeps response times predictable and frees server memory for checkout concurrency. To evaluate how enterprise stores integrate complex catalog databases with external corporate ERPs, explore our comprehensive technical review covering [woocommerce erp integration](/en/woocommerce-erp-integration/). ## Streaming XML and NDJSON feed generation pipelines …[truncated, fetch the canonical URL for the full body]… --- ## How to export WordPress data to CSV or Excel URL: https://wppoland.com/en/export-wordpress-data-excel-csv/ Description: Export WordPress posts, users, and WooCommerce data to CSV or Excel using PHP, WP-CLI, and the REST API without turning the job into a manual spreadsheet task. Published: Sat Aug 17 Updated: Tue Oct 13 Type: guide Level: advanced Tags: export, csv, excel, wp-cli Exporting data from WordPress does not always require a plugin. If you need posts, users, form submissions, or WooCommerce orders in a spreadsheet, the right method depends on dataset size, who consumes the file, and how often the job runs. <div id="introduction"></div> Use plain CSV for most exports, stream rows with `fputcsv()` for browser downloads, batch with `WP_Query`, and switch to WP-CLI when an admin request would hit memory or timeout limits. Reach for the REST API when another system needs structured data rather than a file. ## Best way to export WordPress data to CSV Three approaches cover almost every WordPress export job: - **PHP inside WordPress** for capability-checked admin downloads - **WP-CLI** for large datasets and scheduled server jobs - **REST API** for dashboards, warehouses, CRMs, and headless consumers Occasional small exports fit a PHP download well. Recurring or multi-gigabyte-adjacent tables belong on the CLI. External systems should pull JSON over REST and shape CSV outside WordPress when they need a spreadsheet. Match method to failure mode. Browser downloads fail on timeouts. Plugins fail when they try to build a full spreadsheet object in one request. Ad-hoc SQL dumps fail when column names drift after a plugin update. Pick the path that keeps the export reproducible next month, not only today. Need a custom exporter wired into your stack? Talk to a [WordPress developer](/en/wordpress-developer/) who has shipped production exports before. ## What Tools > Export in WordPress actually exports WordPress ships an exporter in core, but it does not produce a spreadsheet. According to the [Tools Export screen documentation](https://wordpress.org/documentation/article/tools-export-screen/), the downloaded file is an XML file in WordPress eXtended RSS (WXR) format containing posts, pages, custom post types, comments, custom fields, categories, tags, custom taxonomies, and users. When you pick posts or pages, you can filter by category, author, date range, and status. That file is meant for Tools > Import > WordPress on another install. Excel can open the XML, but every entry drags along the full content HTML, the metadata, and the comments, so it is of little use as a spreadsheet. Use WXR for migrations and content copies. Use CSV when a person has to filter, sum, or cross-reference columns. The same WXR comes out on the server with [wp export](https://developer.wordpress.org/cli/commands/export/). It accepts filters such as `--post_type`, `--start_date` and `--end_date` (YYYY-MM-DD format), `--post_status`, and `--author`, splits files at 15 MB by default (`--max_file_size`, with `-1` for no limit), and with `--stdout` writes the XML to standard output: ```bash wp export --dir=/tmp/exports/ --post_type=post --start_date=2026-01-01 --end_date=2026-06-30 ``` ## CSV or XLSX for WordPress data exports Start with CSV unless a stakeholder has a hard requirement for `.xlsx`. **CSV strengths** - Easy to generate with PHP or WP-CLI - Easy to inspect and debug in a text editor - Opens in Excel, Numbers, and Google Sheets - Avoids XLSX libraries and their memory cost **XLSX trade-offs** - Binary format with worksheets, styles, and shared strings - Needs a library such as PhpSpreadsheet or a post-export conversion step - Builds more state in memory before the file is complete - Harder to stream safely during a long HTTP request Practical pattern: export CSV from WordPress, then convert with Excel, LibreOffice, or a small offline script if someone insists on XLSX. That keeps the WordPress request lean. Excel tip: UTF-8 CSV files sometimes need a BOM (`\xEF\xBB\xBF`) so Excel on Windows opens diacritics correctly. [Microsoft support](https://support.microsoft.com/en-us/office/opening-csv-utf-8-files-correctly-in-excel-8a935af5-3416-4edd-ba7e-3dfd2bc4a032) confirms it: a UTF-8 CSV saved with a BOM opens normally on double-click. Without a BOM, the documented route is Data > Get Data > From File > From Text/CSV, which lets the user pick the encoding before loading. Write the BOM before the header row when your audience lives in Excel, and leave it out when the file feeds another script, because many parsers read those three bytes as part of the first column name. ## Export WordPress users to CSV with PHP For custom admin tools, stream CSV to the browser. Capability and nonce checks come first. Then set headers, open `php://output`, write the header row, and stream data rows page by page. ```php add_action( 'admin_post_wppoland_export_users', 'wppoland_export_users_csv' ); function wppoland_export_users_csv() { if ( ! current_user_can( 'manage_options' ) ) { wp_die( 'Access denied.' ); } check_admin_referer( 'wppoland_export_users' ); header( 'Content-Type: text/csv; charset=utf-8' ); header( 'Content-Disposition: attachment; filename=users-export.csv' ); $output = fopen( 'php://output', 'w' ); // Optional BOM for Excel on Windows: // fwrite( $output, "\xEF\xBB\xBF" ); fputcsv( $output, array( 'ID', 'Email', 'Registered' ), ',', '"', '' ); $page = 1; do { $users = get_users( array( 'fields' => array( 'ID', 'user_email', 'user_registered' ), 'number' => 500, 'paged' => $page, 'orderby' => 'ID', 'order' => 'ASC', ) ); foreach ( $users as $user ) { fputcsv( $output, array( $user->ID, $user->user_email, $user->user_registered ), ',', '"', '' ); } $page++; } while ( count( $users ) === 500 ); fclose( $output ); exit; } ``` This pattern works for smaller exports and internal admin tools. Do not collect every row into a giant PHP array and then implode it. Stream each row as you fetch it. A single `get_users()` call with `number => 500` would return only the first 500 users; the loop with `paged` walks the rest in pages of the same size. Protect the endpoint with a nonce and a capability check. The form that triggers the download must include `wp_nonce_field( 'wppoland_export_users' )` so `check_admin_referer()` can validate it. User and order exports often contain personal data, so treat them like any other privileged admin action under GDPR-style rules: log who ran the export and keep the file off public URLs. ## fputcsv in PHP 8.4 and the escape parameter The examples in this guide pass five arguments to `fputcsv()`, and that is deliberate. The [PHP manual](https://www.php.net/manual/en/function.fputcsv.php) states that as of PHP 8.4.0, relying on the default value of `escape` is deprecated: it has to be passed explicitly, positionally or as a named argument. An export that runs on every cron tick would otherwise fill the log with deprecation notices. The same manual explains that any `escape` other than the empty string can produce CSV that is not RFC 4180 compliant or that cannot survive a roundtrip through the PHP CSV functions. The default is a backslash, and the recommendation is to set it to `""`. That is why every call here uses `',', '"', ''`. The manual also warns that the default will change in a future version, no earlier than PHP 9.0, so pinning it today keeps the output from changing on its own after a server upgrade. ## Export large WordPress datasets without memory errors The usual failure mode is [loading too much into memory at once](/en/the-definitive-guide-to-wpquery-the-loop-2026-performance-edition/). PHP memory limits, `max_execution_time`, and reverse-proxy timeouts all kill long admin exports. Batch with `WP_Query` using `posts_per_page` and `offset`, or better, page with a stable cursor when offsets get expensive on large tables. ```php // $output is the stream opened as in the users example. $offset = 0; $limit = 500; do { $query = new WP_Query( array( 'post_type' => 'post', 'post_status' => 'publish', 'posts_per_page' => $limit, 'offset' => $offset, 'orderby' => 'ID', 'order' => 'ASC', 'fields' => 'ids', 'no_found_rows' => true, 'update_post_meta_cache' => false, 'update_post_term_cache' => false, ) ); foreach ( $query->posts as $post_id ) { fputcsv( $output, array( $post_id, get_the_title( $post_id ) ), ',', '"', '' ); } $offset += $limit; wp_cache_flush_runtime(); // WP 6.0+: clears only this request's in-memory cache } while ( count( $query->posts ) === $limit ); ``` Why this helps: - `fields => 'ids'` keeps object hydration light - Disabling meta and term caches stops the object cache from growing without bound - Fixed batch sizes keep peak memory closer to one page of rows - Streaming with `fputcsv()` avoids holding the full CSV string in RAM - Ordering by ascending `ID` stops a post published mid-export from shifting pages and duplicating or skipping rows Use `wp_cache_flush_runtime()`, not `wp_cache_flush()`, inside the loop. With a persistent object cache (Redis or Memcached), `wp_cache_flush()` empties the cache for the whole site in the middle of the export. The [runtime function](https://developer.wordpress.org/reference/functions/wp_cache_flush_runtime/), available since WordPress 6.0, clears only the current request's memory, and if the drop-in does not support it, it returns `false` without touching the shared cache. On very large tables, `offset` itself becomes slow because MySQL still walks discarded rows. Prefer `post__not_in` carefully (it also scales poorly) or keyset pagination: `WHERE ID > last_id ORDER BY ID ASC LIMIT N`. For CLI jobs, that pattern is worth the extra code. Official reference for query arguments: the [WP_Query class](https://developer.wordpress.org/reference/classes/wp_query/) on developer.wordpress.org. ## Export WordPress posts to CSV with WP-CLI When you export tens of thousands of rows, WP-CLI avoids the browser and the web server timeout chain. ```bash wp post list --post_type=post --fields=ID,post_title,post_date --format=csv > posts.csv ``` Useful for: - large post or product catalogues - WooCommerce order dumps that would timeout in wp-admin - nightly cron exports into object storage or a shared drive - migration and reporting hand-offs Command docs: [wp post list](https://developer.wordpress.org/cli/commands/post/list/). It accepts `--format=csv`, `json`, `yaml`, `ids`, `count`, or `table`, plus any `WP_Query` argument as `--<field>=<value>`. One detail matters on big sites: `--posts_per_page` defaults to `-1`, which means every post in a single query. If the table is huge, page with `--posts_per_page=1000 --paged=N` in a shell loop. Users have the matching command [wp user list](https://developer.wordpress.org/cli/commands/user/list/), whose default fields are ID, user_login, display_name, user_email, user_registered, and roles: ```bash wp user list --role=customer --fields=ID,user_email,user_registered --format=csv > customers.csv ``` Every command accepts the global `--ssh=user@host/path` parameter, which runs the export against a remote server from your machine without a separate session. You can also write a custom WP-CLI command that opens a file handle, pages through `WC_Order_Query` or `WP_Query`, and writes CSV to disk. That keeps memory predictable and lets you resume from a checkpoint if a job is interrupted: ```php WP_CLI::add_command( 'wppoland export-orders', function ( $args, $assoc_args ) { $file = fopen( 'orders.csv', 'w' ); fputcsv( $file, array( 'order_id', 'date_created', 'status', 'total', 'billing_email' ), ',', '"', '' ); …[truncated, fetch the canonical URL for the full body]… --- ## Advanced Caching Strategies for WordPress 2026: Beyond Simple Static Files URL: https://wppoland.com/en/advanced-wordpress-caching-strategies-2026-guide/ Description: WordPress caching in 2026 needs edge rules, cache tags and fragment caching that match the site's content model and invalidation paths. Published: Fri Sep 05 Updated: Tue Oct 13 Type: guide Level: advanced Tags: wordpress-caching, edge-caching, redis-object-cache, cache-tagging, performance-architecture In 2026, the performance gap between a "standard" WordPress site and an "enterprise" WordPress site is defined by **cache intelligence**. While basic page caching was sufficient a decade ago, modern web applications require sophisticated multi-layer caching strategies that understand *what* to cache, *where* to cache it, and precisely *when* to invalidate it. Ten years ago, caching was simple: you saved a page as an HTML file and served it until it expired. In 2026, that all-or-nothing approach is no longer sufficient. Modern websites are **hybrid entities** - part static, part dynamic, and served globally to users with varying connection speeds and devices. To hit 100/100 Core Web Vitals while serving personalized content, you need a strategy that optimizes every layer of the delivery stack. The practical architecture is layered: browser cache, CDN edge, full-page cache, fragment cache, object cache and database hygiene working together instead of competing. ## How three-layer edge caching works for WordPress In 2026, your origin server almost never sees a visitor request directly. Modern WordPress implementations follow a sophisticated triple-layer caching strategy that distributes content across the globe. ### Layer 1: Static edge cache (CDN) HTML, images, CSS, and JavaScript are stored at the network edge through services like Cloudflare, Bunny.net, or Fastly. This provides the critical sub-50ms [Time to First Byte (TTFB)](/en/services/core-web-vitals-audit/) that users expect. **Key Configuration Settings:** - **Cache Everything**: Cache HTML at the edge, not just static assets - **Edge TTL**: Set appropriate cache lifetimes (1 hour for dynamic, 1 year for static) - **Browser TTL**: Control client-side caching headers - **Always Online**: Serve stale content if origin is unreachable **Cloudflare Page Rules Example:** ``` *example.com/* Cache Level: Cache Everything Edge Cache TTL: 2 hours Browser Cache TTL: 30 minutes Always Online: On ``` ### Layer 2: API response caching For [headless or decoupled WordPress setups](/en/headless-vs-monolith-wordpress-2026-tco-guide/), API responses are cached separately from HTML: - REST API endpoints cached with short TTL (5-15 minutes) - GraphQL queries cached based on complexity and data volatility - Webhook-triggered cache purging for instant updates **Benefits:** - Reduces database load for JavaScript-driven frontends - Enables faster mobile app experiences - Supports real-time features with cached fallbacks ### Layer 3: Cache locking and thundering herd protection When a cached item expires, traditional setups allow multiple simultaneous requests to hit the origin server. In 2026, we implement **cache locking**: - Only the first request regenerates the cached content - Subsequent requests are served a slightly stale version - Once regeneration completes, all users receive fresh content **Implementation with Cloudflare Workers:** ```javascript // Cache locking pattern async function handleRequest(request) { const cache = caches.default; const cacheKey = new Request(request.url); let response = await cache.match(cacheKey); if (!response) { // Check for regeneration lock const lockKey = `lock:${request.url}`; const lock = await CACHE_LOCKS.get(lockKey); if (lock) { // Serve stale while regenerating response = await cache.match(`${cacheKey}:stale`); } else { // Acquire lock and regenerate await CACHE_LOCKS.put(lockKey, 'locked', {expirationTtl: 30}); response = await fetchOrigin(request); await cache.put(cacheKey, response.clone()); await cache.put(`${cacheKey}:stale`, response.clone()); } } return response; } ``` ### Full page caching with Nginx FastCGI and Varnish Edge networks deliver static assets and public HTML rapidly, but origin architectures still require high-efficiency full-page caching before PHP execution begins. Nginx FastCGI cache stores rendered HTML responses in shared memory zones and on local storage, bypassing PHP-FPM workers completely for anonymous visitors: ```nginx # FastCGI cache configuration in nginx.conf fastcgi_cache_path /var/run/nginx-cache levels=1:2 keys_zone=WORDPRESS:256m inactive=1d max_size=4g; fastcgi_cache_key "$scheme$request_method$host$request_uri"; # Purge location using fastcgi_cache_purge location ~ /purge(/.*) { allow 127.0.0.1; allow 10.0.0.0/8; deny all; fastcgi_cache_purge WORDPRESS "$scheme$request_method$host$1"; } ``` When editors update content, a purge plugin sends an HTTP `PURGE` request to the local Nginx endpoint, and the entry for that cache key is removed. The [nginx FastCGI module documentation](https://nginx.org/en/docs/http/ngx_http_fastcgi_module.html) says cache file names are the MD5 of the key, and it lists `fastcgi_cache_purge` as part of the commercial subscription, so open source Nginx builds rely on the third-party ngx_cache_purge module for the same job. The same page documents two directives worth enabling on any busy WordPress origin: `fastcgi_cache_lock`, which lets only one request at a time populate a new cache element, and `fastcgi_cache_use_stale`, which serves a stale response when the FastCGI backend errors. In multi-server environments with Varnish, `PURGE` requests or `BAN` expressions clear entries by URL pattern or by tag headers emitted by WordPress plugins. ## How to purge WordPress cache by tag The biggest problem with enterprise caching has always been "The Purge Problem." You update a typo on the homepage, and the entire site cache gets deleted, causing a massive performance hit and origin server overload. In 2026, we solve this with **Cache Tagging**. ### How cache tagging works Instead of treating cached content as isolated files, we tag each cached item with metadata about its dependencies: ``` Homepage: tags=["home", "post_123", "post_124", "category_news"] Blog Post: tags=["post_125", "category_tutorials", "author_john"] Category Page: tags=["category_tutorials", "post_125", "post_126"] ``` When you update "Post A," only the items tagged with `post_a` are purged: - The post itself - Its category archive pages - Related posts widgets - Author archive pages - Homepage (if featured) The rest of your 10,000 pages remain cached and fast. ### Implementing cache tags in WordPress **With Cloudflare:** ```php // Add cache tags to Cloudflare function add_cache_tags_header() { if (is_single()) { $tags = [ 'post_' . get_the_ID(), 'author_' . get_the_author_meta('ID'), ]; // Add category tags $categories = get_the_category(); foreach ($categories as $cat) { $tags[] = 'category_' . $cat->slug; } header('Cache-Tag: ' . implode(',', $tags)); } } add_action('template_redirect', 'add_cache_tags_header'); ``` **Purge by Tag:** ```php // Purge specific tags when post is updated function purge_post_cache_tags($post_id) { $tags = [ 'post_' . $post_id, 'author_' . get_post_field('post_author', $post_id), ]; // Cloudflare API purge by tag $api = new Cloudflare\API\Client($email, $api_key); $api->zones()->cachePurgeTags($zone_id, $tags); } add_action('save_post', 'purge_post_cache_tags'); ``` ### Which cache tags to purge when a post changes **Smart Tag Hierarchy:** - `post_{id}`: Individual post content - `category_{slug}`: Category archive pages - `author_{id}`: Author archive pages - `taxonomy_{name}_{term}`: Custom taxonomy pages - `widget_{id}`: Dynamic widget content - `global`: Site-wide elements (header, footer, menus) **Conditional Purging:** ```php // Only purge what changed function smart_cache_purge($post_id) { $post = get_post($post_id); $tags = ['post_' . $post_id]; // If featured image changed, purge image-related caches if (did_post_thumbnail_change($post_id)) { $tags[] = 'featured_images'; } // If post status changed, purge archive listings if ($post->post_status !== get_previous_post_status($post_id)) { $tags[] = 'category_' . get_primary_category($post_id); $tags[] = 'author_' . $post->post_author; } purge_cache_tags($tags); } ``` ## Redis object cache for WordPress in 2026 The [database is the bottleneck of WordPress](/en/wordpress-database-optimization-guide/). Every page load triggers dozens of SQL queries to fetch posts, metadata, options, and user data. Object caching stores these query results in memory, eliminating redundant database lookups. ### Why Redis 8+ in 2026 The [Redis Open Source 8.0 release notes](https://redis.io/docs/latest/operate/oss_and_stack/stack-with-enterprise/release-notes/redisce/redisos-8.0-release-notes/) (May 2025) state that Redis Search, JSON, time series and five probabilistic data structures, previously separate modules, are now part of Redis itself. For WordPress, that means one server can hold the object cache and also the data used by search or metrics features: **Redis 8 Features:** - **RedisJSON**: Store and query complex JSON objects - **RedisSearch**: Full-text search within cached data - **RedisTimeSeries**: Track cache performance metrics - **Persistence options**: RDB and AOF for data durability **Redis vs Memcached (2026 Comparison):** | Feature | Redis 8+ | Memcached | |---------|----------|-----------| | Data Types | 8+ (strings, hashes, lists, sets, sorted sets, JSON, streams) | 1 (strings) | | Persistence | RDB + AOF | None | | Replication | Master-slave + Cluster | None | | Memory Efficiency | Better with compression | Good | | Tag invalidation | Manual (for example sets of keys) | Manual implementation | | Query Capabilities | RedisSearch | None | ### Redis drop-in versus Memcached and object cache mechanics WordPress core provides a pluggable caching interface through `wp-content/object-cache.php`. Without an object cache drop-in, WordPress defaults to an in-memory runtime cache for the lifetime of a single PHP request. With a persistent drop-in (for example the one installed by the Redis Object Cache plugin, or a Memcached drop-in), calls like `wp_cache_set()`, `wp_cache_get()`, `wp_cache_delete()`, and `wp_cache_add()` are served by the Redis or Memcached server and survive between requests. The [WP_Object_Cache reference](https://developer.wordpress.org/reference/classes/wp_object_cache/) puts the default plainly: "By default, the object cache is non-persistent", so data lives "in memory only and only for the duration of the request". Developers frequently confuse transients (`set_transient()`, `get_transient()`) with direct object cache calls (`wp_cache_set()`, `wp_cache_get()`): - When an external object cache drop-in is active, `set_transient()` maps directly to `wp_cache_set()` under the `transient` group, completely bypassing the `wp_options` table. - When no persistent drop-in exists, transients are written to `wp_options` as rows (`_transient_*` and `_transient_timeout_*`). In core's `set_transient()` code, a transient saved with an expiration gets a timeout row and is not autoloaded, while a transient saved without one is autoloaded on every request, so expiry-less transients quietly grow the autoloaded options. - The [Transients API handbook](https://developer.wordpress.org/apis/transients/) limits the key to 172 characters and quotes Ryan McCue: "transient expiration times are a maximum time. There is no minimum age." Code must always handle a miss, because Redis or Memcached can evict the value before its TTL. - Direct `wp_cache_*` calls allow custom cache groups and granular invalidation. ```php // Storing complex computed data in a dedicated cache group $cache_key = 'user_order_summary_' . $user_id; $order_summary = wp_cache_get($cache_key, 'orders_analytics'); …[truncated, fetch the canonical URL for the full body]… --- ## Advanced WP_Query: taxonomies, meta data and performance (2026) URL: https://wppoland.com/en/advanced-wp-query-taxonomy-meta-performance-guide/ Description: Stop writing slow loops. Master `tax_query` with complex relations (AND/OR), speed up queries with `no_found_rows` and filter Custom Post Types like a professional. Published: Wed Apr 18 Updated: Tue Oct 13 Type: guide Level: advanced Tags: development, taxonomy, performance, sql Every [WordPress developer](/en/wordpress-developer/) can run a simple loop. The trouble starts when a client asks for a compound filter: products from the seasonal collection in a given colour category, without items marked as unavailable, sorted by a custom field. That is where `cat=5` and `query_posts()` end up in debug.log, or on production under load. This guide is hands-on. We build `tax_query` and `meta_query`, set `relation` to AND/OR, turn on `no_found_rows` and `fields => ids`, avoid the index traps in `wp_postmeta`, and finally check the query in Query Monitor and the object cache. The code targets WordPress 6.x; the patterns also work on older 6.0+ releases, as long as you do not mix legacy parameters with the newer array syntax. ## How tax_query works in WP_Query Forget `cat`, `tag_id` and `category__and` as your default API. Those shortcuts still work, but they do not scale to nested logic. `tax_query` is the standard: each clause is an array with `taxonomy`, `field`, `terms`, and optionally `operator` and `include_children`. ### AND relation between taxonomies You want `movie` CPT entries that are in the `action` genre and in the year `2026` at the same time: ```php $args = [ 'post_type' => 'movie', 'posts_per_page' => 12, 'tax_query' => [ 'relation' => 'AND', [ 'taxonomy' => 'genre', 'field' => 'slug', 'terms' => 'action', ], [ 'taxonomy' => 'year', 'field' => 'slug', 'terms' => '2026', ], ], ]; $query = new WP_Query( $args ); ``` A top-level `relation` applies only to its direct children. Without an explicit `'relation' => 'AND'`, WordPress assumes AND anyway. Write it out regardless, because in code review it shows the intent. ### OR relation within one taxonomy When a list of terms should act as "any of", one clause with a `terms` array and the default `IN` operator is enough. Separate clauses with `relation => OR` are needed when you combine different taxonomies or different operators (`IN` vs `NOT IN`). ```php $args = [ 'post_type' => 'product', 'tax_query' => [ 'relation' => 'OR', [ 'taxonomy' => 'product_cat', 'field' => 'slug', 'terms' => [ 'on-sale', 'clearance' ], ], [ 'taxonomy' => 'product_label', 'field' => 'slug', 'terms' => 'last-pieces', ], ], ]; ``` ### Nesting groups (AND around OR) A real catalogue filter usually looks like this: (category A OR category B) AND (colour C) AND NOT discontinued status. In `tax_query` you do that with a nested array that has its own `relation`: ```php $args = [ 'post_type' => 'product', 'tax_query' => [ 'relation' => 'AND', [ 'relation' => 'OR', [ 'taxonomy' => 'product_cat', 'field' => 'slug', 'terms' => [ 't-shirts', 'hoodies' ], ], [ 'taxonomy' => 'product_cat', 'field' => 'slug', 'terms' => 'accessories', ], ], [ 'taxonomy' => 'pa_color', 'field' => 'slug', 'terms' => 'red', ], [ 'taxonomy' => 'product_visibility', 'field' => 'name', 'terms' => [ 'outofstock', 'exclude-from-catalog' ], 'operator' => 'NOT IN', ], ], ]; ``` Each nested group generates a separate JOIN to `wp_term_relationships`. Three levels of nesting on a catalogue with hundreds of thousands of rows is a signal to measure with EXPLAIN. Not to "simplify for marketing", but to know whether MySQL picks the indexes. ## Filtering by custom fields with meta_query `meta_query` filters on `wp_postmeta`. Each clause has a `key`, and optionally `value`, `compare` and `type`. `type` (`NUMERIC`, `DECIMAL`, `DATE`, `CHAR`, `BINARY`) controls the CAST in SQL. Without `NUMERIC`, comparing "10" and "2" is lexicographic: `'2' > '10'` in CHAR. ### A basic clause with CAST ```php $args = [ 'post_type' => 'product', 'meta_query' => [ [ 'key' => '_stock', 'value' => 0, 'compare' => '>', 'type' => 'NUMERIC', ], ], ]; ``` ### EXISTS and NOT EXISTS Sometimes you do not care about the value, only whether the key is there. `compare => 'EXISTS'` (and `NOT EXISTS`) needs no `value`. It is cheaper than `LIKE` on an empty string and easier to read in code review. ```php $args = [ 'post_type' => 'event', 'meta_query' => [ 'relation' => 'AND', [ 'key' => 'event_start', 'compare' => 'EXISTS', ], [ 'key' => 'event_cancelled', 'compare' => 'NOT EXISTS', ], ], ]; ``` ### BETWEEN, IN and LIKE in meta_query `BETWEEN` needs an array of two values. `IN` needs a list. `LIKE` with `%` on both sides forces a full scan of `meta_value`, because an index on `meta_key` is not enough to search the middle of a value. If you filter by a fragment of text in meta, consider a separate taxonomy or a denormalized column in a custom table. `LIKE '%foo%'` on a million rows of `wp_postmeta` is a classic hotspot from trac.wordpress.org and core performance tickets. ### AND/OR relation in meta_query The syntax mirrors `tax_query`. You can nest groups. Named clauses (a string key instead of a numeric index) let you sort later with an `orderby` that points to the clause name. That is the official pattern from the `WP_Query` documentation, not a hack. ```php $args = [ 'post_type' => 'product', 'meta_query' => [ 'relation' => 'AND', 'stock_clause' => [ 'key' => '_stock_status', 'value' => 'instock', 'compare' => '=', ], 'rating_clause' => [ 'key' => '_wc_average_rating', 'value' => 4, 'compare' => '>=', 'type' => 'DECIMAL', ], ], 'orderby' => [ 'rating_clause' => 'DESC', 'date' => 'DESC', ], ]; ``` ## Combining tax_query and meta_query in one query Both arguments work together. WordPress merges them into one SELECT with JOINs to terms and meta. A typical catalogue scenario: a category taxonomy plus a `_featured` field or a date range. ```php $args = [ 'post_type' => 'product', 'posts_per_page' => 24, 'tax_query' => [ [ 'taxonomy' => 'product_cat', 'field' => 'slug', 'terms' => 't-shirts', ], ], 'meta_query' => [ 'relation' => 'AND', [ 'key' => '_stock', 'value' => 0, 'compare' => '>', 'type' => 'NUMERIC', ], [ 'key' => '_featured', 'value' => 'yes', 'compare' => '=', ], ], ]; ``` A practical note: every extra meta JOIN is another scan of `wp_postmeta`. Two meta filters on a [large WooCommerce store](/en/woocommerce-performance-optimization-2026/) can stretch [response time](/en/services/core-web-vitals-audit/) far faster than three taxonomies, because `term_relationships` has a better index shape than the EAV model in postmeta. If you filter by the same key in many places (for example stock and featured), consider denormalizing into taxonomy attributes or an index table. Not because it is "best practice", but because EXPLAIN shows `Using where; Using temporary` on meta. ## How to speed up WP_Query without pagination By default, when the query has a `LIMIT`, `WP_Query` adds `SQL_CALC_FOUND_ROWS` and then runs `SELECT FOUND_ROWS()` to fill `$query->found_posts` and `$query->max_num_pages`. When you build a "related" widget, a shortcode with three cards or a sidebar block, you do not need pagination. ```php $args = [ 'post_type' => 'post', 'posts_per_page' => 5, 'no_found_rows' => true, 'update_post_meta_cache' => false, 'update_post_term_cache' => false, 'fields' => 'ids', ]; $ids = ( new WP_Query( $args ) )->posts; // array of int ``` What each flag does: - `no_found_rows => true`: skips the expensive count of all matches. With `SQL_CALC_FOUND_ROWS`, MySQL has to walk every matching row even when it returns only five; without it, MySQL can stop at the `LIMIT` when the order comes from an index. MySQL has deprecated `SQL_CALC_FOUND_ROWS` and `FOUND_ROWS()` since 8.0.17 ([MySQL manual](https://dev.mysql.com/doc/refman/8.0/en/information-functions.html#function_found-rows)). - `fields => 'ids'`: the SELECT returns IDs only. Ideal when you call `get_post()` selectively afterwards or build an ID map. Do not combine it with a loop that calls `the_title()` without loading the objects, or you get N+1. - `update_post_meta_cache => false`: skips bulk-loading meta into the object cache for the whole result. Turn it back on if the loop reads ACF or `get_post_meta`. - `update_post_term_cache => false`: the same for terms. Turn it off when you do not render categories and tags. `orderby => rand` looks tempting for "similar posts", but on large tables it generates `ORDER BY RAND()`, which sorts the entire result in memory. A better pattern: fetch a pool of IDs with `fields => ids` and `no_found_rows`, then use `array_rand` in PHP, or cache the randomized set for a few minutes in a transient or the object cache. ## Suppressing filters and avoiding query hooks overhead When third-party plugins hook into `posts_where`, `posts_join` or `posts_clauses`, secondary queries can inherit unexpected constraints, multilanguage conditions, or security checks meant strictly for the main loop. In custom background routines, CLI scripts, and micro-queries, you can isolate `WP_Query` by passing `'suppress_filters' => true`: ```php $clean_args = [ 'post_type' => 'product', 'posts_per_page' => 10, 'no_found_rows' => true, 'suppress_filters' => true, 'fields' => 'ids', ]; $clean_query = new WP_Query( $clean_args ); ``` Note that `get_posts()` sets `'suppress_filters' => true` by default, whereas `new WP_Query()` defaults to `false`. This distinction explains why identical arguments can yield different results depending on the caller. `suppress_filters` switches off the `posts_*` filters (`posts_where`, `posts_join`, `posts_clauses` and the rest), but not the `pre_get_posts` action, which core always fires. If a multilingual plugin scopes the language through those filters, the query returns posts in every language; check how your plugin filters before you turn it on. ## Slow meta_query and wp_postmeta indexes WordPress does not create an index on `(meta_key, meta_value)` that is useful for numeric filters on the value. The standard index on `meta_key` helps find rows for a given key; filtering and sorting by `meta_value` often ends in a filesort. Symptoms in Query Monitor: a long time on the main SELECT, `Using filesort`, a high `Rows examined`. Common traps: …[truncated, fetch the canonical URL for the full body]… --- ## WordPress conditional logic for taxonomies URL: https://wppoland.com/en/check-if-post-belongs-to-category-children/ Description: Stop writing messy if-statements. Learn the difference between in_category and has_term, how to handle recursive child categories efficiently, and optimize your conditional tags. Published: Thu May 03 Updated: Tue Oct 13 Type: guide Level: advanced Tags: taxonomy, php, logic, hierarchy Conditional logic in WordPress is not a pile of `if` statements scattered through `functions.php`. It is a contract with the main query: core decides the context of the HTTP request, the [conditional tags](https://developer.wordpress.org/themes/basics/conditional-tags/) read that context, and your code reacts. In 2026, with [block themes](/en/gutenberg-blocks-patterns-full-site-editing-guide/) and Full Site Editing (FSE), PHP still governs assets, capabilities, cache and every branch the site editor cannot express. This guide treats conditional logic as engineering: when `is_singular()` misleads you, when `in_the_loop()` fails outside the Loop, why `current_user_can()` and page cache do not mix, and how to isolate helpers you can test. Taxonomy (`in_category` vs `has_term`) comes at the end as a concrete case, not as the only subject. ## Where conditional tags read their state from Conditional tags do not inspect the URL by hand. After `parse_request` and `WP_Query`, the global `$wp_query` object holds flags (`is_single`, `is_page`, `is_front_page`, `is_category` and others). Functions such as `is_singular()` and `is_front_page()` are wrappers around those flags. Practical consequence: call a conditional tag too early, before `wp` / `template_redirect`, and the result is undefined or false. The handbook says it plainly: a conditional tag placed directly in `functions.php` will not work, it has to sit inside a function hooked to a later action or filter. In plugins, the safe places for template branches and enqueues are `wp_enqueue_scripts`, `template_redirect` or later hooks documented in [Hooks](https://developer.wordpress.org/plugins/hooks/). Another consequence: a secondary `WP_Query` (widget, recent posts block, shortcode) does **not** change the flags of the main query. `is_singular()` keeps describing the requested page, not the post the widget is iterating over. For data about a specific post, pass the ID or the `WP_Post` object to the post and term APIs. ## Common mistakes with is_singular and is_front_page `is_singular()` returns true for a single post, page or CPT. It does not distinguish the type. In WooCommerce stores `is_singular()` is true on `product`, which leads many themes to load blog CSS on the product page. Prefer `is_singular( 'post' )`, `is_page()`, or `is_singular( array( 'post', 'page' ) )` with an explicit list. `is_front_page()` and `is_home()` remain the classic confusion: - With "Your latest posts" under Settings > Reading, the homepage is both `is_front_page()` and `is_home()`. - With a static page as the homepage and another page as the "Posts page", the homepage is only `is_front_page()`; the posts feed is `is_home()` and **not** `is_front_page()`. Code that runs `if ( is_home() )` to "show the homepage hero" breaks the moment the client switches Reading to a static page. The stable pattern for the public homepage is `is_front_page()`. For the blog archive, use `is_home() && ! is_front_page()`. A production case from Gdynia: a theme loaded its slider only under `is_home()`. After the homepage moved to a block-built page, the slider vanished and the `/blog/` archive inherited the carousel JavaScript. One line, `is_front_page()`, would have been enough. `is_singular()` is also false on requests that look like "a page" to the user but are not singular in the query: search (`is_search()`), 404 (`is_404()`), and REST requests, which do not go through the theme's main query. Before assuming "there is a current post", check `get_queried_object()` and its type. ## How to use in_the_loop and has_term outside the Loop Functions such as `the_title()`, `the_content()` and several post conditionals (`in_category()` without an ID) depend on the global post set by the Loop. `in_the_loop()` tells you whether the code runs between `while ( have_posts() ) : the_post();` and the end of that Loop. Outside the Loop, in `header.php`, a `body_class` filter or `wp_footer`, `in_category( 'news' )` without its second argument reads the global post, which can be the last post of the previous query, a post from a widget, or `null`. Typical symptom: the "news category" CSS class shows up on the archive, or the legal notice appears only on the last article of the listing. Safe pattern: ```php function wppoland_is_news_singular(): bool { if ( ! is_singular( 'post' ) ) { return false; } $post_id = (int) get_queried_object_id(); if ( $post_id <= 0 ) { return false; } return has_term( 'news', 'category', $post_id ); } ``` Use `get_queried_object_id()` for the requested document; use the post ID inside a secondary Loop when you are iterating results. Do not mix the two. `in_the_loop()` helps you decide whether you can trust the global post. If you are outside the Loop and need data about the current document, do not "enter" the Loop artificially just to read meta: read it by the main query's ID. For code that runs with no request context at all, such as a background job or a REST endpoint, `is_object_in_term( $object_id, $taxonomy, $terms )` takes the object ID as its first argument and does not need a global post. ## current_user_can and logged-in branches `current_user_can( 'edit_posts' )` and friends read the current user's session and capabilities. They are the correct API for admin UI, edit shortcuts and editor-only content. Three rules that prevent incidents: 1. **Never** mix different HTML for anonymous and logged-in visitors in the same document if that document is served from a shared page cache. The edge or the cache plugin stores the first visitor's variant. An editor sees the "Edit" button; the next anonymous visitor receives the same HTML. 2. For logged-in branches, use cache-bypass cookies (the default in most page cache plugins), ESI, or serve the branch only through authenticated JavaScript/REST after the static HTML. 3. Capabilities are not roles. Test `current_user_can( 'manage_options' )`, not `current_user_can( 'administrator' )`: the second is not the API's stable contract. In classic themes a frequent pattern is hiding the admin bar from subscribers. Do it with a filter on `show_admin_bar`, not with conditional CSS in cached HTML: ```php add_filter( 'show_admin_bar', static function ( $show ) { if ( is_user_logged_in() && ! current_user_can( 'edit_posts' ) ) { return false; } return $show; } ); ``` The filter runs in the PHP request; the anonymous page cache never sees it because the logged-in user is already outside that cache. ## When to use the template hierarchy and when PHP conditionals The [template hierarchy](https://developer.wordpress.org/themes/basics/template-hierarchy/) resolves files (`single-product.php`, `category-news.php`, `front-page.php`). Conditional tags resolve branches **inside** a shared file (`header.php`, `functions.php`, a partial). Prefer the hierarchy when the markup diverges structurally: a CPT with its own layout deserves `single-{post_type}.php` (or the block theme equivalent: a dedicated HTML template). Prefer PHP conditionals when the difference is small: a notice, an enqueue, a class on `body`. Anti-pattern: a single generic `page.php` with twenty chained `if ( is_page( 'contact' ) )`. That duplicates the hierarchy in PHP, makes code review harder and stops FSE (or a child theme) from replacing just one template. Move pages with distinct markup into their own templates; leave conditionals for fine variation. Rule of thumb: if the branch fits a file name in the hierarchy, use the file. If the branch depends on a capability, cookie, A/B test or feature flag, use PHP (or a block with server-side logic from a plugin). ## What are the limits of FSE in block themes FSE moves templates and template parts into HTML in the site editor. It does not remove conditional tags. The site editor covers visual variation by template type (singular, archive, 404). It does not reliably cover: - Conditional enqueue of heavy scripts (maps, calculators, players). - Branches by capability (`current_user_can`). - Recursive taxonomy logic (parent includes children). - ERP or WooCommerce integrations that depend on product meta in the current query. - Anything that needs a secondary `WP_Query` with dynamic arguments. Block themes still load `functions.php`. That is where `wp_enqueue_scripts`, `body_class` filters and term helpers live. Blocks with "variations" in the editor do not replace `has_term()` when the business rule is "if the product sits in any descendant of `clothing`". Operational boundary: markup only in the editor, runtime decisions in PHP. Mixing the two layers without a clear contract (for example a block pattern that assumes `is_front_page()` and a plugin that alters the main query) produces regressions that are hard to reproduce on staging. ## Taxonomies: in_category versus has_term `in_category()` is a historical shortcut for the `category` taxonomy. It does not cover `product_cat`, `post_tag` or taxonomies registered with `register_taxonomy()`. Its [reference page](https://developer.wordpress.org/reference/functions/in_category/) lists two parameters: the category (ID, name, slug or an array of them) and an optional post. `has_term( $term, $taxonomy, $post = null )` is the general API. For new code, prefer `has_term()` even for native categories: the signature is explicit and the same helper serves WooCommerce and CPTs. Native checks are an **exact match**. A post only in `apple` does not satisfy `in_category( 'fruit' )` just because `apple` is a child of `fruit`. Core offers no "is in this branch of the tree" in a single call. Use `get_term_children()` (and object cache) in a helper: ```php function wppoland_post_in_term_branch( int $post_id, string $term_slug, string $taxonomy ): bool { $term = get_term_by( 'slug', $term_slug, $taxonomy ); if ( ! $term instanceof WP_Term ) { return false; } if ( has_term( (int) $term->term_id, $taxonomy, $post_id ) ) { return true; } $children = get_term_children( (int) $term->term_id, $taxonomy ); if ( is_wp_error( $children ) || $children === [] ) { return false; } return has_term( $children, $taxonomy, $post_id ); } ``` WooCommerce trap: `is_product_category()` describes the product category **archive**, not the product in the Loop. WooCommerce has its own page conditionals (`is_product()`, `is_shop()`, `is_product_category()`), and all of them describe the request. Inside a product loop use `has_term( $slug, 'product_cat', $post_id )`. Learn more about [checking custom taxonomy terms](/en/check-if-post-is-in-taxonomy-term/) and [showing the current and parent category](/en/display-current-and-parent-category/). ## Page cache with logged-in users in WordPress Page cache (nginx `fastcgi_cache`, Cloudflare, full-page cache plugins) serves ready HTML to anonymous visitors. Any `if ( is_user_logged_in() )` or `current_user_can()` baked into that HTML is a UI leak or, in the other direction, missing content. Patterns that work: - **Separate**: identical public HTML for all anonymous visitors; logged-in UI through an authenticated endpoint or an uncached fragment. - **Bypass**: session cookies make the proxy skip the cache for logged-in users (cost: lower hit ratio). - **Do not condition** critical homepage assets on `is_user_logged_in()` in the PHP of the cached document. "Safe" conditionals under anonymous page cache: `is_front_page()`, `is_singular( 'post' )`, `has_term( $slug, 'category', $queried_id )`, everything that depends only on the public URL and query. "Dangerous" conditionals in the same document: capabilities, user preferences, IP geolocation without a vary, A/B tests without a vary cookie. On projects with edge cache in the EU, document the vary matrix (cookie, header) next to the helper. Without it, the next "promo bar for customers" plugin goes back to sharing HTML. ## How to test conditional tags with PHPUnit …[truncated, fetch the canonical URL for the full body]… --- ## Factors affecting outgoing link value in SEO URL: https://wppoland.com/en/factors-affecting-outgoing-link-value-seo/ Description: Learn how search engines evaluate outgoing links. Covers PageRank math, semantic relevance, link audits, and technical attributes. Published: Thu Jul 10 Updated: Tue Oct 13 Type: guide Level: advanced Tags: outbound-links, pagerank, search-visibility, crawling <div id="introduction"> In search engine optimization, outbound links are the connective tissue of the web. By linking to external domains, a page shows which sources it builds on and gives readers a way to check its claims. Outgoing links get less attention in SEO than incoming ones, yet they shape the context in which a search engine and a reader place your page. This guide provides a developer's overview of outbound link valuation, exploring the PageRank formula, anchor text, link position, `rel` attributes, Google's link spam policies, link injection [security audits](/en/eu-compliance-audit-wordpress/), and automated validation tooling. For each factor it says plainly what Google documents, what follows from the original PageRank paper or from Google patents, and what is industry practice only. </div> Learn more about our [SEO and visibility services](/en/wordpress-ai-search-readiness-geo-aeo/) to optimize your content's technical architecture. --- ## Do outbound links help SEO ### What outbound links are Outbound links, also called external links, are hyperlinks that lead from your page to other domains. Many site owners think only about earning backlinks, while deliberate outbound linking helps a site become a useful resource in its niche. Google does not treat linking out as a risk in itself. Its link documentation says: > "Linking to other sites isn't something to be scared of; in fact, using external links can help establish trustworthiness (for example, citing your sources)." > > Google Search Central, [Link best practices for Google](https://developers.google.com/search/docs/crawling-indexing/links-crawlable) A link to an authoritative source works like a footnote in a research paper: the reader can check where a claim comes from, and the search engine sees the context in which you place your content. ### What Google documents about links Early SEO focused on the number of links, which led to link farms and other manipulative tactics. Today Google publishes a handful of concrete rules about links, and only these can be treated as confirmed: - **A link must be an `<a>` element with an `href` attribute.** Google writes that it can generally crawl a link only if it is an HTML `<a>` element, and that it cannot reliably extract a URL from an `<a>` element without `href`. - **Anchor text should be descriptive.** According to Google, good anchor text is descriptive, reasonably concise, and relevant both to the page it sits on and to the page it links to. - **Keyword-stuffed anchors are spam.** The same page reminds readers that keyword stuffing violates Google's spam policies. - **Images as links.** For image links, Google uses the `alt` attribute of the `img` element as the anchor text. - **Nofollow only where you do not trust the source.** Google recommends `nofollow` only for sources you do not trust, not for every external link. - **Number of links.** Google writes that there is no magic ideal number of links on a page, and that if you think you have too many, you probably do. Anything beyond these points, for example domain age, link freshness or clicks as a ranking factor, has no confirmation in Google's documentation. Some of these topics appear in patents, covered below, but a patent describes a possible system and does not confirm that it is in use. --- ## How PageRank splits value across outbound links The foundational theory of outbound link value originates from Google's original **PageRank** algorithm, described by Sergey Brin and Larry Page in the 1998 paper "The Anatomy of a Large-Scale Hypertextual Web Search Engine". PageRank models user browsing behavior, representing links as votes of confidence. ### PageRank formula and damping factor The mathematical representation of PageRank in the 1998 paper is defined as follows: $$PR(A) = (1-d) + d \left( \frac{PR(T_1)}{C(T_1)} + \dots + \frac{PR(T_n)}{C(T_n)} \right)$$ Where: - $PR(A)$ is the PageRank of page $A$. - $d$ is the **damping factor**. The authors write that they usually set it to **0.85**. In the usual reading of the model, it governs how often the surfer keeps following links rather than jumping to a random page. - $PR(T_i)$ is the PageRank of page $T_i$ linking to page $A$. - $C(T_i)$ is the total number of **outgoing links** on page $T_i$. Two things follow from the formula, and both still come up in every discussion about links: 1. **The value passed by one link depends on the PageRank of the linking page.** A link from a page that nobody links to passes little. 2. **A page's value is divided by the number of its outgoing links.** The more links on a page, the smaller the share each one receives. The authors explain the formula with a "random surfer" model: a surfer who starts on a random page, keeps clicking links, never hits the back button, eventually gets bored and starts again on another random page. The probability that the surfer lands on a given page is its PageRank. The same paper describes a second mechanism that matters for outbound links: the text of a link is associated with the page it points to, not only with the page it sits on. The authors write that they use anchor text propagation mostly because it helps provide better quality results. This is why the anchor counts as a description of the page you link to. ### How PageRank is computed with power iteration In a web graph containing billions of pages, PageRank is computed iteratively over a stochastic link transition probability matrix $M$ using power iteration methods. Later literature on PageRank computation usually writes the normalised variant below, in which the random jump term is $(1-d)/N$, so that the scores form a probability distribution. The 1998 paper uses $(1-d)$ without dividing by $N$. Let $v$ be the PageRank distribution vector across all web nodes: $$v^{(k+1)} = d M v^{(k)} + \frac{1-d}{N} e$$ Where: - $N$ represents the total number of pages in the graph. - $e$ is a vector of all ones, modeling the uniform probability of a random jump. - **Dangling nodes**: Nodes with no outbound links ($C(T_i) = 0$) act as "sinks" that drain PageRank from the system. A common treatment in this literature replaces the rows for dangling nodes with uniform probabilities ($1/N$), distributing their PageRank evenly across the entire network. This formulation shows that the PageRank a page passes on is divided among all its outgoing links: ``` [ Page A (High PageRank) ] | +-----+-----+ (Outbound Links) | | [ Link 1 ] [ Link 2 ] ... [ Link C ] (share) (share) (share) ``` As the number of outgoing links ($C$) increases, the share passed to each target decreases. The 1998 formula is not a description of today's ranking. Google does not publish current PageRank values, and ranking relies on many signals. The formula still explains well why a page with hundreds of links is a poor place to cite sources. --- ## How to optimize outbound anchor text distribution ### What anchor text is Anchor text is the visible, clickable text of a hyperlink. In the PageRank paper, anchor text is associated with the target page, so it tells the search engine what the page you link to is about. Google's documentation adds a practical test: read the anchor text on its own, out of context, and check whether it is specific enough to make sense. ### Types of anchor text classifications The SEO industry usually splits anchors into several types. These names come from practice, not from Google's documentation: - **Exact match**: Anchor matches the exact target keyword (e.g., "WordPress [malware](/en/security-standards-for-corporate-cms-2026-comprehensive-guide/) cleanup"). Google's spam policies list links with optimized anchor text in articles, guest posts, advertorials and press releases as an example of link spam. - **Partial match**: Anchor contains the target keyword alongside other words (e.g., `"learn how to execute WordPress malware cleanup"`). - **Branded**: Anchor contains the name of the brand or site (e.g., `"WPPoland"`). It describes the target well when you link to a company's home page. - **Naked URL**: The anchor is the raw web link (e.g., `"https://wppoland.com/en/"`). It works in a list of sources, but reads poorly inside running text. - **Generic**: Standard calls-to-action (e.g., `"click here"`, `"website"`, `"source"`). These fail Google's test, because out of context they say nothing. - **Variants and synonyms**: Words related in meaning to the topic of the target page. The industry sometimes calls them "LSI" anchors, although Google describes no such category. ### Is there an optimal anchor text distribution There is no official ratio of anchor types. The percentage tables that circulate in the industry do not come from any Google source. The only things Google states directly are that anchor text should be descriptive, concise and relevant, and that keyword stuffing is spam. For outbound links this comes down to one rule: write the sentence as you would without thinking about SEO, then turn into a link the part of it that best describes the target page. ### How to audit anchor text distribution in WordPress To monitor anchor text density across your site's posts, add this validation script to see how often a single phrase repeats as an anchor: ```php declare(strict_types=1); namespace WPPoland\SEO\AnchorAudit; /** * Audits anchor text distributions within post content. */ function audit_post_anchor_text_ratios( int $post_id ): array { $content = get_post_field( 'post_content', $post_id ); if ( empty( $content ) ) { return []; } $dom = new \DOMDocument(); @$dom->loadHTML( '<?xml encoding="UTF-8">' . $content ); $anchors = $dom->getElementsByTagName( 'a' ); $total_links = $anchors->length; if ( 0 === $total_links ) { return []; } $exact_matches = 0; $target_keyword = 'wordpress speed optimization'; // Example target keyword foreach ( $anchors as $anchor ) { $text = trim( strtolower( $anchor->textContent ) ); if ( $text === $target_keyword ) { $exact_matches++; } } $ratio = ( $exact_matches / $total_links ) * 100; return [ 'total_links' => $total_links, 'exact_count' => $exact_matches, 'ratio' => $ratio, // 15% is an arbitrary internal review threshold, not a Google number. 'flagged' => $ratio > 15.0 ]; } ``` --- ## Why outbound link position and layout prominence matter ### Does link position in the HTML source matter A popular piece of advice says that a link placed higher in the source code passes more value. Google's documentation does not confirm it. Google only requires the anchor text to sit between crawlable `<a>` tags. Order in the HTML source is not described as a factor. Position in the visible layout is a different matter, because a Google patent describes it. That is a feature of the layout the user sees, not of the order in the source. ### What link features the reasonable surfer patent describes Patent US 7716225 B1, "Ranking documents based on user behavior and/or feature data", was filed by Google in June 2004 and granted in May 2010. Its inventors are Jeffrey A. Dean, Corin Anderson and Alexis Battle. The patent describes a system that assigns different weights to links based on their features and on data about how users actually click. The industry calls it the "reasonable surfer" model, in contrast to the random surfer of the original PageRank. Among the example link features, the patent lists: …[truncated, fetch the canonical URL for the full body]… --- ## Headless WordPress sitemap and canonical: one source of truth, served from the front URL: https://wppoland.com/en/headless-wordpress-sitemap-canonical/ Description: In a headless WordPress build, the sitemap and the canonical URL must be rendered by the front end, not the WordPress origin. This is the specific pattern that prevents two sitemaps and two canonical URLs from competing. Published: Tue Apr 14 Updated: Tue Oct 13 Type: guide Level: intermediate Tags: headless-wordpress, sitemap, canonical, astro, nextjs, schema-org # Headless WordPress sitemap and canonical: one source of truth, served from the front Sitemap inclusion is a weak canonical signal; redirects and rel=canonical are stronger signals. Related implementation context: [SEO patterns for headless WordPress](/en/seo-patterns-for-headless-wordpress/), [break silently](/en/xml-sitemap-mistakes/). This article makes the pattern concrete. It assumes the architectural decision ([Astro or Next.js](/en/nextjs-astro-migration/) per [the decision matrix](/en/headless-wordpress-nextjs-vs-astro-2026/)) is already made. ## What is the headless sitemap and canonical pattern in one paragraph Generate the sitemap from a complete public route inventory and render one canonical in the HTML head. The inventory may be produced by the front or by a correctly configured backend. Keep all active sitemap endpoints consistent; multiple child maps are valid. ## Why do headless WordPress sites end up with two sitemaps WordPress has provided core sitemaps since version 5.5. Their availability depends on configuration and filters, and SEO plugins can disable the core provider. Audit the actual endpoints; three simultaneous sitemap generators are not inevitable. 1. `/wp-sitemap.xml` from WordPress core. 2. `/sitemap_index.xml` from Yoast or Rank Math. 3. `/sitemap.xml` from the front-end framework. Several sitemaps may coexist without affecting indexing adversely. Conflicting public URL inventories need correction, but Google does not choose indexed URLs merely according to which sitemap it reads first. Use the front-end public URL inventory for all active sitemap endpoints. Disable an unnecessary origin generator or redirect its XML endpoint when appropriate. More than one child sitemap can respond 200 as part of a sitemap index. ## How do you build the front-end sitemap in headless WordPress Two real options for an Astro or Next.js front: **Build-time generation.** The front-end build pulls every published post, page, and term URL from the WordPress origin during the build, sorts them, and emits the XML. This works for sites with predictable publishing cadence (most sites). Cache invalidation is handled by triggering a rebuild on publish. **On-demand at the edge.** A Cloudflare Worker route generates the sitemap on request, reading from a cached list of URLs that the WordPress origin pushes via webhook on publish. This works for sites with high publish frequency where rebuild latency would be a problem. We default to build-time generation. The Worker pattern is reserved for sites publishing more than a few times per hour. ## How should the canonical URL be rendered on a headless front end The canonical URL must be in the HTML head, in the initial server response, before any client-side script runs. The pattern: ```html <link rel="canonical" href="https://example.com/headless-wordpress-for-woocommerce/" /> ``` Three rules. Render the canonical in the initial HTML head using the layout or framework metadata API. Google supports JavaScript-generated canonicals but recommends keeping the signal clear and avoiding later changes. Initial output also makes release tests deterministic. Resolve SEO metadata against the public route map. Yoast provides a documented REST API; other plugins require their own supported integration. Do not assume their canonical output already uses the public headless URLs. **Three, self-referential by default.** Every URL declares itself as canonical unless there is an explicit reason to point elsewhere (paginated archives, parameterised filtered URLs, syndicated content). When pointing elsewhere, the destination canonical points back at itself. ## Which sitemap and canonical edge cases break headless SEO Filtered URLs need an explicit indexing policy. Use canonical for genuinely duplicate content and noindex when exclusion is intended; do not apply both indiscriminately to every filter. ## How do you validate sitemap and canonical before go-live Two checks we run on every headless WordPress build: **Sitemap diff.** Generate the new sitemap, compare against the [legacy WordPress sitemap](/en/modernizing-legacy-wordpress-codebases-2026-strategy-guide/) by URL set. Anything missing from the new one is a content gap. Anything new is a regression suspect (often a draft or a private post leaking). **Canonical sample.** For 50 high-traffic pages, request the URL on the new front and assert the canonical in HTML head matches the URL itself (or matches the expected target if intentionally cross-canonical). One mismatch is a bug; ten mismatches is a pattern that needs the front-end build re-checked. Both checks run in CI. A new build that fails either one does not deploy. ## Related guides on headless WordPress SEO Anchored to the [SEO patterns for headless WordPress](/en/seo-patterns-for-headless-wordpress/) checklist. Pairs with the [Headless WordPress service pillar](/en/services/headless-wordpress/) and the [Next.js vs Astro decision matrix](/en/headless-wordpress-nextjs-vs-astro-2026/) for the broader build-time decisions. ## Define a public URL contract before fetching metadata WordPress stores content identifiers and its own permalinks. A headless front can expose a different language prefix, category structure or trailing-slash policy. Write down the mapping from post ID and locale to the public URL before producing a sitemap. Treat the mapping as application configuration. Replacing the origin hostname with the public hostname is insufficient when the paths also change. A page under a nested WordPress parent may have a flat public route, while a product can have a translated category segment. Use the same resolver for internal links, sitemap entries, canonical tags, hreflang alternatives and structured-data identifiers. This is an implementation recommendation that prevents separate functions gradually producing different addresses. Keep editorial canonical overrides explicit: an override may intentionally reference a partner's syndicated article, so a universal hostname replacement would silently change its meaning. Validate allowed external destinations separately from normal self-canonical routes. Reject preview hosts, local development hosts and malformed schemes before publishing the HTML. The [Yoast REST API](https://developer.yoast.com/customization/apis/rest-api/) exposes SEO output associated with WordPress URLs. Fetching that output does not make its URLs correct for a different front-end route map. Decide whether the front consumes structured metadata and builds its own head or accepts sanitised output from an integration. Avoid emitting an entire SEO head and then adding a second canonical from the layout. Inspect the final response because a correct data object can still become duplicate markup when two components render it. ## Build an indexable inventory from a complete content snapshot A sitemap generator must read every required API page, not only the first response. WordPress collections can be paginated, and terms need their own inventory when the front publishes useful archive pages. Track the number of records fetched and compare it with an expected range from the previous successful build. If the origin times out halfway through pagination, fail the release or retain the previous complete artifact. Publishing a shortened sitemap as though the fetch succeeded hides an integration failure. The inventory should contain only routes that actually exist on the public front. A published WordPress attachment, author or category does not automatically have a headless counterpart. Include a route after its template, public URL and indexing policy are resolved. Exclude drafts, authenticated pages, internal searches, redirect sources and URLs deliberately marked noindex. Keep a rejection reason with the record in the build report so an editor can distinguish a policy exclusion from missing content. Google's [sitemap guidance](https://developers.google.com/search/docs/crawling-indexing/sitemaps/build-sitemap) defines a limit of 50,000 URLs or 50 MB uncompressed per sitemap. Split larger inventories and expose them through a sitemap index. Several child sitemaps are normal and can also help analyse different content collections. Use fully qualified public URLs, encode XML correctly and preserve significant URL characters. A raw ampersand in a location element can invalidate XML even when the browser accepts the corresponding address. Set lastmod from a meaningful content or metadata change when a reliable timestamp exists. A build timestamp is the deployment time, not evidence that every article changed. Rewriting every lastmod on every deployment removes its usefulness for identifying edited pages. If an upstream importer changes only technical bookkeeping, decide whether that update should alter the public modification date. Document the decision and apply it consistently across sitemap entries and article metadata. ## Keep removal, canonicalisation and crawl control separate A canonical identifies the preferred member of a set of duplicate or very similar pages. It does not redirect visitors and does not guarantee that Google selects that member. A permanent redirect is appropriate when an old public URL has been replaced. A genuine deletion without an equivalent destination can return 404 or 410. Redirecting every removed article to the homepage prevents the migration report from showing which content was actually lost. Use noindex when a publicly accessible page must be excluded from search results. Google must be able to crawl the page to read the directive, as explained in its [noindex documentation](https://developers.google.com/search/docs/crawling-indexing/block-indexing). Blocking that same URL in robots.txt can prevent the directive from being seen. A robots disallow rule controls crawling and is not a substitute for access control. Protect private WordPress administration and preview data with authentication rather than relying on crawler instructions. For an origin that previously served public articles, choose between redirects to the equivalent front-end URLs and continued public origin pages with a deliberate canonical policy. Redirecting the sitemap file alone does not redirect the articles listed inside it. Check individual legacy URLs and their internal links. If the origin exists only to serve the content API, disable unnecessary public templates or restrict them without blocking the API endpoints the front legitimately needs. ## Handle pagination and language variants as separate routes Each useful archive page has its own contents and normally its own self-referencing canonical. Google no longer uses rel=prev and rel=next to identify pagination, according to its [pagination documentation](https://developers.google.com/search/docs/specialty/ecommerce/pagination-and-incremental-page-loading). Provide crawlable anchor links to subsequent pages instead of a button that only appends client-side results. Test the final archive page and requests beyond the valid range; an empty page returning 200 can create unnecessary routes. Translate the route map alongside the content. A German article should not canonicalise to its English sibling merely because the English version was the source text. Include reciprocal hreflang links only for published equivalents, and use the corresponding canonical public address for each language. If one translation is removed, update the other siblings and the language sitemap together. Returning a generic language homepage as the missing article's alternate gives the annotation a different meaning. …[truncated, fetch the canonical URL for the full body]… ---

# wppoland.com, full markdown digest > Curated long-form Markdown for retrieval-augmented LLM agents. Includes the canonical EN service pillars and top EN blog posts. For the short index see /llms.txt. For other locales, fetch any URL with `Accept: text/markdown` content negotiation. Source of truth: https://github.com/wppoland/wppoland-new Generated at build time, 61 pillars + 60 blog posts. --- # Service pillars ## AI-built website rescue and remediation URL: https://wppoland.com/en/ai-built-website-rescue/ Description: Audit and repair for WordPress and WooCommerce sites built or heavily modified by AI. Senior review of vibe-coded plugins, security holes, broken flows, and AI-slop content. Published: Sat Jun 20 Updated: Fri Jul 10 Type: guide Level: advanced ## What AI-built WordPress site rescue covers

AI can build a WordPress or WooCommerce site fast. It cannot take responsibility when that site leaks data, breaks checkout, or quietly fills Google with duplicate pages. This service is the senior cleanup after the AI: we audit what was generated, find what is unsafe or broken, and fix it, with a human accountable for every change.

This is not the same as our general [WordPress repair and technical support](/en/wordpress-repair-service-technical-support/) or a standard [WordPress security audit](/en/wordpress-security-audit/). Those assume a site built by people. Here the failure patterns are specific to generated code and content, and the remediation is different. ## How AI-built sites tend to break The damage clusters into a few recognisable patterns. A typical case is a WooCommerce store where an AI-generated checkout customisation skipped nonce verification, so the cart could be manipulated through a forged request, and nobody noticed until chargebacks started. Another is a marketing site where an assistant generated forty near-identical service pages that compete for the same query, so none of them rank and the whole domain looks thin to Google. Other recurring failures: - Generated PHP that calls functions that do not exist, or that were hallucinated from a different plugin's API. - Admin-ajax and REST endpoints registered without a capability or nonce check. - Unsanitised form input written straight into the database or echoed back into the page. - Plugin sprawl: ten plugins installed to solve a problem one line of code would have handled, dragging Time to First Byte over a second. - Content with confident but wrong facts, fabricated statistics, and invented client names. - Migrations the AI "finished" that silently dropped redirects, breaking indexed URLs. ## Symptoms of a broken AI-built site and their causes Not every broken AI-built site needs the same response. The symptom usually points to whether a targeted rescue is enough or the foundation should be replaced. Use this table as a first-pass triage before you commit budget or downtime. | Symptom | Likely cause | First action | | --- | --- | --- | | Checkout or cart fails intermittently | AI-wired WooCommerce hooks, missing nonce on cart mutations | Pause paid traffic; run a functional audit on the checkout path | | Subscriber or anonymous user can trigger admin AJAX | Missing `current_user_can()` on a `wp_ajax` handler | Security pass on generated PHP; see [auditing AI-generated plugin code](/en/auditing-ai-generated-wordpress-plugin-code/) | | Scanner flags critical CVEs on common plugins | Outdated versions installed during a fast AI-assisted build | Run a [WordPress security audit](/en/wordpress-security-audit/) and patch or remove exposed plugins | | Forty near-identical service pages, none rank | AI content cannibalisation and thin duplication | Content inventory; consolidate or noindex duplicates | | White screen or fatal error after a small change | Hallucinated function calls in generated custom code | Code inventory against developer.wordpress.org; scope rescue vs rewrite | | Time to First Byte above one second on a simple page | Plugin sprawl from "install a plugin for that" answers | Performance strip-down; measure before adding more tooling | | Form saves but stored data looks corrupted or executable | Unsanitised `$_POST` written straight to options or post meta | Plugin code audit; treat as active XSS or injection risk | | REST or admin-ajax endpoint returns data it should not | Missing `permission_callback` or nonce on custom routes | Endpoint audit; block public access until fixed | | Owner wants to keep using AI in the build | No review gate, no version control on generated output | Rescue first, then guardrails; see remediation stages below | If most rows point to isolated, fixable gaps in otherwise sound WordPress core usage, rescue is usually the cheaper path. If hallucinated APIs, missing security primitives, and plugin sprawl show up together across custom code and content, plan for a partial or full rebuild and say so before repair work starts. ## What an audit of an AI-built website checks The audit inventories everything the AI touched and triages it by two axes: security risk and revenue risk. We separate the code AI wrote, the plugins it chose, and the content it produced, because each needs a different fix. You get a written split of what is safe to keep, what must be rewritten, and what should be removed, with the reasoning behind each call. ## Remediation stages for an AI-built website Remediation follows a fixed order so security and revenue risks close before cosmetic work. Stages can overlap in calendar time, but we do not skip ahead to performance tuning while checkout is still broken or a public endpoint still leaks data. | Stage | Focus | Deliverable | | --- | --- | --- | | 1. Inventory and triage | Map every AI touchpoint: custom PHP, plugin choices, content, migrations | Written keep / rewrite / remove split with reasoning | | 2. Security pass | Nonces, capabilities, sanitisation, exposed AJAX and REST routes | Patched or removed vulnerable handlers; [plugin code audit](/en/auditing-ai-generated-wordpress-plugin-code/) findings closed | | 3. Functional repair | Checkout, forms, CRM and payment integrations | Broken user flows restored and regression-checked | | 4. Content remediation | Duplicate pages, hallucinated facts, thin AI filler | Consolidated pages that can rank; corrected or removed false claims | | 5. Performance recovery | Plugin bloat, render-blocking assets, cache misconfiguration | Core Web Vitals back in range on key templates | | 6. Guardrails | Version control, staging workflow, review checklist for future AI use | Short runbook so the next prompt does not reopen the same holes | Emergency items (active exploit, broken checkout during a campaign, legal or compliance exposure) jump the queue inside stage 2 or 3 regardless of where the rest of the site sits in the table. ## Common security gaps in AI-generated code Generated WordPress code passes the "it runs" test while failing the "it is safe" test. We test directly for the gaps that matter: missing `wp_verify_nonce` and `current_user_can` checks, input that reaches the database without `sanitize_*` or prepared statements, output that skips `esc_*`, PHP files reachable without an `ABSPATH` guard, and endpoints exposed without authorisation. The failure patterns repeat often enough that we published a diagnostic walkthrough in [auditing AI-generated WordPress plugin code](/en/auditing-ai-generated-wordpress-plugin-code/). Where the security surface is large, this connects to a full [WordPress security audit](/en/wordpress-security-audit/). We documented the real CVE patterns these stacks carry in [outdated-plugin CVEs](/en/wordpress-security-audit-outdated-plugins-cve-2026/). ## How to clean up AI-generated content A site built with AI usually has an AI-content problem too. We deduplicate pages that cannibalise each other, correct hallucinated facts and round-number fake statistics, and consolidate thin pages into ones that earn citations. This is the same discipline behind [GEO and LLMO optimisation](/en/geo-llmo-optimization/): content that is accurate and distinct, not generated filler. ## How to fix performance on an AI-built website AI tends to solve problems by adding plugins. We reverse that: remove the bloat, replace plugin stacks with targeted code, and bring Core Web Vitals back into range. The dedicated [Core Web Vitals rescue for AI-built WordPress sites](/en/core-web-vitals-rescue-ai-built-wordpress/) page walks through the staged teardown, measurement checklist, and the anonymised case where median uncached TTFB dropped from 1.47 s to 0.68 s after cutting 38 plugins to 21. See [plugin sprawl after an AI build](/en/plugin-sprawl-ai-wordpress-build/) for the full diagnostic and [AI-slop content cleanup](/en/ai-slop-content-cleanup-wordpress/) when hallucinated facts need editorial triage. For a formal audit scope, the [Core Web Vitals audit](/en/services/core-web-vitals-audit/) service covers the same metrics with a written backlog. ## Should you rescue or rebuild an AI-built website After the audit you get an honest recommendation. If most of the AI output is salvageable, a targeted rescue is the cheapest path. If the foundation is unsound, we scope a rebuild instead of patching forever. When rebuild is the right call, our [agency rescue case study](/en/case-study-astro-migration-agency-rescue-2026/) documents a full stack migration where load time went from 12 s to 0.3 s after a bad agency delivery. And if you want to keep using AI in the build, but safely, with a human gate, that is exactly what our [AI implementation for companies](/en/services/ai-implementation/) covers: agents and tooling with version control, tests, and review built in. ## What you get A working, accountable site: insecure generated code rewritten, broken flows repaired, AI-slop content cleaned, performance restored, and a short guardrails document so the next round of AI assistance does not reopen the same holes. Every change is reviewed by a senior engineer, not applied autonomously. ## Related services - [Auditing AI-generated WordPress plugin code](/en/auditing-ai-generated-wordpress-plugin-code/), Diagnostic patterns for vibe-coded PHP before you ship - [WordPress security audit](/en/wordpress-security-audit/), Deep security pass for high-risk generated code - [WordPress repair and technical support](/en/wordpress-repair-service-technical-support/), Ongoing support after the rescue - [AI implementation for companies](/en/services/ai-implementation/), Using AI in the build safely, with human gates - [Core Web Vitals rescue for AI-built sites](/en/core-web-vitals-rescue-ai-built-wordpress/), Staged performance recovery after AI plugin sprawl - [Core Web Vitals audit](/en/services/core-web-vitals-audit/), Formal audit with written backlog - [Agency rescue case study](/en/case-study-astro-migration-agency-rescue-2026/), Full rebuild when rescue alone is not enough - [GEO and LLMO optimisation](/en/geo-llmo-optimization/), Turning cleaned content into citations Pricing is individual and scoped after the audit. [Contact us](/en/contact/) with the site and a short note on how it was built. --- ## AMP for WordPress, speed and Core Web Vitals URL: https://wppoland.com/en/amp-accelerated-mobile-pages-en/ Description: Make your WordPress site fast with AMP. Accelerated Mobile Pages implementation for better Core Web Vitals, mobile speed optimization, and improved user experience. Published: Sun Jan 01 Updated: Sat Jan 31 Type: guide Level: advanced

## What is AMP service? AMP (Accelerated Mobile Pages) implementation service makes your WordPress site load instantly on mobile devices. With scope agreed individually, we deliver: - **AMP Implementation** - Official AMP plugin setup with three modes (Standard, Transitional, Reader) - **Core Web Vitals Optimization** - Achieve sub-1-second LCP, optimal INP, and zero CLS - **Schema.org Markup** - Structured data for Top Stories carousel and rich results - **Analytics Integration** - Track performance with amp-analytics - **Testing & Validation** - Full validation with Google Search Console

## Who needs AMP? ### News publishers Top Stories no longer requires AMP, so the question is whether the AMP Cache still buys you anything on top of a fast site. For a newsroom publishing dozens of articles a day it sometimes doess. ### E-commerce sites Reduce mobile bounce rates with near-instant page loads. AMP-compatible WooCommerce integration available. ### Businesses in emerging markets Critical for regions with poor internet infrastructure. AMP Cache serves content from Google's global CDN. ### Sites with limited dev resources Get enterprise-level mobile performance without complex custom development.

## Where does AMP work? AMP optimization benefits your site across multiple touchpoints: - **Google Search** - Top Stories carousel, rich results, AMP badges - **Mobile Devices** - Near-instant loading on all mobile browsers - **Slow Connections** - Optimized delivery via AMP Cache - **Social Media** - Faster sharing and preview experiences - **Email** - AMP for Email interactive experiences

## AMP service pricing Our AMP implementation service includes, with scope agreed individually: ### Basic package (individual quote) - Official AMP plugin installation and configuration - Standard mode or Transitional mode setup - Basic theme compatibility adjustments - Schema.org markup implementation - Google Search Console validation - Core Web Vitals baseline report ### Advanced package (individual quote) - Everything in Basic, plus: - Custom AMP template development - WooCommerce AMP integration - Advanced analytics setup - AdSense/ad integration - Page builder compatibility - Performance monitoring dashboard ### Enterprise package (individual quote) - Everything in Advanced, plus: - Multi-site AMP implementation - Custom component development - A/B testing setup - Monthly performance reports - Priority support for 6 months ### Factors affecting price - Theme complexity and customizations - Number of custom post types - WooCommerce product catalog size - Third-party integrations required - Multi-language requirements [Get a custom quote](/en/contact/) for your WordPress site.

## What are AMP (Accelerated Mobile Pages)? AMP (Accelerated Mobile Pages) is an open-source HTML framework developed by Google and the AMP Open Source Project to create fast-loading web pages for mobile devices. Launched in 2015, AMP was designed to address the growing need for faster mobile web experiences, especially in regions with limited internet connectivity. The core principle behind AMP is simple: strip down web pages to their essential content and eliminate elements that slow down loading times. This is achieved through a combination of simplified HTML, restricted JavaScript usage, and the AMP Cache system that serves content from Google's servers. ## Is AMP still worth using in 2026? A reality check before we go further: AMP is not a 2026 best practice. It is a 2015-era framework that Google demoted in 2021 when the Top Stories carousel stopped requiring it. Mobile-first indexing did not save AMP, because AMP was never the only way to be fast on mobile, and Core Web Vitals replaced it as the metric Google actually cares about. What AMP does well, technically, has not changed. Strict CSS limits, no arbitrary JavaScript, and prefetching from Google's CDN produce sub-1-second LCP almost by default, low CLS because layout rules are enforced, and predictable INP because there is no third-party script chaos. If you are working with a small team and need a mobile variant that is hard to make slow, AMP still delivers on that narrow promise. What AMP does not do anymore is buy you preferential search treatment. The AMP badge is gone in most markets. Top Stories ranks canonical URLs with good Core Web Vitals just as readily as AMP URLs. The crawl-efficiency argument matters only at very large scale. So if you are considering AMP for the SEO upside specifically, that upside is mostly historical at this point. ## How AMP works ### AMP HTML AMP uses a specialized version of HTML with custom tags and restrictions: - All CSS must be inlined and limited to 75KB - JavaScript is restricted to AMP-approved components - Images and videos use lazy loading by default - Third-party scripts are sandboxed to prevent blocking ### AMP cache Google's AMP Cache stores AMP pages and serves them directly from Google's infrastructure, providing: - Pre-validation of AMP pages - Compression and optimization - Global CDN distribution - Near-instantaneous delivery ### AMP JavaScript The AMP JS library implements best performance practices: - Asynchronous loading of all resources - Pre-calculation of layout before loading - Sandboxed iframes for third-party content - Built-in analytics support ## Which WordPress AMP plugins are still maintained in 2026? Before touching anything, look at what is actually still maintained. The official **AMP** plugin (`amp` on WordPress.org, formerly "AMP for WordPress") is the only one I would still install on a new project. It is the plugin Google and Automattic backed, and it still ships updates against current WordPress and PHP versions. Three modes: Standard (the whole site is AMP), Transitional (AMP and canonical coexist), Reader (legacy templates, mostly relevant for old blogs you do not want to rebuild). Standard mode is the cleanest, but it will surface every theme incompatibility you have. Most paid themes from 2018-2020 break Standard mode in ways that take a day to fix. **AMP for WP, Accelerated Mobile Pages** by Ahmed Kaludi and Mohammed Kaludi is the other plugin most clients arrive with. It is more permissive about ads, page builders, and WooCommerce, which is why agencies pushed it. Update cadence has slowed, GitHub issues sit open for months, and the WooCommerce add-ons broke in several WC 8.x releases. Functional, but I now treat it as legacy code I am migrating off, not a fresh choice. **Penci AMP**, **Schema AMP** and the long tail of theme-bundled AMP plugins are mostly abandoned. If a client is on one of these, the migration question is not "if" but "when". Whichever plugin you are on, the setup that actually matters is small: pick Standard or Transitional, run the AMP validator from Search Console (while it still exists), wire `amp-analytics` to your existing GA4 property, and audit which canonical-page features silently disappear on the AMP variant. The plugin's UI will not warn you when it strips your contact form's reCAPTCHA or your booking widget's JavaScript. ## Common AMP problems on WordPress sites The AMP failure modes I keep seeing on real client sites, not the theoretical ones from the docs: **Validation errors after a plugin update.** A perfectly valid AMP variant breaks the morning after someone activates a popup plugin, a chat widget, or a new analytics snippet. The non-AMP analytics tag injects inline JavaScript, and AMP rejects the whole page. The fix is removing the offending plugin's frontend output from the AMP variant via the official plugin's "Plugin Suppression" panel, but every new plugin reopens the question. **The 75 KB inline CSS limit.** AMP requires all CSS inlined into a single ` ' . esc_html__( 'Staff accounts only. Report a suspected password leak to IT.', 'your-textdomain' ) . '

'; return $notice . $message; } add_filter( 'login_message', 'wppoland_login_message' ); ``` Implementation notes: - Escape the text (`esc_html__`), or build the markup through `wp_kses_post` if it needs a link. - Do not replace `$message` blindly. Core puts its own notices there (after `loggedout=true`, for example). Prepend, or filter conditionally on the request. - The `.message` class is already styled by `login.css`. Your `style-login.css` should respect it (text colour, left border), or the banner disappears into the background. For text that depends on the action (`login`, `lostpassword`, `rp`), check `$_GET['action']` instead of showing the same note on password recovery and on the 2FA step. ## Add custom CSS to the WordPress login page Do not dump login rules into the public `style.css`. Enqueue a dedicated file on the same hook: ```php function wppoland_login_stylesheet() { wp_enqueue_style( 'wppoland-custom-login', get_stylesheet_directory_uri() . '/style-login.css', array(), wp_get_theme()->get( 'Version' ) ); } add_action( 'login_enqueue_scripts', 'wppoland_login_stylesheet' ); ``` Example `style-login.css`: ```css body.login { background-color: #0d1117; display: flex; align-items: center; justify-content: center; } .login form { background: #161b22; border: 1px solid #30363d; box-shadow: none; border-radius: 8px; } .login label { color: #c9d1d9; } .wp-core-ui .button-primary { background: #238636; border-color: rgba(27, 31, 35, 0.15); } .login #backtoblog a, .login #nav a { color: #c9d1d9; } ``` Match contrast to WCAG where editors need it: pale grey on dark grey fails for some users. Test focus outlines on the username, password, and submit controls; removing outlines for "clean design" is a regress. Language packs and RTL locales still use the same hooks. Avoid hard-coded English strings in CSS `content` properties. Background images on `body.login` should be compressed and sized for a simple full-bleed photo, not a 4K marketing hero. Login traffic is frequent for editors; a heavy background taxes every session. Prefer a solid brand colour or a subtle pattern under 100 KB. If the brand book mandates a light form on a light background, increase border contrast on `.login form` so the card still reads as a distinct surface. Many "minimal" logins fail because the form melts into the page. ## Change the WordPress login error message A failed password for an existing user historically produced a message that confirmed the username. That helps attackers enumerate accounts before brute-forcing passwords. ```php function wppoland_login_errors() { return __( 'Invalid credentials.', 'your-textdomain' ); } add_filter( 'login_errors', 'wppoland_login_errors' ); ``` Keep the copy boring and identical for unknown user and wrong password paths. This is obscurity for enumeration, not a substitute for: 1. Disallowing weak admin passwords. 2. Limiting login attempts at the application or edge. 3. Turning on 2FA for administrators. 4. Not using `admin` as a username on new installs. Lost-password flows have their own messages. Review those templates if you customise registration or membership plugins that share the login CSS. Some membership plugins replace `wp-login.php` with a front-end form. In that case these hooks never fire. Apply the same rules on the plugin's form hooks, or style their template partials directly. Confirm which URL editors actually use before you declare the job done. XML-RPC and the REST users endpoint are separate attack surfaces. Branding `wp-login.php` does nothing for them. Disable or [restrict XML-RPC](/en/wordpress-security-hardening-complete-guide-2026/) if you do not need it, and keep application passwords under policy if the site uses them. ## Disable the WordPress login shake animation Failed logins trigger a shake via `wp_shake_js`. Some brand guidelines treat it as noise. The snippet most tutorials still copy, `remove_action( 'login_head', 'wp_shake_js', 12 )`, has done nothing since WordPress 5.4. Core now attaches `wp_shake_js` to `login_footer`, and only conditionally, inside `login_header()`. You can see it in [`wp-login.php` in the wordpress-develop repository](https://github.com/WordPress/wordpress-develop/blob/trunk/src/wp-login.php); the 5.3 branch still used `login_head`. The stable method is the [`shake_error_codes`](https://developer.wordpress.org/reference/hooks/shake_error_codes/) filter, available since 3.0: an empty list of error codes means no animation. ```php add_filter( 'shake_error_codes', '__return_empty_array' ); ``` The filter is public API, so it does not depend on the priority or on which hook core happens to print the script from. Add a one-line comment above it that states the intent. ## Style 2FA and passkey fields on wp-login.php Building full 2FA inside `functions.php` is the wrong project. Use a maintained plugin (for example the official Two Factor plugin or your host's offering) and style the extra fields so they match the branded form. The [Two Factor](https://wordpress.org/plugins/two-factor/) plugin from the WordPress.org directory (version 0.17.0, 100,000+ active installs according to the directory API in October 2026) emits these classes on the second login step. They are taken from the 0.17.0 source: - `.two-factor-prompt` for the instruction paragraph, - `input.authcode` (with `id="authcode"`) for the TOTP code, the email code and the backup code; the field carries `inputmode="numeric"` and `autocomplete="one-time-code"`, so do not override those attributes with a script, or phones stop offering the code from SMS or the password manager, - `.backup-methods-wrap` for the links to alternative methods, - `.two-factor-email-resend` for the button that resends the email code. ```css .login .two-factor-prompt { color: #c9d1d9; } .login input.authcode { letter-spacing: 0.2em; text-align: center; } .login .backup-methods-wrap a { color: #c9d1d9; } ``` Older tutorials use selectors such as `.backup-methods` or `.two-factor-methods`. The current plugin code has neither, so those rules never match. Load the working rules in the same `style-login.css`. After every plugin update, re-check the second login step on staging, because class names drift. Other 2FA and passkey plugins have their own markup: read their selectors from their code, not from this guide. …[truncated, fetch the canonical URL for the full body]… --- ## Googlebot and JSON-LD: a single unescape pass URL: https://wppoland.com/en/googlebot-json-ld-single-unescape-pass-2026/ Description: Google changed its JSON-LD extraction and now applies only one pass of HTML unescaping. Double-escaped entities are no longer unrolled, so the block stops parsing and the structured data disappears. How to measure your own corpus and how to encode it correctly. Published: Sun Aug 30 Updated: Wed Oct 14 Type: guide Level: intermediate Tags: json-ld, structured-data, googlebot, schema-org, technical-seo

Google has stopped repairing your structured data. JSON-LD extraction now applies a single pass of HTML unescaping, so a block that used to be quietly straightened out simply fails to parse and disappears. There is no error in Search Console, no warning, only a rich result that stops showing up. This piece shows how to measure your own corpus in a few minutes instead of guessing, where that encoding comes from in WordPress, and why a one-off audit is not enough. Our own measurement across 68 055 blocks is in here, along with the script.

## What changed in Google's JSON-LD extraction in 2026 The statement is short and worth quoting whole, because everything else follows from one sentence: > To bring our parser up to JSON and other standards, we changed our JSON-LD extraction and are now only applying a single pass of HTML unescaping Gary Illyes added a pointer to where correctness is defined: RFC 8259, the JSON specification. That is not an SEO guideline, it is a reference to the standard every JSON parser in the world already follows. The practical consequence is stated just as briefly: double-escaped entities, such as `&` or `✔`, will no longer be unrolled. Google's parser used to make an extra pass and straighten that out. It now makes one pass and is left with text that is not valid JSON. It is worth naming what the announcement does not contain. There is no rollout date. There is no link to updated Google documentation. The source is a LinkedIn post, reported by Search Engine Roundtable on 21 August 2026. Treat it as a state Google described, not as a specification you can cite back to a client. ## What is double escaping in JSON-LD Take a simple case: the company name "Smith & Sons" in a JSON-LD `name` field. | written as | what the JSON parser sees | status | | --- | --- | --- | | `"Smith & Sons"` | Smith & Sons | valid, JSON does not require escaping an ampersand | | `"Smith \u0026 Sons"` | Smith & Sons | valid, universal escape | | `"Smith & Sons"` | Smith & Sons | parses, but the value is wrong | | `"Smith & Sons"` | Smith & Sons | this is double escaping | An ampersand on its own will not blow up the block, because JSON does not require it to be escaped. The real trouble starts with the quotation mark. If a template writes `"` where `\"` belongs, one unescape pass leaves you with `"` rather than a quote character. The string never closes and the block stops being JSON. Where does it come from in WordPress? Almost always from processing the same value twice. Content passes through `esc_html()` on save, then through a theme filter on output, and finally lands in a JSON-LD field that would have escaped it properly on its own. Each of those steps is correct in isolation. Composed together they produce an encoding that worked for years only because Google was straightening it out for you. ## How to check JSON-LD for double escaping The rule that matters most: check the built HTML, not the template source. The source always looks fine, because the escaping is added on output. If you ship a static build, scan the output directory. On a classic WordPress install, pull a sample of URLs with `wget` or `curl` and scan what the server actually returned. The check itself is a dozen lines. Pull out every `'; }); ``` ## 3. How to lazy load YouTube videos in WordPress Video embeds are traditionally heavy and can ruin your LCP (Largest Contentful Paint) scores. A single YouTube embed can add 2MB+ to your page weight and significantly delay interactivity. ### How the YouTube facade pattern works This applies to article and product pages where the video supports the text. A dedicated watch page is the exception, explained in the facade section further down. Never load the video player on initial page load. Instead, use a **Thumbnail Placeholder** that only loads the actual player when the user interacts with it. **How It Works:** 1. Display a high-resolution thumbnail image with a play button overlay 2. Load the heavy JavaScript only when the user clicks or scrolls the video into view 3. Replace the thumbnail with the actual video player on demand **Implementation Example:** ```html

``` ```javascript // Lazy load video on interaction document.querySelectorAll('.video-facade').forEach(facade => { facade.addEventListener('click', () => { const videoId = facade.dataset.videoId; facade.innerHTML = ` `; }); }); ``` ### How lazy loading video affects Core Web Vitals | Metric | Direct Embed | Lazy-Loaded | |--------|--------------|-------------| | LCP | 3.2s | 1.1s | | TTI | 4.8s | 1.9s | | Page Weight | +2.1MB | +45KB | | Mobile Score | 42/100 | 94/100 | ## 4. How video supports E-E-A-T and conversions In 2026, video isn't just for entertainment - it's a critical component of [E-E-A-T](/en/wordpress-seo-2026-eeat-ai-search-guide/) (Experience, Expertise, Authoritativeness, Trustworthiness) that Google uses to evaluate content quality. ### How video builds trust **Expert Interviews**: Featuring recognized experts in your videos builds credibility that text alone cannot achieve. Seeing a real person speak creates a connection that establishes trust. **Product Demonstrations**: On a [WooCommerce site](/en/woocommerce-developer/), a demo video shows the product working. Marketing surveys quote high conversion lifts for that format; the original studies are vendor surveys, not Google measurements, so we do not repeat a percentage. Show the product in action anyway. **Behind-the-Scenes Content**: Authentic glimpses into your process humanize your brand and differentiate you from AI-generated content. ### Which video types convert best 1. **Tutorial Videos**: How-to content that solves specific problems 2. **Testimonials**: Customer success stories in video format 3. **Product Comparisons**: Side-by-side feature demonstrations 4. **FAQ Videos**: Address common objections and questions 5. **Webinar Recordings**: Long-form educational content ### How to show E-E-A-T in a video - Show the speaker/expert clearly in the video - Include credentials and experience in the video description - Link to author profiles and social media - Use professional production quality (good lighting, clear audio) - Include publication dates to show content freshness ## 5. YouTube, TikTok and LinkedIn video SEO ### YouTube SEO in 2026 YouTube's algorithm has evolved to prioritize watch time and engagement over simple view counts: **Title Optimization:** - Front-load primary keywords - Use numbers and brackets for CTR boost: "[2026 Guide]" - Keep under 60 characters for full display - Example: "WordPress SEO: 10 Tips for 2026 [Tutorial]" **Description Best Practices:** - First 100 characters are crucial (appear in search) - Include timestamps for longer videos - Add relevant links with UTM parameters - Use 3-5 relevant hashtags **Thumbnail Strategy:** - 1280x720 resolution minimum - Readable text at small sizes (under 20 characters) - High contrast colors - Consistent branding across your channel - Include human faces when possible (increases CTR) ### Does TikTok video help SEO Short-form video (under 60 seconds) has exploded in 2026. While TikTok doesn't directly impact Google rankings, it drives significant brand awareness and traffic: - Repurpose long-form content into 30-60 second clips - Use trending sounds and hashtags - Post consistently (1-3 times daily) - Include clear CTAs linking to your WordPress site - Embed TikTok videos on your site for cross-promotion ### How to use LinkedIn video for B2B For WordPress agencies and B2B service providers: - Native LinkedIn video usually holds attention better than a bare link; measure yours, do not copy an infographic multiple - Keep videos under 2 minutes for maximum reach - Use professional captions (many watch without sound) - Share case studies and client success stories ## 6. Video vs text content for SEO | Metric | Text-only article | Article + video | Video-first page | |--------|-------------------|-----------------|------------------| | Time on page | Baseline | Wistia measured about 1.4x vs pages without video | Measure on your own property | | Bounce and conversion | Do not copy a template rate | Do not copy a template rate | Read Search Console and shop analytics | | Search visibility | Web results | Web + video features | Web + video + YouTube | | What a shopper can see | Specs and photos | Specs plus a working demo | Demo first, text as support | ## 7. Best WordPress video plugins for SEO ### Presto Player, Videopack and WP Rocket for video …[truncated, fetch the canonical URL for the full body]… --- ## How to downgrade WordPress? (Plugin, FTP, wp-CLI) URL: https://wppoland.com/en/how-to-downgrade-wordpress-rollback-guide/ Description: Update crashed your site? Don't panic. See 3 proven ways to rollback WordPress core, plugins, or themes to a previous version. Published: Tue Jan 03 Updated: Wed Oct 14 Type: guide Level: advanced Tags: update, backup, wp-cli, debugging You click "Update", wait a moment, and suddenly see the "White Screen of Death" or a critical PHP error. Your site is down, and the client is calling. Don't panic. In WordPress, you can almost always revert changes. In this guide, I'll show you three methods for a **downgrade**, ranging from easiest to most advanced. Before that, one step saves you from fixing the wrong thing: figure out what actually broke, so you roll back the specific component at fault instead of guessing. --- ## How to find which update broke your WordPress site A rollback is only useful if you revert the right thing. If a theme update broke the layout and you downgrade WordPress core, you waste time and add risk. Spend five minutes on diagnosis first. ### How to enable WP_DEBUG and read debug.log WordPress hides fatal errors behind the white screen by default. Switch on debugging so the real message is written to a file rather than shown to visitors. Edit `wp-config.php`, above the line that says `/* That's all, stop editing! */`: ```php define( 'WP_DEBUG', true ); define( 'WP_DEBUG_LOG', true ); define( 'WP_DEBUG_DISPLAY', false ); ``` With `WP_DEBUG_LOG` on, errors land in `wp-content/debug.log`. Open that file and read the last entries. A typical line names the exact file and function, for example a fatal error in `wp-content/plugins/some-plugin/includes/class-loader.php`. That path tells you which plugin is at fault before you touch anything. If `debug.log` is empty or missing, check your host's own logs. Most panels expose a PHP error log and a server (Apache or Nginx) error log under a "Logs" or "Metrics" section. The server log catches memory-limit and timeout failures that never reach the WordPress log. ### How to find the faulty plugin by deactivating plugins If the log points at a plugin, or if nothing is conclusive, deactivate plugins to narrow it down. With wp-admin still reachable, deactivate them one at a time and reload the broken page after each. When the error clears, the last plugin you switched off is the cause. If you are locked out of the dashboard, do the same over FTP or SSH. Renaming the whole `wp-content/plugins` folder to `plugins_off` deactivates every plugin at once. If the site returns, rename it back and disable plugins individually until the offender shows itself. Over WP-CLI the same check is two commands: `wp plugin deactivate --all`, then reactivate one by one. ### Should you downgrade core, a plugin, a theme or PHP Match the symptom to the layer, because each one rolls back differently: - **A plugin** is the most common cause. Downgrade that single plugin (Method 1 or 2 below) and leave everything else alone. - **A theme** update usually breaks layout, styling, or the block editor rather than throwing a fatal error. Roll the theme back, or switch to a default theme like Twenty Twenty-Four to confirm. - **WordPress core** is the culprit when the site broke immediately after a core update and plugins are ruled out. Core needs Method 2 or 3. - **A PHP version bump** breaks the site when your host upgraded PHP (often automatically), not WordPress. The tell is a fatal error mentioning a deprecated or removed function even though you did not update anything in WordPress. That is a hosting-panel fix, covered further down. Only once you know which layer failed does picking a rollback method make sense. --- ## What to check before you downgrade WordPress A rollback destroys evidence. Before you replace a single file, record what the site is running right now, so you can move forward again once the bug is patched and so you can compare states if the rollback does not help. With WP-CLI it takes under a minute: ```bash wp core version --extra wp plugin list --fields=name,status,version,update_version --format=csv > plugins-before.csv wp theme list --fields=name,status,version --format=csv > themes-before.csv wp db export backup-before-rollback.sql ``` `wp core version --extra` prints the core version together with the database revision that the running code expects. Compare it with `wp option get db_version`, the revision actually stored in the database: if the stored number is higher than the one your target release expects, the database has already migrated forward and a file-only rollback will not match it. The two CSV files give you the exact versions to return to afterwards, instead of guessing from memory at midnight. Two plugin headers decide whether a core downgrade is even possible. A plugin can declare `Requires at least` and `Requires PHP` in its main file header, and where those headers are present WordPress blocks activation when the running core or PHP version does not meet them. So if a plugin declares WordPress 6.6 and you drop core to 6.4, you cannot reactivate it after the downgrade, and its code may call core functions that the older release does not ship. Read the headers before you pick a target version: ```bash grep -RE "Requires (at least|PHP)" wp-content/plugins/*/*.php ``` Finally, put the site behind maintenance mode so visitors and crawlers get a 503 instead of a half-replaced install: `wp maintenance-mode activate`, and `wp maintenance-mode deactivate` when the work is done. A 503 with a short retry window is the response Google expects during maintenance, so it does not treat the outage as a permanent change. --- ## Method 1: revert a plugin update with WP Rollback If you still have access to the Dashboard (wp-admin), you are saved. The best tool for reverting plugins and themes is the free **WP Rollback** plugin. 1. Install and activate **WP Rollback**. 2. Go to **Plugins > Installed Plugins**. 3. A new link **"Rollback"** will appear next to each plugin. 4. Click it and choose the version you want to return to (e.g., from 5.4 to 5.3). 5. Confirm. Done! **Note:** The free version of WP Rollback works with plugins and themes from WordPress.org, according to its [plugin page](https://wordpress.org/plugins/wp-rollback/); premium plugins need the paid Pro version. It does not revert WordPress core. For core, use a separate plugin, **Core Rollback** by Andy Fragen, which sits under **Tools**. --- ## Method 2: downgrade the WordPress version with WP-CLI If you have SSH access (see our [SSH guide](/en/ssh-for-wordpress-developers-guide/)), this is the fastest and safest method. To downgrade WordPress Core: ```bash wp core update --version=7.0.7 --force ``` The `--force` parameter, in the words of the [WP-CLI docs](https://developer.wordpress.org/cli/commands/core/update/), updates "even when installed WP version is greater than the requested version". To downgrade a plugin (e.g., WooCommerce): ```bash wp plugin install woocommerce --version=8.5.0 --force ``` Here `--force` belongs to `wp plugin install`, where it overwrites any installed version without prompting ([docs](https://developer.wordpress.org/cli/commands/plugin/install/)). `wp plugin update` has no `--force` flag, although it also accepts `--version`. Themes follow the same pattern: `wp theme install twentytwentyfour --version=1.0 --force`. ### Which WordPress version to roll back to Not every older release is a safe target. WordPress.org publishes the security status of every core release through the [stable-check API](https://api.wordpress.org/core/stable-check/1.0/), and the Core Rollback plugin uses the same list: its [description](https://wordpress.org/plugins/core-rollback/) says it only offers the latest release and outdated, secure ones. On 14 October 2026 the API marks 7.1.3 as `latest`, the final point release of each older branch (7.0.7, 6.9.10, 6.8.11 and so on) as `outdated`, and every earlier point release of those branches as `insecure`. The 6.4.3 this guide used as its example until this update is on the insecure list. So the rule is: roll back to the last point release of the branch that worked, not to the exact number you ran before. If 7.1.x broke the site, the target is 7.0.7, not 7.0.2. Check the status before you run the command: ```bash curl -s https://api.wordpress.org/core/stable-check/1.0/ | grep '"7.0.7"' ``` The second check is PHP. The core team's [PHP compatibility table](https://make.wordpress.org/core/handbook/references/php-compatibility-and-wordpress-versions/) lists which PHP versions each release is tested with, and a rollback can move you off it: | Server PHP | Oldest core release the table lists for it | | --- | --- | | 8.5 | 6.9 | | 8.4 | 6.7 | | 8.3 | 6.4 | | 8.2 | 6.1 | If the host has already moved the server to PHP 8.5, rolling back to 6.8 lands on a combination the core team never listed as supported. The limit runs the other way too: WordPress 7.0 dropped support for PHP 7.2 and 7.3, so on such a server 6.9 is the newest release you can run. Pick the target that passes both checks: secure according to stable-check and listed for the PHP version your server runs. `wp eval 'echo PHP_VERSION;'` shows the version WordPress actually sees. --- ## Method 3: downgrade WordPress manually via FTP If you have no access to the panel or SSH, only "open heart surgery" via FTP remains. **This is risky. Backup your database before starting!** 1. Go to [WordPress.org Releases](https://wordpress.org/download/releases/) and download the older WP version (zip). If you have WP-CLI on your own computer, `wp core download --version=7.0.7 --skip-content --path=wp-7.0.7` fetches the same release without the default themes and plugins ([docs](https://developer.wordpress.org/cli/commands/core/download/)). 2. Unzip it on your computer. 3. **DELETE** the `wp-content` folder and `wp-config-sample.php` file from the unzipped folder. * *Why?* So you don't accidentally overwrite your photos, themes, and configuration! 4. Connect via FTP (FileZilla). 5. Upload the remaining files (`wp-admin`, `wp-includes`, root files) to the server, choosing **"Overwrite"**. After uploading, try accessing `wp-admin`. If WordPress shows **Database Update Required**, confirm with **Update WordPress Database**. --- ## How to restore WordPress from a hosting backup Before you touch a single file, check whether your host can undo the update for you. On managed WordPress hosting this is often the fastest route, and it needs no command line at all. Most managed hosts keep automatic daily restore points and expose a one-click restore in the control panel, usually under a "Backups" or "Restore" tab. You pick a snapshot from before the update and confirm. The host rebuilds the site (files and database together) to that moment. Because both layers move back in sync, this sidesteps the schema-mismatch trap described in the next section. Two things to check first. Some hosts restore files and database separately, so read the labels and choose the full snapshot, not files-only. And a restore overwrites everything since the snapshot, so any orders, comments, or posts created after that point are lost. On a busy store, weigh that against a targeted plugin rollback. For a brochure site that changed nothing overnight, the one-click restore is usually the cleanest option. --- ## How to tell whether the rollback actually worked "The homepage loads" is not verification. A rollback can leave a half-copied file tree, a stale bytecode cache, or a broken admin path while the front page still renders from cache. Start by checking the version that is actually in place, not the one you intended to install: ```bash wp core version wp plugin get woocommerce --field=version wp core verify-checksums wp plugin verify-checksums --all ``` …[truncated, fetch the canonical URL for the full body]… --- ## Core Web Vitals 2026: The Complete INP Optimization Guide for WordPress URL: https://wppoland.com/en/core-web-vitals-2026-inp-optimization-guide/ Description: How to optimize Interaction to Next Paint (INP) on WordPress sites. Practical fixes for the newest Core Web Vital metric that directly impacts Google rankings. Published: Sat Mar 21 Updated: Wed Oct 14 Type: guide Level: advanced Tags: core-web-vitals, inp, interaction-to-next-paint, page-speed, wordpress-performance, lcp, cls

Google's Core Web Vitals are no longer optional for SEO. In 2026, these metrics directly influence search rankings, and **INP (Interaction to Next Paint)** has become the most challenging one for WordPress sites. While LCP and CLS can be fixed with image optimization and layout reservations, INP requires fundamentally rethinking how JavaScript runs on your pages. INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. The difference is significant: FID only measured the first interaction, while INP measures **every interaction** throughout the entire page visit. A site could score well on FID but terribly on INP - and many WordPress sites do.

## Core Web Vitals thresholds for LCP, INP and CLS ### Good and poor values for LCP, INP and CLS | Metric | What It Measures | Good | Needs Work | Poor | |---|---|---|---|---| | **LCP** (Largest Contentful Paint) | Loading speed | < 2.5s | 2.5-4s | > 4s | | **INP** (Interaction to Next Paint) | Responsiveness | < 200ms | 200-500ms | > 500ms | | **CLS** (Cumulative Layout Shift) | Visual stability | < 0.1 | 0.1-0.25 | > 0.25 | ### Why is INP harder to fix than LCP and CLS LCP is primarily about server speed and [image optimization](/en/wordpress-image-optimisation-critical-css-performance-guide/) - well-understood problems with clear solutions. CLS is about reserving space for dynamic content - a CSS and HTML discipline. INP is about **JavaScript execution efficiency** - a fundamentally harder problem because it requires understanding the browser's main thread, task scheduling, and event handling. WordPress sites are particularly vulnerable to poor INP because: 1. **Plugin bloat** - every plugin can add JavaScript that blocks the main thread 2. **Page builders** - Elementor, Divi, WPBakery add heavy frontend frameworks 3. **Third-party scripts** - analytics, ads, chat widgets, social embeds all compete for main thread time 4. **jQuery dependency** - many WordPress themes and plugins still rely on jQuery, adding 85KB+ of blocking JavaScript 5. **No code splitting** - traditional WordPress themes load all JavaScript on every page ## How INP works ### What are the three phases of an interaction When a user clicks a button, taps a link, or presses a key, the browser processes it in three phases: 1. **Input delay** - time between the physical interaction and the browser starting to process the event handler (caused by main thread being busy with other tasks) 2. **Processing time** - time to execute all event handlers for this interaction 3. **Presentation delay** - time to render the visual update after event handlers complete INP = Input delay + Processing time + Presentation delay The metric reports the **slowest interaction** of the visit. On busy pages the rule is slightly softer: according to [web.dev](https://web.dev/articles/inp), one highest interaction is ignored for every 50 interactions. Most pages see fewer than 50 interactions per visit, so in practice the worst one is what gets reported. Google then rates the page at the 75th percentile of all visits recorded in the field. This means a single slow interaction can tank your INP score, even if every other interaction is fast. On a typical WordPress site with forms, menus, filters and carousels there are dozens of possible interactions, and one bad one is enough. INP became a Core Web Vital and replaced FID on 12 March 2024, as announced on [web.dev](https://web.dev/blog/inp-cwv-march-12). FID was deprecated in the same transition and removed from the Search Console report. ### What counts as an interaction Not every user action registers as an interaction for INP purposes. The distinction matters because optimizing for the wrong events wastes effort. **These actions DO trigger INP:** - **Clicks** on buttons, links, toggles, menus, checkboxes, radio buttons - **Taps** on mobile (touch events including `pointerdown`, `pointerup`, `click`) - **Key presses** in input fields, search boxes, text areas, and contenteditable elements - **Keyboard shortcuts** - pressing Enter to submit a form, Space to toggle a checkbox - **Custom interactive elements** - any element with a `click`, `pointerdown`, or `keydown` handler attached **These actions do NOT trigger INP:** - **Scrolling** - scroll is measured separately and does not count as a discrete interaction - **Hovering** - mouse hover alone doesn't generate an INP entry, even if a tooltip appears - **Pinch-to-zoom** - this is a continuous gesture, not a discrete interaction - **CSS-only transitions** - animations triggered purely by CSS (`:hover`, `:focus`) without JavaScript event handlers - **Page load** - the initial rendering of the page is not an interaction; that's what LCP measures One nuance: a single physical action like a tap can generate multiple events (`pointerdown`, then `mousedown`, `pointerup`, `mouseup` and finally `click`). The browser groups these into a **single interaction** and measures the total duration from the first event to the final paint. This grouping means you don't get penalized five times for one tap, but it also means slow handlers on any of those grouped events will increase the overall interaction duration. ## Measuring INP on WordPress sites ### Google Search Console (field data) The most important data source. Navigate to Core Web Vitals, then Mobile or Desktop. Search Console shows real-user INP data aggregated over 28 days. Pages are grouped by URL pattern and rated as Good, Needs Improvement, or Poor. Always start here. Field data reflects what real users experience, including slow devices, weak connections and interactions that lab tests never simulate. If Search Console reports poor INP, Google is seeing that problem, and it can affect rankings. ### PageSpeed Insights (lab + field) Enter any URL and get both: - **Field data** - real user measurements from the Chrome UX Report (CrUX). This is the data Google uses for its assessment - **Lab data** - simulated measurements from Lighthouse, run in a controlled environment For INP, field data matters more because lab tests may not trigger the same interactions real users perform. A site can show a clean lab report and still have poor field INP, because real users open complex menus, search filters and forms that Lighthouse never touches. ### Chrome DevTools (debugging) To diagnose a specific INP problem, Chrome DevTools is the tool. The process: 1. Open DevTools, go to the **Performance** panel and click **Record** 2. Interact with the page: click buttons, open menus, fill in forms 3. Stop the recording and analyse the result Look for: - **Long tasks** - tasks over 50ms, marked with a red triangle in the corner. Any task above this threshold blocks the main thread - **Event handlers** - how long each click or tap takes to process. If one click triggers several handlers, the time adds up - **Layout thrashing** - forced synchronous layouts during interactions. This happens when JavaScript alternately reads and writes layout properties, forcing the browser to recalculate again and again ### How to read a waterfall chart in DevTools The Performance panel waterfall can be overwhelming, but a systematic approach makes it manageable. After recording an interaction, focus on these areas: 1. **Find the interaction marker** - Chrome marks discrete interactions with a dashed vertical line in the timeline. Click it to highlight the associated events. 2. **Check the main thread flame chart** - look directly below the interaction marker for the stack of function calls. The widest bars represent the longest-running functions - these are your optimization targets. 3. **Identify the three INP phases** - input delay appears as idle time before the first event handler fires, processing time spans the event handler execution, and presentation delay covers style recalculation, layout, and paint after handlers complete. 4. **Look for forced reflows** - purple "Layout" bars inside event handlers indicate synchronous layout calculations. These appear when JavaScript reads a layout property (like `offsetHeight`) after modifying the DOM, forcing the browser to recalculate layout immediately rather than batching it. 5. **Check the "Interactions" track** - Chrome DevTools has a dedicated Interactions lane that shows each interaction's total duration and its rating (green/yellow/red). This gives you a quick pass/fail before diving into the flame chart. A common pattern on WordPress sites: clicking a menu toggle triggers a 200ms long task because the event handler forces a reflow by reading `element.getBoundingClientRect()` immediately after adding a CSS class. Moving the DOM read before the DOM write eliminates the forced reflow and can cut interaction time by 60-80%. ## How to improve INP in WordPress ### 1. Defer non-critical JavaScript The single most impactful fix. Most WordPress plugins load JavaScript in the ``, blocking the main thread before the page even renders: ```html ``` The `defer` attribute tells the browser to download the file in parallel but execute it only after the HTML has been fully parsed. That frees the main thread during the initial load and cuts input delay for early interactions. Plugins that benefit most from deferring: - **Analytics** (GA4, GTM) - add `defer` or load via `requestIdleCallback` - **Chat widgets** (Intercom, Tawk.to) - load after user scroll or after 5 seconds - **Social embeds** (Facebook, Twitter) - load only when visible (Intersection Observer) - **Sliders and carousels** - defer initialization until visible ### 2. Remove unused plugin JavaScript Many plugins load their scripts on every page of the site, whether they are needed there or not. Audit which plugins actually need frontend JavaScript: ```bash # List the scripts enqueued on the front end wp eval 'do_action("wp_enqueue_scripts"); global $wp_scripts; foreach ($wp_scripts->queue as $s) echo $s . "\n";' ``` `wp eval` runs outside a page request, so the `wp_enqueue_scripts` hook has to be fired by hand, otherwise the queue is empty. Scripts that a plugin enqueues only for a specific template or query will not show up this way. For a per-page view, the [Query Monitor](https://wordpress.org/plugins/query-monitor/) plugin lists the enqueued scripts of the page you are looking at. From that list, mark the ones that page does not need. Common offenders: - **Contact Form 7** loads its CSS and JavaScript on every page, but the forms usually live on one or two pages. Fix: load it conditionally, only where a form exists - **WooCommerce cart fragments** - the cart fragments AJAX runs on every page, even outside the shop. Fix: disable it on pages that are not part of the store - **Gutenberg block styles** - WordPress loads CSS and JavaScript for all registered blocks, even ones not used on the page. Fix: strip the styles of unused blocks Conditional loading can be done in the theme's `functions.php` or with an asset manager plugin such as Asset CleanUp or Perfmatters. ### 3. Break long tasks Any JavaScript task over 50ms blocks the main thread. While it runs, the browser cannot respond to user input, which directly raises the input delay part of INP. The fix is to split long tasks into smaller pieces and hand control back to the browser between them. `scheduler.yield()` is the modern API. It is not available in every browser yet (the [web.dev long tasks guide](https://web.dev/articles/optimize-long-tasks) lists Chrome and Edge 129 and Firefox 142, with Safari still missing), so wrap it with a `setTimeout` fallback and yield on a deadline: …[truncated, fetch the canonical URL for the full body]… --- ## Corporate web development in Spain with Astro and headless WordPress in 2026 URL: https://wppoland.com/en/corporate-web-development-astro-headless-wordpress-spain/ Description: A detailed look at rolling out Astro and headless WordPress for corporate websites in Spain. Mobile performance, Core Web Vitals and SEO in 2026. Published: Fri May 08 Updated: Wed Oct 14 Tags: astro, headless, guide, 2026 # Corporate web development in Spain with Astro and headless WordPress in 2026 The Spanish corporate market in 2026 demands an unprecedented level of digital rigour. Mid-sized and large companies in Spain understand that their online presence is not a static business card but a direct commercial tool that generates business. With mobile traffic dominating browsing and Google penalising slow sites hard, the classic corporate web architecture built on monolithic CMSs has speed and security limits that are hard to justify to a board of directors. In response, the **Astro and headless WordPress** architecture has become the technical reference standard in Spain for leading brands in B2B, retail and the institutional sector. The model combines the familiarity and editorial power of WordPress with the speed and security of Astro on the frontend. This technical guide walks through the components of the architecture, integration best practices and their direct impact on SEO and GEO (Generative Engine Optimization) in the Spanish market. --- ## 1. Why use headless WordPress for a corporate website For years, IT and marketing departments in Spanish companies have been in constant conflict over the organisation's content management system (CMS): - **Marketing** insists on WordPress because its writing teams know the interface, are fluent in the Gutenberg editor, can schedule posts quickly and rely on the plugin ecosystem for content optimisation. - **IT / development** rejects WordPress because of its history of security problems (recurring plugin vulnerabilities), the complexity of maintaining Apache/Nginx servers with FPM and, above all, poor load performance caused by repeated queries to the MySQL database and the code overhead injected by classic themes. A [headless architecture](/en/nextjs-astro-migration/) settles this dilemma at the root: ```mermaid graph LR subgraph Backend Privado A[WordPress Core + Gutenberg] --> B[Base de Datos MySQL] A --> C[REST API / GraphQL] end subgraph Frontend Público C --> D[Compilación de Build en Astro] D --> E[Cloudflare Pages & Workers] E --> F[HTML estático + CSS ligero] end ``` Once the CMS is decoupled, the marketing team keeps using the usual WordPress dashboard on a restricted subdomain (`wp.empresa.es`) to manage news, landing pages and success stories. The public visitor of the corporate website, however, interacts with an ultra-fast static application compiled by Astro and distributed over Cloudflare's global network (`empresa.es`). --- ## 2. What Astro is and why it loads so fast Astro is a development framework built specifically for fast, content-driven corporate websites. Its approach differs radically from traditional [single-page application (SPA) frameworks](/en/headless-wordpress-nextjs-vs-astro-2026/) such as React or Angular, which ship large amounts of JavaScript to the visitor's browser and slow down the mid-range mobile devices common in the Spanish market. ### Astro islands architecture explained Astro uses an approach called the "islands architecture". By default, every page generated in Astro compiles to plain HTML and lightweight CSS, with all unnecessary JavaScript removed. If a section of the page needs interactivity (a dynamic search box, an interactive carousel or a product filter form), Astro creates an "island" of interactivity and injects the required framework code (React, Vue, Svelte or vanilla JS) only for that specific component. The result is flawless mobile performance: - **LCP (Largest Contentful Paint)**: the main visual element of the page (usually the hero image or the main title) appears in under 0.8 seconds on most mobile networks. - **INP (Interaction to Next Paint)**: user interactions with the page get an instant response, removing the lag typical of heavy websites. ### View Transitions and CSS animations in Astro In the 2026 corporate market, being fast is not enough; the site also has to delight the user visually. Astro has native support for the **View Transitions** API, which enables smooth navigation between pages that mimics a native mobile or desktop app. - Shared elements (the navigation menu, the logo or the header) stay in place while the page content fades smoothly. - It supports scroll-driven animations and optimised parallax effects that run directly on the device GPU without blocking the CPU main thread. The result is dynamic interfaces that respond naturally to touch and keep users on the site longer. ### How to serve WordPress images as AVIF in Astro Image weight is the main cause of slow loading on Spanish corporate websites. Astro ships native optimisation tools that process the files editors upload to the WordPress media library. According to the [Astro images guide](https://docs.astro.build/en/guides/images/), the transformation happens at build time for prerendered pages, and on the fly when a page rendered on demand is viewed. - **AVIF has to be requested**: it is not the default format. The [`astro:assets` reference](https://docs.astro.build/en/reference/modules/astro-assets/) states that `` produces a `.webp` file by default and that `