Water and city pages on your guide site

At five o'clock on the afternoon of 26 July 2026 the Guadalupe River near Spring Branch was running 770 cubic feet per second, with a gage height of 4.13 feet. Anybody can check that, free, without an account.

That is the answer to the problem every water page on every guide site has, which is that it says nothing a stranger could not have guessed. The federal government maintains a public river gage network with an open interface, a public weather service that will tell you which forecast office, grid and radar station cover any coordinate you name, and neither costs anything. A page carrying that is a page about a place. A page carrying three paragraphs about how beautiful the river is in autumn is eight other guides' page with the name swapped. Everything alongside this sits under the getting-booked hub.

Why do these pages usually fail?

Because they are one page written eight times.

The standard build takes a template, swaps a place name, and publishes the result once per water and once per town.

Google's own documentation on titles describes exactly this pattern as a defect, under the heading of boilerplate text that varies by only a single piece of information.

Its indexing documentation describes what then happens: pages with similar content are clustered, one is selected as canonical, and the rest become alternate versions.

So eight templated pages are not eight chances. They are one page and seven shadows.

The fix is not more words. It is different words, and the only reliable source of different words is different facts.

Which is where a place that publishes data about itself becomes genuinely useful.

The title-level version of this problem is worked through in the on-page basics piece.

Hook 1 Charters, FL

What does the URL have to do?

Be readable, and be crawlable, which are separate requirements.

Google states that if URLs do not meet its criteria, Search will likely crawl the site inefficiently, including but not limited to extremely high crawl rates, or not at all.

The requirements it lists are that URLs follow the internet standard for addresses, with reserved characters percent encoded, and that fragments are not used to change page content, since Search generally does not support them.

Its best practices ask for descriptive URLs using readable words rather than long identifiers, in the language your audience searches in.

For a guide that means a path naming the water in the words people use, not a numeric page identifier and not an abbreviation only locals would recognise.

It also asks you to use as few parameters as possible, trimming any that do not change the content.

A water page needs no parameters at all, which makes this the easiest requirement on the list to meet.

The documentation is published as Google's URL structure best practices.

Hyphens or underscores?

Hyphens, and the reasoning is specific.

Google recommends separating words in URLs and specifically recommends hyphens rather than underscores, on the ground that hyphens help users and search engines better identify concepts in the URL.

Its stated reason for avoiding underscores is historical: that style is already commonly used to denote concepts that should be kept together, giving the example of programming languages naming functions.

It separately advises against joining words together with no separator at all.

None of that is a large effect, and all of it is free at the moment you choose the path.

What is expensive is changing paths later, which is a redirect exercise rather than an edit.

So the time to decide is before the first water page exists, not after there are nine.

The keyword work that decides the words in those paths is in the keyword list piece.

What creates pages you never meant to make?

Four named patterns, and two can appear on a small site.

Google lists additive filtering, where combinable filters explode the number of views of the same set, using a hotel search that can be narrowed by beach and then by fitness centre.

It lists irrelevant parameters, naming referral parameters, sorting parameters and session identifiers, and advises using cookies rather than session identifiers in addresses.

It lists calendar issues, where a dynamically generated calendar links onward to future and previous dates without limit, and suggests marking those links so they are not followed.

And it lists broken relative links, where a parent-relative link on the wrong page can generate bogus addresses indefinitely if the server does not return the right status for pages that do not exist, with root-relative links given as the fix.

A guide site with a booking calendar and a trip-filter widget can produce two of those four without anybody noticing.

Google's own remedy is to consider blocking such addresses in the robots file, which is one of the few legitimate uses of it.

What that file can and cannot do is set out in the search basics piece.

Nervous Water, TX

What can a water page carry that nothing else does?

The river's own numbers, updated without you.

The United States Geological Survey runs a public water data service that returns readings for a named gage station in a machine-readable form, with no account and no key.

Asked on 26 July 2026 for site 08167500, the Guadalupe River near Spring Branch in Texas, it returned two series: streamflow in cubic feet per second, and gage height in feet.

The most recent readings at that moment were 770 cubic feet per second and a gage height of 4.13 feet, both timestamped to five o'clock that afternoon, central time.

That is a fact about one river at one moment, and no competitor's template contains it.

It also gives the page a reason to be looked at again, which a description of the scenery does not.

The service is documented at the USGS instantaneous values reference, and that station has its own page at USGS water data.

What else is published for a place?

Its forecast office, its grid, its zone and its radar.

The National Weather Service publishes an interface that turns a coordinate into the administrative facts about that point.

Asked on 26 July 2026 for a point off Galveston, Texas, it returned the forecast office identifier HGX, a grid reference of 85 and 74, a forecast zone of TXZ438, a county zone of TXC167, a time zone of America Chicago and a radar station of KHGX.

Every one of those is a durable identifier for that stretch of coast, and each is different for the next stretch along.

A page that names the forecast zone its water sits in, and the radar a client should be watching the morning of the trip, is being useful in a way no adjective manages.

It is also, incidentally, the kind of detail that reads as local knowledge, because it is.

The interface is published at the National Weather Service points service.

How does that solve the duplication problem?

By making the pages different in fact rather than in wording.

Two pages built from one template and reworded remain the same page dressed twice, and rewording is exactly what the clustering step is designed to see through.

Two pages carrying different gage stations, different forecast zones, different radar coverage and different access points are different documents by construction.

That is a structural fix rather than a writing trick, which is why it survives whatever the algorithms do next.

It also has an honest justification, which is that those facts are the ones a client planning a trip would actually want.

Nobody books a day because a paragraph called the water pristine. People book because they can picture the day.

Numbers, place identifiers and access details help somebody picture it. Adjectives do not.

The structured data that can describe those places to a machine is covered in the schema markup piece.

What does a city page carry instead?

Logistics, not scenery.

A town page is read by somebody working out whether a trip from that town is practical, which is a different question from what the fishing is like.

So it carries the ramps or marinas you launch from, with names rather than descriptions.

It carries the meeting point, the hour, and how long the run is from there to the water you would fish that month.

It carries the honest note about which months from that town are worth it and which are better from somewhere else, which almost no page does and which every reader wants.

It carries parking, because parking at six in the morning is a real question with a real answer.

And it links to the water pages rather than repeating them, which keeps each page about one thing.

How the profile handles the same geography is described in the profile setup piece.

How many should you build?

One per place you genuinely work, and no more.

The temptation is a page for every town within two hours, on the theory that each one catches its own searches.

The constraint is that a page you cannot fill with specific facts is a page that will cluster with the others and add nothing.

So the test is simple: can you name the ramp, the run time, the gage and the months, from memory, without inventing anything.

If you can, the page is worth building. If you cannot, you do not work there often enough to have a page about it.

Three or four genuinely detailed places beat twelve thin ones, and the thin ones actively dilute the set.

This is the same discipline as the profile's service area, and for the same reason.

Which searches those pages are competing for is examined in the local search piece.

What about the water you rarely fish?

Leave it off, and say why on the page you do have.

Every operation has a second or third water it runs a handful of trips on each year, usually when the main one is unfishable.

The instinct is to give it a page, on the theory that some coverage beats none.

The better move is a paragraph on the page you already have, saying plainly that when the river blows out you move to the other water, and what changes when you do.

That paragraph is specific, honest and impossible to template, which is more than a thin standalone page achieves.

It also answers a question clients genuinely ask, which is what happens if conditions ruin the day they booked.

If the second water later becomes a real part of the season, it earns its own page then, built from facts you now have.

Pages should follow the operation rather than the ambition, which is a rule that saves a great deal of writing.

How often should the numbers update?

Automatically, or not at all, and never by hand.

A gage reading typed into a page by hand is accurate for an afternoon and misleading for the following year.

Either the page pulls the figure from the service each time it loads, or it names the station and links to it and lets the reader look.

The second option costs nothing to build, never goes stale, and is honest about what it is doing.

The first is better if somebody is maintaining the site anyway, and worse if nobody is.

What must be avoided is the middle version, which is a number that was true once and now sits there uncontradicted.

The same applies to season dates, which change by rulemaking, and to prices, which change by decision.

A page that dates its own facts survives neglect. A page that asserts them without dates does not.

What does a good water page look like end to end?

Five blocks, and only one of them is prose.

A short opening saying what the water is and who it suits, in the words a client would use rather than the ones a brochure would.

The gage block: the station name, its number, and a link, so anybody can see what the river is doing today.

The weather block: the forecast zone and radar station covering it, which is the thing to watch the night before.

The access block: the ramps or put-ins by name, with the one you actually use marked.

The season block: month by month, plainly, including the months that are poor, because the months you leave out are the ones that produce disappointed clients.

Then a link to the trip you would actually run there, and nothing else.

Everything not on that list is scenery, and scenery is what makes the page identical to everybody else's.

The wider writing standard those blocks sit inside is described in the blogging piece.

Where do guide sites go wrong here?

Seven ways, and the first is the whole strategy.

Publishing a page per town from one template with the name swapped, which the documentation describes as a defect and the indexing step collapses.

Filling the pages with scenery rather than logistics, so nothing on them could only be true of that place.

Using underscores or run-together words in the path, against explicit guidance.

Letting a booking calendar or a filter widget generate addresses nobody meant to publish.

Building pages for towns the operation does not actually launch from.

Copying a competitor's structure, which reproduces their duplication as well as their layout.

And publishing a gage number once, by hand, and leaving it there until it is wrong.

What genuinely earns a link to these pages is examined in the backlinks piece.

What do operators not expect?

That the useful data is free and nobody uses it.

Both services described here are public, keyless and stable, and almost no guide site in the country carries either.

The second surprise is that a page with numbers on it reads as more expert than a page with adjectives, which reverses how most site copy is written.

The third is that fewer pages usually outperform more, because the thin ones are not neutral.

The fourth is that path choices are effectively permanent, since changing them later is a redirect project.

The fifth is that the same facts make the page genuinely more useful to a human, so the search benefit and the client benefit point the same way.

That alignment is rare enough to be worth exploiting whenever it appears.

The seasonal material those pages should reflect is planned in the content calendar piece.

How would you audit what you have?

Four checks, an afternoon, no software.

Open two of your location pages side by side and delete every sentence true of both, then look at what survives.

If less than half the page survives, the page is a template rather than a document.

Check every path for underscores, capitals and run-together words, and note that fixing them later needs redirects.

Look at whether your site generates addresses from a calendar or a filter, and if so whether anything stops them multiplying.

Then look up the gage station and forecast zone for each water you name, which takes about five minutes each, and see how much of the page they could replace.

Most operations find the replacement is an improvement in both directions.

How the same places should be named on social is covered in the tags and place names piece.

The pages, in order

Fewer, specific, numbered, and cleanly addressed.

Build one page per place you genuinely work, and refuse the rest.

Give each a lowercase, hyphenated path naming the place in the words clients use, and decide it once.

Carry the gage station for each water and the forecast zone and radar for each stretch of coast.

Carry ramps, meeting points, run times, parking and the honest seasonal note, all of which are logistics rather than scenery.

Delete every sentence that would be equally true of the next water along.

Stop any calendar or filter from generating addresses, and use the robots file for that rather than for privacy.

Link town pages to water pages instead of repeating them, so each page is about one thing.

Then leave the paths alone, because changing them is a project rather than an edit.

How all of it feeds the map results is examined in the map pack piece.