What an agent is told, and the report behind it.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: robots.txt rules do not apply to named agents (ROBOTS_RULES_SHADOWED, medium severity)
Page: https://denverpost.com/robots.txt
What was measured: 3 named User-agent groups (3 agents) do not repeat 8 of the Disallow rules the `*` group carries. A crawler obeys only its own most-specific group and ignores `*` entirely, so those rules do not apply to any of the named agents. Worst group: `amazonadbot` bypasses /wp-admin/, /cgi-bin/, /wp-includes/, /xmlrpc.php, /wp-content/plugins/, /wp-content/cache/, /trackback/, /comments/.
Why it matters: A crawler reads only the User-agent group that matches it best and ignores every other group, including `*`. Naming an agent and giving it only `Allow: /` therefore deletes all of your `*` Disallow rules for that agent. The file still parses and the agent still reaches your homepage, so this is invisible on inspection — but the paths you meant to keep out of search are open, and search engines will crawl and may index them.
How to fix it: Every User-agent group that names a crawler must repeat the Disallow rules you want applied. A named group with no rules means 'allow everything' for that crawler.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/ROBOTS_RULES_SHADOWED
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when ROBOTS_RULES_SHADOWED is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: Two business records on this page claim the same identity (ENTITY_COLLISION, medium severity)
Page: https://denverpost.com/
What was measured: 1 identity collision in this page's structured data: two nodes share the same url.
Why it matters: A system resolving which business this page is about has more than one candidate for one identity. Two LocalBusiness or Organization nodes sharing a phone number, an @id or a coordinate pair give a retrieval system no way to decide which record is the entity, so it may pick either or neither. This reads only what the page declares - it does not assert the business is duplicated or wrongly located.
How to fix it: Merge the duplicate business nodes into one, keep a single @id, and remove any plugin that emits a second empty LocalBusiness record.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/ENTITY_COLLISION
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when ENTITY_COLLISION is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: The homepage depends on files this site's own robots.txt disallows (RENDER_RESOURCE_BLOCKED, medium severity)
Page: https://denverpost.com/robots.txt
What was measured: 15 render resources referenced by the homepage are disallowed to every crawler by this site's own robots.txt: /wp-content/plugins/dfm-trust-indicators/dist/css/style.min.css (/wp-content/plugins/), /wp-content/plugins/mng-digisubs/static/mng-digisubs.styles.css (/wp-content/plugins/), /wp-content/plugins/loader-wp/static/loader.min.js (/wp-content/plugins/), /wp-content/plugins/mng-digisubs/static/mng-digisubs.shared.bundle.js (/wp-content/plugins/). A crawler that obeys robots.txt will not fetch these, so it renders the page without them.
Why it matters: Googlebot renders pages, and a stylesheet or script it is forbidden to fetch is rendered without. Layout, visibility and any content a script inserts are then judged from a page the site never intended to show. Only rules in the * group count here - a rule aimed at one named crawler is a narrower question.
How to fix it: Allow crawlers to fetch the CSS and JavaScript the page depends on. Remove the Disallow rules covering those paths, or serve the content without them.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/RENDER_RESOURCE_BLOCKED
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when RENDER_RESOURCE_BLOCKED is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: Almost nothing a machine receives from this page is readable text (PAGE_IS_MOSTLY_CODE, medium severity)
Page: https://denverpost.com/
What was measured: 4.4% of 313,548 decompressed bytes is visible text, and the largest single block is inline css at 44,440 bytes
Why it matters: A crawler pays for every byte it fetches and can only quote the text. Under 5% readable content means an answer engine downloads the whole page and comes away with almost nothing it can use — the difference between being quotable and being skipped. The content-ratio row above passes at 20%, so without this a page at 2% and a page at 19% were scored identically.
How to fix it: Move inline CSS and JavaScript into external files, drop unused page-builder styling, and make sure the words a visitor reads are in the HTML itself.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/PAGE_IS_MOSTLY_CODE
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when PAGE_IS_MOSTLY_CODE is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: The sitemap does not say when anything changed (SITEMAP_NO_LASTMOD, low severity)
Page: https://denverpost.com/sitemap.xml
What was measured: 9,068 child sitemaps listed, none carrying a lastmod date.
Why it matters: The sitemap lists URLs but carries no usable lastmod dates: either none at all, or one date copied onto every URL, which says everything changed at once and so says nothing. Either way it tells a crawler what exists and not what changed. A crawler with a budget uses lastmod to decide what to re-fetch; without it, the choice is made for you — usually by re-crawling little and late. This is the change signal every crawler already understands, and unlike a push protocol it needs no key, no account and no participation from the search engine.
How to fix it: Give each sitemap entry its own <lastmod>: the date that page last changed, not the date the sitemap was built. Then a crawler can prioritise the pages that changed.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/SITEMAP_NO_LASTMOD
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when SITEMAP_NO_LASTMOD is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: The published coordinates are not in the country the address names (GEO_COUNTRY_MISMATCH, low severity)
Page: https://denverpost.com/
What was measured: This page declares latitude 39.7392, longitude 104.9903 beside an address in US (read from addressRegion). negating the longitude puts it inside US - a missing minus sign.
Why it matters: Two facts in the same record disagree about where the business is. Anything that trusts the coordinate over the address is sent to the wrong place, and a range check cannot catch it because the value is a legal longitude. Nobody proofreads a number that never renders on the page.
How to fix it: Change what the server sends at that path so the finding no longer applies.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/GEO_COUNTRY_MISMATCH
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when GEO_COUNTRY_MISMATCH is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: The homepage is reached through a chain of redirects (REDIRECT_CHAIN, note severity)
Page: https://denverpost.com/
What was measured: http://denverpost.com/ takes 2 redirects to reach the page: 301 permanent (http→https) → 301 permanent (apex→www) → https://www.denverpost.com/ (200). Point the first redirect straight at the final address.
Why it matters: Reaching the homepage takes more than one redirect, for example http to https and then the domain to www. Each hop is another request and round trip before a crawler or visitor gets the page, temporary hops (302, 307) tell search engines to keep the old address, and Google stops following after ten.
How to fix it: Send every old address straight to the final one in a single permanent (301 or 308) redirect: in the host, CDN or plugin rules, redirect http://domain and http://www straight to the final https address instead of chaining scheme, host and path fixes.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/REDIRECT_CHAIN
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when REDIRECT_CHAIN is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: No llms.txt (NO_LLMS_TXT, note severity)
Page: https://denverpost.com/llms.txt
What was measured: Not present: /llms.txt answered HTTP 404.
Why it matters: Not a defect. llms.txt is an emerging convention for telling AI systems what a site is and which pages matter.
How to fix it: Publish /llms.txt: a short Markdown file naming the business, what it does, and the pages worth reading, served as text/plain or text/markdown.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/NO_LLMS_TXT
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when NO_LLMS_TXT is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: The machine files cost more than the page (MACHINE_CHAIN_HEAVY, note severity)
Page: https://denverpost.com/
What was measured: The machine files a crawler reads before the page total 893,406 bytes, 2.84x the homepage HTML (314,053 B); the heaviest are /sitemap.xml 888,839 B, /robots.txt 4,567 B. An absent agent file answers 404 with 95,281 bytes of HTML on average (/agents.md, /.well-known/agent-skills/index.json, /.well-known/mcp/server-card.json, /.well-known/api-catalog, /.well-known/media-kit.json) - a crawler probing for a file that is not there pays for a page each time; a short 404 body costs nothing to serve.
Why it matters: A crawler reads robots.txt, the sitemap, llms.txt and the agent files before the first page, and pays for every 404 that answers with a full page. Keep machine files as small as their job allows and serve absent paths with a short 404 body.
How to fix it: Change what the server sends at that path so the finding no longer applies.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/MACHINE_CHAIN_HEAVY
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when MACHINE_CHAIN_HEAVY is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: Private files or live keys are readable by anyone (advisory: not in the grade yet) (SECRETS_EXPOSED, note severity)
Page: https://denverpost.com/
What was measured: Readable by anyone: Private key private key block in /wp-content/plugins/mng-digisubs/static/mng-digisubs.shared.bundle.js.
Why it matters: A file the site should never serve (a .git or .svn folder, a .env file, a config backup) answered with its own contents, or a live API key or private key is written into the homepage or the site's own scripts. Anyone who requests the same address gets the same bytes: database passwords, keys and source history are the first things an attacker tries. Each path was requested once and counts only when it answers with the file itself, never with a page.
How to fix it: Deny the listed paths at the server (or delete the files), then treat every password and key they contained as public: change the passwords and revoke and reissue each key shown. Remove keys from page code and scripts; a key a browser needs must be a publishable one.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/SECRETS_EXPOSED
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when SECRETS_EXPOSED is gone from the new report.

You are working in the codebase (or server/CDN configuration) that serves denverpost.com. A crawler audit found the problem below. Fix it at the source, keep the change as small as possible, and do not change anything a visitor sees unless the fix requires it.

Finding: 4 off-site listings carry this phone number and the site never links them (NAP_UNDECLARED_LISTING, note severity)
Page: https://denverpost.com/
What was measured: Searched YellowPages, DexKnows, BBB by (303) 954-1010. A listing the site does not declare is one an engine corroborates without you: whatever it prints becomes your name, hours and category in the answer.
Why it matters: Declare the ones you own in sameAs so the entity graph and the directory agree, and correct or claim the ones you do not.
How to fix it: Change what the server sends at that path so the finding no longer applies.
Detected platform: WordPress. Make the change where this platform controls it.
Rule and examples: https://crawlcheck.io/rules/NAP_UNDECLARED_LISTING
Full report (markdown): https://crawlcheck.io/r/aasc46z1wv.md

When you are done:
1. Tell me which files or settings you changed and why.
2. If the fix is a server, CDN or cache setting you cannot change from the code, say exactly where it is set.
3. After deploying, re-scan at https://crawlcheck.io/?url=denverpost.com . The fix counts when NAP_UNDECLARED_LISTING is gone from the new report.