Rank Math Setup: Schemas, GSC, Redirects for WordPress

Setting Up Rank Math: What Breaks in Site Metadata

Metadata breaks not at setup time, but later — after a bulk import, a change to the output template, or connecting a filter block.

The title template loses variables, and dozens of pages enter the index with the same title: the search engine picks one, the rest are pushed out as duplicates. This is usually noticed by a drop in clicks, not by a data quality report.

Empty meta descriptions look harmless until the snippet starts being assembled from the first paragraph — often a shipping block or a navigation line.

The canonical URL often points to an outdated URL: after the link structure changes, it remains set in the archive settings and diverts signals from the working page to a redirect that itself returns nothing.

The sitemap and indexing directives finish the picture. Service sections, pagination pages, and URLs with sorting parameters get included, while the necessary categories, conversely, remain under noindex — a leftover from migration off a test environment that no one removed.

Crawling spends its limit on junk, useful pages wait their turn for weeks, and the section drops out of visibility entirely.

Setting up Rank Math in this state doesn't help: the plugin dutifully outputs what is in the database and templates.

So we start by crawling the site and checking titles, descriptions, canonical URLs, and indexing directives across each post type, taxonomy, and archive — and only then do we edit the templates. Below, we break down how this is resolved.

What a Correct Metadata and Markup Structure Delivers

Metadata and markup are what the search engine reads before the text itself. If titles and canonical URLs are set manually, some URLs end up excluded: filter duplicates, pagination, empty archives.

Metadata templates solve this systematically — a rule is set once for a post type and then works for all new pages, including those that will appear a year later.

Markup correctness is checked with a validator, not by eye: it finds unfilled required fields, mismatch between the declared object type and the content, and references to non-existent entities.

This class of errors disappears completely — the markup is either valid or flagged as a problem in the report.

The share of excluded pages drops from a third of URLs to a few percent: duplicates are merged with canonical links, and service URLs are intentionally closed. Crawl speed increases because the bot does not spend resources on parameterized URLs and repeated content.

Implementation Options: Module, Manual Markup, Hybrid

A ready-made module, such as Rank Math, covers the standard set: page titles and descriptions, sitemap, structured data, redirects. It assembles markup from templates like "%title% — %sitename%" by entity: posts, pages, taxonomies, archives.

Limitations begin where the structure is non-standard — custom post types, page builder fields, products with variations. The module either does not see this data or outputs it with the wrong hierarchy: duplicate titles or empty descriptions appear in search results.

Manual templates assemble metadata in the theme code for the actual page structure. The trade-off is maintenance: with every layout change, the template must be checked, and an editor without code access can no longer fix the description themselves.

The hybrid approach leaves the base, redirects, and sitemap on the module, and moves custom metadata output into a child theme through filters and hooks — only for those sections where the module cannot cope.

Before choosing, we compare the site structure with the module's capabilities: this removes most revisions before the start, not after the first reindexing.

Work Order: Audit, Setup, Verification, Handover

The work follows an engineering sequence — from capturing the current state to handover with a regulation. This way changes do not break indexing, and the result is visible at every step.

1. Technical audit: we capture current meta tags, the redirect map, schema markup, sitemap status, and Search Console data. We record duplicates, broken chains, and pages without markup.
2. Metadata schema: we describe in a table which title and description template, as well as which schema type, each post type receives — page, post, category, product. We separately check templates for conflicts and empty variables.
3. Setup on a copy: we assemble all rules, maps, and redirects on a test copy of the site to debug the application order without risk to the index.
4. Connecting Search Console and the sitemap: we confirm rights, serve the current sitemap, and remove previous sources so the search engine does not receive conflicting signals.
5. Spot check: we take a sample of URLs by type and compare before and after — response code, canonical, markup, absence of redirect chains longer than one hop.
6. Transfer to the live site: we repeat the same sample to make sure the copy and the main site produce the same result.
7. Maintenance regulation: we hand over a document with rules for adding new templates, the procedure for edits, and control points after theme and module updates.

What We Hand Over: Configurations, Schemas, Regulations

We hand over not panel access, but a working kit that your team can use without us. Everything we set up in Rank Math is described so that routine tasks are handled by the editor and marketer themselves, without pulling us in for every new section or changed URL.

• Template map. Which markup schema — article, product, service, FAQ, breadcrumbs — is attached to each post type and archive, with priorities and conditions. A new category picks up the rules automatically, without manual editing.
• Redirect rules. An "from → to" table with redirect codes, patterns for groups of URLs, and a ban on chains longer than one step: old URLs do not accumulate weight and do not show the visitor a 404 error.
• Markup schemas. Ready-made field sets for articles, products, services, and FAQ, with validator checking and a note on which fields are required and which can be left empty.
• Change log. Date, author, and substance of the edit in templates, markup, and rules — you can see after which change search results dropped or pages fell out of the index.
• Instructions for editors. Where to fill in the title, description, and schema fields, how not to break the canonical URL, and what to do when moving content.
• Verification regulation. Frequency of sitemap crawling, monitoring of scan errors and broken links, and the person responsible for each action.

The kit is self-sufficient: any setting can be repeated or rolled back using the document, without dredging up the message history.

Case: A Catalog of Several Thousand Pages Before and After

A catalog of several thousand product and category pages grew over the years along with manual Rank Math settings — rules were edited point by point, for a specific section.

By the time of the review, mass duplicates had accumulated: hundreds of categories had matching titles and descriptions, and the markup contradicted the content — structured data still contained characteristics and prices from old product cards.

Crawling was worse. Some filters and pagination pages were closed to bots "just in case," and along with them live catalog sections fell out of the index.

The share of pages in the main index stayed around one third, and new positions lingered for a long time in the "discovered, not indexed" status.

What We Did

• Assembled metadata templates by post type: title — from the category name and a key attribute, description — from the first paragraph and main characteristics. Manual edits were left only where the template produced a weak variant.
• Rebuilt canonical URLs: filters and sorting variants no longer generate standalone pages, but lead to the clean category URL.
• Removed unnecessary bans, leaving only service and technical sections closed, and compared the sitemap with the actual structure.
• Matched markup with page content and removed fields that are not on the page.

Result

The share of pages in the main index grew from one third to almost ninety percent, and the number of pages with duplicate metadata dropped to isolated cases.

New categories enter the index in days, not weeks, and template edits are now applied to the entire catalog at once — without manually going through thousands of pages.

What to Do If Another Markup Module Is Already Deployed on the Site

Two modules, each outputting title, description, canonical, and schema markup, create a conflict of two sources: the page code contains two sets of tags and two schemas, and the search engine chooses the suitable variant itself. The snippet becomes unpredictable, and markup errors grow in the webmaster panel.

Changing the markup module is not "enable the new one and disable the old one," but a sequence with verification at every step. First we transfer the settings: title and description templates by post type, indexing directives, sitemap, redirect rules. Only after that does the old module lose the right to output metadata, and only then is it deleted.

The shutdown procedure solves the main task — preserving URLs. If the old module has its own redirects, we export them and transfer them before deactivation, otherwise the rules will disappear with it and some links will start returning an error. We regenerate the sitemap and submit it for recrawling so that already indexed URLs are not lost.

Post-transition check: one schema, one canonical, one set of meta tags for each page type — home, post, category, paginated page. If the module was built into the theme, its templates are edited in the theme files — this is where partial transfer helps.

Doubts Before Starting: Markup, Redirects, Indexing

Before work starts, technical specialists ask the same questions — and this is a good sign: the client understands exactly where markup breaks. Below are four doubts that most often surface at the estimate stage.

What should be done if redirects are already partially configured on the server?

Two rules for one URL create a loop or a chain of redirects: the bot loses the signal, the visitor loses time. We assemble a map of redirects from server rules, plugin settings, and old URLs, remove conflicts, and leave one source of truth.

Is recrawling needed, and when should results be expected?

The search engine will see the edits only after it re-reads the page. We update the sitemap, submit key URLs for recrawling, and use reports to check how many were accepted.

If a URL remains in its old state, we check the response code and canonical URL rather than waiting for recrawling to happen on its own.

Do filters and pagination create duplicate URLs?

Yes, if parameters are not managed: filtered selections and pagination pages turn into dozens of nearly identical URLs. We set canonical URLs for lists, close insignificant filter combinations, and make sure pagination does not fall out of crawling entirely.

Let's Discuss the Task: What Is Needed to Start Work

So that the scope estimate is based on facts rather than guesses, a short list of inputs is enough for us. We assemble it in one meeting — after that we come back with a work plan and timelines. Setting up Rank Math almost always runs into details that are not in the correspondence.

• What has already been done: whether the plugin is installed, which modules are enabled, whether markup schemas and redirects are configured — without this, the scope estimate turns into guesswork.
• Site access: an account with rights to plugins, the hosting panel, and, if available, a Search Console account for the required resource.
• Content types and page templates: how many there are and how they differ — this determines the number of markup schemas that need to be described and checked.
• Redirect map: a table of old URLs and new targets. If it does not exist, we will assemble it together — otherwise rules are debugged one URL at a time.
• Constraints: approval procedure, edit regulations, windows when markup cannot be changed on the site.
• Baseline: an export of positions and statistics before work — so that the result can be compared afterward rather than discussed in words.

Then our part: we review the inputs, estimate the scope, and state timelines and the work order. Describe the task — we will come back with an estimate and a plan.