Blogging for guides: what to actually write

A fishing report is almost entirely dates. We fished the twelfth, the water dropped by the fourteenth, the run should start around the first week of October. Google's documentation on dates has a specific warning about pages like that.

It asks you not to specify the date of the action described on the page, states that the dates must describe the publication or update of the page rather than the events described in it, and then adds a line worth reading twice: if incorrect dates are being selected, consider removing some or all of the other dates that appear on the page. Which is a genuine problem for the one thing a guide is uniquely qualified to write. What follows is what to write, and how to date it so the thing you wrote in October is not presented as being from March. Everything alongside this is filed on the getting-booked hub.

What should a guide actually write?

The thing nobody else can, which is what happened on the water.

Every guide site carries the same four articles: what to bring, what to wear, why hire a guide, and the best time to fish.

All four are answerable by anybody with an afternoon, which is why they read identically across a hundred sites.

What cannot be copied is a specific account of specific water on a specific set of days, written by the person who was standing in it.

That material arrives free, weekly, whether you write it down or not, and it is the only genuinely defensible content this trade has.

The catch is that it is also the format most likely to confuse a search engine about when it was written, which is the rest of this page.

Fixing that is mechanical and takes about ten minutes to set up once.

The standard that decides whether such a page deserves to exist at all is discussed in the search fundamentals piece.

Fly Ventures, FL

What is a byline date?

An estimate, and Google says so in the definition.

The documentation defines a byline date as the date that Google estimates the web page was updated or published, and says that when it can determine one, it may expose it in results where that seems useful to the reader.

It then explains the approach: Google does not depend on a single date factor, because all factors can be prone to issues, so its systems look at several to arrive at a best estimate of when a page was published or significantly updated.

Estimate is the operative word, and it is the reason the rest of the guidance exists.

An estimate assembled from several signals can be wrong when the signals disagree, which is exactly the condition a fishing report creates.

None of which is a reason to stop writing them. It is a reason to make the signals agree.

All of that sits in the byline dates page on Search Central.

Why does that matter more here?

Because the reader is deciding whether the information is current.

Somebody reading a fishing report is asking one question, which is whether this describes the water as it is now.

A report showing the wrong date answers that question incorrectly before they read a word.

Worse, a report from last October presented as recent is actively misleading about conditions, which is a credibility problem rather than a search problem.

And the reverse case is just as costly: a current report showing a date from three years ago gets closed immediately.

So the date is not decoration on this kind of page. It is the first thing being read.

Which makes it worth the ten minutes, on a page type most guides publish forty times a season.

Where these posts should sit in the site's structure belongs to the piece on place pages.

What does the guidance ask you to do?

Two things, and the second is the one people skip.

First, add a user-visible date to the page and feature it prominently, labelled with text such as Publish or Last updated.

Its own examples of acceptable labelling include a posted date, a published date, a last updated date, and an updated date carrying a time and a timezone.

Second, specify the date in structured data, recommending a subtype of creative work such as an article, a blog posting or a video object, carrying a published date and a modified date.

Both, not either. The visible date is for the reader and the structured one is for the machine, and the guidance is explicit that they should match.

It says to ensure that the date, and the optional time and timezone, are consistent between the equivalent visible and structured values.

Time and timezone remain optional in the visible version even where they appear in the markup.

The markup itself follows the rules set out in the schema markup piece.

What is the rule a fishing report breaks?

Dating the page by the day the fish were caught.

The guidance instructs you not to specify future dates, or the date of the action described on the page.

It states that the dates must describe the publication or update of the page rather than the stories or events described within it, and points to event markup as the correct way to describe activities listed on a page.

For a guide that means a report written on the twentieth about a trip on the twelfth is dated the twentieth, not the twelfth.

Then comes the harder instruction: minimise the presence of other dates on the page, and if incorrect dates are being selected despite the best practices, consider removing some or all of the other dates that appear.

A fishing report cannot lose its dates, since the dates are the content, so the practical reading is to keep them in prose and out of anything that looks like a byline.

Write the twelfth into a sentence, never into a heading, a caption, a filename or a sidebar.

The photographs attached to those reports have their own constraints, described in the profile photos piece.

Lumberjack, TX

What format do the timestamps use?

An internet standard, and the timezone is the fiddly part.

The example markup in the guidance carries a published value written as a date, the letter T, a time, and an offset from universal time.

That form comes from the internet timestamp standard, whose abstract describes it as defining a date and time format for use in internet protocols, being a profile of the international standard for representing dates and times using the Gregorian calendar.

Its section on the internet date and time format is what every content system is implementing when it writes those values.

The reason to care is the offset. Google asks you to provide the correct timezone, taking daylight saving into account as appropriate.

A site publishing central time offsets that never change across the year is asserting something untrue for roughly half of it.

Most systems handle this correctly, and the ones that do not tend to do it consistently, which makes it easy to spot once.

The standard is published as RFC 3339.

What does the vocabulary call a post?

A blog posting, and it sits four levels down.

The vocabulary defines a blog posting simply as a blog post, and places it beneath a chain running from thing, to creative work, to article, to social media posting.

Its date properties are defined precisely. The published date is the date of first publication or broadcast.

The modified date is the date on which the work was most recently modified, or when the item's entry was modified within a data feed.

Those definitions settle a question guides ask constantly, which is what to do when a report is corrected or extended.

First publication does not move. Most recent modification does.

Changing the published date to make a post look fresh is therefore describing something that did not happen.

The type is documented at schema.org.

What about updating an old post?

Legitimate, common, and it has a correct form.

Guides revisit reports constantly, because a piece about a river in September is worth extending the following September.

The honest version updates the modified date, leaves the published date alone, and says in the visible text what changed and when.

Google's own labelling examples include a last updated form precisely for this case.

The dishonest version rewrites the published date so a three-year-old post presents as new, which describes a publication event that never occurred.

There is also a middle case worth avoiding, which is touching a post to change nothing and updating the date anyway.

If a reader would not notice the difference, the post was not updated.

How that discipline applies across the site is discussed in the on-page basics piece.

What should a report actually contain?

Six things, and only one of them is about fish.

The date it was written, prominent and labelled, at the top.

The water, named the way clients name it, and the stretch of it you were actually on.

The conditions in numbers rather than adjectives, meaning the gage, the tide, the wind and the temperature.

What the fish were doing, honestly, including the days they did nothing.

What that means for somebody booking in the next fortnight, which is the paragraph everybody skips and everybody reads.

And one photograph of the place rather than the catch, since the place is the subject.

Nothing on that list requires a writer, and all of it requires having been there.

The numbers come from the sources described in the local search piece.

How often should any of this happen?

Less than you think, and on a rhythm rather than a whim.

A report a fortnight through the season is ten posts, which is more genuine local content than most guide sites accumulate in five years.

Publishing weekly is achievable in April and abandoned by July, which leaves a blog whose last entry is dated the start of the season.

An abandoned blog is worse than no blog, because the visible date on the most recent post tells a reader exactly how long ago you stopped.

So pick the cadence you can hold in the busiest month and hold it through the quiet ones too.

The off-season is when the evergreen pieces get written, since they need time rather than water.

That split, capture in season and write out of it, is the same one that governs everything else.

The calendar behind it is set out in the content calendar piece.

What are the evergreen pieces worth writing?

Four, and each answers something a client asks by phone.

What a day actually looks like, hour by hour, from the meeting point to the ramp at the end.

What is provided and what is not, in plain terms, because that question arrives on every enquiry and the answer never changes.

What happens when the weather turns, which is the question clients are too polite to ask and most anxious about.

And how the seasons run on your water, month by month, including the months you would advise somebody to go elsewhere.

Those four are evergreen because the answers hold for years, and they are specific because only you know them.

Each replaces a phone call you would otherwise have, which is the return on writing them.

Write them in February, date them honestly, and revisit them once a year.

The client questions behind them are catalogued in the profile questions piece.

Should the writing sound like you?

Yes, and the alternative is the reason most guide blogs fail.

The generic four articles are not just interchangeable in content, they are interchangeable in voice, because nobody wrote them from experience.

A report that says the wind was up and we worked the lee shore for four hours and found three fish reads as a person. A report that says conditions were challenging but persistence paid off reads as nothing.

Voice is not a style exercise here. It is the evidence that somebody was present.

The practical test is whether a sentence could appear on a competitor's site unchanged. If it could, it is doing no work.

Numbers help with this too, because a specific figure cannot be written by somebody who was not there.

None of that requires writing well in a literary sense, only writing plainly about what actually happened.

Guides who worry they cannot write usually mean they cannot write like a brochure, which is the point.

Where do guides go wrong here?

Seven ways, and three of them are dates.

Publishing with no visible date at all, which leaves the reader guessing and the estimate to other signals.

Dating the post by the day of the trip rather than the day of writing, which the guidance names directly.

Rewriting the published date to make old material look current.

Letting the visible date and the structured date disagree, when the guidance asks for consistency between them.

Writing the same four generic articles every other guide site carries.

Starting weekly in April and stopping in July, leaving a dated monument to the moment it got busy.

And describing conditions in adjectives when the numbers are free and published.

Which listings might carry those posts onward is assessed in the directories piece.

What surprises people here?

That the date is treated as an estimate rather than a fact.

Most people assume the date they typed is the date that appears, and the documentation describes a best estimate assembled from several signals.

The second surprise is the explicit instruction to remove other dates from a page when the wrong one keeps being chosen.

The third is that the guidance declines to promise a byline date will be shown at all, while saying that following the practices helps its systems find and process the information.

The fourth is that the timestamp format is an internet standard from 2002 rather than anything to do with search.

The fifth is how much better a report reads when the conditions are numbers, which is a writing improvement rather than a technical one.

Taken together the work is small, one-time, and mostly about telling the truth precisely.

What the same discipline does for the ranking picture is examined in the map pack piece.

How would you audit your blog?

Four checks, an hour, mostly in a browser.

Open your three most recent posts and find the visible date, then check it is labelled rather than floating.

View the source and find the structured published and modified values, then check they match what the page displays.

Look at what else on the page carries a date, including captions, headings, sidebars and image filenames.

Search for one of your posts and see what date Google prints beside it, which is the only test that matters.

Anything that disagrees is the diagnosis, and the fix is almost always in the template rather than the post.

Fix the template once and every future post inherits it, which is the cheapest leverage on the whole site.

The links those posts can genuinely earn are discussed in the backlinks piece.

The writing, in order

Report what happened, date it honestly, hold the rhythm.

Write the thing only you can write, which is a specific account of specific water on specific days.

Put a labelled, visible date at the top, describing when you wrote it rather than when you fished.

Carry the same value in the markup, with a correct offset that respects daylight saving.

Keep every other date in the prose and out of headings, captions and filenames.

Use numbers for conditions, because they are free, published and impossible to fake.

Update the modified date when you genuinely change something, and never touch the published one.

Pick a cadence you can hold in July and hold it in November as well.

And write the evergreen pieces in the off-season, when there is time to make them good.