From site audit to pull request: six suspected issues, three real ones

We ran RankPropel's audit pipeline on a mature website we operate: a multilingual professional-services site with about 2,100 URLs in its sitemap and a translated section in two other languages. The goal was a real pull request, not a slide. What made it worth writing up is what we did not ship.

Status, October 14, 2026 (updated). The pull request is still open and nothing from it is live. A status message said the fix was finished, so we ran the post-deploy check anyway. The live site still serves the old markup, and the owner's deploy pipeline has not shipped any change since early October. The live check below shows what the site serves today. We will add after results when the change is deployed.

How the pipeline works

1. Audit public pages only. The crawler reads robots.txt and the sitemap, samples pages from every section and records status, canonicals, language links (hreflang), language markers, titles, structured data and cache headers. Ten of those pages also went through the RankPropel MCP service, which only ever receives public HTML.
2. Verify every finding a second way. Nothing goes into a fix until an independent check agrees.
3. Read the repository's own rules. This site's repo has an SEO lessons file built from its own Search Console data, an i18n rollout guide and strict release rules. They outrank generic advice.
4. Make the smallest fix that follows existing patterns, with a test.
5. Open a pull request. The owner's build machine finishes the build snapshots, runs CI, merges and deploys. Nobody outside the owner's workflow touches production.
6. Re-audit after deploy.

The three findings that survived

A translated section had no language marker. Every page in one hand-written translated section was fully in another language, yet the only language declaration on the page said English. The site's machine-translated sections already solved this with a lang attribute on the content. The fix copies that pattern with one layout file, using display: contents so the wrapper does not change the page layout. Search engines mostly detect language from visible text, so the search benefit is modest. The clearer gain is for screen readers, which were reading the text with English pronunciation, and for browser translation prompts.

A page claimed the wrong translated counterpart. An English section page declared the translated homepage as its translation. The translated homepage, correctly, pairs with the English homepage. Google ignores language links that are not confirmed from both sides, so the claim did nothing except muddy the signal. There is no translated version of that page, so the fix removes the claim.

A translated page was missing its return link. An English guide linked to its translation, but the translation did not link back, and the pair was missing from the shared registry the site uses to keep these links consistent. The fix registers the pair and adds the return link.

The site already had a test guarding one direction of these links. We added the two missing guards: every registered translation must link back to its English page, and no English page may claim a translation outside the registry. On the old code, the new test fails with exactly the two pages above.

The three findings we withdrew

"English pages don't link to their translations." Our first check reported dozens of one-sided language links. It was wrong. React writes the attribute as hrefLang, our first regular expression only matched lowercase, and HTML attribute names are case-insensitive. Fetching the alternate pages directly showed complete clusters. Shipping a "fix" here would have meant rewriting working code.

"Server responses take two to four seconds." A known-fast site measured just as slowly from the same network. The delay was the auditor's connection, not the site, whose own records show fast cached responses.

"Sitemap dates are missing on about 900 URLs." True. But the repository's SEO lessons, built from its own crawl data, record that sitemap date freshness was not what limited this site's indexing. Without new evidence, we left it alone and said so in the pull request.

Live check: the fix is not live yet

We fetched the affected pages again on October 14 and rendered the relevant markup. Each image shows the live markup on the left and the change waiting in the pull request on the right.

The check also corrected our own acceptance test. The fix marks the Chinese content with a wrapper element, and the root <html> element still says English across the site. An after check that looks only at <html lang> would report a failure even after a good deploy. The check has to look for lang="zh-CN" on the content wrapper.

After deploy, we will check:

• The Chinese pages carry lang="zh-CN" on their content, and the two language links match the pull request on both sides.
• A RankPropel re-audit of the same ten pages, compared with the before audit.
• Over the following weeks, in Search Console: whether the Chinese pages are indexed, and which version Google selects as canonical in URL Inspection.

We are not claiming any ranking or traffic change. These are configuration fixes. The pull request makes the language signals consistent, and the measurements above will show whether that changes anything in search.

What changed in RankPropel because of this run

• The snapshot limit was too small. Three modern pages exceeded the 100,000-character limit. It is now 300,000 characters per page, and the error message names the oversized page and suggests removing scripts first.
• The evidence gate is now part of the pipeline. Each finding needs a second, independent check before it reaches a pull request, and withdrawn findings are recorded in the pull request so reviewers can see what was ruled out.

Why a pull request, not a deploy

The site's owner runs CI and deployment from one machine, with build snapshots that must be regenerated after any source change, and release rules for new URLs. A pull request lets the pipeline do the audit, the reasoning and the code while the owner's process stays in charge of production. In this run, that boundary also caught something: the local build step tried to add 80 scheduled translation URLs to the sitemap. Those belong to the site's own release schedule, so they were left out of the pull request.

If you want the same pipeline for your site, connect an agent to RankPropel, or ask about the audit and baseline sprint.