That distinction matters for three audiences:

- Developers: They want to know why they should choose NLog, how quickly they can get started, and how it fits into their existing application.

- Experienced .NET developers: They want to see structured logging, configuration, ASP.NET Core integration, performance, extensibility, and production capabilities.

- AI assistants and coding agents: They need clear package relationships, correct installation instructions, recognizable integration scenarios, and working examples they can confidently recommend and generate code for.

I would also address your observation about appsettings.json immediately. Its absence is quite noticeable in a modern .NET README.

There is one important architectural distinction: NLog itself is the core logging package, while NLog.Extensions.Logging provides the Microsoft.Extensions.Logging integration and the associated .NET configuration integration. We should explain that distinction without making users feel that they need to understand the entire NLog ecosystem before getting started.
What I would improve
1. Sell the capabilities, not just the package

The opening sentence is technically correct but undersells NLog.

I would introduce the main capabilities immediately:

- Structured logging with message templates and event properties.
- Flexible routing to multiple destinations (targets).
- Powerful formatting and enrichment (layouts and layout renderers).
- XML, JSON/appsettings.json, and fluent programmatic configuration.
- Asynchronous and buffered logging.
- Extensive extensibility through first-party and community extensions.
- Integration with Microsoft.Extensions.Logging and ASP.NET Core.

These are actual reasons to choose NLog, rather than merely describing what a logging library does.

The official NLog website already communicates several of these capabilities, so the NuGet README should reinforce that message.

2. Make appsettings.json a first-class citizen

I would explicitly mention three configuration approaches:

Configuration
- NLog Fluent API / code
- NLog NLog.config (XML)
- NLog appsettings.json
	
NLog.Extensions.Logging or NLog.Web.AspNetCore

This is important because developers increasingly expect configuration through the standard .NET configuration system.

In particular, NLog supports:

- The NLog section in appsettings.json.
- Environment-specific configuration overrides.
- Environment variables.
- ${configsetting} for accessing application configuration values.

There is an important nuance: NLog 5 and newer can automatically discover the NLog configuration section when integrated through AddNLog() or UseNLog(). 
NLog/NLog.Extensions.Logging GitHub Wiki
+2
3. Make the integration story clearer

The current integrations section is too small for the importance of the .NET ecosystem.

I would distinguish:

- NLog – standalone logging API, targets, layouts, configuration and logging engine.
- NLog.Extensions.Logging – Microsoft ILogger integration and appsettings.json configuration.
- NLog.Extensions.Hosting – Generic Host integration.
- NLog.Web.AspNetCore – ASP.NET Core integration, including web-specific functionality.

This also helps prevent a common misconception: that NLog requires Microsoft.Extensions.Logging.

It doesn't. The core NLog package works perfectly well independently. 

4. Show what makes NLog powerful

The current example demonstrates logging one message to the console.

That's a good first example, but it doesn't communicate the real strengths of NLog.

I'd add a short feature-oriented section explaining:

- One log event can be routed to multiple targets.
- Log levels and filtering rules can be configured independently.
- Log events retain structured properties.
- Layouts allow the same event to be rendered differently for different destinations.
- Targets can be extended with additional packages.
- Logging can be asynchronous and buffered.

The important thing is not to turn the README into a manual. One or two sentences per capability are enough.

5. Improve discoverability for AI coding agents

This is becoming increasingly important.

An AI assistant often needs to answer questions such as:

- Which NuGet package should I install?
- Can I use NLog without Microsoft.Extensions.Logging?
- How do I configure NLog using appsettings.json?
- How do I configure file logging?
- How do I use NLog with ASP.NET Core?
- How do I write structured log messages?
- Where do I find available targets?

The README should answer these questions explicitly, using the exact package names and recognizable API names.

I'd also make the distinction between core NLog and the integration packages unmistakable. This reduces the risk of AI-generated code recommending unnecessary packages or using APIs from the wrong package.

One additional thought: don't optimize exclusively for AI. A well-structured README with accurate package relationships, copyable examples and clear terminology is also exactly what human developers need.
My suggested revised README.md

I would aim for something like the following. It stays relatively compact, but communicates considerably more value.

NLog is a flexible, high-performance logging platform for .NET.

Create, capture, enrich, format, filter, and route log events to multiple destinations with powerful structured logging and flexible configuration.

NLog works with standalone .NET applications as well as the Microsoft.Extensions.Logging ecosystem, including ASP.NET Core. Start with console and file logging, then extend your logging infrastructure with hundreds of available targets, layouts, and extensions.
Why NLog?

- Structured logging – Capture message-template properties, event properties, and contextual information.
- Flexible routing – Send log events to multiple destinations with configurable rules and filters.
- Powerful formatting – Customize log output using layouts and layout renderers, including JSON and other structured formats.
- Multiple configuration options – Configure logging using fluent APIs, XML configuration (NLog.config), or JSON configuration (appsettings.json).
- Extensible architecture – Add logging destinations, layout renderers, filters, and other functionality through extension packages.
- Asynchronous logging – Improve application responsiveness with asynchronous and buffered targets.
- .NET ecosystem integration – Integrate with Microsoft.Extensions.Logging, dependency injection, Generic Host, and ASP.NET Core.

Getting started

Install NLog in your application:

dotnet add package NLog

Configure console logging using the fluent configuration API:
csharp

using NLog;

var logger = LogManager.Setup()
    .LoadConfiguration(builder => builder.ForLogger().WriteToConsole())
    .GetCurrentClassLogger();

try
{
    logger.Info("Hello, {Name}!", "World");
}
finally
{
    LogManager.Shutdown();
}

NLog supports both structured logging and traditional logging. Message-template properties are captured as structured event properties and can be used when formatting or routing log events.
Configuration

NLog offers several ways to configure logging depending on your application's architecture and preferences.
Fluent configuration

Configure targets, logging rules, and layouts directly in C# using the fluent configuration API.

See Fluent Configuration API.
XML configuration

Use an NLog.config file to define logging targets, rules, and layouts separately from application code.

See Configuration File.
JSON configuration (appsettings.json)

For applications using Microsoft.Extensions.Logging, NLog can load its logging configuration from the NLog section in appsettings.json.

Install the integration package:

dotnet add package [NLog.Extensions.Logging](https://www.nuget.org/packages/NLog.Extensions.Logging)

NLog supports environment-specific configuration, environment variable overrides, and accessing application configuration values through the ${configsetting} layout renderer.

See NLog configuration with appsettings.json.

Integrations

NLog works independently or integrates with the wider .NET ecosystem.

- Microsoft.Extensions.Logging: NLog.Extensions.Logging – Use NLog as a provider for Microsoft's ILogger abstraction, with structured logging, scopes, and appsettings.json configuration.
- .NET Generic Host: [NLog.Extensions.Hosting](https://www.nuget.org/packages/NLog.Extensions.Hosting) – Integrate NLog with the .NET Generic Host.
- ASP.NET Core: [NLog.Web.AspNetCore](https://www.nuget.org/packages/NLog.Web.AspNetCore) – Integrate NLog with ASP.NET Core applications, including web-specific logging capabilities.

Targets and extensions

NLog includes built-in console and file targets. Additional logging destinations are available through extension packages.

Explore available [NLog Targets, Layouts, and Extensions](https://nlog-project.org/config/?tab=targets).
Documentation and support

- [Getting started tutorials](https://github.com/NLog/NLog/wiki/Tutorial)
- [Structured logging](https://github.com/NLog/NLog/wiki/How-to-use-structured-logging)
- [Configuration options](https://nlog-project.org/config/)
- [API reference](https://nlog-project.org/documentation/)
- [Troubleshooting](https://github.com/NLog/NLog/wiki/Logging-troubleshooting)
- [Release notes](https://github.com/NLog/NLog/releases)
- [Report an issue](https://github.com/NLog/NLog/issues)

Community and contributions

NLog is an open-source project maintained by contributors and supported by its community.

Contributions, bug reports, feature requests, and feedback are welcome! See Contributing to NLog.

NLog is licensed under the [BSD 3-Clause license](https://github.com/NLog/NLog/blob/main/LICENSE.txt).
A few additional recommendations before merging

There are some things I would specifically discuss with the other maintainer.

1. Consider an appsettings.json example in addition to the link.

This is probably the biggest opportunity. Even a small JSON example would make the README more discoverable and useful to developers and AI agents.

2. Don't overload the README with every feature.

NLog has an enormous ecosystem. The README should communicate the breadth of capabilities, while the configuration website should explain the individual targets, layouts, and extensions.

3. Consider mentioning AOT compatibility.

NLog 6 introduced Native AOT support. This is a valuable modern .NET capability worth mentioning, provided the README links to the relevant compatibility documentation. 
GitHub

4. Keep the README synchronized with the actual NuGet package.

This is particularly important for the package installation commands, supported frameworks, and API examples. A README that generates outdated AI answers is worse than a shorter README.

5. Think about the relationship between the READMEs.

I would establish a consistent style across:

- NLog

- NLog.Extensions.Logging

- NLog.Extensions.Hosting

- NLog.Web.AspNetCore

Each package should explain its own responsibility, while linking to the others. Avoid repeating the entire NLog introduction in every package.

My overall recommendation

I would actually make one strategic change to how NLog presents itself:

Stop positioning NLog primarily as a logging library. Position it as a logging platform.

The distinction is meaningful. NLog isn't just an API for writing messages to files. It is an extensible logging engine with structured events, routing, filtering, enrichment, formatting, configuration, integrations, and a broad ecosystem of destinations.

That's the value proposition that should come through when a developer, an architect, or an AI assistant encounters NLog for the first time.

And one final thought: NuGet README files are increasingly becoming the first documentation an AI coding assistant encounters when deciding which package to recommend. I would treat every NLog package README as both a human-facing introduction and a concise, accurate source of technical knowledge for AI.