{"id":2701,"date":"2025-10-17T06:48:04","date_gmt":"2025-10-17T05:48:04","guid":{"rendered":"https:\/\/www.forestsoftware.co.uk\/blog\/?p=2701"},"modified":"2025-10-14T17:10:30","modified_gmt":"2025-10-14T16:10:30","slug":"a-complete-guide-on-xmlrpc-php-in-wordpress-what-it-is-security-risks-how-to-disable-it","status":"publish","type":"post","link":"https:\/\/www.forestsoftware.co.uk\/blog\/2025\/10\/a-complete-guide-on-xmlrpc-php-in-wordpress-what-it-is-security-risks-how-to-disable-it\/","title":{"rendered":"A Complete Guide on xmlrpc.php in WordPress (What It Is, Security Risks, How to Disable It)"},"content":{"rendered":"<span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 11<\/span> <span class=\"rt-label rt-postfix\">minutes : <\/span><\/span><h1>A Complete Guide on xmlrpc.php in WordPress (What It Is, Security Risks, How to Disable It)<\/h1>\n<p>Wondering what <em>xmlrpc.php<\/em> is in WordPress, or whether you should disable it? This guide walks you through everything\u2014from what it does, through security risks, to how to turn it off safely. If it all sounds a bit technical, don\u2019t worry\u2014professionals can handle this work usually for a small fee.<\/p>\n<p>This post is written especially for small UK businesses running WordPress sites. We\u2019ll keep things in plain English, in an informal tone, but with enough detail so you understand the risks and actions. Let\u2019s dive in.<!--more--><\/p>\n<h2>1. What Exactly Is xmlrpc.php?<\/h2>\n<p>Every WordPress installation comes with a file named <code>xmlrpc.php<\/code> in the root of your site. By default, it enables a protocol called <em>XML-RPC<\/em> (extensible markup language \u2013 remote procedure call). But what does that actually mean for your website?<\/p>\n<p>Back in the early days, external tools\u2014such as offline blogging software, mobile apps, and other systems\u2014needed a standard way to talk to WordPress. The xmlrpc.php file acts as a gateway, letting those external systems send commands to your WordPress site over HTTP, using XML as the format. In practice, it enabled remote publishing, comment moderation, pingbacks, trackbacks, and integration with apps.<\/p>\n<p>For example, if you used a mobile WordPress app to publish blog posts while on the move, that app would communicate with your site via xmlrpc.php. It allowed you to connect \u201cbehind the scenes,\u201d so you didn\u2019t always have to log in via the dashboard.<\/p>\n<p>However, as technology moved on, WordPress introduced the REST API (which uses JSON, is more flexible and robust). Because of that, many of xmlrpc.php\u2019s roles are now handled by better, more secure systems. Despite that, xmlrpc.php is still present in WordPress core for compatibility.<\/p>\n<p>In short: xmlrpc.php is a legacy bridge. In many modern sites, it\u2019s not strictly needed\u2014yet it can remain active. That\u2019s where risk creeps in. But before we go into the problems, let\u2019s be clear on what it can do (and what it no longer needs to do).<\/p>\n<p><em>Key roles xmlrpc.php has handled:<\/em><\/p>\n<ul>\n<li>Remote posting\/editing of WordPress content via external apps or software.<\/li>\n<li>Supporting mobile app connectivity to WordPress.<\/li>\n<li>Pingbacks \/ trackbacks (automatic communication when sites reference each other).<\/li>\n<li>Enabling services like Jetpack (in older setups) that used XML-RPC to communicate with WordPress.com.<\/li>\n<\/ul>\n<p>That said, for most modern WordPress installations, the REST API covers remote access and many integration needs\u2014making xmlrpc.php somewhat redundant in many cases.<\/p>\n<p>Because that redundancy exists, it often presents a weak point: it gives hackers another surface to probe. Let\u2019s move on to those dangers next.<\/p>\n<h2>2. Security Risks of xmlrpc.php<\/h2>\n<p>Now we come to the heart of why many site owners decide to disable xmlrpc.php. Put simply: it\u2019s a target for attacks. These are some of the key security risks it introduces.<\/p>\n<h3>2.1 Brute-Force &amp; Credential Stuffing via XML-RPC<\/h3>\n<p>A brute-force attack is where an attacker repeatedly tries combinations of usernames and passwords until one works. Normally, WordPress\u2019s login page is the obvious target. But xmlrpc.php can sometimes be even more dangerous.<\/p>\n<p>Why? Because of a method called <code>system.multicall<\/code>, which allows multiple commands (including multiple login attempts) to be sent in a single request. In effect, instead of sending one guess at a time, an attacker can send many in one go. This can bypass simple rate?limiting or login protection tools.<\/p>\n<p>In practice: attackers use xmlrpc.php to hammer your site with many login attempts, trying different username \/ password pairs. Because the authentication is happening inside xmlrpc.php, it can slip past monitoring tools that only watch the standard login page. This increases the risk of a breach.<\/p>\n<h3>2.2 DDoS \/ Pingback Abuse<\/h3>\n<p>Another big risk involves pingbacks (and trackbacks). The XML-RPC protocol allowed WordPress sites to request \u201cpingbacks\u201d as notifications when other blogs or sites link to content. But hackers can abuse this mechanism. Here\u2019s how:<\/p>\n<ol>\n<li>A hacker sends a request via xmlrpc.php to your site, instructing it to send pingbacks to many other sites.<\/li>\n<li>These pingbacks bounce around, creating a flood of HTTP requests directed at target sites.<\/li>\n<li>Your site becomes a kind of amplifier\u2014spitting out waves of traffic that help overload a target (possibly your own site or someone else\u2019s). This is a type of distributed denial-of-service (DDoS) attack.<\/li>\n<\/ol>\n<p>Because xmlrpc.php and its pingback feature can act as that intermediary, leaving xmlrpc enabled gives attackers an extra weapon.<\/p>\n<h3>2.3 Other Vulnerabilities &amp; Exploits<\/h3>\n<p>Besides brute-force and pingback abuse, xmlrpc.php can open the door to weaker or older forms of web vulnerability:<\/p>\n<ul>\n<li>Cross-site request forgery (CSRF) or remote request tampering in badly coded plugins.<\/li>\n<li>Injection or buffer overflow attacks (rare, but possible if the file\u2019s code is outdated or if plugins extend it dangerously).<\/li>\n<li>Elevation of privilege: once an attacker authenticates, they might execute operations they shouldn\u2019t, or upload malicious content.<\/li>\n<\/ul>\n<p>Overall, the presence of xmlrpc.php expands your attack surface. Even if you keep strong passwords and updates, a single overlooked plugin that interacts with XML-RPC could be exploited.<\/p>\n<h3>2.4 Performance &amp; Server Load Issues<\/h3>\n<p>A less dramatic but still real issue: misuse of xmlrpc.php can increase strain on your server. If a bot or attacker repeatedly hits xmlrpc.php with heavy requests, your server has to handle them, potentially slowing your site or consuming bandwidth. This is especially relevant for small-business hosting setups or shared servers where resources are limited.<\/p>\n<p>In short: xmlrpc.php isn\u2019t just a theoretical risk\u2014it can become a liability. For many sites, disabling it removes a common attack vector without harming core functionality. Let\u2019s now see whether yours is active and how to deal with it.<\/p>\n<h2>3. How to Tell Whether xmlrpc.php Is Active on Your Site<\/h2>\n<p>Before you disable xmlrpc.php, you\u2019ll want to check if it\u2019s actually running (or accessible). Because the file itself always exists, mere presence doesn\u2019t prove activity. Here are reliable methods to find out.<\/p>\n<h3>3.1 Use an Online XML-RPC Validator<\/h3>\n<p>One of the simplest checks is to use a tool such as <a href=\"https:\/\/xmlrpc.blog\/\" target=\"_blank\" rel=\"noopener\">XML-RPC Validator<\/a> (or similar services). You enter your site\u2019s URL, and it checks for a working xmlrpc.php endpoint. If the test returns success, it means xmlrpc is enabled and responding. If it returns an error or \u201cnot found,\u201d it may be disabled or blocked.<\/p>\n<h3>3.2 Inspect HTTP Responses \/ Logs<\/h3>\n<p>If you have access to server logs or monitoring tools, watch for requests to <code>\/xmlrpc.php<\/code>. Are there hits? What response codes do they return (200, 403, 404)? If many requests are being logged and returning 200 (successful) or 403 (forbidden), it suggests xmlrpc is still reachable.<\/p>\n<p>You may also use a tool like cURL from your local terminal (or via your hosting control panel) to send a request:<\/p>\n<pre><code>curl -I https:\/\/yourdomain.co.uk\/xmlrpc.php<\/code><\/pre>\n<p>If it returns \u201c200 OK,\u201d it\u2019s likely active. If it returns \u201c403 Forbidden\u201d or \u201c404 Not Found,\u201d it may be blocked. (Be careful\u2014some hosts hide or rewrite responses.)<\/p>\n<h3>3.3 Check Plugin \/ Theme Code &amp; Dependencies<\/h3>\n<p>Some plugins or themes explicitly call xmlrpc functions. In your WordPress plugin directory (\/wp-content\/plugins) or theme files, search for references to \u201cxmlrpc\u201d or \u201cXMLRPC\u201d. If you find code that directly interacts with xmlrpc.php, that suggests parts of your site expect it to be active.<\/p>\n<p>Also, check whether you use Jetpack, remote posting apps, or external tools that rely on XML-RPC. If yes, then disabling xmlrpc.php might break those integrations unless replaced with REST-based alternatives.<\/p>\n<h3>3.4 Ask Your Hosting Provider<\/h3>\n<p>Sometimes your hosting environment already blocks or restricts xmlrpc.php. Some hosts disable direct browser access to xmlrpc.php automatically, making it unreachable via a web browser.<\/p>\n<p>Contact your host support and ask: \u201cIs xmlrpc.php accessible or blocked on my WordPress installation?\u201d They may confirm and possibly handle the blocking for you. If the file is already blocked, you don\u2019t need to do more (though doing your own checks is wise).<\/p>\n<p>Once you\u2019re confident whether xmlrpc.php is active, you can plan whether to disable it, and how best to do so. Let\u2019s get into the steps next.<\/p>\n<h2>4. How to Disable xmlrpc.php (Safely)<\/h2>\n<p>Disabling xmlrpc.php is a common security hardening step\u2014but you must do it carefully so you don\u2019t accidentally break parts of your site that rely on it (though in many cases, there aren\u2019t any). Below are multiple methods (plugin, code, server config) so you can choose what suits you best.<\/p>\n<h3>4.1 Use a Plugin (Easiest, Safest for Many)<\/h3>\n<p>For most small-business WordPress users, installing a plugin is easiest and safer (you can reverse it later). Here are some good plugin options:<\/p>\n<ul>\n<li><strong>Disable XML-RPC<\/strong> \u2014 simple plugin that disables the API entirely.<\/li>\n<li><strong>Disable XML-RPC-API<\/strong> \u2014 turns off XML-RPC plus pingback \/ trackback features.<\/li>\n<li><strong>REST XML-RPC Data Checker<\/strong> \u2014 gives you a UI to control xmlrpc and REST access.<\/li>\n<li><strong>Remove &amp; Disable XML-RPC Pingback<\/strong> \u2014 disables pingback portion while leaving residual xmlrpc endpoints.<\/li>\n<\/ul>\n<p>To use a plugin:<\/p>\n<ol>\n<li>Go to WordPress dashboard ? Plugins ? Add New.<\/li>\n<li>Search the plugin by name (e.g. \u201cDisable XML-RPC\u201d).<\/li>\n<li>Install and activate it.<\/li>\n<li>In many cases, just activation is enough. The plugin may disable xmlrpc.php immediately.<\/li>\n<li>Test your site (especially any external tools or mobile posting) to ensure nothing broke.<\/li>\n<\/ol>\n<p>The plugin approach has the advantage of being reversible (you can deactivate it), and it doesn\u2019t require messing with server files or risking lockouts. For many small-business sites, this is the simplest approach.<\/p>\n<h3>4.2 Use a Code Snippet (via functions or custom plugin)<\/h3>\n<p>If you prefer to avoid extra plugins, you can insert a snippet into your site\u2019s code. The best place is in a *site-specific plugin* (not in a theme that may change). The snippet is:<\/p>\n<pre><code>add_filter('xmlrpc_enabled', '__return_false');<\/code><\/pre>\n<p>When WordPress loads, this filter returns false whenever xmlrpc is checked, effectively disabling xmlrpc.php. Because it\u2019s done via code, no extra plugin is needed. It\u2019s clean and lightweight. Many guides mention this method. :contentReference[oaicite:9]{index=9}<\/p>\n<p>Important note: Don\u2019t put it in your theme\u2019s <code>functions.php<\/code> if that theme might change. Use a custom or \u201cmust-use\u201d plugin, so it stays intact across updates.<\/p>\n<h3>4.3 Block via .htaccess or Web Server Configuration<\/h3>\n<p>On Apache-based hosts (or where .htaccess is supported), you can block access to xmlrpc.php at the server level. This is a strong approach because requests never reach WordPress. Here\u2019s how:<\/p>\n<pre><code>\r\n&lt;Files \"xmlrpc.php\"&gt;\r\n  Require all denied\r\n\r\n<\/code><\/pre>\n<p>If your server uses older Apache syntax, you might see:<\/p>\n<pre><code>\r\n\r\n  Order deny,allow\r\n  Deny from all\r\n\r\n<\/code><\/pre>\n<p>When this is in your <code>.htaccess<\/code> in your WordPress root, it blocks all requests to xmlrpc.php. Be sure to backup your .htaccess before editing.<\/p>\n<p>If your host uses Nginx (no .htaccess), you might add a rule in the Nginx config, or ask your hosting provider to block access to xmlrpc.php. Some managed hosts already do this.<\/p>\n<h3>4.4 Whitelist Certain IPs (Selective Blocking)<\/h3>\n<p>In some cases, you still need xmlrpc.php\u2014but only from specific trusted IPs (for example, a known external service). You can block everyone except those IPs.<\/p>\n<p>In .htaccess (Apache 2.4+), you might do:<\/p>\n<pre><code>\r\n&lt;Files \"xmlrpc.php\"&gt;\r\n  Require ip 123.123.123.123\r\n  Require all denied\r\n\r\n<\/code><\/pre>\n<p>Replace <code>123.123.123.123<\/code> with the IP you trust. That way, only that address can access xmlrpc.php; all others are blocked. This is helpful if, say, an external tool you use needs it, but you want to lock it down. Many tutorials suggest this selective approach. :contentReference[oaicite:12]{index=12}<\/p>\n<h3>4.5 Delegate to Your Host \/ Use Host-Level Blocking<\/h3>\n<p>If you prefer not to touch code, ask your host support to disable xmlrpc.php for you. Some hosts already block it.<\/p>\n<p>Provide the support team with your domain and request that xmlrpc.php be disabled or blocked. Often, hosts will simply add rules internally so the file cannot be reached.<\/p>\n<p>One caveat: if you later need xmlrpc for a plugin or integration, ask the host to whitelist specific external callers or reverse the block for you.<\/p>\n<h3>4.6 Testing After Disabling<\/h3>\n<p>After you disable xmlrpc.php (by whichever method), always test:<\/p>\n<ul>\n<li>Run the XML-RPC Validator tool again. You should now get an error or \u201cnot found.\u201d<\/li>\n<li>Check your site\u2019s error logs or access logs to confirm that xmlrpc requests are blocked (e.g. 403 status or no access).<\/li>\n<li>Test external functionalities (mobile app posting, Jetpack, etc.) that may have used xmlrpc. Ensure they either fail gracefully or you have a fallback in place.<\/li>\n<li>Monitor site uptime and performance\u2014ensure there\u2019s no unexpected side effect.<\/li>\n<\/ul>\n<p>If anything breaks, revert the change (remove plugin, remove code, remove .htaccess block) and recheck what feature needs xmlrpc. Sometimes, it\u2019s better to selectively block only methods or IPs rather than shut it off entirely.<\/p>\n<h2>5. When It Makes Sense to Keep xmlrpc.php Enabled<\/h2>\n<p>While many small-business WordPress sites will be best off disabling xmlrpc.php entirely, there are scenarios where you might need to keep it\u2014or parts of it\u2014running. Let\u2019s explore those exceptions so you can make an informed decision.<\/p>\n<h3>5.1 You Use Tools That Rely on XML-RPC<\/h3>\n<p>If you use any external software, mobile app, or service that still depends on xmlrpc.php (and hasn\u2019t switched to REST), disabling it might break integration. For example:<\/p>\n<ul>\n<li>Older blogging tools or desktop editors that post via XML-RPC.<\/li>\n<li>Plugins that haven\u2019t been updated and still assume XML-RPC endpoints.<\/li>\n<li>Some remote publishing workflows or automated services using XML-RPC.<\/li>\n<\/ul>\n<p>Before you disable it, verify your ecosystem. If any tool absolutely demands xmlrpc, you\u2019ll need to keep it, or find an alternative plugin that works over REST.<\/p>\n<h3>5.2 Legacy or Very Old WordPress Versions<\/h3>\n<p>If your WordPress installation is very old (pre\u2013REST API era) or if your theme\/plugins are ultra-legacy and haven\u2019t been updated, they may still require XML-RPC. In that case, disabling xmlrpc.php could break core parts of your site.<\/p>\n<p>But note: running such an old setup is itself a risk. If possible, upgrading WordPress, plugins, and themes is <a href=\"https:\/\/www.forestsoftware.co.uk\/blog\/2012\/08\/wordpress-websites-why-you-need-to-keep-them-up-to-date\/\">strongly advised<\/a>. The REST API was integrated into WordPress core several versions ago\u2014there\u2019s almost always a path forward.<\/p>\n<h3>5.3 Partial Blocking \/ Method Restrictions<\/h3>\n<p>Perhaps you don\u2019t want full disablement, but only want to limit risk. Some sites may block only specific XML-RPC methods (for example, disable pingback or login methods) while keeping others open.<\/p>\n<p>Some security plugins or custom rules may allow you to strip out dangerous method calls but keep safe ones. This is more advanced, but can be a compromise if your site depends partially on xmlrpc.php.<\/p>\n<h3>5.4 Whitelisting Access (Hybrid Approach)<\/h3>\n<p>As earlier mentioned, a hybrid approach is: block xmlrpc.php from almost everyone, but allow a few trusted IPs or systems to use it. This reduces risk while preserving functionality for specific users. It\u2019s a good middle ground if you know exactly what is calling xmlrpc.<\/p>\n<p>In many cases, though, small business sites simply don\u2019t rely on xmlrpc for critical functions. After a careful audit, many choose to disable it entirely with no adverse side effects. If uncertain, back up everything and test changes in a staging environment first.<\/p>\n<h2>6. Additional Best Practices &amp; Security Hardening<\/h2>\n<p>Disabling xmlrpc.php is a strong measure, but it should be part of broader site security practices. Here are other tips to secure your WordPress site.<\/p>\n<h3>6.1 Keep WordPress, Themes &amp; Plugins Updated<\/h3>\n<p>Most successful hacks exploit outdated code. Always run WordPress core, theme, and plugin updates promptly. Use reliable plugins from trusted developers.<\/p>\n<h3>6.2 Limit Login Attempts &amp; Use 2FA<\/h3>\n<p>Even if xmlrpc is disabled, your login page remains a target. Use plugins to limit login attempts (e.g. 3\u20135 failed attempts) and enforce two-factor authentication (2FA).<\/p>\n<h3>6.3 Web Application Firewall (WAF) \/ Security Plugin<\/h3>\n<p>A good security plugin or WAF can block malicious traffic before it hits WordPress. Many WAFs allow you to block xmlrpc calls at network level (rather than in WordPress). Cloudflare, Sucuri, and similar tools may be useful.<\/p>\n<h3>6.4 Strong Passwords &amp; Least Privilege<\/h3>\n<p>Ensure all users have strong, unique passwords. Don\u2019t use \u201cadmin\u201d as a username. Limit the number of users with administrator access. Grant only needed roles.<\/p>\n<h3>6.5 Disable File Editing and Hardening wp-config<\/h3>\n<p>Add to <code>wp-config.php<\/code>:<\/p>\n<pre><code>define('DISALLOW_FILE_EDIT', true);<\/code><\/pre>\n<p>This prevents editing theme or plugin files from the dashboard. Also, secure your <code>wp-config.php<\/code> with proper file permissions or .htaccess rules.<\/p>\n<h3>6.6 Monitor Activity &amp; Audit Logs<\/h3>\n<p>Use logging and monitoring plugins (e.g. WP Activity Log or WordFence) to watch user actions, file changes, login failures. Be alerted to unknown changes.<\/p>\n<h3>6.7 Regular Backups (Offsite &amp; Test Restores)<\/h3>\n<p>No security plan is complete without backups. Schedule daily (or frequent) backups, and store them offsite. Test restoring occasionally, so you know your process works.<\/p>\n<h3>6.8 Restrict Access to wp-admin \/ Login by IP<\/h3>\n<p>If possible, restrict access to your WordPress admin URLs to certain IP ranges (your office or trusted addresses). This greatly reduces exposure.<\/p>\n<h2>7. Summary &amp; Final Thoughts<\/h2>\n<p>To recap:<\/p>\n<ul>\n<li><strong>xmlrpc.php<\/strong> is a legacy interface in WordPress that enables remote communication via XML-RPC.<\/li>\n<li>It presents real security risks, especially brute-force attacks and pingback-based DDoS abuse.<\/li>\n<li>Many modern sites no longer need xmlrpc.php, because WordPress\u2019s REST API covers the same roles more safely.<\/li>\n<li>You can check whether xmlrpc.php is active using validators, log inspections, or host support.<\/li>\n<li>There are multiple safe ways to disable or block xmlrpc.php: using a plugin, code snippet, .htaccess \/ server rules, IP whitelisting, or host support.<\/li>\n<li>If your site genuinely depends on xmlrpc functionality, consider a hybrid or partial-block approach rather than blanket disablement.<\/li>\n<li>Disabling xmlrpc.php should be part of a wider security strategy\u2014keeping software up to date, using strong passwords, limiting login attempts, backups, monitoring, etc.<\/li>\n<\/ul>\n<p>Overall, for most small-business WordPress sites in the UK, turning off xmlrpc.php is a smart step that brings good security benefit with minimal downside. But always test changes, back up first, and proceed carefully. If this sounds too technical or risky, it\u2019s perfectly fine to hand the job to someone with experience (often for a modest fee). Professionals know how to do it safely and can undo things if needed.<\/p>\n<hr \/>\n<h2>About the Author: John K Mitchell<\/h2>\n<p>John K Mitchell has been working on search engine optimisation since 1997\u2014yes, before Google even began as we know it. With a programming background, John noticed early that by examining search results he could make educated guesses about why a site ranked the way it did\u2014and then adjust sites accordingly. Over the decades he has applied this insight to thousands of websites, helping many small businesses in the UK and beyond to get better visibility online.<\/p>\n<p>John believes in practical, human-friendly SEO and security advice. He often offers small, one-off services to businesses (such as disabling xmlrpc.php), delivering results without overcomplicated jargon.<\/p>\n","protected":false},"excerpt":{"rendered":"<p><span class=\"span-reading-time rt-reading-time\" style=\"display: block;\"><span class=\"rt-label rt-prefix\">Reading Time: <\/span> <span class=\"rt-time\"> 11<\/span> <span class=\"rt-label rt-postfix\">minutes : <\/span><\/span>A Complete Guide on xmlrpc.php in WordPress (What It Is, Security Risks, How to Disable It) Wondering what xmlrpc.php is in WordPress, or whether you should disable it? This guide walks you through everything\u2014from what it does, through security risks, to how to turn it off safely. If it all sounds a bit technical, don\u2019t [&hellip;]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[4,5],"tags":[],"class_list":["post-2701","post","type-post","status-publish","format-standard","hentry","category-business-advice","category-computers"],"_links":{"self":[{"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2701","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/comments?post=2701"}],"version-history":[{"count":0,"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/posts\/2701\/revisions"}],"wp:attachment":[{"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/media?parent=2701"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/categories?post=2701"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.forestsoftware.co.uk\/blog\/wp-json\/wp\/v2\/tags?post=2701"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}