Setting up SEO packages in MODX: where meta-data output breaks
Meta-data in MODX is assembled from three independent sources: the resource fields themselves, TV parameters, and default values in the template.
If one link fails, the title in the source code is substituted from the site name, description remains empty, and the search engine sees something completely different from what the visitor sees.
Most often, output breaks in four places. Inheritance down the tree: child pages do not override fields, and they repeat the parent's title and description verbatim. Templates with a hard-coded title in a chunk—edits in the admin panel simply do not reach the output.
Cache serving old markup after saving. And pagination pages with filters, where duplicate titles and descriptions appear on their own, without anyone's involvement.
A separate layer is URLs and the sitemap. If canonical is not set, and filters generate dozens of nearly identical URLs, both variants enter the index.
The sitemap includes service sections, while robots.txt does not block them—SEO markup errors on the site accumulate quietly, without a single log entry.
The cost is predictable: empty page descriptions force the search engine to assemble the snippet from a random text fragment, duplicates dilute weight between URLs, and the search result card stops reflecting the real offer.
Below we break down how this is closed—from auditing templates and parameters to rules for generating meta-data and the sitemap.
What changes after implementation: effects in timelines and coverage
The effect of setup is visible in measurable metrics, not feelings.
The share of pages with correctly filled title, description, and canonical URL stops depending on the author's care: values are substituted by templates, so all published materials have markup—cards, categories, collection pages.
A whole class of errors related to duplicate markup disappears. Pagination, sorting, URLs with campaign tags, and mirrors receive unambiguous canonical links and crawl directives, so copies with identical content are cleaned from the index.
The share of indexed pages grows, and site weight is no longer diluted between versions of the same material.
Time for meta-data edits shrinks from hours to minutes. The title and description for an individual page are changed in the MODX control panel, not in templates with re-export; for dozens of similar URLs, one substitution rule is enough. Bulk updates across an entire section stop being a separate task for the developer.
Separately, the risk that new materials enter the index without markup is removed: rules extend to future sections automatically, rather than being added manually.
Acceptance follows a checklist: all published URLs have unique titles and descriptions, the canonical URL is not duplicated, the sitemap covers new sections, and substitution templates work without developer involvement.
Ways to connect modules in MODX: comparison of options
The connection method determines not only the set of fields in the admin panel, but also how predictably meta tags behave across thousands of pages. We break down four alternatives that projects on MODX choose between.
| Option | When it fits | Limitations |
|---|---|---|
| Ready-made SEO packages | typical site with one output template and a flat section structure | meta tag logic is set by the package developer; non-standard fields are difficult to output; with multiple extensions, conflicts are possible |
| Custom template setup | non-standard structure, multiple content types, custom rules for forming titles and descriptions | no ready-made interfaces for editors; all behavior is described per project; higher cost of error during edits |
| Combined connection option | catalog, blog, and promo pages on one site with different output logic | need to monitor template priority so solutions from the extension do not override custom ones |
| Refinement of the existing setup | site is already in search results; a complete change of link structure is unacceptable | we work within the boundaries of current markup; some tasks are solved pointwise |
What we consider when choosing
The review order is simple: we take a map of templates and resource types, look at who publishes materials and how often, and check extension compatibility with current settings.
We run the scheme on a copy—if meta tags and URLs match the previous ones, we switch the production site.
Work order: from template audit to handover of regulations
Work follows a fixed order: first we record the current state, then design the target scheme, and only after that do we edit settings. This way each change is tied to a specific problem, rather than looking like "we redid everything at once."
- Site SEO settings audit. We take a map of templates and fields: how many templates are actually used, where meta tags are assembled from a chunk, and where they are hard-coded in markup, on which pages empty or duplicate values are output.
- Cleanup and inventory. We remove unused templates and fields—extra elements confuse editors and break output when copying a page.
- Designing the page markup scheme. For each content type, we define its own set of fields and inheritance rules: what is filled at the section level, what is overridden on an individual page.
- SEO-friendly URLs and redirects setup. We define URL generation rules—slashes, case, transliteration; we close old URLs with permanent redirects so accumulated weight is not lost.
- Checking meta tag output. We run a control sample: home page, sections, cards, pagination, filter pages. Title, description, and canonical URL must be assembled by one logic.
- Sitemap and robots. We build the sitemap from the same data that goes into markup—it does not diverge from actual URLs.
- Handover of regulations to the team. We provide a document describing fields, rules, and typical errors so new pages can be added without editing templates.
We roll out changes first on a control sample of up to 40 pages, verify the result, and only then apply them to the entire site.
Handover kit: configurations, templates, and update regulations
The kit is assembled so that the markup setup can be raised and developed without the person who configured it. Each artifact covers its own area: one is responsible for field behavior, the second for who has the right to change what, the third for the procedure after release. Below is what exactly remains with the customer in the repository and internal knowledge base.
- SEO package configuration — working field values, template priorities, and system settings exported to files, not locked in the admin panel: settings are deployed to the test setup with one command.
- Template and field scheme — a mapping: which template outputs which markup fields, where values are duplicated, where the title and description for each page type come from.
- Editor access rules — roles and boundaries: what the content manager edits themselves, what goes to the developer, why templates are closed to editing from the control panel.
- Markup documentation — required fields, length limits, heading nesting requirements, examples of correct and broken values.
- Update regulations — sequence for updating the core and packages, markup checks after release, rollback procedure when templates diverge.
- Release acceptance checklist — checkpoints: page availability, correctness of canonical URLs, absence of duplicates, sitemap integrity.
- Dependency map — which settings are tied to templates and plugins, what exactly breaks when they are changed.
Handover is not a file by email, but a walkthrough: the engineer goes through each item with your team on the test setup, shows where a value changes and how to verify the result.
After that, markup edits no longer require an external contractor, and updates proceed without a drop in indexing.
Case study: removed duplicate meta tags on a portal with hundreds of sections
A portal with hundreds of sections: pages are generated by templates, and meta markup is inherited from the parent.
In indexing reports it looked like this—dozens of URLs with identical titles and descriptions, entire catalog branches dropped from search, empty values on filter pages.
The issue was not MODX, but that SEO packages were installed "by default": output rules did not account for nesting level and section type.
Measurements were taken for each page type before edits and recorded as a baseline—otherwise it is impossible to prove that the result came from setting up SEO packages rather than general reindexing. Comparison used the same URLs:
| Metric | Before edits | After |
|---|---|---|
| Pages with unique title | 34% | 96% |
| Pages with unique description | 21% | 93% |
| URLs with duplicate markup | 6 out of 10 | less than 1 out of 20 |
| Share of URLs in the index | 41% | 88% |
What we did
We separated packages by section types, configured title and description output by template taking into account parent and nesting depth, disabled inheritance of empty values, defined rules for pagination, filters, and sorting, and rebuilt the sitemap.
Rules are applied by tree branch: a failed variant is rolled back pointwise, without editing templates and reindexing the entire portal.
What to do if modules are already installed and interfere with each other?
An extension conflict almost never looks like an error—it looks like "meta tags change by themselves." Two packages subscribe to the same events and both consider themselves the owner of the page title.
Who wins depends on registration order and priority, which differs across builds—so behavior seems random.
The order of event processing in MODX is set by numeric priority: a plugin with a lower value runs earlier and can overwrite what the previous one set.
If one package builds the title from a template and the second from a resource field, the result from the one that ran last goes to output. We start debugging with tracing: enable the event log, look at the call chain, and only then change anything.
The second source of discrepancies is settings inheritance. A field value is taken from the resource, if empty—from the parent, then from context and system settings.
Extensions read these levels differently: one substitutes a system value, another gets a parameter hard-coded in the snippet call. Externally identical pages receive different data, and an edit in one place does not reach half the sections.
Cleaning up the existing setup starts with inventory: we list all installed extensions, their events, and write points into fields.
Then we disable them one by one, taking measurements before and after—this shows which package actually affects output and which has been dead weight for years. Settings that duplicate each other are reduced to a single source of truth.
As a result, the project retains a predictable chain: one extension is responsible for meta-data, URL and sitemap generation are separated, and conflicting parameters are removed.
After that, the only question is what data the template is built on—this is what we discuss during task review.
Technical doubts before starting: common engineer questions
Doubts before starting are usually not about the package itself, but about how it will coexist with an already working site: templates, snippets, rules in the server configuration file, and meta tags that editors set manually. Below are four questions that come up most often when setting up SEO packages.
Will the package overwrite our templates and manual meta tags?
No. Setup follows priorities: automation fills only empty fields, and manually set values remain untouched. We first build a map of templates and fields, then enable generation—so manual content edits are not overwritten on the next markup update.
What to do about extension conflicts?
The classic case is two extensions writing to the same tags at the same time. Before setup, we take a list of what is installed and see who else touches meta tags, the sitemap, or redirect rules. We disable duplicates at the plugin level, leaving one data source.
How are redirects checked?
We build an "old URL → new URL" table and run it in full: no more than one hop, no loops, 301 code. We verify against server logs and the template URL map, not selectively across a few pages.
Will already indexed pages suffer?
We do not change URLs; we update markup in waves. After each wave, we compare key sections with search engine data—if a page drops, we roll back the rule pointwise without affecting the rest of the site.
Let's discuss the task: where to start and what we need from your team
To discuss the task substantively, rather than in general terms, we need a snapshot of the project's current state: how meta tag output is currently arranged, which packages are already installed, and what of that is not working as expected.
The more complete the source data from the customer, the more accurate the scope estimate—from experience, lack of access to the staging environment or a list of custom edits shifts the review more than the size of the catalog itself.
- List of domains and subdomains with a section map: which SEO-friendly URL rules are used, where URL duplicates and old structures exist.
- Access: administrative part of the system, hosting panel, webmaster panels, access to server cache and scheduler.
- List of installed packages and snippets responsible for meta tags, sitemap, redirects, and structured data—with screenshots of current settings.
- Templates and chunks where titles and descriptions are formed: show what is generated automatically and what is set manually.
- Export of indexed URLs and redirect map, including the history of migrations and catalog structure changes.
- List of priority sections and target queries, requirements for structured data and language versions.
- Test setup where migrations can be run and markup output checked without risk to the production site.
- Known limitations: hosting limits, caching specifics, errors in logs that interfere with page assembly.
Then we review these materials, compare the behavior of current packages on the staging environment, and return with a scope estimate and setup plan: order of stages, what we roll out first, where rollback points are, which checks close acceptance, and what will be required from your team at each step. Describe the task—we will return with an estimate and plan.
