{"id":5181,"date":"2026-09-12T11:51:59","date_gmt":"2026-09-12T08:51:59","guid":{"rendered":"https:\/\/www.dchost.com\/blog\/?p=5181"},"modified":"2026-09-12T06:17:41","modified_gmt":"2026-09-12T03:17:41","slug":"wordpress-permalink-settings-structure-seo-safe-changes","status":"publish","type":"post","link":"https:\/\/www.dchost.com\/blog\/en\/wordpress-permalink-settings-structure-seo-safe-changes\/","title":{"rendered":"WordPress Permalink Settings: Structure, SEO and Safe Changes"},"content":{"rendered":"<div class=\"dchost-blog-content-wrapper\"><div id=\"toc_container\" role=\"navigation\" aria-label=\"Table of Contents\" data-nosnippet class=\"toc_transparent no_bullets toc_numbered toc_title_center\"><p class=\"toc_title\">\u0130\u00e7indekiler<\/p><ul class=\"toc_list\"><li><a href=\"#Why_I_treat_WordPress_permalinks_as_a_production_setting\"><span class=\"toc_number toc_depth_1\">1.<\/span> Why I treat WordPress permalinks as a production setting<\/a><\/li><li><a href=\"#Changing_the_permalink_structure_in_WordPress\"><span class=\"toc_number toc_depth_1\">2.<\/span> Changing the permalink structure in WordPress<\/a><ul><li><a href=\"#Why_Post_name_is_usually_my_starting_point\"><span class=\"toc_number toc_depth_2\">2.1.<\/span> Why Post name is usually my starting point<\/a><\/li><\/ul><\/li><li><a href=\"#Choosing_a_structure_without_creating_future_redirects\"><span class=\"toc_number toc_depth_1\">3.<\/span> Choosing a structure without creating future redirects<\/a><\/li><li><a href=\"#Posts_pages_categories_and_custom_post_types\"><span class=\"toc_number toc_depth_1\">4.<\/span> Posts, pages, categories, and custom post types<\/a><\/li><li><a href=\"#Why_saving_permalinks_can_expose_a_404\"><span class=\"toc_number toc_depth_1\">5.<\/span> Why saving permalinks can expose a 404<\/a><ul><li><a href=\"#OpenLiteSpeed_and_Nginx_need_different_checks\"><span class=\"toc_number toc_depth_2\">5.1.<\/span> OpenLiteSpeed and Nginx need different checks<\/a><\/li><\/ul><\/li><li><a href=\"#Before_changing_URLs_on_a_live_site\"><span class=\"toc_number toc_depth_1\">6.<\/span> Before changing URLs on a live site<\/a><\/li><li><a href=\"#Redirects_are_part_of_the_permalink_change\"><span class=\"toc_number toc_depth_1\">7.<\/span> Redirects are part of the permalink change<\/a><\/li><li><a href=\"#Checks_I_run_after_clicking_Save_Changes\"><span class=\"toc_number toc_depth_1\">8.<\/span> Checks I run after clicking Save Changes<\/a><\/li><li><a href=\"#Symptoms_that_point_to_a_permalink_problem\"><span class=\"toc_number toc_depth_1\">9.<\/span> Symptoms that point to a permalink problem<\/a><ul><li><a href=\"#Posts_work_but_pages_return_404\"><span class=\"toc_number toc_depth_2\">9.1.<\/span> Posts work, but pages return 404<\/a><\/li><li><a href=\"#The_same_URL_works_with_and_without_a_trailing_slash\"><span class=\"toc_number toc_depth_2\">9.2.<\/span> The same URL works with and without a trailing slash<\/a><\/li><li><a href=\"#Turkish_or_other_non-ASCII_characters_create_an_awkward_slug\"><span class=\"toc_number toc_depth_2\">9.3.<\/span> Turkish or other non-ASCII characters create an awkward slug<\/a><\/li><li><a href=\"#The_dashboard_works_but_the_frontend_does_not\"><span class=\"toc_number toc_depth_2\">9.4.<\/span> The dashboard works, but the frontend does not<\/a><\/li><\/ul><\/li><li><a href=\"#Using_WP-CLI_to_inspect_rewrite_settings\"><span class=\"toc_number toc_depth_1\">10.<\/span> Using WP-CLI to inspect rewrite settings<\/a><\/li><li><a href=\"#My_defaults_for_a_new_WordPress_installation\"><span class=\"toc_number toc_depth_1\">11.<\/span> My defaults for a new WordPress installation<\/a><\/li><li><a href=\"#Frequently_asked_questions\"><span class=\"toc_number toc_depth_1\">12.<\/span> Frequently asked questions<\/a><ul><li><a href=\"#Which_permalink_option_is_best_for_WordPress\"><span class=\"toc_number toc_depth_2\">12.1.<\/span> Which permalink option is best for WordPress?<\/a><\/li><li><a href=\"#Will_changing_permalinks_delete_old_posts\"><span class=\"toc_number toc_depth_2\">12.2.<\/span> Will changing permalinks delete old posts?<\/a><\/li><li><a href=\"#Why_do_pages_return_404_after_saving_the_permalink_settings\"><span class=\"toc_number toc_depth_2\">12.3.<\/span> Why do pages return 404 after saving the permalink settings?<\/a><\/li><li><a href=\"#Can_changing_permalinks_harm_SEO\"><span class=\"toc_number toc_depth_2\">12.4.<\/span> Can changing permalinks harm SEO?<\/a><\/li><\/ul><\/li><\/ul><\/div>\n<h2><span id=\"Why_I_treat_WordPress_permalinks_as_a_production_setting\">Why I treat WordPress permalinks as a production setting<\/span><\/h2>\n<p>A WordPress site can look perfectly healthy until someone follows an old post link and gets a 404. The homepage loads. The dashboard works. Then one URL exposes the part nobody tested.<\/p>\n<p>I think of a permalink as more than a pretty address. It is part of your content&#8217;s identity, your redirect plan, your cache behaviour, and the rewrite rules on the server. A bad choice made during installation can stay quiet for months before it becomes a migration problem.<\/p>\n<p>When I investigate one of these tickets, I check the URL, the redirect response, the cache, and the web server configuration together. Looking at only the WordPress setting is rarely enough.<\/p>\n<h2><span id=\"Changing_the_permalink_structure_in_WordPress\">Changing the permalink structure in WordPress<\/span><\/h2>\n<p>Open <strong>Settings &gt; Permalinks<\/strong> in the WordPress dashboard. You will see several predefined structures and a custom structure field.<\/p>\n<ul>\n<li><strong>Plain:<\/strong> Uses URLs such as <code>?p=123<\/code>.<\/li>\n<li><strong>Day and name:<\/strong> Includes the full publication date, such as <code>\/2026\/09\/12\/sample-post\/<\/code>.<\/li>\n<li><strong>Month and name:<\/strong> Includes the year and month in the address.<\/li>\n<li><strong>Numeric:<\/strong> Uses the post ID as the main part of the URL.<\/li>\n<li><strong>Post name:<\/strong> Uses a short slug such as <code>\/sample-post\/<\/code>.<\/li>\n<li><strong>Custom structure:<\/strong> Lets you build the address with structure tags.<\/li>\n<\/ul>\n<p>For most new company sites, blogs, and WooCommerce projects, I start with <strong>Post name<\/strong>. Then I click <strong>Save Changes<\/strong>. That click matters even if you did not change the selected option, because WordPress rebuilds its rewrite rules.<\/p>\n<p>Let me put it this way: choosing an option and leaving the page does not apply anything. On Apache, WordPress may also update the <code>.htaccess<\/code> file when you save.<\/p>\n<h3><span id=\"Why_Post_name_is_usually_my_starting_point\">Why Post name is usually my starting point<\/span><\/h3>\n<p>A URL such as <code>\/wordpress-permalink-settings\/<\/code> is readable and does not become dated when the post is updated. That is useful, but it is not a reason to move every established site to a new structure.<\/p>\n<p>A news site may have a real editorial reason to include the date. An older website may already have thousands of links using its current format. Changing those URLs just because shorter ones look nicer can create more work than value.<\/p>\n<p>Keep working URLs stable. That is the quieter choice.<\/p>\n<h2><span id=\"Choosing_a_structure_without_creating_future_redirects\">Choosing a structure without creating future redirects<\/span><\/h2>\n<p>The right permalink depends on how long your content stays useful, how often categories change, and whether you have a migration plan. SEO is only one part of the decision.<\/p>\n<table>\n<thead>\n<tr>\n<th>Structure<\/th>\n<th>Example<\/th>\n<th>Useful for<\/th>\n<\/tr>\n<\/thead>\n<tbody>\n<tr>\n<td>Post name<\/td>\n<td><code>\/sample-post\/<\/code><\/td>\n<td>Blogs, company websites, and most content projects<\/td>\n<\/tr>\n<tr>\n<td>Month and name<\/td>\n<td><code>\/2026\/09\/sample-post\/<\/code><\/td>\n<td>Sites where the publication month adds useful context<\/td>\n<\/tr>\n<tr>\n<td>Day and name<\/td>\n<td><code>\/2026\/09\/12\/sample-post\/<\/code><\/td>\n<td>Daily news and chronological archive sites<\/td>\n<\/tr>\n<tr>\n<td>Custom structure<\/td>\n<td><code>\/%category%\/%postname%\/<\/code><\/td>\n<td>Projects that genuinely need categories in post URLs<\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n<p>I think twice before using <code>%category%<\/code>. If an editor moves a post from one category to another, the URL may change. A post assigned to multiple categories can also make the chosen category less obvious, depending on the plugin and configuration.<\/p>\n<p>For a new content site, I normally choose <code>\/%postname%\/<\/code>. For product catalogs, I avoid making product URLs depend on categories. A product moving from <em>Accessories<\/em> to <em>Campaigns<\/em> should not need a new address.<\/p>\n<h2><span id=\"Posts_pages_categories_and_custom_post_types\">Posts, pages, categories, and custom post types<\/span><\/h2>\n<p>On the Permalinks screen, you can also change the category and tag bases. WordPress normally uses addresses such as <code>\/category\/hosting\/<\/code> and <code>\/tag\/wordpress\/<\/code>.<\/p>\n<p>You could change the category base to <code>topic<\/code>, producing <code>\/topic\/hosting\/<\/code>. This affects existing category URLs, not just categories created later. Treat it as a URL migration.<\/p>\n<p>WooCommerce adds another layer. Check the product, product category, and product tag settings separately. A page at <code>\/shop\/<\/code> and a product category base of <code>shop<\/code> may conflict with the structure you intended. Slugs need room to breathe.<\/p>\n<p>Custom post types follow the rules registered by their theme or plugin. A portfolio plugin may use <code>\/portfolio\/<\/code>; an events plugin may use <code>\/event\/<\/code>. After changing the general structure, I test one URL from every important content type.<\/p>\n<h2><span id=\"Why_saving_permalinks_can_expose_a_404\">Why saving permalinks can expose a 404<\/span><\/h2>\n<p>A post shown on the homepage does not prove that its individual URL works. WordPress usually does not serve that URL as a physical file. The web server must pass the request to WordPress through rewrite rules.<\/p>\n<p>On Apache, those rules usually live in the <code>.htaccess<\/code> file in the WordPress directory. A typical root installation contains something similar to this:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\"># BEGIN WordPress\n&lt;IfModule mod_rewrite.c&gt;\nRewriteEngine On\nRewriteBase \/\nRewriteRule ^index\\.php$ - [L]\nRewriteCond %{REQUEST_FILENAME} !-f\nRewriteCond %{REQUEST_FILENAME} !-d\nRewriteRule . \/index.php [L]\n&lt;\/IfModule&gt;\nEND WordPress<\/code><\/pre>\n<p>Existing files and directories are served directly. Other requests go to <code>index.php<\/code>. If WordPress is installed under a subdirectory, the paths must match that installation.<\/p>\n<p>Back up <code>.htaccess<\/code> before editing it. I learned that on my first site, after placing a forum plugin&#8217;s rewrite rule in the wrong context and turning the whole site into a 500 error. The browser said only &#8220;Internal Server Error.&#8221; The Apache error log showed the actual mistake. Logs come first now.<\/p>\n<h3><span id=\"OpenLiteSpeed_and_Nginx_need_different_checks\">OpenLiteSpeed and Nginx need different checks<\/span><\/h3>\n<p>OpenLiteSpeed can use Apache-compatible <code>.htaccess<\/code> rules in many WordPress setups. A cache can still make a fixed rule appear broken, so I clear the OpenLiteSpeed cache after testing the rewrite itself. If CyberPanel or another control panel manages the virtual host, I check its configuration before changing files manually.<\/p>\n<p>Nginx does not read <code>.htaccess<\/code>. A common WordPress location block contains:<\/p>\n<pre class=\"language-nginx line-numbers\"><code class=\"language-nginx\">location \/ {\n    try_files $uri $uri\/ \/index.php?$args;\n}<\/code><\/pre>\n<p><code>try_files<\/code> checks for a real file or directory, then sends the remaining request to WordPress. After changing Nginx configuration, test it before reloading:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">nginx -t\nsystemctl reload nginx<\/code><\/pre>\n<p>The first command checks the configuration syntax. The second applies it without stopping the running service. On production servers, I prefer a reload when a restart is not needed.<\/p>\n<h2><span id=\"Before_changing_URLs_on_a_live_site\">Before changing URLs on a live site<\/span><\/h2>\n<p>Record the current setup first. I write down:<\/p>\n<ul>\n<li>The old and new permalink formats.<\/li>\n<li>Important URLs receiving traffic or external links.<\/li>\n<li>Post, page, category, and product URLs in the sitemap.<\/li>\n<li>Plugins and custom post types with their own rewrite rules.<\/li>\n<li>Redirect settings in the cache, CDN, security layer, and web server.<\/li>\n<\/ul>\n<p>I also export the database before making the change:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp db export \/home\/site\/backups\/before-permalinks-$(date +%F).sql<\/code><\/pre>\n<p>This writes an SQL export with the current date in its filename. The command must be run as the correct site user, and the backup directory must already exist and be writable. Check the file afterwards; a command that exits successfully is not the same thing as a tested restore.<\/p>\n<p>On a busy site, I prefer to restore that export on a separate test machine or staging environment. A backup that has never been restored is still an assumption.<\/p>\n<h2><span id=\"Redirects_are_part_of_the_permalink_change\">Redirects are part of the permalink change<\/span><\/h2>\n<p>Imagine the old structure is <code>\/%year%\/%monthnum%\/%postname%\/<\/code> and the new one is <code>\/%postname%\/<\/code>. A broad redirect may handle simple cases, but edited slugs, unusual characters, and manually changed URLs still need individual checks.<\/p>\n<p>If you use a redirect plugin, start with a few representative URLs. I check the old address first:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">curl -I https:\/\/example.com\/2025\/08\/sample-post\/<\/code><\/pre>\n<p>The response should be a single <code>301<\/code> with the correct <code>Location:<\/code> header. Then I request the new URL and expect a successful response. If the old URL redirects to an intermediate URL before reaching the final page, I investigate the chain instead of accepting it.<\/p>\n<p>Old URLs can also remain in menus, post content, image links, XML sitemaps, and structured data generated by plugins. As I explain in <em><a href=\"https:\/\/www.dchost.com\/blog\/en\/how-to-read-and-fix-wordpress-site-health-report\/\">WordPress Site Health: How to Read and Fix the Report<\/a><\/em>, a WordPress warning rarely tells you which layer is broken. The response headers and server logs usually narrow it down.<\/p>\n<h2><span id=\"Checks_I_run_after_clicking_Save_Changes\">Checks I run after clicking Save Changes<\/span><\/h2>\n<p>The homepage is not a sufficient test. I check a few different paths:<\/p>\n<ol>\n<li>Open a post, page, category, and tag in a private browser window.<\/li>\n<li>Create a temporary draft and inspect its generated URL.<\/li>\n<li>Confirm that an old URL returns the expected single 301.<\/li>\n<li>Test menus, internal links, search results, categories, and tags.<\/li>\n<li>On WooCommerce sites, test a product, cart, checkout, and account page.<\/li>\n<li>Clear the cache and CDN, then repeat the test from another network.<\/li>\n<li>Watch access and error logs for new 404 or 500 responses.<\/li>\n<li>Check crawl and indexing reports in Google Search Console over the following days.<\/li>\n<\/ol>\n<p><em><a href=\"https:\/\/www.dchost.com\/blog\/en\/how-to-read-google-search-console-performance-report\/\">How to Read the Google Search Console Performance Report<\/a><\/em> covers the traffic and query reports. After a URL change, I look at impressions and indexing as well as clicks.<\/p>\n<p>Not every 404 is a failure. Typos and intentionally removed pages appear in logs too. Repeated requests for the same old URL usually mean an external link or internal reference still needs attention.<\/p>\n<h2><span id=\"Symptoms_that_point_to_a_permalink_problem\">Symptoms that point to a permalink problem<\/span><\/h2>\n<h3><span id=\"Posts_work_but_pages_return_404\">Posts work, but pages return 404<\/span><\/h3>\n<p>Start by visiting the Permalinks screen and clicking <strong>Save Changes<\/strong> without changing the structure. If that does not help, inspect <code>.htaccess<\/code>, the Nginx <code>try_files<\/code> rule, permissions, and the server error log.<\/p>\n<p>Do not jump straight to <code>chmod 777<\/code>. It changes the permission problem&#8217;s appearance without fixing its cause.<\/p>\n<h3><span id=\"The_same_URL_works_with_and_without_a_trailing_slash\">The same URL works with and without a trailing slash<\/span><\/h3>\n<p>WordPress, the web server, the CDN, and an SEO plugin may each be trying to control canonical redirects. Decide which layer owns that redirect and make the others agree. Three competing redirect rules are not redundancy; they are a future debugging session.<\/p>\n<h3><span id=\"Turkish_or_other_non-ASCII_characters_create_an_awkward_slug\">Turkish or other non-ASCII characters create an awkward slug<\/span><\/h3>\n<p>WordPress generally converts these characters into URL-safe slugs, but I still prefer to set short slugs manually. If a title changes, I usually keep the existing slug. If I change it, I add a 301 from the old address.<\/p>\n<h3><span id=\"The_dashboard_works_but_the_frontend_does_not\">The dashboard works, but the frontend does not<\/span><\/h3>\n<p>This usually sends me toward the rewrite or cache layer. I test with a basic theme and temporarily disable relevant plugins on staging, then check the web server logs. Random file edits only make the trail harder to follow.<\/p>\n<h2><span id=\"Using_WP-CLI_to_inspect_rewrite_settings\">Using WP-CLI to inspect rewrite settings<\/span><\/h2>\n<p>With SSH access, WP-CLI gives me a direct view of the stored setting:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp option get permalink_structure<\/code><\/pre>\n<p>Output such as <code>\/%postname%\/<\/code> means the site uses the Post name structure. Empty output means the Plain structure is active.<\/p>\n<p>To refresh the rewrite rules stored by WordPress, run:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp rewrite flush<\/code><\/pre>\n<p>This cannot create a missing Nginx rule or repair a damaged Apache configuration. On Apache or OpenLiteSpeed, <code>--hard<\/code> can also write the WordPress rules to <code>.htaccess<\/code>:<\/p>\n<pre class=\"language-bash line-numbers\"><code class=\"language-bash\">wp rewrite flush --hard<\/code><\/pre>\n<p>I use that option only after backing up the existing file and confirming that WordPress owns the expected document root. A successful WP-CLI command does not prove that the request will pass through the correct virtual host.<\/p>\n<p>If a migration also changes the domain, back up before using <code>wp search-replace<\/code>. Run it on staging first with <code>--dry-run<\/code>; an incorrect scope can damage serialized data or update values that should have stayed untouched.<\/p>\n<h2><span id=\"My_defaults_for_a_new_WordPress_installation\">My defaults for a new WordPress installation<\/span><\/h2>\n<p>After setting the domain, SSL, and homepage, I normally choose <code>\/%postname%\/<\/code>. I set category and tag bases according to the project, then test a page, category, tag, and any custom post type from outside the dashboard.<\/p>\n<p>For WooCommerce, product URLs do not depend on category paths unless the project has a strong reason for that hierarchy. For content sites, I use short, stable slugs. If the date has no editorial purpose, I leave it out.<\/p>\n<p>One support ticket still influences how I work. A misplaced rule in <code>.htaccess<\/code> left the homepage working while posts returned 500 errors. The permalink selection looked suspicious, but the Apache error log showed that the rule was being used in the wrong context. Restoring the backup and rebuilding the rules fixed it.<\/p>\n<p>My order is simple: backup first, logs second, manual editing last.<\/p>\n<h2><span id=\"Frequently_asked_questions\">Frequently asked questions<\/span><\/h2>\n<h3><span id=\"Which_permalink_option_is_best_for_WordPress\">Which permalink option is best for WordPress?<\/span><\/h3>\n<p>For most blogs and company websites, <strong>Post name<\/strong> provides a short, maintainable structure. News sites may have a genuine editorial reason to include the date.<\/p>\n<h3><span id=\"Will_changing_permalinks_delete_old_posts\">Will changing permalinks delete old posts?<\/span><\/h3>\n<p>No. The posts remain in the database, but their URLs change. Without 301 redirects, visitors and search engines may receive 404 responses at the old addresses.<\/p>\n<h3><span id=\"Why_do_pages_return_404_after_saving_the_permalink_settings\">Why do pages return 404 after saving the permalink settings?<\/span><\/h3>\n<p>The server is probably not applying the rewrite rules correctly. Check <code>.htaccess<\/code> on Apache or OpenLiteSpeed, the <code>try_files<\/code> rule on Nginx, and the relevant error logs.<\/p>\n<h3><span id=\"Can_changing_permalinks_harm_SEO\">Can changing permalinks harm SEO?<\/span><\/h3>\n<p>It can create traffic and indexing problems if old URLs do not redirect. Reduce the risk with a tested 301 map, an updated sitemap, corrected internal links, and a staging test before changing the live site.<\/p>\n<\/div>","protected":false},"excerpt":{"rendered":"<p>Choose and change WordPress permalink settings safely. Learn about URL structures, 301 redirects, rewrite rules, WP-CLI checks, and post-change testing.<\/p>\n","protected":false},"author":4,"featured_media":5178,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[183],"tags":[502,367,503,501,272,356,116,402],"class_list":["post-5181","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-wordpress","tag-301-redirects","tag-apache","tag-nginx","tag-permalinks","tag-seo","tag-woocommerce","tag-wordpress","tag-wp-cli"],"_links":{"self":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5181","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/users\/4"}],"replies":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/comments?post=5181"}],"version-history":[{"count":1,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5181\/revisions"}],"predecessor-version":[{"id":5183,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/posts\/5181\/revisions\/5183"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media\/5178"}],"wp:attachment":[{"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/media?parent=5181"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/categories?post=5181"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.dchost.com\/blog\/en\/wp-json\/wp\/v2\/tags?post=5181"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}