How to check a sitemap for broken links (with a short Python script)

Seovoro — Tue, 13 Oct 2026 11:27:44 +0000

Your XML sitemap is a list of pages you want search engines to crawl. If it contains pages that no longer exist, pages that redirect, or pages you have blocked, it stops being a clean list. Here is a quick way to check yours.

What should be in a sitemap

Only canonical pages that return a normal 200 status and that you want in search results. Leave out 404 and 410 pages, redirected URLs, pages with noindex, pages blocked in robots.txt and duplicate versions of the same page. One sitemap file can hold up to 50,000 URLs or 50 MB uncompressed.

Step 1: list every URL

Open the sitemap, or use a tool that extracts the URLs. If you use a sitemap index, remember that it points to other sitemap files, so you need to read those too. The script below does that.

Step 2: check the status of each URL

This script reads a sitemap (or a sitemap index), then asks each URL for its status without following redirects. Only run it on your own site, or with permission, and keep the delay so you do not overload the server.

import time
import requests
import xml.etree.ElementTree as ET

SITEMAP = "https://example.com/sitemap.xml"
NS = {"sm": "http://www.sitemaps.org/schemas/sitemap/0.9"}

def urls_from(sitemap_url):
    root = ET.fromstring(requests.get(sitemap_url, timeout=15).content)
    if root.tag.endswith("sitemapindex"):
        for loc in root.findall("sm:sitemap/sm:loc", NS):
            yield from urls_from(loc.text.strip())
    else:
        for loc in root.findall("sm:url/sm:loc", NS):
            yield loc.text.strip()

for url in urls_from(SITEMAP):
    r = requests.get(url, allow_redirects=False, timeout=15)
    if r.status_code != 200:
        print(r.status_code, url, r.headers.get("Location", ""))
    time.sleep(0.3)

Anything printed is a URL that does not return a plain 200.

Step 3: decide what to do

Status	Meaning	What to do
200	Page works	Keep it
301 or 308	Moved permanently	Put the final address in the sitemap
302, 303 or 307	Temporary move	Check whether it should be permanent
404 or 410	Page is gone	Remove it, or restore the page if it should exist
5xx	Server error	Fix the server problem and check again

Step 4: update and resubmit

Remove or replace the bad URLs, upload the new sitemap and submit it again in Google Search Console. Google Search Console's Pages report also lists problems such as "Submitted URL not found (404)", so check it too.

Keep it clean

Generate the sitemap automatically so deleted pages drop out of it, and run this check after every redesign or migration.

If you want a no-code version, our free Sitemap URL Extractor lists every URL in a sitemap, and the Sitemap Validator checks the file itself. The full guide, with more detail, is on seovoro.com.

How We Improved Our Website's Mobile PageSpeed Score From 81 to 100

Seovoro — Mon, 05 Oct 2026 22:02:09 +0000

Website performance matters for both users and search engines.

We recently worked on our own website and improved its mobile PageSpeed score from 81 to 100.

Instead of simply sharing the final score, we wanted to document what we changed, what caused the performance issues, and what the results looked like afterward.

The Starting Point
Before making the changes, our mobile PageSpeed score was:

81 / 100

The website was functional, but there was still room for improvement.

We checked the PageSpeed Insights report to identify which resources and page elements were contributing to the performance issues.

The goal wasn't to blindly optimize everything. We wanted to identify the actual bottlenecks and make targeted changes.

What We Changed
We focused on several areas that commonly affect website performance:

Reduced unnecessary resources We reviewed the CSS and JavaScript being loaded on the page and removed or reduced resources that weren't necessary for the initial page load.

This helped reduce the amount of work the browser needed to perform before the page became usable.

Optimized images Large images can have a significant effect on mobile performance.

We reviewed the images used on the page and optimized them so the browser didn't have to download unnecessarily large files.

We also paid attention to how images were loaded so that they wouldn't interfere with the initial rendering of the page.

Improved CSS delivery We reviewed our CSS and reduced unnecessary styling and resources that were being loaded before the main content could render.

The objective was to make the critical part of the page available to the browser as quickly as possible.

Reduced unnecessary page overhead We also reviewed the HTML structure and other elements that weren't contributing directly to the user experience.

Small improvements across several areas can add up to a noticeable performance difference.

The Result
After making the changes, we ran the page through Google PageSpeed Insights again.

The mobile score improved from:

81 → 100

The final report also showed improved performance metrics compared with the original test.

The important point is that the improvement didn't come from one magic optimization.

It came from identifying several smaller performance problems and addressing them systematically.

Before and After
Before: Mobile PageSpeed — 81

After: Mobile PageSpeed — 100

We captured screenshots of both tests as well as the final performance metrics so the results can be independently reviewed.

What We Learned
One of the biggest lessons from this process is that website performance optimization should be based on measurements rather than assumptions.

Instead of asking:

"What optimization should we try?"
It's usually better to ask:

"What is the performance report actually telling us?"
That approach makes it easier to prioritize the changes that are most likely to have an impact.

Key Takeaways
Measure performance before making changes.
Optimize images and other large resources.
Reduce unnecessary CSS and JavaScript.
Pay attention to what blocks the initial rendering.
Test again after every major optimization.
Don't rely on a single optimization to solve every performance issue.
Keep real before-and-after measurements.
One Important Limitation
A PageSpeed score is useful, but it isn't the entire story.

Real users can have different devices, network conditions, browsers, and geographic locations.

A perfect lab score doesn't automatically mean every visitor will experience a perfect website.

That's why performance should be treated as an ongoing process rather than a one-time task.

Full Case Study
We've published the complete case study on our website, including the detailed before-and-after results, screenshots, metrics, and the changes we made:

https://seovoro.com/single-blog.php?slug=case-study-mobile-pagespeed-81-to-100

If you're working on website performance yourself, hopefully this breakdown gives you a useful starting point.

About Seovoro

Seovoro helps businesses improve their organic search visibility through SEO, technical optimization, content, local SEO, and AI-search strategies.

Website: https://seovoro.com

DEV Community: Seovoro