I Built an IRCTC Refund Calculator: How to Estimate Your Refund

A Canceled Trip, An Unexpected Project

Have you ever spent weeks planning a perfect schedule only to see it fall apart due to things you cannot control? This month was supposed to be a special one for my family. We had organized a spiritual journey to the Maa Vaishno Devi shrine in Jammu. I had already secured our train seats and confirmed our stay to ensure everything would run smoothly. It was more than just a vacation; it was a rare chance for us to connect and share a meaningful experience.

In life, just as in any complex project, unexpected changes can ruin even the best-laid plans. A few days before we were set to leave, reports of heavy rain turned into serious warnings about landslides. We watched the news closely, hoping for the best, until the official announcement arrived. For safety reasons, the railway authorities officially canceled our train.

The disappointment was heavy. As we began the task of undoing our preparations, a practical problem emerged regarding our return trip. While the first train was canceled by the provider, the return train was still active. To get my money back, I had to manually cancel the return ticket myself.

The Conundrum: Navigating the Maze of Refund Rules

Before I clicked the cancel button, I stopped to think. I wanted to know exactly how much of my money would be returned. In India, these rules are notoriously difficult to understand. The final amount is based on several different factors, which makes the whole process feel like a confusing puzzle.

Why It Matters

The final refund is determined by a specific set of rules. Each detail you enter can change the final result significantly. During my research, I realized I had to account for many different parts of the system.

• Ticket Status: The rules change depending on whether your seat is fully confirmed or if you are on a waiting list.
• Time of Cancellation: The amount they take out increases as you get closer to the departure time. There are different rules for more than 48 hours, the 12 to 48 hour window, and the final 4 hours before the train leaves.
• Travel Class: The basic fee they keep is different for every type of carriage, from simple seating to luxury air-conditioned cars.
• Booking Type: The rules for a standard ticket are very different from a last-minute "emergency" booking. In many cases, a last-minute confirmed booking is non-refundable.

Trying to do this math by hand was a frustrating and unclear process. I spent a lot of time reading through old rulebooks and online discussions. It was at this point that I had an idea: instead of just solving this for myself, I could build a tool to help everyone else.

From Frustration to Function: Building the IRCTC Refund Calculator

I decided to turn my frustration into a useful project. My goal was to create a tool that would make this process clear and simple for any traveler. Let us talk about how I designed the solution.

The Goal: Simplicity and Clarity

I wanted to build a web tool that felt clean and easy to use. It needed to ask for the most important details in plain language and give an instant, reliable answer. This led me to create the IRCTC Refund Calculator.

How It Works

The heart of the tool is a simple form designed to capture the specific details needed for the calculation. I focused on making it fast to read and easy to fill out. The form asks for:

• The total number of travelers.
• The class of travel.
• The booking category.
• The current status of the seat.
• The exact time you plan to cancel.
• The total price you paid for the ticket.

Behind the scenes, I wrote a program that follows the official rules exactly. It identifies your specific situation and applies the correct fees instantly. Whether you are canceling a day early or just a few hours before the trip, the tool gives you an immediate estimate.

More Than Just a Calculator: An Educational Tool

I prefer tools that explain "why" instead of just giving a final number. To help users feel more confident, I added an educational section. In practice, the results page shows detailed information broken down into easy sections.

• Confirmed Tickets: An explanation of how the percentage-based fees and flat fees work together.
• Online Procedures: Best practices for how to cancel a digital ticket correctly.
• Special Cases: What to do if the train is canceled by the company or how to file a special request after the schedule is finalized.

Pro Tip: Always check if the final passenger list has been prepared before you try to cancel. Once that list is made, you usually cannot cancel online and must file a special form to get your money back.

A Silver Lining: Turning a Setback into a Solution

In the end, the disappointment of a canceled trip became a project I am very proud of. Our journey may have been delayed, but it led to a practical tool that can help many other people avoid stress. I believe that consistent effort to solve these common problems is the best way to help a community.

Dealing with travel problems is already hard enough. You should not have to worry about the math of your refund as well. While the calculator is very accurate, please remember that the final amount might be slightly lower due to small bank fees that cannot be avoided.

This experience was a great reminder for me. Often, our biggest frustrations are the starting point for our most useful and inspired ideas. I encourage you to look at your own problems and see if you can build a solution that helps others too.

How to Build a Local SEO Chrome Extension with the uule Parameter

As an SEO practitioner, I know that viewing search results exactly as they appear in a specific city or country is a constant requirement. Do you know that the same keyword can produce vastly different results in New York compared to Sydney? This variance directly impacts your campaigns, reporting, and local SEO audits.

I have found that VPNs or location-spoofing tools can sometimes work, but they are often slow, unreliable, or expensive. I wanted a fast, accurate, and browser-based solution. To solve this, I built Search Like Local. This Chrome extension lets you perform searches from any city or country instantly.

In this post, I will share the step-by-step technical implementation. We will talk about how I handled Google’s uule parameter, which is the core of location-specific Google searches.

Step 1: Understanding Google’s uule Parameter

Why it matters: When you inspect Google search URLs for different locations, you will notice a mysterious parameter called uule. For example, consider this URL: https://www.google.com/search?q=carpet&hl=en&gl=au&uule=w+CAIQICIGc3lkbmV5.

Here is what each part represents:

• q: the search query
• hl: the language, such as en for English
• gl: the country, such as au for Australia
• uule: encodes the specific location, including the city or region

What is uule?

In practice, uule is a Base64-like encoded string that tells Google to return results as if the user is physically in that location. It allows for precise local SERP simulations.

Without uule, Google may only consider your country (gl) but not the exact city. For SEO professionals, this distinction is critical because a keyword might rank first in one city and tenth in another. By generating uule dynamically, you can simulate searches from any city in the world instantly without VPNs or proxies.

Pro Tip: Always verify your location string matches Google's canonical names. If the name is off by a single character, the uule parameter will fail to trigger the local SERP.

Step 2: Populating Dropdowns for Countries, Languages, and Google Domains

To let users select exactly where and how to search, I created dropdowns for several key metrics. These include ISO country codes, Google-supported languages, and all Google TLDs (Top-Level Domains) like google.com or google.com.au.

const countries = { "US": "United States", "AU": "Australia", "GB": "United Kingdom" }; const countrySelect = $("#countrySelect"); Object.keys(countries) .sort((a, b) => countries[a].localeCompare(countries[b])) .forEach(code => { countrySelect.append(`<option value="${code.toLowerCase()}">${countries[code]}</option>`); });

The languages and domains dropdowns are populated similarly. Sorting alphabetically ensures the UI is user-friendly and easy to navigate for the practitioner.

Step 3: Handling Keyword Modes

The extension supports two distinct keyword modes. Single keyword mode is for simple, fast searches, while multi-keyword mode allows you to enter multiple queries at once for bulk audits.

I ensured the multi-keyword input box auto-resizes dynamically to improve usability:

$('#multiKeywordInput').on('input', function() { this.style.height = 'auto'; this.style.height = (this.scrollHeight) + 'px'; });

This ensures that all keywords are visible and prevents scroll overflow. This small adjustment significantly improves the experience during extensive bulk testing.

Step 4: Saving User Preferences

I know that SEO professionals often perform repetitive searches. To streamline this workflow, I implemented Chrome storage to save user settings. This allows you to leverage your previous configurations without starting from scratch.

$("#saveSettings").on("click", function() { const settings = { keywordMode: $('input[name="keyword-mode"]:checked').val(), selectedCountry: $('#countrySelect').val(), selectedLanguage: $('#languageSelect').val(), selectedLocation: $("#locationInput").val().trim(), selectedDomain: $('#domainSelect').val() }; chrome.storage.local.set(settings, () => { $('#save-feedback').text("Settings saved!").css('opacity', 1); setTimeout(() => { $('#save-feedback').css('opacity', 0); }, 2500); }); });

This makes the extension ready for repeatable searches. You can get straight to the analysis without re-entering details every time.

Step 5: Generating the uule Parameter

The most important technical component is the logic that generates the uule code. This is where we model the string that Google understands.

function generateUULE(canonicalName) { if (!canonicalName) return ""; try { const key = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789-_"; const encodedName = btoa(unescape(encodeURIComponent(canonicalName))); return 'w+CAIQICI' + key[canonicalName.length] + encodedName.replace(/=/g, ''); } catch (e) { console.error("UULE generation failed:", e); return ""; } }

The process takes the location name, such as "Sydney, Australia," and outputs the uule string. This string is then appended to the Google search URL to facilitate precise location-based SERP simulation.

Step 6: Constructing Search URLs

When a user clicks the Search button, the extension builds the URLs dynamically. I usually automate this so each keyword opens in a new tab.

const searchUrl = `https://www.${selectedDomain}/search?q=${encodeURIComponent(query)}&hl=${language}&gl=${country}&uule=${uuleCode}&num=10&sourceid=chrome&ie=UTF-8`; chrome.tabs.create({ url: searchUrl });

The URL includes the language, the country, and the exact location. I also add num=10 to ensure we capture the top 10 results for a clean audit view.

Step 7: Handling Technical Challenges

During development, I encountered several technical hurdles. I prefer to be transparent about these because they often impact tool reliability.

• Encoding uule for special characters: Cities like "São Paulo" require encodeURIComponent combined with btoa to avoid parsing errors.
• Multi-keyword input handling: Each keyword generates a separate URL, so I had to filter out empty lines and whitespace.
• Compatibility across Google domains: I tested extensively on google.com.au and google.co.uk to ensure consistent behavior across different TLDs.
• Performance optimization: Opening too many tabs simultaneously can crash a browser, so I implemented limits to protect the user's workspace.

Step 8: Examples of uule

Here are a few examples of how these strings appear after processing:

Location	Generated uule
Sydney, Australia	w+CAIQICIRU3lkbmV5LCBBdXN0cmFsaWE
New York, USA	w+CAIQICINTmV3IFlvcmssIFVTQQ
London, UK	w+CAIQICIKTG9uZG9uLCBVSw

These codes allow for exact SERP simulation for those specific cities. This is invaluable data for any local SEO audit.

Step 9: Real-World SEO Application

Let us talk about a typical use case. Suppose you are auditing the keyword "coffee shop" across Sydney, Melbourne, and Brisbane. Using the multi-keyword search, the extension opens separate tabs with the correct uule codes automatically.

In practice, you can instantly see how rankings differ city by city. This allows you to help your clients optimize their local SEO campaigns with actual localized data rather than generic national averages.

Step 10: Key Takeaways

• uule is the game-changer for local SEO testing and precise audits.
• Chrome extensions can effectively combine UI controls with dynamic URL generation to save time.
• Multi-keyword and multi-location support makes bulk auditing fast and efficient for the practitioner.
• Handling encoding and Google domains correctly is critical for tool robustness.

Step 11: Conclusion

With Search Like Local, SEO professionals can finally see true location-specific SERPs without relying on expensive VPNs. By combining country selection, multi-keyword search, and dynamic uule generation, I built a tool that is fast, reliable, and highly practical.

Consistent execution of local SEO audits requires reliable data. If you are curious about how your keywords rank in different cities, give it a try: Search Like Local on Chrome Web Store.

Solving the "Sitemap could not be read" Error in GSC | Case Study

When you’re managing a large-scale website with over 500,000 pages, getting everything properly indexed in Google is always a challenge. I recently worked on an Australia-specific website built on Laravel, and one of my first priorities was to make sure all those pages were correctly submitted to Google Search Console (GSC).

To do this, we created multiple XML sitemaps and submitted them through GSC. But instead of smooth indexing, I was met with a frustrating error message:

“Sitemap could not be read.”

At first, a few sitemaps went through without any issues, but the majority kept failing. If you’ve ever run into this problem, you know how discouraging it feels — especially when you’re working on a big project where indexing efficiency directly impacts visibility in search results.

In this post, I’ll break down what this error actually means, why it happens, and how I ultimately solved it for this half-a-million-page website.

2. What the Error Means

The “Sitemap could not be read” error in Google Search Console doesn’t always mean your sitemap is completely broken. It simply means Googlebot was unable to access or process it correctly.

Here are the most common reasons this error shows up:

• Invalid Sitemap Format → The file isn’t a proper XML sitemap (e.g., wrong tags, encoding issues, or not following the protocol).
• Server Issues → The sitemap URL returns errors like 403 (forbidden), 404 (not found), 500 (server error), or times out before Google can fetch it.
• Redirects in Sitemap URL → If the sitemap link redirects (HTTP → HTTPS or www → non-www), GSC may fail to read it.
• Blocked by Robots.txt or Headers → Sometimes the sitemap file is accidentally blocked from crawling.
• File Size or URL Limits → A single sitemap can only hold up to 50,000 URLs or be 50MB in size. Anything bigger needs to be split into multiple sitemaps.

My Investigation Process

1. Checking Sitemap Format & Structure

The first thing I did was review the sitemap’s XML formatting. Sometimes, missing opening/closing tags or small syntax errors can break a sitemap. After going through it carefully, I confirmed that everything looked correct.

Since this was a large sitemap, I decided to test a smaller version. I stripped it down to just 100 URLs and submitted it — but to my surprise, I still got the same error in Google Search Console.

2. Inspecting HTTP Headers

Next, I checked the HTTP response headers for the sitemap. That’s when I found an issue:

Incorrect header: Content-Type: text/html (expected: application/xml)

Since we usually work on WordPress projects, headers like this are handled automatically. But because this site was built on Laravel, the configuration was incorrect. I fixed it via the .htaccess file so the headers would serve the sitemap correctly.

# Force .xml files to serve as proper XML
AddType application/xml .xml

Even after fixing the headers, GSC was still showing the same error.

3. Validating with an XML Sitemap Checker

To be sure, I ran the sitemap through My Sitemap Generator’s validator.

The validator confirmed the sitemap was valid and correctly formatted. This told me the issue wasn’t with the sitemap file itself.

I also went through a quick checklist:

• ✅ Sitemap returned a 200 status code
• ✅ Sitemap located at the root of the site
• ✅ Sitemap URL added in robots.txt
• ✅ No redirects on the sitemap URL
• ✅ Sitemap not blocked by robots.txt
• ✅ XML parsing was correct

Just to be sure, I submitted the sitemap in Bing Webmaster Tools and Yandex — and both crawled and processed the sitemap successfully. This gave me confidence that the issue was isolated to Google Search Console.

4. Looking for External Insights

While researching, I came across a Google SEO Office Hours (March 5, 2021) where John Mueller mentioned that sometimes simply changing the sitemap filename/URL can reset Google’s processing and “reset their opinion” of the file.

This gave me a clue — maybe the issue wasn’t the content of the sitemap but the way Google was handling the filenames.

5. Discovering the “Sitemap Number Bug”

Digging deeper, I found reports (via Screaming Frog in late 2023/early 2024) of a “sitemap number bug.”

This happens when sitemap filenames use a hyphen followed by multiple digits, for example:

• /sitemap-10.xml
• /sitemap-25.xml

Google’s systems sometimes fail to parse these filenames, leading to “Sitemap could not be read” errors.

Our sitemaps were following a similar pattern.

6. Fixing the Laravel Sitemap Setup

While investigating, I also discovered another issue: the Laravel dev team had configured the system to compile sitemaps in real time. This caused delays whenever Google tried to fetch them.

To fix this, I worked with the devs to:

• Generate static sitemaps instead of on-the-fly ones.
• Set up a nightly sitemap refresh for updated content.
• Rename sitemap files to avoid the hyphen + multiple digits issue.

The result? Blazing fast load times and Google Search Console finally accepted the sitemaps without errors.

Key Takeaway

In my case, the solution was a combination of fixing headers, avoiding the filename bug, and switching to static sitemaps. After making these changes, the “Sitemap could not be read” error was resolved, and indexing improved significantly for this 500K+ page Laravel site.

If you’ve faced a similar issue, I’d love to hear how you solved it — feel free to drop your experience in the comments.