AI SEO Audit and PHP 8.3 Migration Preparation for MODX Evolution
Technical audit · MODX Evolution · PHP · AI search
Audit of the site of the monument workshop on MODX Evolution: correction of technical SEO, preparation of structured data and verification of the transition to PHP 8.3. The work was carried out on a copy of the site, and the update CMS was checked on a separate stand.
Challenge and conditions of work
The site had a directory of several hundred items and server output pages. It was necessary to check how search engines receive content, which addresses are considered primary and how the site presents information about the company and products.
The client provided files and a database dump. The main audit and corrections were performed offline. To check HTTP headers, response codes and availability of the work site, a separate CLI script was prepared for launch by the client.
Technical SEO
Robots.txt, llms.txt, JSON-LD, canonical, sitemap and response compression.
Updating the environment
Check code under PHP 8.3 and transfer a copy of the site from Evolution 1.4.17 to Evolution 3.5.7.
What is improved in the code and configuration
Robots.txt
Rules for circumvention, restrictions for the administrative part, service directories and parameters of URL were streamlined. After rechecking, a common set of rules was left without conflicting groups for individual bots.
Llms.txt
We prepared a description of the company and navigation through the catalog and articles. Links were collected from the CMS database using the addresses of existing pages.
Schema.org / JSON-LD
Wrote a snippet for the generation of Organization, WebSite and BreadcrumbList, and on the cards – Product and Offer. Data is taken from the fields used on the pages themselves.
FAQPage is formed only when the field of questions and answers is filled. Error handling in the snippet allows you not to interrupt the page output if the markup fails.
Compression of response
Added configuration Gzip/Deflate for HTML, CSS, JavaScript, SVG and fonts. Verification of actual HTTP responses is allocated to the network stage of the audit.
What the recheck found
Before transferring the changes, the address assembly, markup and bypass rules were rechecked. This stage revealed errors in both existing templates and the first version of the new edits.
Extra slash in canonical
The formula in head-chank added slash to the already formed link. The correction was prepared for the original CMS chunk so that it would persist after cache reassembly.
Repeat the domain in JSON-LD
The base address was added to the result of the function, which already returned the full URL. Fixed link build in BreadcrumbList, Product and Offer.
Group conflict robots.txt
In the first version, individual groups of bots did not contain general restrictions. The configuration has been simplified so that prohibitions for service sections remain in the applicable set of rules.
Doubles at sitemap
The card had a 394 record and 381 unique address. Six URLs were repeated two to five times. Possible document conflicts and alias have been made a separate task for verification in CMS.
Removing repeats from unloading does not resolve a possible document conflict by itself. Therefore, the cause of the doubles was not masked by a change in the sitemap generator.
What was left for approval
On the contact page, the visible phone and e-mail differed from the values in the links. The actual data had to be confirmed by the owner. Prior to this, the prepared editing of contacts was not applied.
Questions and answers on behalf of the company were not invented: the FAQPage mechanism was prepared, and its filling was left for real content.
Check code under PHP 8.3
The original copy worked on Evolution 1.4.17 and PHP 7.2.34. To check the update used the second loop with Evolution 3.5.7 and PHP 8.3. These versions relate to the described stage of the project.
The main error group was in the PHPExcel import module. Two more files related to the old image processor, one to the CMS kernel, which is replaced during the update.
Syntactic testing helped to localize the problem components. It does not replace verification of application behavior, extensions and business scenarios.
How to check the transfer of CMS
Old and new copies were launched with separate bases, ports and volumes. The transfer included setting up the connection to the database, transferring the configuration, matching the history of migrations with the scheme and reassembling the service hierarchy of documents.
What did you check?
Proven page types on the new booth returned HTTP 200 without fatal errors and warnings PHP 8.3 in output. Improvements to the JSON-LD, FAQ-block and lazy image loading survived after the transfer.
What remains unresolved
The internal link generator produced numerical ID instead of human-readable paths. At the same time, direct addresses were opened. In the collected cache was missing card alias → id.
The next step was to reassemble through the CMS administrative panel and further diagnose while maintaining the error. Therefore, the result is described as a check of migration on the booth, and not as a complete transfer of the work site.
Outcome of work
- Prepared changes robots.txt, llms.txt, JSON-LD, canonical and compression configuration.
- Revealed duplicates of sitemap and discrepancies in contact information.
- A tool for network verification of the work site was transferred.
- The syntax of 947 files under PHP 8.3 is checked.
- The stand of the new CMS was raised and the problem of link generation was fixed.
Separately, there were actions in the working environment: application of SQL migration, setting up WAF and registration in Bing Webmaster Tools. The result of the audit is specific edits and a list of the next steps with the specified verification restrictions.
Frequent questions
Has your website been fully translated to PHP 8.3?
The article describes the check of transition on a separate stand. Verified pages worked, but internal link generation remained an open question. The completed transfer of the work site is not stated here.
What was the technical preparation for the AI search?
robots.txt correction, llms.txt preparation, JSON-LD generation from CMS data, canonical fix and sitemap validation. This is code and presentation work on the site; the growth of mentions in AI responses in this audit was not measured.
Why check plugins separately from the CMS kernel?
User components may contain incompatible code. In this project, 18 from 21 files with syntactic errors were related to the Excel import module, and two more to the image processor.
What is the syntax verification of 947 files?
It shows which files fail to parse the syntax in the selected version of PHP. To check the real work of the site, you additionally need to launch the application and check user scenarios.
Why didn’t FAQ contacts and contents be fixed immediately?
Visible contacts differed from the values of the links, so confirmation of the owner was required. The content of FAQ was not invented: they prepared a conditional generation of markup from filled CMS data.
When do you need separate safety and recovery work?
If the task involves hacking, malicious code, or restoring site features, it should be considered separately from this compatibility audit. The composition of such works is described on the page of security and site recovery services.